Is there a reason why you could not just use a Cinder Volume for your
data, in this case?

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?


On 28 October 2013 02:00, Robert Collins <> wrote:
> For context, in TripleO we have precious state to preserve when we
> push updates out to a cluster: nova instance volumes (obviously),
> swift data stores, mysql db's etc. We have a long term plan to have a
> volume model and interface that with Cinder, but thats an Ironic
> planed feature, and somewhat down the track : in the short term we'd
> like to use the ephemeral volume for such storage: it seems like 'nova
> rebuild' could easily be extended to preserve the ephemeral block
> device.
> From a nova bm perspective, all that needs to happen is for us to
> /not/ format the volume - simples - and we can do that in the current
> rebuild code path where destroy + spawn is called, as long as we end
> up on the same host.
> However, we'd like to support this for libvirt too, because that lets
> us test workflows in virt rather than on purely baremetal (or emulated
> baremetal). For that, it looks to me like we need to push rebuild down
> a layer to the virt driver : so rather than destroy(); spawn(); have a
> rebuild() method that takes the same data spawn would, and will be
> able to preserve data as needed.
> Seeking thoughts on this - both the use of ephemeral in this way, and
> sketched out code change - are sought!
> Thanks,
> Rob
> --
> Robert Collins <>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to