On 10/28/2014 02:50 PM, John Griffith wrote:


On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin <daniel.ge...@jhuapl.edu <mailto:daniel.ge...@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.ge...@jhuapl.edu
        <mailto: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 <mailto: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 <mailto:dtro...@gmail.com>


            _______________________________________________
            OpenStack-dev mailing list
            OpenStack-dev@lists.openstack.org
            <mailto:OpenStack-dev@lists.openstack.org>
            http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



            _______________________________________________
            OpenStack-dev mailing list
            OpenStack-dev@lists.openstack.org
            <mailto:OpenStack-dev@lists.openstack.org>
            http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






    _______________________________________________
    OpenStack-dev mailing list
    OpenStack-dev@lists.openstack.org
    <mailto:OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to