In ironic, we have multiple places where we are calling network interface from inside the deployment interface, for both our main deployment machanisms - agent (e.g. https://github.com/openstack/ironic/blob/stable/ocata/ironic/drivers/modules/agent.py#L403) and iscsi (e.g. https://github.com/openstack/ironic/blob/stable/ocata/ironic/drivers/modules/iscsi_deploy.py#L471). From my POV, this brings several problems:
1. This makes the third party deploy driver maintainers to make changes to their drivers to support things like multitenancy, or the storage interface actions being currently proposed;
2. We can not ensure that third-party drivers are doing the right thing with networking setup (at least on the abstract level, this of course does not prevent anyone to write a flawed network interface), which may lead to security issues;
3. This basically means that our abstraction for interfaces is not good, as each interface should be doing a specific thing that is defined by the interfaces' API, and should not directly call other interfaces; instead, the coordination should be done in conductor.
Basically, to move the network interface calls to conductor, the changes are pretty minimal, as most of the things we do with networking are idempotent, so even if third party deploy interfaces will keep calling the network interface, they will not break. We'll also try to communicate that the conductor now deals with networking stuff, so there is no need to put it in the deploy interface.
The only change that might be non-trivial is finishing the deployment, as this is completely in control of the deployment interface, so in conductor, we don't know when do we have to switch to the tenant network. This can be mitigated by introducing some kind of callback (in task manager?) that will be called on 'done' event for nodes being deployed.
I'm not sure I think this a good idea, or the correct understanding of Ironic's architecture.
My understanding of the Ironic interface architecture is that the deploy interface is the main interface that understands the whole process for deploying that node and will use the other interfaces to achieve its goal. If that is the case then the conductor should only need to call the deploy interface for deploying a node and the deploy interface should be charge of calling power, network, boot etc at the right time in its particular deployment process which might differ depending on deployment process or hardware etc.