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 range options to --scale #1070

Closed
wants to merge 39 commits into from
Closed

Add range options to --scale #1070

wants to merge 39 commits into from

Conversation

mpetason
Copy link
Contributor

Description

Adds range options to --scale

Changes

  • Changed Scale from Int to String
  • Added Options to set min/max with 1..5

Reference

Fixes #822

Replaces previous PR where I had issues with a rebase - #986

@google-cla google-cla bot added the cla: yes Indicates the PR's author has signed the CLA. label Oct 22, 2020
@knative-prow-robot knative-prow-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 22, 2020
@mpetason
Copy link
Contributor Author

I'm not sure about the failed lint test - maybe I can get more information in a review.

When setting 1.. or ..5 it defaults to 0 <-- I still need to resolve this. I'll write an additional test to cover this as well.

Copy link
Contributor

@maximilien maximilien left a comment

Choose a reason for hiding this comment

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

Missing a test case for case when user only specifies separator or has too many separators, e.g.,

  1. —scale ..
  2. —scale 1..5..

Also couple more minor feedback. Thanks for contribution.

@@ -88,7 +88,7 @@ kn service create NAME --image IMAGE
--requests-cpu string DEPRECATED: please use --request instead. The requested CPU (e.g., 250m).
--requests-memory string DEPRECATED: please use --request instead. The requested memory (e.g., 64Mi).
--revision-name string The revision name to set. Must start with the service name and a dash as a prefix. Empty revision name will result in the server generating a name for the revision. Accepts golang templates, allowing {{.Service}} for the service name, {{.Generation}} for the generation, and {{.Random [n]}} for n random consonants. (default "{{.Service}}-{{.Random 5}}-{{.Generation}}")
--scale int Minimum and maximum number of replicas.
--scale string Set the Minimum and Maximum number of replicas. You can use this flag to set both to a single value, or set a range with min/max values, or set either min or max values without specifying the other. Example: --scale 5 or --scale 1..5 or --scale 1.. or --scale ..5. (default "1")
Copy link
Contributor

Choose a reason for hiding this comment

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

I would not use a “.” in the last example “or —scale ..5” since it’s confusing as to whether that last character is part of the syntax

Copy link
Collaborator

@navidshaikh navidshaikh Oct 26, 2020

Choose a reason for hiding this comment

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

