During multi-tenancy testing, I discovered an undesirable behavior.
In /etc/ironic/ironic.conf, I specify the provisioning and cleaning networks by name so that I do not have to deal with the UUIDs - to make the scripts work better.
The config looks like :
[neutron]
cleaning_network = ironic-provision
provisioning_network = ironic-provision
This all works fine, except, if I delete the provisioning network and recreate it, Ir-cond remembers the old network's UUID and tries to create ports on old network which is rejected by Neutron, and hence, all BM deploy operations will fail. Instead of remembering the network UUID, conductor should read the config variable for provisioning (and cleaning networks).
The work around is restart ir-cond - which is kind of annoying.
This is caused by the conductor caching the neutron network uuid after pulling it from neutron, I think we should fix this by removing the is not None check in these functions:
https:/