Users with _member_ or member roles cannot use cinder-volume via Horizon Dashboard

[Cody]

Users with _member_ or member roles are unable to use cinder-volume via Horizon Dashboard.

Version:
Queens

Environment:
openstack-dashboard-13.0.2-0.20180913182351.c7dc4b4.el7.noarch
openstack-cinder-12.0.4-0.20181005163903.8b1aa5f.el7.noarch
python2-cinderclient-3.5.0-0.20180211213738.1de605c.el7.centos.noarch
python-cinder-12.0.4-0.20181005163903.8b1aa5f.el7.noarch
puppet-cinder-12.4.1-0.20180831230802.22ee15c.el7.noarch
puppet-horizon-12.4.1-0.20180921011912.0177965.el7.noarch

How reproducible:
Every time. Tested with file, nfs, rbd cinder backends.

Step to reproduce:
1. Assign a user with either _member_ or member role to a project;
2. Log in as the user and switch to the project;
3. Go to Project -> Compute -> Instances, click on "Launch Instance" to get following errors:

  Error: Unable to retrieve the volume snapshots.
  Error: Unable to retrieve the volumes.

(Notice that users are unable to choose volume as a boot source from Source)

4. Go to Project -> Volumes -> Volumes, Click on "Create Volume" to get following errors:

  Error: Unable to retrieve list of volumes.
  Error: Unable to retrieve volume snapshots.

These problems only affect users using Horizon Dashboard. The same users have no issues with cinder-volume service via CLI.

[James Okken (jokken)]

codylab suggested i might have a very similar issue.

On Newton i am using the cinder.volume.drivers.san.hp.hpmsa_fc.HPMSAFCDriver driver for a second volume/cinder backend.

A _member_ user on the command line is creating volumes on the correct storage backend, our HP MSA).

But while in Horizon the _member_ user is creating volumes on the incorrect storage backend (our RBD/CEPH), even though the same MSA volume type as on the command line is being selected

any news on a fix for this I'd love to overlay/dropfile a fix into my Newton environment.

thanks!

[Jesse Pretorius (jesse-pretorius)]

Fixed in OSA and release in 18.1.3

[James Okken (jokken)]

sorry for the naive question. if the last comment says "fix released" does that mean there is a fix I can find somewhere? I would like to test this in my environment. thanks!

[Harald Moeller (h.moeller)]

sorry, but I would have the very same "naive question" ... Thx Harry

[Jesse Pretorius (jesse-pretorius)]

@James For OSA, this was fixed in release 18.1.3 - so you can use that or anything later.

[James Okken (jokken)]

could we please have some direction as to where and what the bug and the fix is? is it something that can be applied in place to an working older environment?

[Jesse Pretorius (jesse-pretorius)]

@James - Apologies for the delayed response, it took me a while to track this down. I believe that the fix was https://review.opendev.org/#/q/I0f699c9869effc5ccc0d3f79422935975f698134 in OSA. If you're using an older environment than one with that present, you could implement that patch. IIRC it was not applicable to anything Queens and before - it was only a Rocky bug which was fixed in 18.0.3/Rocky and pre-release for Stein.