On 10/28/2014 12:47 PM, Duncan Thomas wrote:
Hi Dan

You're quite right, the nesting isn't as I thought it was, sorry to mislead you.

It isn't a show stopper, it just makes testing some proposed useful
functionality slightly harder. If nova were to namespace its volumes
(e.g. start all the volume names with nova-*) then that would allow
the problem to be easily worked around in the test, does that sound
reasonable?
Changing Nova disk names is a loooong shot. It's likely I will be doing something else by the time that gets merged:) So we are left with the two options of 1) using a shared volume group and, thus, complicating life for Cinder or 2) using separate volume groups potentially causing headaches for DevStack. I am trying to figure out which of these two is the lesser evil. It seems that Dean's concerns can be addressed, though, he still has to weigh in on the proposed mitigation approaches. I have little understanding of what problems a shared Cinder-Nova volume group would cause for Cinder testing. How hard would it be to make the tests work with a shared volume group?

Dan
On 28 October 2014 14:27, Dan Genin <daniel.ge...@jhuapl.edu> wrote:
Duncan, I don't think it's possible to have multiple volume groups using the
same physical volume[1]. In fact, counter-intuitively (at least to me) the
nesting actually goes the other way with multiple physical volumes
comprising a single volume group. The LVM naming scheme actually makes more
sense with this hierarchy.

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.

Duncan, could you please elaborate on the pain a single volume group is
likely to cause for Cinder? Is it a show stopper?

Thank you,
Dan

1. https://wiki.archlinux.org/index.php/LVM#LVM_Building_Blocks


On 10/21/2014 03:10 PM, Duncan Thomas wrote:

Sharing the vg with cinder is likely to cause some pain testing proposed
features cinder reconciling backend with the cinder db. Creating a second vg
sharing the same backend pv is easy and avoids all such problems.

Duncan Thomas

On Oct 21, 2014 4:07 PM, "Dan Genin" <daniel.ge...@jhuapl.edu> wrote:
Hello,

I would like to add to DevStack the ability to stand up Nova with LVM
ephemeral
storage. Below is a draft of the blueprint describing the proposed
feature.

Suggestions on architecture, implementation and the blueprint in general
are very
welcome.

Best,
Dan

========================
Enable LVM ephemeral storage for Nova
========================

Currently DevStack supports only file based ephemeral storage for Nova,
e.g.,
raw and qcow2. This is an obstacle to Tempest testing of Nova with LVM
ephemeral
storage, which in the past has been inadvertantly broken
(see for example, https://bugs.launchpad.net/nova/+bug/1373962), and to
Tempest
testing of new features based on LVM ephemeral storage, such as LVM
ephemeral
storage encryption.

To enable Nova to come up with LVM ephemeral storage it must be provided a
volume group. Based on an initial discussion with Dean Troyer, this is
best
achieved by creating a single volume group for all services that
potentially
need LVM storage; at the moment these are Nova and Cinder.

Implementation of this feature will:

  * move code in lib/cinder/cinder_backends/lvm to lib/lvm with appropriate
    modifications

  * rename the Cinder volume group to something generic, e.g., devstack-vg

  * modify the Cinder initialization and cleanup code appropriately to use
    the new volume group

  * initialize the volume group in stack.sh, shortly before services are
    launched

  * cleanup the volume group in unstack.sh after the services have been
    shutdown

The question of how large to make the common Nova-Cinder volume group in
order
to enable LVM ephemeral Tempest testing will have to be explored.
Although,
given the tiny instance disks used in Nova Tempest tests, the current
Cinder volume group size may already be adequate.

No new configuration options will be necessary, assuming the volume group
size
will not be made configurable.


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


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



_______________________________________________
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