Open Stack

On 28 October 2013 23:17, John Garbutt <john at johngarbutt.com> wrote:
> Is there a reason why you could not just use a Cinder Volume for your
> data, in this case?

Because this is at the baremetal layer; we want local disks - e.g.
some of the stuff we might put in that partition would be cinder lvm
volumes for serving out to VM guests. Until we have a cinder
implementation that can reference the disks in the same baremetal node
an instance is being deployed to we can't use Cinder. We want that
implementation, and since it involves nontrivial changes as well as
cross-service interactions we don't want to do it in nova-baremetal -
doing it in Ironic is the right place. But, we also don't want to
block all progress on TripleO until we get that done in Ironic....

> While at a first glance, it feels rather wrong, and un-cloudy, I do
> see something useful about refreshing the base disk, and leaving the
> data disks alone. Prehaps it's something that could be described in
> the block device mapping, where you have a "local volume" that you
> choose to be non-ephemeral, except for server terminate, or something
> like that?

Yeah. Except I'd like to just use ephemeral for that, since it meets
all of the criteria already, except that it's detached and recreated
on rebuild. This isn't a deep opinion though - mainly I don't want to
invest a bunch of time building something needlessly different to the
existing facility, which cloud-init and other tools already know how
to locate and use.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud