-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service and Revision labels #342
Service and Revision labels #342
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aaron-lerner: 1 warning.
In response to this:
Partially addresses #328
Proposed Changes
- Adds a --label flag to set service-level labels
Release Note
Add --label (alias -l) on `kn service create` and `kn service update` commands to set service-level labels.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Hi @aaron-lerner. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking promising, just a few small suggestions.
overall looks good. Did you want to support unsetting a label too? |
Added support for unsetting by passing an empty value, ie |
Does the |
I'm also wondering whether how we could allow setting labels on services, but also on the pod templates. I think both might be useful, and I wonder how the UX for this would look like.
Or should |
Nope, doesn't seem so. So my last question still holds: Apply the label to service itself or the contained the revision template ? I would argue for the latter or both |
BTW, you see how a revision get the labels from the template, not the sevice itself here: https://github.com/knative/serving/blob/c6860bf7c0663ddbf71d8fa3b48cbfbd9b54c205/pkg/reconciler/configuration/resources/revision.go#L30-L33 |
Changed the unset behavior to match kubectl. So pass the name/key of the environment variable followed by With this, you can now set a label with an empty string and the already existing behavior of setting an environment variable with no value still works. |
👍
I would treat both variants as the same, no need to make
👍 as this is similar to the the kubectl behaviour.
This is an invalid env var name, an env var can't end with a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a lot, very nice PR, love it :)
'happy to update the env handling in one sweep here, too.
See some comments inline, the biggest thing that we still have to decide which label to update (i opt for both locations).
// UpdateServiceLabels updates the labels on a service | ||
func UpdateServiceLabels(service *servingv1alpha1.Service, vars map[string]string) error { | ||
if service.ObjectMeta.Labels == nil { | ||
service.ObjectMeta.Labels = make(map[string]string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems at that point there might as well be separate
--revision-label
,--service-label
, and--label
flags. It would be much more explicit both in the documentation and I think code that way. Plus, special characters change (slightly) across different shell environments and if this list is any indication, it may not be worth the time and effort to find and confirm which characters are valid in a reasonable number of shell environments.
This is always a tradeoff between options bloat and being too obfuscated. Currently, there is a tendency to add 1-5 new options per new features, and I'm doing my best to fight against the bloat. At least asking, whether there could be a compromise and whether all those options are needed (e.g. see #345 (comment) or #326 (review) or #282 (review) how to reduce the UX surface and so the cognitive load).
Of course, we should no go over the top, and using special chars like that might be the case here (although ^
and :
are safe shell chars so no need to escape).
What's about that compromise: Let's implement --label
to label both, service and template and wait on feedback if the other use cases (individual labelling of serving/template) are actually requested ?
From a single feature's PR POV adding 3 new options might not be a big deal, but its the sum which might lead to multi page help outputs which are really overwhelming (especially when alphabetically ordered, and --revision-label, --sevice-label and --label will apear on totally different positions in a list of 50+ options)
+1 for support these operations.
We should treat this same as |
I assumed the lack of validation client-side on names and values meant this was being done server-side. However, I am allowed to set an environment variable with a name ending in |
I just meant that |
Updated to have env and label keys passed without values map to empty values rather than throw an error. Additionally, keys that indicate deletion ( |
/retest |
The following is the coverage report on pkg/.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aaron-lerner, maximilien, sixolet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
* Fix backup Makefile and auth Apparently "works on my machine" isn't enough. 1. The Makefile was broken, use the current directory for the build context. 2. Activate the service account (not necessary for gcrane, but necessary for gsutil). * Get service account key from env * For backup image, pass keyfile as first argument
Fixes #328
Proposed Changes
Release Note