You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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 profileproviders=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.
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:
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.
The text was updated successfully, but these errors were encountered: