Description of problem: Openstack on virsh , 1 controller, 1 compute and 1 ceph node Tempest trying to create an encrypted volume , fixed_key was working. Having issue with policy pemission. Can we force in barbican default policy to support order_creation ?? What about policy.json file with rules ? Trying to run tempest code (downstream) , When trying to create a volume , barbican main.log message: 2018-04-09 08:13:53.222 21 DEBUG barbican.api.controllers.quotas [-] === Creating ProjectsQuotaController === __init__ /usr/lib/python2.7/site-packages/barbican/api/controllers/quotas.py:117 2018-04-09 08:13:53.222 21 DEBUG barbican.api.controllers.secretstores [-] Creating SecretStoresController __init__ /usr/lib/python2.7/site-packages/barbican/api/controllers/secretstores.py:131 2018-04-09 08:13:53.224 21 INFO barbican.api.app [-] Barbican app created and initialized 2018-04-09 08:13:53.228 21 WARNING keystonemiddleware._common.config [-] The option "__file__" in conf is not known to auth_token 2018-04-09 08:13:53.229 21 WARNING keystonemiddleware._common.config [-] The option "here" in conf is not known to auth_token 2018-04-09 08:13:53.230 21 WARNING keystonemiddleware.auth_token [-] AuthToken middleware is set with keystone_authtoken.service_token_roles_required set to False. This is backwards compatible but deprecated beh aviour. Please set this to True. 2018-04-09 08:13:53.233 21 WARNING oslo_config.cfg [-] Option "auth_uri" from group "keystone_authtoken" is deprecated. Use option "www_authenticate_uri" from group "keystone_authtoken". 2018-04-09 08:13:53.239 21 DEBUG barbican.api.controllers.versions [-] === Creating VersionsController === __init__ /usr/lib/python2.7/site-packages/barbican/api/controllers/versions.py:121 2018-04-09 08:14:18.399 27 WARNING keystonemiddleware.auth_token [-] Using the in-process token cache is deprecated as of the 4.2.0 release and may be removed in the 5.0.0 release or the 'O' development cycle. T he in-process cache causes inconsistent results and high memory usage. When the feature is removed the auth_token middleware will not cache tokens by default which may result in performance issues. It is recomme nded to use memcache for the auth_token token cache by setting the memcached_servers option. 2018-04-09 08:14:19.226 27 DEBUG oslo_policy.policy [-] The policy file /etc/barbican/policy.json could not be found. load_rules /usr/lib/python2.7/site-packages/oslo_policy/policy.py:548 2018-04-09 08:14:19.233 27 ERROR barbican.api.controllers [req-c4093da4-1296-450c-beae-953e3eb1e991 8325cbdefc7e491a95a60670c16d273a - - default default] Order creation attempt not allowed - please review your u ser/project privileges: PolicyNotAuthorized: orders:post is disallowed by policy 2018-04-09 08:14:19.235 27 INFO barbican.api.middleware.context [req-c4093da4-1296-450c-beae-953e3eb1e991 8325cbdefc7e491a95a60670c16d273a - - default default] Processed request: 403 Forbidden - POST http://172. 17.1.16:9311/v1/orders/ 2018-04-09 08:14:21.840 25 WARNING keystonemiddleware.auth_token [-] Using the in-process token cache is deprecated as of the 4.2.0 release and may be removed in the 5.0.0 release or the 'O' development cycle. T he in-process cache causes inconsistent results and high memory usage. When the feature is removed the auth_token middleware will not cache tokens by default which may result in performance issues. It is recomme nded to use memcache for the auth_token token cache by setting the memcached_servers option. Version-Release number of selected component (if applicable): How reproducible: Run tempest code (downstream) and try to create volume with none admin user. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Where are the log files?
> 2018-04-09 08:14:19.233 27 ERROR barbican.api.controllers [req-c4093da4-1296-450c-beae-953e3eb1e991 8325cbdefc7e491a95a60670c16d273a - - default default] Order creation attempt not allowed - please review your u ser/project privileges: PolicyNotAuthorized: orders:post is disallowed by policy This happens if the request to Barbican to create the key is made by a user that isn't in the creator role.
Yes, this definitely sounds like the user not having the creator role.
(In reply to Ade Lee from comment #3) > Yes, this definitely sounds like the user not having the creator role. Is it a configuration needed to be done in tripleO during the barbican installation or part of project configuration?
Hi all , I just installed devstack with barbican , Looks like redhat installer should install as devstack with prepared roles . [stack@localhost ~]$ openstack role list +----------------------------------+---------------------------+ | ID | Name | +----------------------------------+---------------------------+ | 0f515ce019fe4144bba109a834df4752 | observer | | 269c25ca337b4c0aa322ebda20b3ad7c | admin | | 278a91beda464af19cd068502592972f | service | | 770c909071cc446a9bd0d5156f9fa913 | creator | | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | | a3eea10c8998431fb1d24ba5d32ee300 | anotherrole | | c656cac112e44ef9a253d303659ca242 | Member | | cc11bfa9b8094080a8630ebd7a8a38ff | audit | | f4d91c39792147e998e3affe20766a24 | ResellerAdmin | | fd827c52074f4d9997128ffb89a3ea78 | key-manager:service-admin | +----------------------------------+---------------------------+ if rhos installer will not install barbican properly , we will be blocked in our testing.
Well, devstack has the luxury of performing any amount of post-deployment setup operations. There are a number of day-1 operations that OSP expects the Admin to perform that are not considered part of the TripleO deployment, so we need to be careful when comparing TripleO and devstack deployments. The question is, what does the OSP documentation for Barbican say?
Till this is incorporated we have a workaround, on undercloud from admin user: #openstack role create creator #openstack role add --user demo creator --project demo Where demo is user name and project name in my case. Unset blocker flags.
*** This bug has been marked as a duplicate of bug 1664429 ***