Open
Conversation
There are two libraries - os-client-config and shade - that already exist for the purposes of what these utility libs are doing. os-client-config's job is to collect client config information, whether via environment variables, command line arguments or clouds.yaml files and construct relevant objects from that. For instance, it will very happily make novaclient.client.Client objects for user - and it'll handle all of the arguments possible. shade's job is to contain business logic. So a good amount of the API calls in NovaClient are probably just things that need to live in shade. That's a few more steps than this is, but since shade is also driven by os-client-config, moving to os-client-config as a first step seems fairly sane.
nishpatwa
requested changes
Mar 20, 2017
Collaborator
nishpatwa
left a comment
nishpatwa
left a comment
There was a problem hiding this comment.
LGTM
Thanks for submitting PR, I liked your approach :)
Couple of nits:
-
would you be able to include os_client_config in requirements.txt under antiaffinity_check tool
-
Since removing the authentication.py will influence the other tools, would you be able to keep the file for the present? I will present a fix for the other tools to utilize os_client_config once this PR is merged
I have one concern:
Can we control the version of python apis os_client_config utilize?
The explanation for this is in future we will branch this repo to the particular openstack stable release
| @@ -109,9 +109,17 @@ def setup_clients(self): | |||
| A method to seting up authentication and necessary clients for | |||
Collaborator
There was a problem hiding this comment.
can you add "import os_client_config" on top?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There are two libraries - os-client-config and shade - that already
exist for the purposes of what these utility libs are doing.
os-client-config's job is to collect client config information, whether
via environment variables, command line arguments or clouds.yaml files
and construct relevant objects from that. For instance, it will very
happily make novaclient.client.Client objects for user - and it'll
handle all of the arguments possible.
shade's job is to contain business logic. So a good amount of the API
calls in NovaClient are probably just things that need to live in shade.
That's a few more steps than this is, but since shade is also driven by
os-client-config, moving to os-client-config as a first step seems
fairly sane.