Bug 1588838

Summary:	Unable to add a custom role with a new name in UI.
Product:	Red Hat OpenStack	Reporter:	Alexander Chuzhoy <sasha>
Component:	openstack-tripleo-common	Assignee:	Dougal Matthews <dmatthew>
Status:	CLOSED ERRATA	QA Contact:	Alexander Chuzhoy <sasha>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	13.0 (Queens)	CC:	apannu, beth.white, dmacpher, dmatthew, dtrainor, jschluet, jtomasek, mburns, sclewis, slinaber, ukalifon
Target Milestone:	rc	Keywords:	Triaged
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-tripleo-common-8.6.1-20.el7ost	Doc Type:	Bug Fix
Doc Text:	The tripleo.plan_management.v1.update_roles workflow did not pass the overcloud plan name (swift container name) or zaqar queue name to the sub-workflow it triggered. This caused incorrect behaviour when using an overcloud plan name other than the default ('overcloud'). This fix correctly passes these parameters and restores the correct behaviour.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-27 13:57:12 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alexander Chuzhoy 2018-06-07 23:36:21 UTC

Unable to add a custom role with a new name in UI.

Environment:
instack-undercloud-8.4.1-4.el7ost.noarch
openstack-tripleo-heat-templates-8.0.2-31.el7ost.noarch
openstack-tripleo-ui-8.3.1-3.el7ost.noarch


Created a custom role named ControllerNoNetworker and after running:
openstack object create <planname> roles/ControllerNoNetworker.yaml saw it in the list of roles (after clicking on "Manage roles".
When I checked the box next to the new role to have it listed under "Configure Roles and Assign Nodes" , the following error appeared:

Invalid roles requested: ControllerNoNetworker Valid Roles: BlockStorage CephAll CephFile CephObject CephStorage Compute ComputeAlt ComputeDVR ComputeHCI ComputeInstanceHA ComputeLiquidio ComputeOvsDpdk ComputeOvsDpdkRT ComputeRealTime ComputeSriov ComputeSriovRT Controller ControllerAllNovaStandalone ControllerNoCeph ControllerNovaStandalone ControllerOpenstack Controller Database HciCephAll HciCephFile HciCephMon HciCephObject IronicConductor Messaging Networker Novacontrol ObjectStorage Telemetry Undercloud Undercloud

Comment 1 Jiri Tomasek 2018-06-08 08:10:29 UTC

The problem is in tripleo.plan_management.v1.update_roles as the workflow does not pass container and queue_name inputs to list_available_roles subworkflow:

update_roles:
    description: >
      takes data in json format validates its contents and persists them in
      roles_data.yaml, after successful update, templates are regenerated.
    input:
      - container
      - roles
      - roles_data_file: 'roles_data.yaml'
      - replace_all: false
      - queue_name: tripleo
    tags:
      - tripleo-common-managed
    tasks:
      get_available_roles:
        workflow: list_available_roles
        publish:
          available_roles: <% task().result.available_roles %>
        on-success: validate_input
        on-error: notify_zaqar
        publish-on-error:
          status: FAILED
          message: <% task().result %>


when I add input for get_available_roles task and update workbook, selecting custom role works correctly.
input:
  container: <% $.container %>
  queue_name: <% $.queue_name %>

I would consider this a blocker as this bug prevents to enable custom roles on non default ('overcloud') deployment plans. (Same impact as previous bug https://bugzilla.redhat.com/show_bug.cgi?id=1588838

Comment 2 Udi Kalifon 2018-06-10 06:53:28 UTC

See also bug https://bugzilla.redhat.com/show_bug.cgi?id=1573965 which is probably related. I raised that bug to urgent/blocker.

Comment 6 Alexander Chuzhoy 2018-06-12 20:31:08 UTC

Verified:

Environment:
openstack-tripleo-common-8.6.1-20.el7ost.noarch


The reported issue doesn't reproduce.
Was able to add a new custom role.

Comment 8 errata-xmlrpc 2018-06-27 13:57:12 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:2086