Open Stack

On 10/28/2014 02:50 PM, John Griffith wrote:
>
>
> On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin <daniel.genin at jhuapl.edu 
> <mailto: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
>         <mailto: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 <mailto: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 <mailto:dtroyer at gmail.com>
>
>
>             _______________________________________________
>             OpenStack-dev mailing list
>             OpenStack-dev at lists.openstack.org
>             <mailto: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
>             <mailto: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
>     <mailto: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.
Agree.
> 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.
Dean is actually for using a shared VG to conserve space and loop devices.

Dan
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141029/638672a4/attachment.html>
-------------- 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/20141029/638672a4/attachment.bin>