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


_______________________________________________
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