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

Thomas Graf tgraf at noironetworks.com
Thu Feb 19 21:20:13 UTC 2015


This is a first high level review. I'll be digging into the schema
next.

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.

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.

> +    <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?

> +    <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.



More information about the dev mailing list