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

Cross-Provider Enforcement #165

Open
almahmoud opened this issue Jan 5, 2019 · 1 comment
Open

Cross-Provider Enforcement #165

almahmoud opened this issue Jan 5, 2019 · 1 comment

Comments

@almahmoud
Copy link
Collaborator

almahmoud commented Jan 5, 2019

We talked about this quickly at the last Zoom meeting in 2018, so I'm documenting the idea here for further discussion and to see whether it'd be a good one to potentially implement for 2.0 with GCE, and/or work on during this CollabFest.

We had already discussed a few months ago adding decorators (similar to the deprecated decorator) that would issue either a warning or an error (with severity set in the .cloudbridge settings file) when any provider-specific code is being used (an easy example would be invoking az.resource_group, a property specific to Azure and inexistent in other providers). As an extension of this idea, I also was suggesting adding an option to specify for what providers the function should be available. This would thus allow us to add some provider-specific services/functions, even if they are not available across all of our supported providers. A specific use-case which brought this up would be implementing the native Kubernetes services (Azure K8S Service, AWS EKS, GKE) although I don't think an equivalent would exist in OpenStack.

So the final idea would be having two new settings options:

providers: [aws, azure, os, gce]
severity: [ignore, warning, error]

I would suggest defaulting them to be across all providers (as that is the main point of CloudBridge) and to warning (as to not frustrate new users with figuring out error codes if they are starting to learn CloudBridge on a specific provider).

I believe creating the decorator should be fairly straightforward, and it might take a little bit of time to go back and tag previous functions, but would be much easier if done alongside #109.

@nuwang
Copy link
Contributor

nuwang commented Jan 6, 2019

This would be excellent alongside #109. Possibly, we could implement this through the notion of a "Profile" where a profile is a set of methods that are valid in a particular context (sort of like bluetooth having audio profiles, hands free profiles etc). So we could define a "Standard" cloudbridge profile which contains all methods that are guaranteed to be cross-platform, and raise an error if any extra methods are invoked as you've mentioned.

We could also define an "object storage" profile, which only contains methods relevant to the object store. Useful if one day we decide to add support for say dropbox or google drive, and since neither support any of the compute related methods. When requesting providers, we could filter them by their supported profiles.
e.g.

     factory = CloudProviderFactory()
     # return all cloud providers supporting the object store profile
     providers = factory.list_providers(profiles=[Profiles.OBJECT_STORE])

We could also have profile generators for an app. This would mean that all methods used by an app are logged to a file. Subsequently, porting the app to a new, unsupported cloud would only require implementing the methods logged in that profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants