Open Stack

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
>>
>
>


-------------- 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/e115ed3f/attachment.bin>