Allow overriding network names
Features like multiple overclouds require network names to be unique, so we have to override them. Currently, it requires overriding everything in ServiceNetMap, which is bulky and error-prone. It would be better if e.g. the default for internal_api was not hardcoded, but instead was taken from InternalApiNetw
Blueprint information
- Status:
- Complete
- Approver:
- Steven Hardy
- Priority:
- Low
- Drafter:
- Dmitry Tantsur
- Direction:
- Approved
- Assignee:
- Steven Hardy
- Definition:
- Approved
- Series goal:
- Accepted for stein
- Implementation:
- Implemented
- Milestone target:
- None
- Started by
- Juan Antonio Osorio Robles
- Completed by
- Juan Antonio Osorio Robles
Related branches
Related bugs
Bug #1632327: Defining networks inconvenient when deploying multiple overclouds | Expired |
Sprints
Whiteboard
[2019-03-28] (aschultz) This was implemented with network_data.yaml allowing for substituting networks for the defined networks.
[2017-12-08] Moving out to future as there doesn't appear to be any work around this yet.
(shardy) we need to decide if we want e.g InternalApiNetw
(dsneddon) this may be an opportunity for us to think about how to allow the creation of custom networks in addition to customizing the names of existing networks. If the network information came from a map, that might help with both use cases.
(jaosorior) I think this would be a good addition. And it could surely be done in a similar fashion as the composable roles were done (with jinja maybe?) We do need a structure that contains attributes for those networks. Something we can use even for the internal TLS work, cause right now I'm using the hardcoded ones. And also, we need a way to generate dynamic facts in puppet. Cause we do have hardcoded puppet facts for the networks.