Open Stack

Hi Renat


The issue with cron triggers and identity:validate_token was fixed with 
the above patch.

We could then use cron triggers for instance with 
nova.servers_create_image or cinder.volume_snapshots_create with success.


But we hit another issue with cinder.backups_create .

This call will stores the backup on our swift backend (ceph rgw).

The workflow works when executed directly

but it fails when executed via cron trigger:

2019-09-17 10:46:04.525 8 ERROR oslo_messaging.rpc.server 
ClientException: Container PUT failed: 
http://rgw.service.stage.i.ewcs.ch/swift/v1/AUTH_aeac4b07d8b144178c43c65f29fa9dac/volumebackups 
401 Unauthorized   AccessDenied


I will repost this under Subject: cron triggers execution fails with 
cinder.volume_snapshots_create as this is separate issue.



Cheers

Francois


On 9/16/19 5:23 AM, Renat Akhmerov wrote:
> Hi!
>
> Are you aware of other issues with cron triggers and trusts? I’d like 
> to reconcile all of that somehow. The users who I personally work with 
> don’t use cron triggers so I don’t have that much practical experience 
> with them.
>
> Thanks
>
> Renat Akhmerov
> @Nokia
> On 13 Sep 2019, 20:34 +0700, Francois Scheurer 
> <francois.scheurer at everyware.ch>, wrote:
>>
>> Hi Sa Pham
>>
>>
>> Yes this is the good one.
>>
>> Bo Tran pointed it to me yesterday as well and it fixed the issue.
>>
>> See also: https://bugs.launchpad.net/mistral/+bug/1843175
>>
>> Many Thanks to both of you !
>>
>>
>> Best Regards
>>
>> Francois Scheurer
>>
>>
>>
>>
>> On 9/13/19 3:23 PM, Sa Pham wrote:
>>> Hi Francois,
>>>
>>> You can try this patch: https://review.opendev.org/#/c/680858/
>>>
>>> Sa Pham
>>>
>>> On Thu, Sep 12, 2019 at 11:49 PM Francois Scheurer 
>>> <francois.scheurer at everyware.ch 
>>> <mailto:francois.scheurer at everyware.ch>> wrote:
>>>
>>>     Hello
>>>
>>>
>>>
>>>     Apparently other people have the same issue and cannot use cron
>>>     triggers anymore:
>>>
>>>     https://bugs.launchpad.net/mistral/+bug/1843175
>>>
>>>
>>>     We also tried with following patch installed but the same error
>>>     persists:
>>>
>>>     https://opendev.org/openstack/mistral/commit/6102c5251e29c1efe73c92935a051feff0f649c7?style=split
>>>
>>>
>>>
>>>     Cheers
>>>
>>>     Francois
>>>
>>>
>>>
>>>
>>>     On 9/9/19 6:23 PM, Francois Scheurer wrote:
>>>>
>>>>     Dear All
>>>>
>>>>
>>>>     We are using Mistral 7.0.1.1 with  Openstack Rocky. (with
>>>>     federated users)
>>>>
>>>>     We can create and execute a workflow via horizon, but cron
>>>>     triggers always fail with this error:
>>>>
>>>>         {
>>>>             "result":
>>>>                 "The action raised an exception [
>>>>     action_ex_id=ef878c48-d0ad-4564-9b7e-a06f07a70ded,
>>>>                         action_cls='<class
>>>>     'mistral.actions.action_factory.NovaAction'>',
>>>>     attributes='{u'client_method_name': u'servers.find'}',
>>>>                         params='{
>>>>                             u'action_region': u'ch-zh1',
>>>>                             u'name':
>>>>     u'42724489-1912-44d1-9a59-6c7a4bebebfa'
>>>>                         }'
>>>>                     ]
>>>>                     \n NovaAction.servers.find failed: You are not
>>>>     authorized to perform the requested action:
>>>>     identity:validate_token. (HTTP 403) (Request-ID:
>>>>     req-ec1aea36-c198-4307-bf01-58aca74fad33)
>>>>                 "
>>>>         }
>>>>
>>>>     Adding the role *admin* or *service* to the user logged in
>>>>     horizon is "fixing" the issue, I mean that the cron trigger
>>>>     then works as expected,
>>>>
>>>>     but it would be obviously a bad idea to do this for all normal
>>>>     users ;-)
>>>>
>>>>     So my question: is it a config problem on our side ? is it a
>>>>     known bug? or is it a feature in the sense that cron triggers
>>>>     are for normal users?
>>>>
>>>>
>>>>     After digging in the keystone debug logs (see at the end
>>>>     below), I found that RBAC check identity:validate_token an deny
>>>>     the authorization.
>>>>
>>>>     But according to the policy.json (in keystone and in horizon),
>>>>     rule:owner should be enough to grant it...:
>>>>
>>>>                 "identity:validate_token":
>>>>     "rule:service_admin_or_owner",
>>>>                     "service_admin_or_owner":
>>>>     "rule:service_or_admin or rule:owner",
>>>>                         "service_or_admin": "rule:admin_required or
>>>>     rule:service_role",
>>>>                             "service_role": "role:service",
>>>>                         "owner": "user_id:%(user_id)s or
>>>>     user_id:%(target.token.user_id)s",
>>>>
>>>>     Thank you in advance for your help.
>>>>
>>>>
>>>>     Best Regards
>>>>
>>>>     Francois Scheurer
>>>>
>>>>
>>>>
>>>>
>>>>     Keystone logs:
>>>>
>>>>             2019-09-05 09:38:00.902 29 DEBUG
>>>>     keystone.policy.backends.rules
>>>>     [req-1a276b9d-8276-4ec3-b516-f51f86cd1df6 fsc fscproject -
>>>>     testdom testdom]
>>>>                 enforce identity:validate_token:
>>>>                 {
>>>>                    'service_project_id':None,
>>>>                    'service_user_id':None,
>>>>                    'service_user_domain_id':None,
>>>>                    'service_project_domain_id':None,
>>>>                    'trustor_id':None,
>>>>                    'user_domain_id':u'testdom',
>>>>                    'domain_id':None,
>>>>                    'trust_id':u'mytrustid',
>>>>                    'project_domain_id':u'testdom',
>>>>                    'service_roles':[],
>>>>                    'group_ids':[],
>>>>                    'user_id':u'fsc',
>>>>                    'roles':[
>>>>                       u'_member_',
>>>>                       u'creator',
>>>>                       u'reader',
>>>>                       u'heat_stack_owner',
>>>>                       u'member',
>>>>                       u'load-balancer_member'],
>>>>                    'system_scope':None,
>>>>                    'trustee_id':None,
>>>>                    'domain_name':None,
>>>>                    'is_admin_project':True,
>>>>                    'token':<TokenModel
>>>>     (audit_id=0LAsW_0dQMWXh2cTZTLcWA,
>>>>     audit_chain_id=[u'0LAsW_0dQMWXh2cTZTLcWA']) at 0x7f208f4a3bd0>,
>>>>                    'project_id':u'fscproject'
>>>>                 } enforce
>>>>     /var/lib/kolla/venv/local/lib/python2.7/site-packages/keystone/policy/backends/rules.py:33
>>>>             2019-09-05 09:38:00.920 29 WARNING keystone.common.wsgi
>>>>     [req-1a276b9d-8276-4ec3-b516-f51f86cd1df6 fsc fscproject -
>>>>     testdom testdom]
>>>>                 You are not authorized to perform the requested
>>>>     action: identity:validate_token.: *ForbiddenAction: You are not
>>>>     authorized to perform the requested action:
>>>>     identity:validate_token.*
>>>>
>>>>
>>>>     --
>>>>
>>>>
>>>>     EveryWare AG
>>>>     François Scheurer
>>>>     Senior Systems Engineer
>>>>     Zurlindenstrasse 52a
>>>>     CH-8003 Zürich
>>>>
>>>>     tel: +41 44 466 60 00
>>>>     fax: +41 44 466 60 10
>>>>     mail:francois.scheurer at everyware.ch  <mailto:francois.scheurer at everyware.ch>
>>>>     web:http://www.everyware.ch  
>>>
>>>     --
>>>
>>>
>>>     EveryWare AG
>>>     François Scheurer
>>>     Senior Systems Engineer
>>>     Zurlindenstrasse 52a
>>>     CH-8003 Zürich
>>>
>>>     tel: +41 44 466 60 00
>>>     fax: +41 44 466 60 10
>>>     mail:francois.scheurer at everyware.ch  <mailto:francois.scheurer at everyware.ch>
>>>     web:http://www.everyware.ch  
>>>
>>>
>>>
>>> --
>>> Sa Pham Dang
>>> Master Student - Soongsil University
>>> Kakaotalk: sapd95
>>> Skype: great_bn
>>>
>>>
>> --
>>
>>
>> EveryWare AG
>> François Scheurer
>> Senior Systems Engineer
>> Zurlindenstrasse 52a
>> CH-8003 Zürich
>>
>> tel: +41 44 466 60 00
>> fax: +41 44 466 60 10
>> mail:francois.scheurer at everyware.ch
>> web:http://www.everyware.ch  

-- 


EveryWare AG
François Scheurer
Senior Systems Engineer
Zurlindenstrasse 52a
CH-8003 Zürich

tel: +41 44 466 60 00
fax: +41 44 466 60 10
mail: francois.scheurer at everyware.ch
web: http://www.everyware.ch

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190919/3390cc30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190919/3390cc30/attachment-0001.bin>