Looking onto that 'net_config_override = net-config-override.json' thing http://codesearch.openstack.org/?q=net_config_override&i=nope&files=&repos=, it seems we need to rework it in quickstart and implement instack parity for the client's heat installer as well. See http://codesearch.openstack.org/?q=undercloud_resource_registry_args&i=nope&files=&repos= ?
When undercloud_net_config_override is defined in quickstart,
it should only set net_config_override in undercloud.conf and omit generating undercloud-parameter-defaults.yaml.j2 from undercloud_resource_registry_args and undercloud_network_environment_args. Otherwise, the generated undercloud-parameter-defaults.yaml should be set in undercloud.conf's net_config_override instead.
From the client side, net_config_override needs to be wired in and processed, when it is a template file, with a given context, like instack does/did.
This improves upgrades UX when there had been custom net config used for the original instack deployment, which needs to be upgraded into containerized undercloud w/o manual steps, like translating that original net config into something consumable and working well in t-h-t.
Let me clarify, the context is the containerized undercloud, the bug will only affect the future instack to containerized UC regression check job, that verifies undercloud.conf against regressions after upgrades from instack to heat installer for undercloud:
3:53:44 PM GMT+2 - bogdando: we have a 2 interfaces to generate net config for UC
3:54:11 PM GMT+2 - bogdando: the one, based on instack net_config_override should be wired back in
3:54:27 PM GMT+2 - bogdando: the 2nd may be kept or removed
3:54:48 PM GMT+2 - bogdando: but I hope to see it there, it repeats the approach we have for overcloud net config
3:55:14 PM GMT+2 - bogdando: we have no such a job yet