[Openstack] [Cinder] HP MSA array as a secondary backend is only used user is an admin

Jim Okken jim at jokken.com
Thu Oct 11 20:08:47 UTC 2018


hi All,

not sure if I can find an answer here to this specific situation with the
cinder backend driver cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver.
If not how can I get in touch with someone more familiar with
cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver

we have a HP MSA storage array connected to most of our compute nodes and
we are using the cinder driver
cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver as a second backend so
that openstack can, if directed by metadata, create volumes on it during
instance creation. Openstack creates volumes using this MSA backend if the
metadata of the image selected contains "cinder_image_volume_type=MSA".
This second MSA type of volume was added to cinder.

We use a CentOS-6-x86_64-GenericCloud-1707.qcow2 image which has this
metadata added. Without this metadata RBD/CEPH images are made

This works great for the admin user but not for a regular _ member_ user.

With the admin user volumes created show Type=*MSA* and
Host=node-44.domain.com@*MSA#A*. (correct)

With the _member_ user volumes created show Type=*MSA* but
Host=rbd:volumes at RBD-backend#*RBD-backend (this is CEPH, incorrect!)*.

And I can confirm the volume is not on the MSA. Correct RBD/CEPH volumes
show Type=*volumes_ceph* and Host=rbd:volumes at RBD-backend#*RBD-backend*.

This happens if the cinder volume type is created as a Private type or a
Public type.

I have tried to set the properties on the cinder MSA volume type for the
specific project we want to use this volume type in, and to set the
project-domain for this volume type. nothing has helped.

can anyone shed any light on this behavior or point out anything helpful in
the logs pls?

Looking at the logs I do see the _ member_ user is a non-default-domain
user while admin is obviously the default domain. other than that I can't
make heads or tails of the logs.

Here are logs if anyone wants to look at them:
a bad _ member_ volume creation was UUID
fb9047c3-1b6b-4d2b-bae8-5177e86eb1f2 https://pastebin.com/bmFAy6RR

a good admin volume creation was UUID b49e33db-8ab8-489f-b7cb-092f421178c1
https://pastebin.com/5SAecNJ2

We are using Newton, thanks!!!


-- Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20181011/579a03e2/attachment.html>


More information about the Openstack mailing list