Configurable persistent backing storage
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
Low
|
Unassigned | ||
pyjuju |
Triaged
|
Low
|
Unassigned |
Bug Description
Following on the discussion on the mailing list, about storage:
* https:/
I'm filing this bug.
There are many, many difference configurations and considerations, so this bug might be split into multiple bugs or blueprints.
At a basic level, the default deployment of most current Ensemble formulas is rather ephemeral. Ensemble provides quite a nice way to deploy and relate services quickly and reliably. But there is no native support for persistence. It's up to the formula writer/user to manually configure persistent storage (EBS in the AWS case).
Jorge writes:
$ ensemble deploy --respository=
$ ensemble add-relation mysql amazon-ebs
I would then treat "amazon-ebs" as any other resource and set up
relationships to the storage and do other things like:
$ ensemble snapshot // Point in time snapshot the entire thing to S3
$ ensemble backup blah // Prompt me to snag my config and EBS stuff
so I can keep it offsite.
$ ensemble import blah // Import the configs and EBS stuff back to EC2
Of course EBS is just one storage thing that is obvious, I'd want to
be able to treat a local SAN the same way, etc. Thoughts?
Changed in ensemble: | |
status: | New → Confirmed |
tags: | added: production |
Changed in juju-core: | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | added: story-storage |
tags: |
added: feature removed: story-storage |
Changed in juju-core: | |
importance: | Medium → Low |
Changed in juju: | |
status: | Confirmed → Triaged |
importance: | High → Low |
tags: | added: canonical-is |
I personally like the idea of treating "storage" as just another service that Ensemble is able to manage and relate. This would also allow many different types of storage to be supported as different implementations of a generic storage service.