tripleo-heat-templates for Cisco Ml2 plugins to be made compatible with composable roles
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Sandhya Dasu |
Bug Description
Not all ML2 plugins have moved to the new composable role model. This is causing the triplet-
For example in:
https:/
Pasting for reference:
CollectMacDeplo
type: OS::Heat:
properties:
name: CollectMacDeplo
servers: {get_param: [servers, Compute]}
config: {get_resource: CollectMacConfig}
actions: ['CREATE'] # Only do this on CREATE
This block of code assumes that the compute role is called "Compute". When compute hosts are assigned different role names, then this block of code just ignores all compute hosts.
The above block of code should be able to act on a set of compute hosts with roles containing the substring "compute". The server specification should take a regular expression rather than a fixed role called "Compute".
Changed in tripleo: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → pike-3 |
summary: |
- cisco-nexus-ucsm integration not compatible with custom roles + tripleo-heat-templates for Cisco Ml2 plugins to be made compatible with + composable roles |
I would make this bug specific to the cisco integration, then we can raise follow-up bugs for any other integrations which need updating.
I think the cisco integration is something of a special case, because it won't convert cleanly to a composable service due to this logic that collects mac addresses:
https:/ /github. com/openstack/ tripleo- heat-templates/ blob/master/ puppet/ extraconfig/ all_nodes/ neutron- ml2-cisco- nexus-ucsm. yaml#L158
I think the simplest short term approach is to convert the ml2-cisco- nexus-ucsm. yaml to ml2-cisco- nexus-ucsm. j2.yaml and use jinja2 templating (as in
neutron-
neutron-
many other places in t-h-t to support custom roles) to template the
yaml file for all roles. This could be considered a bugfix and
probably backported to newton I think, then we can consider options for refactoring into composable service templates as a second step.
I think you'll need a
j2 loop similar to this:
https:/ /github. com/openstack/ tripleo- heat-templates/ blob/master/ extraconfig/ all_nodes/ swap.j2. yaml#L42
There are some details about how this works in this blog post:
https:/ /hardysteven. blogspot. co.uk/2016/ 10/tripleo- composablecusto m-roles. html
You can test it by renaming your current yaml file, then running process- templates. py (which does the same rendering we do on
./tools/
plan creation in tripleo-common)