Open Stack

On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin <daniel.genin at jhuapl.edu> wrote:

> Great, thank you, Duncan. I will then proceed with the shared volume group.
>
> Dan
>
>
> On 10/28/2014 02:06 PM, Duncan Thomas wrote:
>
>> 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
>>>
>>>
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Noticed my response never posted.... think there's something up with my
mail client, so if you get this a few more times forgive me :)

But....

The idea of sharing a VG
between Nova and Cinder is only relevant in an all in one deployment
anyway, it's a specific edge case for testing.  It certainly (IMHO) does
not warrant any changes in Nova and Cinder.  Also keep in mind that at
some point (I think we're already there) we need to consider whether our
default gating and setup can continue to be done on a single node
anyway.

The answer to this seems relatively simple to me, Dean pointed out just
add a loopback device specifically for Nova LVM testing and move on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/0e964a3d/attachment.html>