-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Fix hyperkube flag parsing #25512
Fix hyperkube flag parsing #25512
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
2 similar comments
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test". This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry. Otherwise, if this message is too spammy, please complain to ixdy. |
@k8s-bot I signed it! |
I'm assigning to to Mike semi-randomly |
ok to test |
See also #22737 cc @ingvagabund |
@colhom I am definitely +1 for the hyperkube_test.go. |
if serverName == hk.Name { | ||
args = args[1:] |
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.
As long as you run hyperkube kubectl
, this should not matter. Why movin 2 lines higher?
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 looks to perhaps break things when you softlink kubectl
to the hyperkube
binary. Have you tested 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.
+1
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.
Ironically enough, this was actually a fix to make softlinking work better :) I've tested it.
There's no reason to pass the command arg to any of the Server Run blocks . In particular, since kubectl
is now a Cobra command, it requires that if args[0]
is not a flag, it match the command name exactly. In the case of a softlink, it's possible thats args[0]
will be for example /usr/bin/kubectl
, and the Cobra command will complain. This removes that possibility.
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.
Ah! Looking at the documentation for pflags.FlagSet.Parse
it looks like the args should not contain the command name. That would imply that we were doing it wrong before when the command name was being included. interspersed
defaulting to true
must have covered our sins.
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.
Yep, that's very true!
} | ||
os.Exit(0) | ||
return nil | ||
cmd.SetArgs(args) |
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.
if we don't muck with args above, this should be args[1:]
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.
Depending on whether or not it's a softlink (os.Args[0] == "hyperkube"
), it's either os.Args[1:]
or os.Args[2:]
. It's kind of nice to let the hyperkube server deal with that logic and sub-servers can just assume that their args list starts with the first relevant flag. This would easily support, for example, nesting servers in servers.
I'm in favor of integrating this with the cobra command structure (I looked at it originally but found it a forced fit) but we need to make sure we don't change behavior of existing commands. Also, need to make sure we don't get divergent implementations between the |
Looks good to me. @ingvagabund, what are your thoughts? Honestly, I lean toward merging both changes. The cobra stuff does enough fancy flag parsing that it makes sense to let it do it. It is a decent service for the rest of the servers. Also, we need to figure out what is going on with the CLA for @colhom. I think you need to respond with |
I signed it! |
@k8s-bot test this issue: #IGNORE Tests have been pending for 24 hours |
GCE e2e build/test passed for commit fd1771e. |
I believe this is not merged because it isn't marked for 1.3. @bgrant0607 -- what is the criteria/process for that? I don't see it linked off of the 1.3 release wiki page or obvious from kubernetes-dev chatter. |
@jbeda I added it to the v1.3 milestone. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit fd1771e. |
Automatic merge from submit-queue |
Thanks @luxas! |
@mikedanese what do you think about a cherrypick-candidate label? |
\cc @jbeda |
@colhom I assume you are asking about cherry picking into 1.2 (and that the 1.3 milestone was added to get through the submit queue). Is that correct? |
@roberthbailey that is correct. |
@colhom I've adjusted the milestone label to indicate where you want it cherry picked to. Please send a cherry pick PR for the 1.2 release branch. |
@roberthbailey cherry pick PR is up: #26754 |
…-upstream-release-1.2 Automated cherry pick of #25512
This was cherrypicked into 1.2 in #26754. Manually removing the cherrypick candidate label. |
…-of-#25512-upstream-release-1.2 Automated cherry pick of kubernetes#25512
…-of-#25512-upstream-release-1.2 Automated cherry pick of kubernetes#25512
Hyperkube flag parsing was not playing nicely with kubectl command and sub-commands. This PR addresses that problem, and adds some tests which exercise hyperkube dispatching to nested cobra commands.
\cc @aaronlevy @kbrwn @mumoshu
fixes #24088