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

[ACS] Add support for top-level browse and install-cli commands. #1476

Merged
merged 2 commits into from
Dec 9, 2016

Conversation

brendandburns
Copy link
Member

Fixes #1358

@mention-bot
Copy link

@brendandburns, thanks for your PR! By analyzing the history of the files in this pull request, we identified @sanar-microsoft, @derekbekoe and @colemickens to be potential reviewers.

@derekbekoe derekbekoe changed the title Add support for top-level browse and install-cli commands. [ACS] Add support for top-level browse and install-cli commands. Dec 1, 2016
@derekbekoe derekbekoe added the ACS az acs/aks/openshift label Dec 1, 2016
orchestrator_type = acs_info.orchestrator_profile.orchestrator_type # pylint: disable=no-member
if orchestrator_type == 'kubernetes':
# TODO: is there a more python idiomatic way to do this?
if client_version:
Copy link
Contributor

Choose a reason for hiding this comment

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

Aren't you guaranteed to have a value here by nature of what you have in _params.py?

Copy link
Contributor

Choose a reason for hiding this comment

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

Same for the check in the dcos branch.

Copy link
Member Author

Choose a reason for hiding this comment

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

Not if you come in the acs install-cli ... path, since we can't have a default in there, since it's orchestrator dependent, and we don't know which it is 'til we do the lookup.

Copy link
Contributor

@colemickens colemickens Dec 6, 2016

Choose a reason for hiding this comment

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

Got it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Now I'm curious, do you only need to register cli arguments in _params.py if you want to specify short flags or defaults?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, (or other fanciness like tab-completion) I believe it otherwise picks them up by reflecting on the method (and looking at it's docstring)

Copy link
Member

Choose a reason for hiding this comment

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

@colemickens if you want to specify defaults, the preferred way is to simply use the Python argument defaulting mechanism in the custom command signature. Using the "default" kwarg in the _params.py is discouraged.

If you don't register something in _params.py the CLI will use reflection to get the following info:

  • requiredness (based on presence of a default)
  • default value
  • long option name
  • parameter help (from a docstring).

Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, I had been encouraged to move the default into _params.py in [this PR] (#1448 (review)) but maybe that was because the default value wasn't a simple constant?

Copy link
Member

Choose a reason for hiding this comment

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

@tjprescott "Using the "default" kwarg in the _params.py is discouraged."

Computed defaults should be added to _params.py though right due to Python's parameter defaulting logic - http://docs.python-guide.org/en/latest/writing/gotchas/#what-does-happen.

Copy link
Member

Choose a reason for hiding this comment

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

Looking at what @colemickens had in PR #1448, I would agree that would be a reasonable use of default in _params.py.

@brendandburns
Copy link
Member Author

@derekbekoe I think this is ready to go in...

Thanks!

if client_version:
return dcos_install_cli(client_version=client_version, install_location=install_location)
else:
return dcos_install_cli(install_location=install_location)
Copy link
Member

@tjprescott tjprescott Dec 7, 2016

Choose a reason for hiding this comment

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

You could say:

return dcos_install_cli(client_version=client_version, install_location=install_location) if client_version else dcos_install_cli(install_location=install_location)

But, even more concise, you should be able to do:

kwargs = {'install_location': install_location}
if client_version:
  kwargs['client_version'] = client_version
return dcos_install_cli(**kwargs)

Copy link
Member Author

Choose a reason for hiding this comment

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

nice! done.

"""
Opens a browser to the web interface for the cluster orchestrator

:param name: name: Name of the target Azure container service instance.
Copy link
Member

Choose a reason for hiding this comment

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

Typo: duplicate name: here.

Copy link
Member Author

Choose a reason for hiding this comment

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

done.

orchestrator_type = acs_info.orchestrator_profile.orchestrator_type # pylint: disable=no-member
if orchestrator_type == 'kubernetes':
# TODO: is there a more python idiomatic way to do this?
if client_version:
Copy link
Member

Choose a reason for hiding this comment

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

@tjprescott "Using the "default" kwarg in the _params.py is discouraged."

Computed defaults should be added to _params.py though right due to Python's parameter defaulting logic - http://docs.python-guide.org/en/latest/writing/gotchas/#what-does-happen.

@tjprescott
Copy link
Member

tjprescott commented Dec 7, 2016

@derekbekoe we tend not to have computed defaults in the _params.py file, especially randomized ones. What we do in those cases is make the default (in the signature) None and then do the dynamic generation in a validator. This is the approach the guide you referenced suggests as well. You wouldn't want to call a method with -h repeatedly and have a different default every time.

However, in the case of dynamic, but essentially static defaults (like user directory paths) then using default in _params.py seems reasonable. The other time it makes sense is when you're reflecting on the SDK and you want to override its default value.

@brendandburns
Copy link
Member Author

Ok, comments addressed, please take another look.

Copy link
Member

@tjprescott tjprescott left a comment

Choose a reason for hiding this comment

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

LGTM

@tjprescott tjprescott merged commit a8a233f into Azure:master Dec 9, 2016
@haroldrandom haroldrandom added ACS az acs/aks/openshift cla-not-required labels Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACS az acs/aks/openshift cla-not-required
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants