[ovs-dev] [PATCH] ovn-controller: Add datapath-type in chassis:external_ids

Russell Bryant russell at ovn.org
Thu Jul 28 18:07:35 UTC 2016


On Thu, Jul 28, 2016 at 1:40 PM, Numan Siddique <nusiddiq at redhat.com> wrote:

> On Thu, Jul 28, 2016 at 10:28 PM, Ben Pfaff <blp at ovn.org> wrote:
>
> > On Thu, Jul 28, 2016 at 08:05:20PM +0530, Numan Siddique wrote:
> > > This patch reads the external_ids:datapath-type value from the
> > > Open_vSwitch table if defined and sets it in the
> > external_ids:datapath-type
> > > of Chassis table.
> >
> > What sets external_ids:datapath-type?  It isn't documented anywhere.
> >
>
> ​The way "ovn-bridge-mappings" is set, it is expected to set in the same
> way.
> I presume either the Administrator will set it or puppet or some other tool
> would set it.
> I will update the documentation accordingly.
>
>
We spoke about this briefly on IRC, but I think it would be better to read
the datapath_type column from the row in the Bridge table for br-int.


>
> > > This will provide hints to the CMS or clients monitoring OVN SB DB to
> > > determine the datapath type (DPDK or non-DPDK) configured and take some
> > > actions based on it.
> > >
> > > One usecase is, OVN neutron plugin can use this information to set the
> > > vif_type (ovs or vhostuser) during the port binding.
> >
> > Why would neutron need this information?  What does it use it for?
> >
>
> ​When a user creates a VM in an open stack deployment, open stack nova will
> select a compute host for the VM. Before booting the VM, nova asks neutron
> to create a port and also provides the host name. Neutron can read the
> datapath-type of the host from the OVN SB DB chassis table and tells nova
> if it is a dpdk host or normal host so that nova can plug the vif to the
> ovs bridge properly.
>
> With this approach, we can have openstack deployments with DPDK and
> non-DPDK compute hosts. Right now this mixed deployment is not supported.
>
> ​Russel, Ryan - Please correct me if I am wrong here.​


Yes, that's the use case.  It seems pretty round about, but this is easiest
way for us to integrate into OpenStack today.  Exposing it as an
external_id on the Chassis seemed like a pretty non-intrusive way to expose
the info.  Hopefully it's not *too* offensive.  :-)

-- 
Russell Bryant



More information about the dev mailing list