On Thu, Feb 19, 2015 at 04:52:44PM -0500, Russell Bryant wrote:
> On 02/19/2015 04:20 PM, Thomas Graf wrote:
> > 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.
>
> I think it makes sense to consider a multi-writer scenario. I was
> trying to see if I could come up with a reason that scenario would be a
> problem. Do you see any?
>
> The only thing I came up with was the need for each CMS to note which
> resources are theirs vs. managed by something else. The inclusion of
> "external_ids" in every table in the OVN northbound schema seems to
> cover that bit.
If you or Thomas have an idea of how this might work, then let's talk
a bit more about details. Until then, how about the following
incremental diff to at least capture this thought?
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index 303865e..f2ca268 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -19,11 +19,18 @@
<ul>
<li>
- A <dfn>Cloud Management System</dfn> (<dfn>CMS</dfn>), which is
- OVN's ultimate client (via its users and administrators). OVN
- integration requires installing a CMS-specific plugin and
- related software (see below). OVN initially targets OpenStack
- as CMS.
+ <p>
+ A <dfn>Cloud Management System</dfn> (<dfn>CMS</dfn>), which is
+ OVN's ultimate client (via its users and administrators). OVN
+ integration requires installing a CMS-specific plugin and
+ related software (see below). OVN initially targets OpenStack
+ as CMS.
+ </p>
+
+ <p>
+ We generally speak of ``the'' CMS, but one can imagine scenarios in
+ which multiple CMSes manage different parts of an OVN deployment.
+ </p>
</li>
<li>
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index 9a2423a..dcd9651 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -8,6 +8,11 @@
db="OVN"/> database.
</p>
+ <p>
+ We generally speak of ``the'' CMS, but one can imagine scenarios in
+ which multiple CMSes manage different parts of an OVN deployment.
+ </p>
+
<h2>External IDs</h2>
<p>
> >> + <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 think making this the responsibility of the CMS integration makes
> sense. Taking OpenStack as an example, I would think OpenStack
> Neutron's db is the source of truth of what the current state should be.
> It will have to include the ability to do a sync in response to any
> event that could have put them out of sync and make sure the data in OVN
> matches. That would include this sort of cleanup. In the case of a
> hypervisor crash, something should still come around and tell Neutron
> that the associated ports need to be deleted.
From OVN's point of view a crashed hypervisor is just unreachable, I
think. The row for a permanently down hypervisor needs to be deleted
eventually; ovs-nbd could handle that, I guess, probably by adding an
occasionally updated "timestamp" or similar field.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
