Hi Dan You're quite right, the nesting isn't as I thought it was, sorry to mislead you.
It isn't a show stopper, it just makes testing some proposed useful functionality slightly harder. If nova were to namespace its volumes (e.g. start all the volume names with nova-*) then that would allow the problem to be easily worked around in the test, does that sound reasonable? On 28 October 2014 14:27, Dan Genin <[email protected]> wrote: > 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" <[email protected]> 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 >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
