-
Notifications
You must be signed in to change notification settings - Fork 261
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 support for envFrom and volumeMounts #393
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.
@igsong: 5 warnings.
In response to this:
Proposed Changes
To use NOT-YET supported expressions of ksvc, following flags, which can be set in
service create
orservice update
, are added.
- Support
envFrom
expression. By giving the flag--env-from (config-map | secret):CONFIG_MAP_OR_SECRET_NAME
, a config map or secret is embedded usingenvFrom
. To unset, a-
suffix can be used like--env
or--label
.- Support
volumeMount
expression. By giving the flag--volume-mount VOLUME_NAME=(config-map|secret):CONFIG_MAP_OR_SECRET_NAME@/mount/here
, a config map or secret is mounted on the user-container. To unset, a-
suffix can be used like--env
or--label
.- Support
serviceAccountName
expression. By giving the flag--service-account-name=SERVICE_ACCOUNT_NAME
, a user can set a service account for a ksvc.- Support
imagePullPolicy
expression. By giving the flag--image-pull-policy=POLICY
, a user can set a image pull policy for a ksvc. POLICY should be one ofalways
,if-not-present
,never
or-
which can be used for unsetting imagePullPolicy.Release Note
NONE
/lint
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 @igsong. 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. |
/lint |
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.
@igsong: 0 warnings.
In response to this:
/lint
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.
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.
/ok-to-test
/test pull-knative-client-build-tests |
We have |
Thank you for comments. But, I think that the |
} | ||
} | ||
|
||
for i := range volumeMounts { |
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.
This seems like this code may not handle mounting the same secret (or whatever volume) at two different paths, or handling a message where the same secret (or whatever volume) was already mounted at two different paths. There are a lot of corner cases here.
I agree with the decision not to make the user handle all the minutae of the difference between volume mounts and volumes if they do not have to, though.
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.
OK, then I think that it would be better to have two flags instead of current one, like --volume-mount /mount/here=VOLUME_NAME
and --volume VOLUME_NAME=(config-map|secret):CONFIG_MAP_OR_SECRET_NAME
. How do you think of it?
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.
I split up the flag --volume-mount
into --volume
and --volume-mount
to cope with the case that @sixolet mentioned
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.
Wondering if there is a way to also include an integration test? Perhaps a modification to other tests that uses these features?
You might need to rebase: pkg/kn/commands/service/service_create_test.go
pkg/kn/commands/service/service_update_test.go |
@igsong : ping! let's rebase and get this in queue. |
I've rebased. |
You might need to make sure and include the newly generated docs. |
…rder to enable multiple times mounting for the same volume
…olume automatically when the config-map or secret is directley used. In addition, the test cases are changed to new unit test style. To keep the original orderedness given via flags, OrderedMap implementation is added as well
I've done to apply all the suggested and discussed changes. One thing I want to notice is that |
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 tons, looks really, really good !
I just started the review, but not yet finished. However there is one serious error which always occur for auto generated volume names (see below, ie.. a name must not contain a /
). If you could sanitize the name before using as a volume name, that would be a good fix.
I will continue later, but wanted to already give you that partial review feedback.
pkg/serving/config_changes.go
Outdated
} | ||
|
||
func generateVolumeName(path string) string { | ||
return fmt.Sprintf("kn-managed-volume:%s", path) |
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.
This is too simplistic, as you have to sanitize the path that it's a well-formed kubernetes identifier. As the path has to start with /
(as you can only mount absolute paths) you will always get an invalid name here. Unfortunately, such things can be only detected in integration tests, not unit tests, as unit tests don't do any validation.
Also, I would either don't use a prefix or, if required e.g. when for auto-deleting volumes, then just use kn:
, which is just shorter and easier to read when examing the k8s files.
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.
I've changed the part to use a sanitized path string + checksum of original path string without any prefix.
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, works for me now !
I'm going to go over the rest of the PR quickly and lets get it merged today so that we get it into 0.10.0 (to be released today). We can then fix any outstanding issues (or add some real integrations tests) later.
The following is the coverage report on the affected files.
|
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 for all your work (and especially for the comprehensive unit tests) and also for your patience with us reviewing it !
The PR looks good to merge and will be included in 0.10.0 (which by accident is released today ;-)
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: igsong, rhuss 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 |
/retest |
The CI test error is a strange beast. See slack channel for the discussion about it. Hopefully its only a hickup. |
/test pull-knative-client-integration-tests |
* Add more functions to shared gcs package These functions are needed for flaky tests reporting, which will need to list n number of latest finished builds, generate some files and upload to gcs to be consumed by testgrid * separate out prow, testgrid, and junit related functions
Proposed Changes
To use NOT-YET supported expressions of ksvc, following flags, which can be set in
service create
orservice update
, are added.envFrom
expression. By giving the flag--env-from (config-map | secret):CONFIG_MAP_OR_SECRET_NAME
, a config map or secret is embedded usingenvFrom
. To unset, a-
suffix can be used like--env
or--label
.volumeMount
expression. By giving the flag--volume-mount VOLUME_NAME=(config-map|secret):CONFIG_MAP_OR_SECRET_NAME@/mount/here
, a config map or secret is mounted on the user-container. To unset, a-
suffix can be used like--env
or--label
.Release Note
/lint