[openstack-dev] [ironic][neutron] ML2 plugin for Ironic needs

Ihar Hrachyshka ihrachys at redhat.com
Tue Oct 11 09:35:06 UTC 2016


Vasyl Saienko <vsaienko at mirantis.com> wrote:

> Hello Community,
>
> Ironic and Neutron projects have become integrated even closer with  
> multitenancy implementation in Ironic.
> There are 2 bugs that require separate ML2 driver specifically for Ironic  
> needs:
>
> 	• Booting ironic instance, Neutron port remains in down state [0]
> 	• Ironic needs to synchronize port status change events with Neutron [1]
>
> I was told (commented) that keeping code in Neutron tree is not right  
> approach [2]. Of course I agree that Neutron has powerful and flexible  
> support of out-of-tree ML2 drivers and such functionality must be a  
> separate ML2 plugin.
>
> So the question to consult with the whole community:
> Do we need a new networking-ironic-* ML2 driver?
>
> To fix [0] and [1] we can use existing networking-generic-switch [3] ML2  
> driver [4,5]. It was designed specially for Ironic case. It already helps  
> us to test Ironic multitenancy on the gates.
>
> My team would prefer supporting one driver without multiplying entities.

If I understand the matter correctly, Ironic may want to adopt the existing  
repository as part of its official deliverables, so probably governance  
discussion should happen between ironic and networking-generic-switch core  
teams. (At the moment, the driver is not even part of Big Tent).  
Alternatively, Ironic may just declare dependency on that other project for  
its networking multi-tenancy.

What I see in the code, the ml2 driver just executes switch specific  
commands via ssh, so the device driver is just a declaration of those  
commands, with some substitution involved. Meaning, the switch specific  
code is really tiny, and should not be a huge burden to maintain for Ironic  
team if they choose so.

To answer your question, I don’t think we need another driver if an  
existing one may cover your needs, but governance should be considered.  
That said, seeing you in the core team of the existing driver repo, I  
believe it’s solvable.

Ihar



More information about the OpenStack-dev mailing list