with each example listed we can add what does that pattern represent in () ? like '--scale 1..' (min-scale=1, max scale undefined) and also we should single quote the range patterns

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good. I'll make this update - have been working on breaking up the helper function at the moment. This will get added to my next commit. I've also updated the formatting so that it looks like other examples in the configuration_edit_flags.go file.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for putting literal examples in quotes, but i would suggest double quotes (") as in the example for --revision-name (just to be consistent).


if err != nil {
t.Fatal(err)
} else if !action.Matches("create", "services") {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would separate them as two different checks. No need to be if/else since either execution will stop and fail the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I separated these, however the original blocks were copied from other tests and I was trying to keep it consistent. Many of the other code blocks in create_test and update_test use:

	if err != nil {
		t.Fatal(err)
	} else if !action.Matches("create", "services") {
		t.Fatalf("Bad action %v", action)
	}

Should I revert this back for consistency?

Copy link
Contributor

Choose a reason for hiding this comment

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

if this is the case, then typically I would recommend to move the shared code pattern into a dedicated function for validation like in a validateAction(t, action, err, []string{ "create", "services") to guarantee that the same code is used everywhere.

However as this is not in scope for this pr I would recommend to do this in a separate pr and for now just keep the pattern so that it can be easily detected when doing the full refactoring.


// Helper function for --scale
func (p *ConfigurationEditFlags) scaleConversion(scale string) (scaleMin int, scaleMax int, err error) {
if len(scale) <= 2 {
Copy link
Contributor

Choose a reason for hiding this comment

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

My preference would be to divide this into smaller private functions for each of the cases... might simply things. Also for each case returning early could also simply code since once case identified the result is there. No need for big if/else if/else.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I break up the helper function into multiple private functions it will complicate the cmd.Flags().Changed("scale") section, is that ok? I was trying to minimize how large that code block was going to be.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Working on breaking this up next - I should be able to avoid complication in the cmd.Flags().Changed("scale") section.

@maximilien
Copy link
Contributor

/ok-to-test
/approve

@knative-prow-robot knative-prow-robot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Oct 22, 2020
@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: maximilien, mpetason

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 Oct 22, 2020
knative-automation and others added 6 commits October 25, 2020 22:10
Signed-off-by: Knative Automation <[email protected]>
* fix(tekton e2e): Fix CONTAINER_REGISTRY name generation

 var `E2E_BASE_NAME` is no longer available

* debug: Run tekton tests

* Revert "debug: Run tekton tests"

This reverts commit dbe125e.
@mpetason
Copy link
Contributor Author

TODO:
Break up helper function and update cmd.Flags() section.
Fix issues where undefined value defaults to 0.

Fixed:
Addressed the easier updates based on reviews.

@rhuss
Copy link
Contributor

rhuss commented Oct 27, 2020

@mpetason please let me know if I can jump on a final review.

Ying Chun Guo and others added 2 commits October 27, 2020 10:45
…dspec_helper (#1024)

* moving utilities of handling podspec to podspec_helper

* address comments

* refactor code base

* change the input parameter from ccmd to flagset

* remove comments and add CHANGELOG
…rom max then min, to min then max, updated tests to reflect updates
@mpetason
Copy link
Contributor Author

@rhuss How can I resolve this issue? This is mostly a copy/paste from other tests. Do we need to create a function for this and just have each test call it to reduce the amount of times it's duplicated?

pkg/kn/commands/service/update_test.go#L529

[Redundant Format] reported by reviewdog 🐶
Please consider avoiding tail format like this:
t.Fatalf("Bad action %v", action)

Raw Output:
./pkg/kn/commands/service/update_test.go:529: Please consider avoiding tail format like this:
t.Fatalf("Bad action %v", action)

@@ -88,7 +88,7 @@ kn service create NAME --image IMAGE
--requests-cpu string DEPRECATED: please use --request instead. The requested CPU (e.g., 250m).
--requests-memory string DEPRECATED: please use --request instead. The requested memory (e.g., 64Mi).
--revision-name string The revision name to set. Must start with the service name and a dash as a prefix. Empty revision name will result in the server generating a name for the revision. Accepts golang templates, allowing {{.Service}} for the service name, {{.Generation}} for the generation, and {{.Random [n]}} for n random consonants. (default "{{.Service}}-{{.Random 5}}-{{.Generation}}")
--scale int Minimum and maximum number of replicas.
--scale string Set the Minimum and Maximum number of replicas. You can use this flag to set both to a single value, or set a range with min/max values, or set either min or max values without specifying the other. Example: --scale 5 (scale-min = 5, scale-max = 5) or --scale 1..5 (scale-min = 1, scale-max = 5) or --scale 1.. (scale-min = 1, scale-max = undefined) or --scale ..5 (scale-min = undefined, scale-max = 5) (default "1")
Copy link
Contributor

Choose a reason for hiding this comment

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

I think saying “undefined” isn’t as clear as saying that the current value is unchanged. And there is no default value so I would remove that.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think that is is "unchanged" as we are here talking about a create operation. Also for an update operation I still think that --scale 1.. mean min-scale is set to one, but no max-scale is set or removed if set, so that there is no upper bound specified by the user (regardless what was specified before). If you want to change only the minimal scale, you should use --min-scale.

+1 that the default value 1 is wrong as there is supposed to be no default at all, the argument is mandatory.

Copy link
Contributor

Choose a reason for hiding this comment

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

So maybe instead of scale-max = undefined, better use no maximum scale defined) ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused. @rhuss in the past I think you said you wanted 1.. to mean only the lower bound is set, and upper bound is untouched. That's why I commented the way I did - I thought you still wanted that.

Let's back up a bit... at one point people wanted to deprecate --scale-min and only have --scale - is that still in the cards or is that idea dead? If --scale-min/max will live on, then I'm ok with a missing value in .. meaning unset that value (or in the 'create' case it means just leave it as the default). And yes --scale .. would mean unset both :-)

@mpetason
Copy link
Contributor Author

Split up the helper function, still working on getting the correct values set when something isn't defined. Right now it sets the default to 0 when it isn't set, which isn't what we want for something like "..5" when using "update."

@mpetason
Copy link
Contributor Author

mpetason commented Nov 6, 2020

/test pull-knative-client-build-tests

@mpetason
Copy link
Contributor Author

mpetason commented Nov 6, 2020

Running build again doesn't update the docs, not sure how to resolve the current failing test.

Copy link
Contributor

@maximilien maximilien left a comment

Choose a reason for hiding this comment

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

Flake perhaps.
/retest

@rhuss
Copy link
Contributor

rhuss commented Nov 9, 2020

@mpetason You need to rebase you local branch so that you get the newly introduced kn service apply also locally and the regenerate the docs with hack/build.sh. The reason for the build failure is, that the CI did the rebase but you did not when committing, and as kn service apply use also the scale options, it is affected by the update.

Just try a

git pull upstream master
git rebase upstream/master
hack/build.sh
git status
git commit -m "Updated command documentation" -a

@rhuss rhuss closed this Nov 9, 2020
@rhuss rhuss reopened this Nov 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 87.5% 86.7% -0.8

@knative-prow-robot
Copy link
Contributor

@mpetason: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
pull-knative-client-build-tests 4b84de3 link /test pull-knative-client-build-tests

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

navidshaikh and others added 15 commits November 9, 2020 01:49
* Add channel sink prefix

* Add unit and e2e tests

* Add CHANGELOG

* Fix e2e tests
in the favor of --no-wait flag
* feat: Add service import command

* fix: Fix e2e test

* fix: Add retry when retrieving Configuration

* fix: Reflect review feedback

* fix: Fix error message

Co-authored-by: Roland Huß <[email protected]>

* fix: Add missing mock tests

* fix: Polish unit test assertions

* fix: Mark import as experimental

* chore: Add changelog entry

* Update CHANGELOG.adoc

Co-authored-by: Roland Huß <[email protected]>

* fix: Remove deprecated flag

Co-authored-by: Roland Huß <[email protected]>
…rom max then min, to min then max, updated tests to reflect updates
@knative-prow-robot knative-prow-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 9, 2020
@mpetason
Copy link
Contributor Author

mpetason commented Nov 9, 2020

@rhuss that didn't work, I guess I'll close this issue and try again.

@mpetason mpetason closed this Nov 9, 2020
@mpetason mpetason deleted the issue-822-pt3 branch November 11, 2020 16:20
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. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support --scale
10 participants