Storage support?

Dustin Kirkland kirkland at
Tue Jul 19 14:20:13 UTC 2011

On Wed, Jul 13, 2011 at 4:35 PM, Clint Byrum <clint at> wrote:
> Excerpts from Gustavo Niemeyer's message of Wed Jul 13 13:10:54 -0700 2011:
>> > I agree that it would be very useful.  I don't know about handling it from
>> > within a formula, though.  If formulas are concerned with deploying and
>> > exposing services, it may not be a good idea to begin considering things
>> > like block devices a service (elastic or otherwise).  I'd personally prefer
>> > to see storage provisioning handled internally by ensemble in the same way
>> > machines are currently launched.  This would allow ensemble to abstract away
>> > the details of each storage type into the corresponding
>> > provisioner/environments (EBS for EC2, SAN for Cobbler, nova-volume for
>> > Openstack, etc). As an added benefit, it would keep the corresponding cloud
>> > credentials in the ensemble environment and not require them to be
>> > dispatched to nodes/zookeeper via formulas.
>> +1!  It also makes sense to me to have it internally handled.
>> We debated about the concept a few times, and there are quite a few
>> nice things we can do by understanding the storage semantics used by a
>> formula (e.g. backups, migrations, etc).
>> For now, though, we opted to simply use EBS at all times to avoid
>> handling yet another problem right now, and to ensure people their
>> data won't magically disappear if the machine is shut down for
>> whatever reason.
> I agree as well that this is something ensemble needs to be capable of doing.


I created this bug based on this email thread, in the interest of tracking it:

> Basically at some point it will be useful to be able to say something like
> ensemble deploy mysql super-awesome-db data:size=100G
> And have the formula define that it has "data", and that it should be
> mounted in such a way (/var/lib/mysql for instance), and have a hook
> 'volume-data-snapshot' which can run a flush command or a freeze command
> or whatever is needed to make sure the snapshot is consistent.
> Then you can say:
> ensemble snapshot-service super-awesome-db:data
> INFO: snapshot created, super-awesome-db:data/0
> Which would really be multiple snapshots, one for each service unit.
> Do it again
> ensemble snapshot-service super-awesome-db:data
> INFO: snapshot created, super-awesome-db:data/1
> Then it gets interesting, because you can do
> ensemble deploy mysql super-awesome-testing-db --using-snapshot super-awesome-db:data/0
> And the holy grail..
> ensemble migrate super-awesome-db super-awesomer-db --instance-type=x99.mega-chunka-honking-large
> Which would make new machines, freeze the old ones, start the new ones,
> and then move all the relations to the new ones.
> Right.. ok, Ensemble 2017 plans are set. ;)

Hehe :-)  So that's funny and all, but those of us trying to build
solutions on top of Ensemble are going to need it solved before, say,
the next Olympics ;-)


Dustin Kirkland
Manager, Systems Integration
Corporate Services
Canonical, LTD

More information about the Ensemble mailing list