overcloud deployment fails on mistral action DeployStackAction

[Alfredo Moralejo]

When deploying tripleo from master repo, overcloud deploy fails with following error in stdout[1]:

2017-11-28 09:58:09 | u'version': u'2.0'},
2017-11-28 09:58:09 | u'updated_at': u'2017-11-28 09:57:36'},
2017-11-28 09:58:09 | u'message': u"Failed to run action [action_ex_id=3f5e4daa-d266-4f61-9c1c-ff3f226a604b, action_cls='<class 'mistral.actions.action_factory.DeployStackAction'>', attributes='{}', params='{u'skip_deploy_identifier': False, u'container': u'overcloud', u'timeout': 140}']\n ERROR: Internal Error",
2017-11-28 09:58:09 | u'status': u'FAILED'}

Looking at heat logs [2] i found following error:

2017-11-28 09:58:08.490 29964 ERROR heat.common.wsgi [req-0a6cefb5-beb2-4b61-b293-a50ffe375699 admin admin - default default] Unexpected error occurred serving API: Remote error: BadRequest Invalid input for field 'roles/1/name': u'_member_' does not match '^[a-zA-Z0-9-]+$'

Failed validating 'pattern' in schema['properties']['roles']['items']['properties']['name']:
    {'maxLength': 64,
     'minLength': 1,
     'pattern': '^[a-zA-Z0-9-]+$',
     'type': 'string'}

[1] https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset002-master-upload/5c3aa6c/undercloud/home/jenkins/overcloud_deploy.log.txt.gz
[2] https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset002-master-upload/5c3aa6c/undercloud/var/log/heat/heat_api.log.txt.gz

[Alfredo Moralejo (amoralej)]

Link to heat log with timestamp is https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset002-master-upload/5c3aa6c/undercloud/var/log/heat/heat_api.log.txt.gz#_2017-11-28_09_58_08_490

[Steven Hardy (shardy)]

Ok so looking at the logs it seems like a potential keystone regression, as we're failing validating the _member_ role when creating the trust.

This looks possibly related:

https://github.com/openstack/keystone/commit/f8e79ab50775bcf5964c7547297577d0a3b82519

raildo is going to discuss with the keystone team about possibly relaxing this validation and/or special-casing the _member_ role.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/523415

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/523415
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=f97df5cb6ff1b3fc0a1c18967c4eefff9e7670ce
Submitter: Zuul
Branch: master

commit f97df5cb6ff1b3fc0a1c18967c4eefff9e7670ce
Author: Colleen Murphy <email address hidden>
Date: Tue Nov 28 14:33:04 2017 +0100

    Fix role schema in trust object

    Previously, we weren't doing any validation on the roles attribute of a
    trust except to validate that it was an array. A hasty glance, however,
    would lead you to believe that it was validating an array of
    parameter_types.id_string[1] and so we translated that to the new role
    object validation. However, id_string doesn't include some valid role
    names like _member_. This patch updates the role name schema to match
    parameter_types.name, which is the same as the schema for the main role
    object.

    [1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/trust/schema.py?id=62f9e57cd81dc98c5816da9fa483d385b4c1a66c#n41

    Change-Id: I83aafc7a96e81a9b6b1056b39cd8c5d23676c014
    Closes-bug: #1734871

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 13.0.0.0b2 development milestone.