Defining networks inconvenient when deploying multiple overclouds
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Expired
|
Undecided
|
Unassigned |
Bug Description
TripleO can now be used to deploy multiple overclouds with the "--stack" option. Whilst this is nice, you cannot deploy >1 overcloud that uses the same templates with the same overcloud network names. It's only possible to utilise the ctlplane network for both, which limits its use. It would be great to deploy multiple overclouds, utilising the same network names, albeit with different subnet allocations or VLANs.
Error shown upon deployment of second overcloud:
2016-10-11 11:05:41Z [region-two]: CREATE_FAILED Resource CREATE failed: Conflict: resources.
It doesn't make sense to have to create a new templates branch with different network names given the amount of references that exist within the templates directory.
Changed in tripleo: | |
milestone: | none → ocata-1 |
status: | New → Triaged |
Changed in tripleo: | |
milestone: | ocata-1 → ocata-2 |
importance: | Low → Medium |
Changed in tripleo: | |
milestone: | ocata-2 → ocata-3 |
Changed in tripleo: | |
milestone: | ocata-3 → pike-1 |
Changed in tripleo: | |
milestone: | pike-1 → pike-2 |
Changed in tripleo: | |
milestone: | pike-2 → pike-3 |
Changed in tripleo: | |
milestone: | pike-3 → pike-rc1 |
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 |
Thanks for the report Rhys - I'm not certain tho if this is a bug or a usability issue - I think we by design don't want multiple overclouds to use the same networks (or they will no longer be isolated), but we do need a better way to easily set the parameters so that things (names in this case) don't collide or overlap.
To get past the issue you're encountering, I think it's probably enough to simply pass a non-default name (e.g something that's unique per stack):
$ cat net-env.yaml tName: internal2 Name: management2 tName: storagemgmt2
parameter_defaults:
ExternalNetName: external2
InternalApiNe
ManagementNet
StorageMgmtNe
StorageNetName: storage2
TenantNetName: tenant2
etc
Would that resolve your problem?