Skip to content
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

Merged
merged 7 commits into from
Mar 9, 2020

Conversation

shashwathi
Copy link
Contributor

Description

Added command line flags label-service and label-revision to add labels more granularly for service and revision template objects.

Fixes #675

/lint

cc @andrew-su
/assign @rhuss

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]>
@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label Mar 5, 2020
Copy link
Contributor

@knative-prow-robot knative-prow-robot left a 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 and label-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.

@knative-prow-robot knative-prow-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Mar 5, 2020
@shashwathi
Copy link
Contributor Author

/test pull-knative-client-integration-tests-latest-release

@shashwathi
Copy link
Contributor Author

/test pull-knative-client-integration-tests

@rhuss
Copy link
Contributor

rhuss commented Mar 6, 2020

@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.

@rhuss
Copy link
Contributor

rhuss commented Mar 8, 2020

/retest

Copy link
Contributor

@rhuss rhuss left a 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, "=")
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dito

var ServiceOnlyLabels = map[string]struct{}{
serving.GroupName + "/visibility": {},
}
// // ServiceOnlyLabels should only appear on the Service and NOT on the
Copy link
Contributor

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.


// 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,
Copy link
Contributor

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.

Copy link
Contributor

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{},
Copy link
Contributor

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 ?

@googlebot
Copy link

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: no Indicates the PR's author has not signed the CLA. and removed cla: yes Indicates the PR's author has signed the CLA. labels Mar 9, 2020
@andrew-su
Copy link
Member

@googlebot I consent.

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: yes Indicates the PR's author has signed the CLA. and removed cla: no Indicates the PR's author has not signed the CLA. labels Mar 9, 2020
@knative-metrics-robot
Copy link

The following is the coverage report on the affected files.
Say /test pull-knative-client-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/kn/commands/service/configuration_edit_flags.go 83.9% 84.1% 0.2
pkg/serving/config_changes.go 79.9% 79.6% -0.3

@shashwathi
Copy link
Contributor Author

@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 👍
cc @andrew-su

@rhuss
Copy link
Contributor

rhuss commented Mar 9, 2020

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

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 9, 2020
@rhuss
Copy link
Contributor

rhuss commented Mar 9, 2020

/approve

@knative-prow-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 9, 2020
@knative-prow-robot knative-prow-robot merged commit 81c1d9c into knative:master Mar 9, 2020
coryrc pushed a commit to coryrc/client that referenced this pull request May 14, 2020
* Don't tear down test environment on boskos

* Add comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add option for adding labels only to service and/or template
6 participants