-
Notifications
You must be signed in to change notification settings - Fork 264
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
Add option for adding labels only to service and/or template #703
Conversation
In this PR we are introducing 2 additional flags for setting label for service(label-service) and revision(label-revision) only. Signed-off-by: Andrew Su <[email protected]>
Signed-off-by: Andrew Su <[email protected]>
Signed-off-by: Andrew Su <[email protected]>
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.
@shashwathi: 0 warnings.
In response to this:
Description
Added command line flags
label-service
andlabel-revision
to add labels more granularly for service and revision template objects.Fixes #675
/lint
cc @andrew-su
/assign @rhuss
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.
/test pull-knative-client-integration-tests-latest-release |
/test pull-knative-client-integration-tests |
@shashwathi thanks a lot for the PR ! The test is failing because the test cluster is already on the latest Knative eventing with some breaking changes. We need the latest update to be merged in to get this PR in. Please stay tuned. |
/retest |
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, looks good in general !
I have some comments, how the implementation could be optimised for better readability and maintainability.
As I would like to get in this PR for 0.13.0 I suggest that we merge this right now and we can improve then on it even post 0.13.0. Only for the suggested API change I would submit and additional PR right now so that it get into 0.13.0 (as the API is exposed as part of the release, too).
In another PR I would also love to see some more tests:
- Unit tests for testing the overriding rules
- Unit tests also for the command line option
- E2E tests for the various labelling cases.
@shashwathi Wdyt ?
serviceMap.Merge(labelsAllMap) | ||
revisionMap.Merge(labelsAllMap) | ||
|
||
labelServiceMap, err := util.MapFromArrayAllowingSingles(p.LabelService, "=") |
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.
we could put the duplicate code into a single method called twice. This time we can guarantee that the specific labels are treated the same.
@@ -47,6 +47,8 @@ type ConfigurationEditFlags struct { | |||
AutoscaleWindow string | |||
Port int32 | |||
Labels []string | |||
LabelService []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.
would calls it "LabelsService" (plural, like for Labels
)
@@ -47,6 +47,8 @@ type ConfigurationEditFlags struct { | |||
AutoscaleWindow string | |||
Port int32 | |||
Labels []string | |||
LabelService []string | |||
LabelRevision []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.
dito
pkg/serving/config_changes.go
Outdated
var ServiceOnlyLabels = map[string]struct{}{ | ||
serving.GroupName + "/visibility": {}, | ||
} | ||
// // ServiceOnlyLabels should only appear on the Service and NOT on the |
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.
Please remove it not needed anymore.
pkg/serving/config_changes.go
Outdated
|
||
// UpdateLabels updates the labels identically on a service and template. | ||
// Does not overwrite the entire Labels field, only makes the requested updates | ||
func UpdateLabels(service *servingv1.Service, template *servingv1.RevisionTemplateSpec, toUpdate map[string]string, toRemove []string) error { | ||
func UpdateLabels(service *servingv1.Service, template *servingv1.RevisionTemplateSpec, |
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.
Having functions with more than 4 or 5 arguments is a code smell, especially when the have the same types. This is not good API design and confuses users and code readers. Instead, its better to either split up a 'god' function (i.e. in a simpler method which might then be called twice) or introduce an option struct (which allows for "named" parameters (field of the structure) in favor of positional arguments). If possible the formere solution is easier to implement and more lightweight. The latter (option struct) should be used only if it can't be avoid.
This seems kind of a nit-pick comment for now, but maintaining god methods that do too much is really hard. Also using smaller method can help in guaranteeing consistency.
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.
E.g. one could also use two methods UpdateServiceLabels
or UpdateRevisionTemplateLabels
(or maybe also UpdatePodLabels
as this is where the lable will end up and might be easier to understand).
I think this is the better option.
"To unset, specify the label name followed by a \"-\" (e.g., name-). This flag takes "+ | ||
"precedence over \"label\" flag.") | ||
p.markFlagMakesRevision("label-service") | ||
command.Flags().StringArrayVarP(&p.LabelRevision, "label-revision", "", []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.
Shouldn't it be really --label-pod
instead of --label-revision
as it is about adding the label to the pod spec ?
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
@googlebot I consent. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
Signed-off-by: Shash Reddy <[email protected]>
The following is the coverage report on the affected files.
|
@rhuss : Yes we will follow up with another Pr for unit and integration test cases. Thanks for the feedback on the PR. Its ready for another review 👍 |
thanks looks good ! Let's merge this know and follow up with more tests after the release. I added issue #718 to not forget. /lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rhuss, shashwathi 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 |
* Don't tear down test environment on boskos * Add comments
Description
Added command line flags
label-service
andlabel-revision
to add labels more granularly for service and revision template objects.Fixes #675
/lint
cc @andrew-su
/assign @rhuss