Comments (7)
And finally, before I leave my computer for the night, Knative could maintain some stock Tekton Task implementations that do a few pleasant classic styles of rollout, so you can get your custom pipelines up and running with a few good choices quickly.
from client.
Highlight to summon @mattmoor @duglin @cppforlife @evankanderson
from client.
I have thoughts here, but I also have a lot of peer feedback to write for Google performance reviews, so I'll have better thoughts on Wednesday or Thursday.
from client.
So the way we inline builds today includes TypeMeta for extensibility:
apiVersion: serving.knative.dev/v1alpha1
kind: Configuration
metadata:
name: foo
spec:
build:
# We support Pipelines / Task here today, as well as random
# other stuff (e.g. I have a test Build we test in e2e for extensibility)
apiVersion: build.knative.dev/v1alpha1
kind: Build
spec:
...
revisionTemplate:
spec:
container:
imate: mattmoor/foo:bar
Creates Revisions with:
apiVersion: serving.knative.dev/v1alpha1
kind: Configuration
metadata:
name: foo
spec:
buildRef:
apiVersion: build.knative.dev/v1alpha1
kind: Build
name: ...
container:
imate: mattmoor/foo:bar
Where we expect the resource embedded into Configuration as spec.build
that we reference from Revision as spec.buildRef
to culminate in a Succeeded: True
condition. Given this, I think I'd be inclined to position this as setup[Ref]:
instead of build[Ref]:
(if we were to keep them) since there's nothing about this contract that necessitates that this be used to produce the image.
However, drilling into your proposal a bit, it sounds like there are a couple key departures from this which raise questions:
- No TypeMeta, so what are the extensibility implications?
- No TypeMeta, so how this is implemented is unclear (would we practically have an internal dependency on Tekton?)
- There are a number of pieces you list that are implicit (e.g. image output, svc ref), which imply that we have a strong enough sense for the schema that we can make alterations.
The cluster has gcr.io/stuff configured as the image repo for this namespace, so the image is going to be by default gcr.io/stuff/thingservice:lolcommithash.
Configured how?
The pipeline build-it-and-roll-it-out-slowly is invoked with the source input, the image output, and a reference to this Service
I'm curious about the "invoked" part. Is this a hard dependency on Tekton? I'm curious how that's appreciably different from us simply invoking a Pipeline that does stuff?
which will build the relevant image and then roll it out slowly on this service (or even several others!).
I believe this means that the instantiated Pipeline will have an ObjectReference to the Service, and post back to it to start and progress a particular rollout? What happens if while this is running I post another new commit? Do the two Pipelines race?
from client.
from client.
The cluster has gcr.io/stuff configured as the image repo for this namespace, so the image is going to be by default gcr.io/stuff/thingservice:lolcommithash.
Configured how?
I was imagining setting namespace-scoped or cluster-scoped defaults for "where do you go and agree to put images?" in a configuration, mostly so you can get good defaulting.
I'm curious about the "invoked" part. Is this a hard dependency on Tekton? I'm curious how that's appreciably different from us simply invoking a Pipeline that does stuff?
It's pretty similar to what we have now, but this introduces two ideas:
- The Service is the input to a Pipeline or other CI/CD system
- The Pipeline or other CD system can take the place of the Service controller for orchestrating traffic rollout, by controlling the Route.
which will build the relevant image and then roll it out slowly on this service (or even several others!).
Soft dependency on Tekton, or a system like it. A dependency on the interface, and the ability to go instantiate a FooRun object of the relevant type. A thing I'm a bit unsure of: how you get from the reference to Pipeline to know you have to instantiate PipelineRun, etc.
I believe this means that the instantiated Pipeline will have an ObjectReference to the Service, and post back to it to start and progress a particular rollout? What happens if while this is running I post another new commit? Do the two Pipelines race?
This is like any case where you go and invoke two PipelineRuns that are competing over the same resources. At least when you have the Service to reference back to, you know what the user intended the end state to be, unlike trying to invoke the Pipelines directly.
from client.
One more thought that occurs to me: Another possible valuable arrangement is one where a POST or PUT or PATCH of a changed Service object doesn't directly reference a Pipeline, but the Pipeline is triggered by the POST PUT or PATCH just like it would be if you made a git commit that caused an event to trigger a PipelineRun. In that scenario it'd be some kind of event binding beastie that would be in charge of associating the Pipeline with the Service, but you'd get a lot of the same benefits.
This assumes you can still reference source in the Serving API, even if you're not referencing a Pipeline— and that's a really weird thing to do if the default controller isn't going to touch it.
You'd need a different way than "specify a pipeline in the Service" to indicate that "there is a Pipeline in charge of managing rollout here", though.
from client.
Related Issues (20)
- Update plugin development docs HOT 5
- Can not get my broker through `kn broker list` HOT 6
- [48h Knative] KServe plugin HOT 4
- Align GVK format accepted by `--channel` flag HOT 12
- Flaky E2E test: e2e/TestDomain - create domain with TLS HOT 9
- Wrong version for kn create kafka channel HOT 7
- Add integration tests for all command usage examples in the binary HOT 6
- [48h Knative] Annotation and Label profiles HOT 1
- [48h Knative] Color output HOT 3
- [48h Knative] UX Evaluation HOT 10
- [48h Knative] Kamelet Sinks HOT 2
- [48h Knative] Command Usage Example Integration Testing POC HOT 4
- [48h Knative] Improved Logging HOT 7
- [48h Knative] Good first issues HOT 3
- Cmd `kn service wait` doesn't end on ready ksvc as expected
- CLI: `--user` option does not work as expected
- Add missing completion support for fish and PowerShell shells
- Error: fork/exec /usr/local/bin/kn-func: exec format error HOT 1
- Proposal: Fold back in client-pkg to Go submodule HOT 11
- kn service export doesn't work with traffic splits HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from client.