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

[Ben Pfaff]

On Thu, Jul 28, 2016 at 02:07:35PM -0400, Russell Bryant wrote:
> 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.  :-)

It's really the idea of adding a external-ids:datapath-type to the
Open_vSwitch table that bothered me the most.  If we can get it from
existing data in br-int, that's much better.