Open Stack

Duncan, I don't think it's possible to have multiple volume groups using 
the same physical volume[1]. In fact, counter-intuitively (at least to 
me) the nesting actually goes the other way with multiple physical 
volumes comprising a single volume group. The LVM naming scheme actually 
makes more sense with this hierarchy.

So this brings us back to the original proposal of having separate 
backing files for Cinder and Nova which Dean thought might take too much 
space.

Duncan, could you please elaborate on the pain a single volume group is 
likely to cause for Cinder? Is it a show stopper?

Thank you,
Dan

1. https://wiki.archlinux.org/index.php/LVM#LVM_Building_Blocks


On 10/21/2014 03:10 PM, Duncan Thomas wrote:
>
> Sharing the vg with cinder is likely to cause some pain testing 
> proposed features cinder reconciling backend with the cinder db. 
> Creating a second vg sharing the same backend pv is easy and avoids 
> all such problems.
>
> Duncan Thomas
>
> On Oct 21, 2014 4:07 PM, "Dan Genin" <daniel.genin at jhuapl.edu 
> <mailto:daniel.genin at jhuapl.edu>> wrote:
>
>     Hello,
>
>     I would like to add to DevStack the ability to stand up Nova with
>     LVM ephemeral
>     storage. Below is a draft of the blueprint describing the proposed
>     feature.
>
>     Suggestions on architecture, implementation and the blueprint in
>     general are very
>     welcome.
>
>     Best,
>     Dan
>
>     ========================
>     Enable LVM ephemeral storage for Nova
>     ========================
>
>     Currently DevStack supports only file based ephemeral storage for
>     Nova, e.g.,
>     raw and qcow2. This is an obstacle to Tempest testing of Nova with
>     LVM ephemeral
>     storage, which in the past has been inadvertantly broken
>     (see for example, https://bugs.launchpad.net/nova/+bug/1373962),
>     and to Tempest
>     testing of new features based on LVM ephemeral storage, such as
>     LVM ephemeral
>     storage encryption.
>
>     To enable Nova to come up with LVM ephemeral storage it must be
>     provided a
>     volume group. Based on an initial discussion with Dean Troyer,
>     this is best
>     achieved by creating a single volume group for all services that
>     potentially
>     need LVM storage; at the moment these are Nova and Cinder.
>
>     Implementation of this feature will:
>
>      * move code in lib/cinder/cinder_backends/lvm to lib/lvm with
>     appropriate
>        modifications
>
>      * rename the Cinder volume group to something generic, e.g.,
>     devstack-vg
>
>      * modify the Cinder initialization and cleanup code appropriately
>     to use
>        the new volume group
>
>      * initialize the volume group in stack.sh, shortly before
>     services are
>        launched
>
>      * cleanup the volume group in unstack.sh after the services have been
>        shutdown
>
>     The question of how large to make the common Nova-Cinder volume
>     group in order
>     to enable LVM ephemeral Tempest testing will have to be explored.
>     Although,
>     given the tiny instance disks used in Nova Tempest tests, the current
>     Cinder volume group size may already be adequate.
>
>     No new configuration options will be necessary, assuming the
>     volume group size
>     will not be made configurable.
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/a468faee/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/a468faee/attachment.bin>