-
Notifications
You must be signed in to change notification settings - Fork 263
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 "kn service export" (#653) #669
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.
@itsmurugappan: 1 warning.
In response to this:
Fixes #653
Proposed Changes
- Add new command kn export
- Add unit test
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 @itsmurugappan. 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. |
/assign @rhuss |
@rhuss I checked out in the serving slack and have made the changes accordingly. I have added 2 flows
Please review. |
/hold |
/ok-to-test |
/test pull-knative-client-integration-tests-latest-release |
/unhold |
thanks a lot ! I will give it a review tomorrow ... |
/test pull-knative-client-integration-tests |
1 similar comment
/test pull-knative-client-integration-tests |
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 for the contribution. I like the idea and this is a cool feature to have.
See my comments. Please address changes.
Thanks.
Also (obviously) tests are still failing. Please address as well. Thx |
The following is the coverage report on the affected files.
|
/test pull-knative-client-integration-tests-latest-release |
@itsmurugappan I saved some time to work on a review this week. Please stay tuned ;-) |
|
||
command := &cobra.Command{ | ||
Use: "export NAME", | ||
Short: "export a service", |
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.
Short: "export a service", | |
Short: "Export a service.", |
Could you please change the short description to be consistent with the rest of commands. It's used in generated .md
as a sentence.
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 looks good. I've added a suggestion about the short name.
I have a objections to current format of tests, the common approach for the rest of cmds is to split unit and mock tests. However, it isn't impacting functionality added and can be addressed later.
Finally, would have time to add E2E tests also? If you prefer as a follow-up issue/PR?
@dsimansk Thanks for reviewing. I will make the changes. Regarding unit tests , all the unit tests were supposed to move to mock based on this issue #358 . |
@itsmurugappan sorry for the confusion. My perspective was a bit different based on parts that I worked on recently (the old way) and I didn't know about #358 the new way. So your approach is actually right. :) |
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.
LGTM pending e2e test. Just to make sure that this gets executed on real services. Thx.
will add the e2e |
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 your contribution, highly appreciated ! It's very well done
Some remarks:
- I'm not 100% sold on the name
--history
option (maybe we should call it something like--replay
or--with-traffic-targets
, to make clear that we are creating kind of a service reply list which needs to be "applied" with kubectl. - I think you missed the annotations, that a user can add e.g. with
kn service create --annotation
. - We should wipe out the traffic block if we only export a single service. Anything else would not be usable if there is a traffic block added.
- Some real e2e tests would be cool. I'm going to open a new issue for this.
My suggestion to proceed is:
- We merge the PR right away.
- I create a smaller PR with a name suggestion for the
--history
option now, so that we can decide on this before we release 0.13.0 - I create an issue for the E2E tests.
Sounds good ?
} | ||
flags := command.Flags() | ||
commands.AddNamespaceFlags(flags, false) | ||
flags.BoolP("history", "r", false, "Export all active revisions") |
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.
Can we remove the shortcut for now. I think its better to spell out the option full each time to make it explicit. Also, the -r
doesn't really play well with --history
. I even probably would go for a --revisions
to make the option more self-explanatory for what is exported in addition (and no shortcut option) (and we could also introduce --no-revisions
for this boolean option, like we do for all boolean options).
exportedSvc := servingv1.Service{ | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Name: latestSvc.ObjectMeta.Name, | ||
Labels: latestSvc.ObjectMeta.Labels, |
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.
what's with custom annotations provided by the user ? We might want to filter out automatically added annotations (which we now), but as we allow a kn service create --annotation
, too, we should copy over annotations as well.
exportedSvc := servingv1.Service{ | ||
ObjectMeta: metav1.ObjectMeta{ | ||
Name: latestSvc.ObjectMeta.Name, | ||
Labels: latestSvc.ObjectMeta.Labels, |
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 would need annotations, too. See below.
|
||
exportedSvc.Spec.Template = servingv1.RevisionTemplateSpec{ | ||
Spec: revision.Spec, | ||
ObjectMeta: latestSvc.Spec.ConfigurationSpec.Template.ObjectMeta, |
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.
Why not from the revision ?
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.
From revision they were lot other values.
From ksvc is see only the below
metadata:
creationTimestamp: null
name: hello-v3
params = append(params, clientservingv1.WithService(latestSvc.ObjectMeta.Name)) | ||
|
||
// Query for list with filters | ||
revisionList, err := client.ListRevisions(params...) |
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.
You could directly use
revisionList, err := client.ListRevisions(clientservingv1.WithService(latestSvc.ObjectMeta.Name))
which is shorter and supposedly easier to read the intention.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: itsmurugappan, maximilien, 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 |
/lgtm |
Sure. |
Fixes #653
Proposed Changes