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. >> + <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. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
