[ovs-dev] [PATCH v2 2/2] [RFC] ovn: Start work on design documentation.

Ben Pfaff blp at nicira.com
Thu Feb 19 22:36:37 UTC 2015


On Thu, Feb 19, 2015 at 10:20:13PM +0100, Thomas Graf wrote:
> On 02/19/15 at 11:16am, Ben Pfaff wrote:
> > +  <ul>
> > +    <li>
> > +      The Cloud Management System, as defined above.
> > +    </li>
> > +
> > +    <li>
> > +      <p>
> > +	The <dfn>OVN/CMS Plugin</dfn> is the component of the CMS that
> > +	interfaces to OVN.  In OpenStack, this is a Neutron plugin.
> > +	The plugin's main purpose is to translate the CMS's notion of logical
> > +	network configuration, stored in the CMS's configuration database in a
> > +	CMS-specific format, into an intermediate representation understood by
> > +	OVN.
> > +      </p>
> 
> Does it make sense to consider a multi writer CMS scenario where
> multiple CMS managed a single physical network? An assumption could
> be made that a particular hypervisor is only controlled through a
> single CMS and that only the logical network and binding would require
> some form of standardization.

Do people do that?  (Do they want to do it?)  Those are serious
questions; I don't know the answers.

> I don't have a good practical example at this point so this is mostly
> a brain exercise but I can't come up for a reason why this may not
> come up as a future requirement.

Maybe that's my answer.

> > +    <li>
> > +      Eventually, a user powers on the VM that owns the VIF.  On the hypervisor
> > +      where the VM is powered on, the integration between the hypervisor and
> > +      Open vSwitch (described in <code>IntegrationGuide.md</code>) adds the VIF
> > +      to the OVN integration bridge and stores <var>vif-id</var> in
> > +      <code>external-ids</code>:<code>iface-id</code> to indicate that the
> > +      interface is an instantiation of the new VIF.  (None of this code is new
> > +      in OVN; this is pre-existing integration work that has already been done
> > +      on hypervisors that support OVS.)
> > +    </li>
> 
> Is this piece CMS specific as well or can we leverage libvirt to
> create some abstraction here and write the vif-id into OVSDB?

I believe that libvirt already does this; see
virNetDevOpenvswitchAddPort() in src/util/virnetdevopenvswitch.c.
(I'm looking at libvirt-0.9.12.3 with Debian patches applied, though I
doubt it matters.)

> > +    <li>
> > +      Eventually, a user powers off the VM that owns the VIF.  On the
> > +      hypervisor where the VM was powered on, the VIF is deleted from the OVN
> > +      integration bridge.
> > +    </li>
> >
> I think it should also be noted who is responsible for cleaning up
> this non-persistent data in case the power off does not occur, e.g.
> system crash of he hypervisor. I assume it's the CMS integration plugin
> running on the hypervisor. It could also be part of the ovn-controller
> system bootup script.

I thought about this a bit when I was working on the OVN database
schema, but I didn't bother to write it up.  Here's an incremental
diff against the OVN schema.  The first hunk is for the Chassis table,
the second for the Bindings table.  The Pipeline table doesn't need
special handling because ovs-nbd is fully in charge of it:

diff --git a/ovn/ovn.xml b/ovn/ovn.xml
index a0c3c82..69e429c 100644
--- a/ovn/ovn.xml
+++ b/ovn/ovn.xml
@@ -108,6 +108,15 @@
       copy of the remaining rows to determine how to reach other hypervisors.
     </p>
 
+    <p>
+      When a chassis shuts down gracefully, it should remove its own row.
+      (This is not critical because resources hosted on the chassis are equally
+      unreachable regardless of whether the row is present.)  If a chassis
+      shuts down permanently without removing its row, some kind of manual or
+      automatic cleanup is eventually needed; we can devise a process for that
+      as necessary.
+    </p>
+
     <column name="name">
       A chassis name, taken from <ref key="system-id" table="Open_vSwitch"
       column="external_ids" db="Open_vSwitch"/> in the Open_vSwitch
@@ -443,6 +452,16 @@
       via the conventions described in <code>IntegrationGuide.md</code>.
     </p>
 
+    <p>
+      When a chassis shuts down gracefully, it should remove its bindings.
+      (This is not critical because resources hosted on the chassis are equally
+      unreachable regardless of whether their rows are present.)  To handle the
+      case where a VM is shut down abruptly on one chassis, then brought up
+      again on a different one, <code>ovn-controller</code> must delete any
+      existing <ref table="Binding"/> record for a logical port when it adds a
+      new one.
+    </p>
+
     <column name="logical_port">
       A logical port, taken from <ref key="iface-id" table="Interface"
       column="external_ids" db="Open_vSwitch"/> in the Open_vSwitch database's



More information about the dev mailing list