provisioning and deploying network layouts must be in sync

[Kevin Carter]

When provisioning nodes the networks must be defined within the baremetal configuration file. Networks within the baremetal configuration file must map to the items defined in the net-data file.

When deploying an environment, the networks defined in the roles-data file must match the networks in the baremetal configuration. If the networks in the baremetal configuration and roles-data files do not match, when running a deployment os-net-config will reconfigure the node's networking and may result in a broken environment.

The issue here is a UX problem as deployers need to match configuration information across multiple files with different syntax. As a deployer I should only have to setup the network information for a given node once, in one spot.

We should figure out a way to unify the configs or allow users to provide input into the execution for a simplified user experience.

[Rabi Mishra (rabi)]

We (Harald and me) had a discussion[1] about this sometime back. We duplicate more than networks in roles_data and baremetal deployment input file.

I was of the opinion that there should be single source of truth, but seems there are more complications. May be we can get away with some validation atleast.

[1]https://meetings.opendev.org/irclogs/%23tripleo/%23tripleo.2021-05-27.log.html#t2021-05-27T08:06:16

ramishra hjensas: btw, we seem to be keep role->network information both in baremetal_deployment.yaml and roles_data.yaml, they can possibly go out of sync, right? probably use roles_data.yaml in overcloud node provision? 08:06

ramishra or we plan to migrate/remove those from roles_data? Probably those information not used with network-data-v2? 08:08

hjensas ramishra: all the jinja2 in THT that use role.networks would have to go, for instance it's many many places where we do "network.name in role.networks". 08:13
ramishra hjensas: OK, probably merge those 2 file contents to roles_data.yaml so it can be easily managed, IMHO we need to use one source of truth 08:15

hjensas ramishra: yes, this problem is'nt only with networks, we duplicate in roles_data.yaml vs baremetal_deployment.yaml, there is CountDefault vs count, HostnameFormatDefault vs hostname_format and probably some more. 08:24

ramishra hjensas: yeah, that's correct and can lead to numerous support cases.. 08:26

ramishra bogdando: right, 'overcloud deploy' is a complete mess atm with so may options. I don't know if many of the options work either. Also there are plans to add more options for netowrk/port provisioning;) 08:28

hjensas ramishra: I feel there are two goals pulling in different direction, a) separate baremetal and network provisioning, b) One source of truth. If we want a) we should avoid defining overcloud service's and service config in what drives the node provisioning and network provisioning. With b) we end up with a huge merged yaml where it is easy to "get lost" when editing it. 08:29

ramishra hjensas: I'm fine having multiple files, but not overlapping

[James Slagle (james-slagle)]

My opinion would be to only specify the data in our roles data file and keep that as the single source of truth. The "overcloud node" commands could be updated to take as input the roles data and an instances data that only specified the instance specific information.