Consider keeping serving->CI/CD control

[knative]

Consider keeping serving->CI/CD control

[sixolet]

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.

[sixolet]

Highlight to summon @mattmoor @duglin @cppforlife @evankanderson

[evankanderson]

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.

[mattmoor]

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:

1. No TypeMeta, so what are the extensibility implications?
2. No TypeMeta, so how this is implemented is unclear (would we practically have an internal dependency on Tekton?)
3. 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?

[sixolet]

Sorry, the lack of type meta is an elision for clarity that turned into an elision for obscurity. It should be there. I'll add when I get back to a real computer.

…

On Mar 7, 2019, at 6:10 PM, Matt Moore ***@***.***> wrote: 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? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sixolet]

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.

[sixolet]

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.