Allow overriding network names

Registered by Dmitry Tantsur on 2016-09-13

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 InternalApiNetworkName variable.

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 on 2019-03-11
Completed by
Juan Antonio Osorio Robles on 2019-03-11

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 InternalApiNetworkName as a hard-coded parameter, or a more flexible NetworkNameMap - I'd probably prefer the latter.
(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.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.