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

Implement Stack Class #110

Open
robparrott opened this issue Nov 6, 2013 · 0 comments
Open

Implement Stack Class #110

robparrott opened this issue Nov 6, 2013 · 0 comments

Comments

@robparrott
Copy link
Contributor

Currently this is a glaringly lacking feature/capability.

We need to implement a Stack class that encompasses a "Scenario" (Blueprint + params [ + context?] ) but that is serializable and trackable. This will let us more easily implement nepho stack list and other operations, and will enable multiple stacks per blueprint (a constraint right now.

Upon successful execution of provider.create(), the provider (or scenario?) should return a Stack object, and then save it. These saved stack objects could be YAML files stored within ~/.nepho/local/, one per stack? A lookup for all stack of a given provider, or cloudlet, or cloudlet+blueprint should be implemented in the ResourceManager helper class, so that implementation changed underneath are transparent to the rest of the codebase.

Stack should have fields:

  • s.id
  • s.provider
  • s.blueprint
  • s.params
  • s.context?

and methods

  • s.status()
  • s.access()
  • s.destroy()

Stack will use the provider class in the backend to do these actions, so that they are pluggable.

ResourceManager needs new method:

  • rm.find_stacks( provider=None, cloudlet=None, blueprint=None)

which returns a list of Stack objects.

StackController class will need to be modified to use "Stack" objects instead of provider in the destroy(), status() and list() methods (and any other that come down the road).

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

No branches or pull requests

1 participant