so for deferred ports there is an inherent race condition between the ip being
assigned and the
metadta being generated.
the ip will not be assinged when using deffered allocation until the
port is bound to a host which happen on the compute node right before we
boot the vm. neutron need to know which network segment the port will be
added too before it cna assign the ip so it need to knwo which host the
vm is on before it can do that.
when the assignemnt happens neutron should be sending a network-vif-
changed event to update nova info cache but that would require nova to
defer creation of the confdrive to after the prots are plugged.
the ironic integration is extra problematic because ironic is violating
our virt driver contract by creating the port bidning in neutron itself
as part fo the provisioning flow.
we have to generate and provide the confgi drive data before that
happens so this may be fundementlaly unfixable in the ironic case unless
we finally fix that and modify ironci so that it never modifies the
neutron prots.
unfortunatly that would break the idea fo ironic prot groups. port
groups only existit in ironic not nova or neutron so there is no way to
express them in the nova or neutron api.
so for irnic i dont see a way to fix this in the short ot medium term.
we may be ablel to move the config drive generation after port binding
and or port pluggin in the libvirt driver to ensure it has the most up
to date info
** Also affects: ironic
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2106073
Title:
Nova fails to generate network metadata with deferred ports
Status in Ironic:
New
Status in OpenStack Compute (nova):
New
Bug description:
When creating an instance with Nova using routed provider networks,
Nova creates a port with `ip_allocation` set to `deferred`. This will
let Neutron add an IP address to the interface once it's bound to a
host to ensure that it's part of the right segment.
When using this in combination with ConfigDrive, you end up with a
broken ConfigDrive with no links due to the fact that you have a
`network_info` on create that looks like this:
```
[
{
"id": "2f28d85a-c215-4c73-91cd-c7d965254711",
"address": "fa:16:3e:85:b4:60",
"network": {
"id": "8c178449-cc1f-4f02-8a58-09f09a975b59",
"bridge": null,
"label": "baremetal",
"subnets": [],
"meta": {
"injected": false,
"tenant_id": "14f0af4a69ea4148b7b18939ae2ebcca",
"mtu": 1500,
"physical_network": "external-rack001",
"tunneled": false
}
},
"type": "unbound",
"details": {},
"devname": "tap2f28d85a-c2",
"ovs_interfaceid": null,
"qbh_params": null,
"qbg_params": null,
"active": false,
"vnic_type": "normal",
"profile": {},
"preserve_on_delete": false,
"delegate_create": true,
"meta": {}
}
]
```
This `network_info` eventually refreshes later to be the correct
value, however, since that is what is used in spawn time, it's also
what is used in deploy time to geneate the config drive and never
updated, meaning that you end up with no correct network_data.json.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/2106073/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
