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

Use objects for CloudEndpoints and CloudSuffixes instead of dicts #1145

Merged
merged 4 commits into from
Oct 26, 2016

Conversation

derekbekoe
Copy link
Member

Making this change based off feedback from the previous PR #1098 (comment)

(this is an internal change and doesn't affect the 'az cloud' or 'az context' commands)

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.

Overall I think it cleans up the logic nicely. We might add some unit tests to validate what happens if you register a cloud with a "None" endpoint to ensure things fail gracefully, and also to test the code path when creating a configuration from file (a la Stack) instead of the common clouds.

AZURE_DATALAKE_ANALYTICS_CATALOG_AND_JOB_ENDPOINT = 'azure_datalake_analytics_catalog_and_job_endpoint' #pylint: disable=line-too-long
class CloudEndpoints(object):
def __init__(self,
management=None,
Copy link
Member

Choose a reason for hiding this comment

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

Instead of None, should these default to public Azure? For example if I had a hybrid cloud (Stack) setup where I had one service running on my Stack instance, but wanted the rest to just come from public?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think it makes sense for them to default to public Azure...
In that scenario you would pass in all the endpoints you need. If some of them happen to be the same as public Azure then so be it.

Also, when I register a cloud, I would not expect for the values I didn't specify to be set to point to public Azure.

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense. Since all of our common cloud objects have everything filled out, I think we should test the scenario where one of these is None to ensure they fail gracefully.

@derekbekoe derekbekoe force-pushed the cloud-endpoint-suffix-obj branch from 62af195 to 52cba5e Compare October 25, 2016 17:04
if cloud.suffixes[suffix]:
config.set(cloud.name, 'suffix_{}'.format(suffix), cloud.suffixes[suffix])
for k, v in cloud.endpoints.__dict__.items():
if v:
Copy link
Contributor

Choose a reason for hiding this comment

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

will that ever be a case that we could have an entry w/o a value?

Copy link
Member Author

@derekbekoe derekbekoe Oct 25, 2016

Choose a reason for hiding this comment

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

Yes.
I don't want to save the values that weren't set by the user to the cloud config file.
e.g. If my cloud doesn't support Data Lake, there's no need to set the Data Lake endpoint.

@@ -108,3 +108,7 @@ def to_camelcase(s):
if not callable(v) and not k.startswith('_')])
else:
return obj

def to_snake_case(s):
Copy link
Contributor

Choose a reason for hiding this comment

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

i suggest put in couple of tests on this, particular if the name is already separated by '_', are we adding a redundant one? Of course, if that will never happen, then you can just add a simple comment.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, tests added.

@yugangw-msft
Copy link
Contributor

LGTM

@tjprescott
Copy link
Member

I would still like 2 additional tests:

  1. make a call against a service for which the endpoint is None
  2. exercise the "stack" path to ensure that that works as intended.

@derekbekoe
Copy link
Member Author

@tjprescott Added more tests. Please take a look.

@derekbekoe
Copy link
Member Author

For test (1), I verify the loading of the endpoints with a call to profile which attempts to load endpoints.management.

There is a unit test to verify that clouds can be added, listed and then deleted appropriately. This verifies (2) in your comment.

This is an internal change and doesn't affect the 'az cloud' or 'az context' commands
- Raise exception if attempting to use endpoint/suffix that is not set
@derekbekoe derekbekoe force-pushed the cloud-endpoint-suffix-obj branch from 6522ea2 to b659bc2 Compare October 25, 2016 23:44
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 👍

@derekbekoe derekbekoe merged commit 7a82595 into Azure:master Oct 26, 2016
@derekbekoe derekbekoe deleted the cloud-endpoint-suffix-obj branch October 26, 2016 00:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants