Open Stack

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.genin at 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.genin at 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
> dtroyer at gmail.com
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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
>



-- 
Duncan Thomas