Composable roles require all services in Services list

Bug #1632289 reported by Steven Hardy
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tripleo
Expired
Undecided
Unassigned

Bug Description

Currently there's a couple of related issues related to our default definition for e.g ControllerServices and other roles.

1. We "enable" a bunch of services which are really disabled via OS::Heat::None - this will be confusing e.g if a Ux shows the list of "enabled" services.

2. When adding a new service to e.g the Controller role, you need to copy (and rebase forever) the entire ControllerServices list (same problem for all roles).

It'd be nice to use the new heat parameter_merge_strategy option to solve this, as I did in https://review.openstack.org/#/c/384618/1/test-environments/multinode.yaml but this doesn't work because we define the default ControllerServices list in overcloud.yaml (not an environment file).

If we moved the definition of the default *Services list into an environment file, these issues could be resolved via the parameter_merge_strategy method.

Steven Hardy (shardy)
Changed in tripleo:
status: New → Triaged
importance: Undecided → High
milestone: none → ocata-1
assignee: nobody → Steven Hardy (shardy)
tags: added: composable-roles
Steven Hardy (shardy)
Changed in tripleo:
milestone: ocata-1 → ocata-2
Changed in tripleo:
milestone: ocata-2 → ocata-3
Changed in tripleo:
milestone: ocata-3 → ocata-rc1
Revision history for this message
Steven Hardy (shardy) wrote :

Deferring to pike as fixing this will require tripleoclient changes, and the ocata tripleoclient is due for imminent release. We can perhaps backport this fix after it lands in (hopefully) early pike.

Changed in tripleo:
milestone: ocata-rc1 → pike-1
tags: added: ocata-backport-potential
Steven Hardy (shardy)
Changed in tripleo:
milestone: pike-1 → pike-2
Changed in tripleo:
milestone: pike-2 → pike-3
Changed in tripleo:
milestone: pike-3 → pike-rc1
Revision history for this message
Ben Nemec (bnemec) wrote :

Per Steve's previous comment I'm deferring this to Queens. I believe the client releases for Pike have already happened, so we're in the same situation we were back at the end of Ocata.

Changed in tripleo:
milestone: pike-rc1 → queens-1
Changed in tripleo:
milestone: queens-1 → queens-2
Changed in tripleo:
milestone: queens-2 → queens-3
Changed in tripleo:
milestone: queens-3 → queens-rc1
Changed in tripleo:
milestone: queens-rc1 → rocky-1
Changed in tripleo:
milestone: rocky-1 → rocky-2
Changed in tripleo:
milestone: rocky-2 → rocky-3
Changed in tripleo:
milestone: rocky-3 → rocky-rc1
Changed in tripleo:
milestone: rocky-rc1 → stein-1
Changed in tripleo:
milestone: stein-1 → stein-2
Revision history for this message
Emilien Macchi (emilienm) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (FUTURE, PIKE, QUEENS, ROCKY, STEIN).
  Valid example: CONFIRMED FOR: FUTURE

Changed in tripleo:
assignee: Steven Hardy (shardy) → nobody
importance: High → Undecided
status: Triaged → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.