Cinder volumes are always (unless you go change the default) in the form: volume-<uuid>, and since the string 'volume-' is never a valid uuid, then I think we can work around nova volumes fine when we come to write our tests.
Sorry for the repeated circling on this, but I think I'm now happy. Thanks On 28 October 2014 17:53, Dan Genin <daniel.ge...@jhuapl.edu> wrote: > On 10/28/2014 11:56 AM, Dean Troyer wrote: > > On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin <daniel.ge...@jhuapl.edu> wrote: >> >> 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. > > > Between Cinder, Nova and Swift (and Ceph, etc) everybody wants some loopback > disk images. DevStack's Swift and Ceph configurations assume loopback > devices and do no sharing. > >> >> Duncan, could you please elaborate on the pain a single volume group is >> likely to cause for Cinder? Is it a show stopper? > > > Back in the day, DevStack was built to configure Cinder (and Nova Volume > before that) to use a specific existing volume group (VOLUME_GROUP_NAME) or > create a loopback file if necessary. With the help of VOLUME_NAME_PREFIX > and volume_name_template DevStack knew which logical volumes belong to > Cinder and could Do The Right Thing. > > With three loopback files being created, all wanting larger and larger > defaults, adding a fourth becomes Just One More Thing. If Nova's use of LVM > is similar enough to Cinder's (uses deterministic naming for the LVs) I'm > betting we could make it work. > > dt > > Nova's disk names are of the form <instance-uuid>_<disk_type>. So > deterministic but, unfortunately, not necessarily predictable. It sounds > like Duncan is saying that Cinder needs a fixed prefix for testing its > functionality. I will be honest, I am not optimistic about convincing Nova > to change their disk naming scheme for the sake of LVM testing. Far more > important changes have lingered for months and sometimes longer. > > It sounds like you are concerned about two issues with regard to the > separate volume groups approach: 1) potential loop device shortage and 2) > growing space demand. The second issue, it seems to me, will arise no matter > which of the two solutions we choose. More space will be required for > testing Nova's LVM functionality one way or another, although, using a > shared volume group would permit a more efficient use of the available > space. The first issue is, indeed, a direct consequence of the choice to use > distinct volume groups. However, the number of available loop devices can be > increased by passing the appropriate boot parameter to the kernel, which can > be easy or hard depending on how the test VMs are spun up. > > I am not saying that we should necessarily go the way of separate volume > groups but, assuming for the moment that changing Nova's disk naming scheme > is not an option, we need to figure out what will bring the least amount of > pain forcing Cinder tests to work around Nova volumes or create separate > volume groups. > > Let me know what you think. > Dan > > > -- > > Dean Troyer > dtro...@gmail.com > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev