Allow automatic client-side revision name generation

[sixolet]

In what area(s)?

Workflow and client conventions

Describe the feature:

Previously, in the client-conventions.md (still in serving, still meaning to port it over here), we suggested adding a nonce to force creation of a new revision and to make that new revision findable once you'd created it.

Now that v1beta1 style (even in v1alpha1) allows for bring-your-own-revision-name, it's much more natural to autogenerate a name for the revision on the client side. We should support random name generation on the client side, and have it on by default, so that the revisions are findable, at least, and so that when you deploy an image by a tag that's changed it forces creation of a new revision.

[rhuss]

Beside random name generation would we want also support incremental numeric revision name suffixes? (svc-1, svc-2, ..). This would have the benefit of add semantics as you can compare the age of two revisions just by looking at its name.

[sixolet]

Beside random name generation would we want also support incremental numeric revision name suffixes? (svc-1, svc-2, ..). This would have the benefit of add semantics as you can compare the age of two revisions just by looking at its name.

Hmm. Maybe! Though I worry about people reading too much into it, and relying on a behavior that isn't reliable.

[cppforlife]

@sixolet

we suggested adding a nonce to force creation of a new revision

from what i remember we used nonce to be able to find correct revision thats created (useful when doing things programmatically); however, the downside of that is that revision keeps on being recreated afaik.

what is the use case for this feature from a user perspective?

[sixolet]

what is the use case for this feature from a user perspective?

These are arguable as to whether they're technical or user cases but:

• It allows us to find the revision, enabling the "don't change the code" use case Don't change running code when not changing --image #280
• It allows redeploying the same --image tag and explicitly changing the code by forcing a new revision which causes a new tag pull.

"Revision keeps on being recreated" — you don't change the name when you don't intend to make a new revision.

When people specify arguments other than an image by tag that do not change, we can decide not to create a new revision, if we want, as long as we tell people what happened.

[duglin]

I'm not following. How does a random name generated by the client make it easy for the user to find? I feel like I'm missing the use case here that isn't satisfied by just erase the name. I'm not necessarily against having the client generate the name instead of the server, but I'd like to understand why people think it's necessary or help in some cases.

[sixolet]

"What is the revision associated with the current template", in a way that's not succeptible to race conditions like using latest created revision name

…

On Jul 22, 2019, at 2:36 PM, Doug Davis ***@***.***> wrote: I'm not following. How does a random name generated by the client make it easy for the user to find? I feel like I'm missing the use case here that isn't satisfied by just erase the name. I'm not necessarily against having the client generate the name instead of the server, but I'd like to understand why people think it's necessary or help in some cases. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[duglin]

ah, and we (the cli) needs that just so it knows when it can tell the user the the revision is ready?

[sixolet]

The revision ready case isn't really the main one — that you can tell by service being ready. The important thing is that the user's running code never changes unless they ask it to, and you need to find the right revision for that.

The fact that docker tags are mutable is such a pain :(

[duglin]

Sorry to keep poking on this, but I want to make sure I grok the usecase.
I get the notion of not changing the digest for non-code changes. But, I'm not clear on why the CLI needs the revisionName for that - or why the CLI is involved at all, aside from it's the one initiating the request to change something like an env var. Maybe it would help if you could show the steps involved here.

[sixolet]

Totally.

• User decides to set env var FOO=bar w/o changing running code
• Client fetches current service
• Client fetches the revision represented by the current template on current service (found by name query. If name query is not possible, this can fall back to latestCreatedRevisionName and then an equality check on the image field, but that's messy)
• Client modifies its copy of the current service to have the template include the new env var and the image by digest based on the Status.ImageDigest of the base revision.
• Client updates the service.
• Profit

[duglin]

I guess I don't understand why it's not just:

• kubectl get ksvc/myapp -o yaml > app.yaml
• vi app.yaml (add env vars)
• kubectl apply -f app.yaml

Client fetches the revision represented by the current template on current service (found by name query. If name query is not possible, this can fall back to latestCreatedRevisionName and then an equality check on the image field, but that's messy)

Why do they fetch the revision at all? They're just modifying the KnService aren't they? So wouldn't the current KnService's template match the latest revision's?

Client modifies its copy of the current service to have the template include the new env var and the image by digest based on the Status.ImageDigest of the base revision.

Right, just edit the KnService they got from the first step. Why is the revision involved at all?

[sixolet]

Status.ImageDigest is on the revision not the service.

…

On Jul 22, 2019, at 5:11 PM, Doug Davis ***@***.***> wrote: I guess I don't understand why it's not just: kubectl get ksvc/myapp -o yaml > app.yaml vi app.yaml (add env vars) kubectl apply -f app.yaml Client fetches the revision represented by the current template on current service (found by name query. If name query is not possible, this can fall back to latestCreatedRevisionName and then an equality check on the image field, but that's messy) Why do they fetch the revision at all? They're just modifying the KnService aren't they? So wouldn't the current KnService's template match the latest revision's? Client modifies its copy of the current service to have the template include the new env var and the image by digest based on the Status.ImageDigest of the base revision. Right, just edit the KnService they got from the first step. Why is the revision involved at all? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.