[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