An example I can think of is a multicast forwarding table with index columns: - mcast address - UUID list of outgoing interfaces (which are some sort of weak-refs to Interface table entries)
It may be desirable to have a mcast table entry garbage collected when when all its participating interfaces are deleted. Maybe new category of weak refs can be employed - one that garbage collects an entry when it's self-to-many relationship is reduced to self-to-zero. > -----Original Message----- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Wednesday, January 20, 2016 1:46 PM > To: Srivatsan, Srinivasan > Cc: dev@openvswitch.org; disc...@openvswitch.org; Ansari, Shad > Subject: Re: [ovs-dev] NTP support with OpenSwitch > > The schema constraints that OVS supports certainly aren't perfect. > There are plenty of situations where one can come up with better kinds > of constraints. Maybe you have come up with one. If you're going to > propose adding a new kind of constraint, then I think it would be > worthwhile to think through whether it will be useful in many > situations. For example, do you have use cases beyond NTP? If it's a > useful general-purpose construct, then I'm more in favor of adding it. > > On Wed, Jan 13, 2016 at 02:38:38AM +0000, Srivatsan, Srinivasan wrote: > > +Adding Michael > > > > Regards > > Srinivasan > > > > > > > > > > On 1/12/16, 4:16 PM, "dev on behalf of Srivatsan, Srinivasan" <dev- > boun...@openvswitch.org on behalf of srinivasan.srivat...@hpe.com> wrote: > > > > >Hi, > > > > > >I am Srinivasan and am trying to add Network Time Protocol support for > OpenSwitch. Openswitch uses OVSDB as the central db for status/configuration > and inter module communication. From the NTP point of view, we are trying to > define how can modulate NTP to accommodate into the ovsdb schema design. > > > > > >About NTP client: > > >NTP servers local/remote synchronize time information to the connected > NTP clients. NTP clients are require to configure servers based on their > liking. > What the NTP client configuration should allow is configuring of different NTP > servers within different VRFs. So following configurations are correct in > terms of > NTP client configuration "ntp server 1.1.1.1 use_vrf vrf1" and "ntp server > 1.1.1.1 > use_vrf vrf2". > > > > > >Schema Design: > > >Now to define a schema, we have a top level System table which refers to > NTP table. NTP table can have multiple rows of server > configuration/associations. Each association should be able to support VRF > configuration per server configuration. Lets say we have the following columns > in the NTP table: > > >- "ip_address" for referring to the server ip address and > > >- "vrf" to refer to the vrf associated with this server. > > > > > >If we have weak references from NTP -> VRF then we should be able to use > NTP:"ip_address" and NTP:”vrf" as the index for the NTP table. Overall it > looks > like this: > > > > > > +---------+ > > > | SYSTEM | > > > +---------+ > > > | | > > >+---v-+ +--v--+ > > >| NTP +----> VRF | > > >| +----> | > > >+-----+ +——---+ > > > > > >- Multiple NTP rows can refer to the same VRF reference. > > >- Multiple NTP rows can have same NTP:"ip_address" but should have a > different VRF:"reference" > > > > > >Pros of doing this schema: > > >- Simpler model of mapping NTP -> VRF instead of using VRF -> NTP since we > should not have the notion of time split per VRF. > > >- Rest can be nicely integrated into system/ntp/vrf or system/ntp/* > > >- vtysh cli/show/config implementation is easier to get all the information > about NTP at one go. > > > > > >Issue: > > >Step1: If we have 2 VRFs : "vrf1" and "vrf2", and if it maps to different > > >rows in > the NTP table with same NTP:"ip_address". > > >Step2: So the NTP table has two rows: 1st row with NTP:"ip_address" as > 1.1.1.1 and NTP:"vrf" as uuid_of("vrf1") and 2nd row with NTP:"ip_address" as > 1.1.1.1 and NTP:"vrf" as uuid_of("vrf2"). > > >Step3: Now lets say user deletes "vrf1" from the VRF table, which would > trigger NTP:"vrf" for the 1st row to point to []. This command executes > successfully and it removes the VRF reference and it invalidates entry within > the > NTP table. > > >Step4: Now the user chooses to delete "vrf2" from the VRF table, which > would trigger a similar update to earlier but it would fail because you cannot > have two entries with the same index ie NTP:"ip_address" and NTP:"vrf" > combination. > > > > > >Unless the information within NTP table is cleared by a garbage collection > program, it would not be possible for Step4 to be executed successfully. > > > > > >From what Michael points out, Today OVSDB schema has two modes of > references > > >1) “Strong” – target row can’t be removed as long as it has strong > references leading to it. > > >2) “Weak” – target row can be deleted and the referencing cell will by > NULLed. > > >We use “weak” references, where one of the inter-referenced tables has to > be updated very frequently. > > >The downside is that rows that get their cells NULLed are generally invalid > rows and have to be garbage collected by somebody. > > >Additionally NULLed cells might cause index constraints violations, in > > >which > case, the target row would again not be deleted. > > > > > >Ideal Solution: > > >What we would require in such a situation to support NTP is to have a > > >"weak- > gc" that would allow the target row to be deleted instead of setting the > reference to NULL. > > > > > >I would like to hear your thoughts on whether you've encountered features > where we would want to support something similar to this. Do we know of any > work-in-progress patches which we can use to do this ? Or is there a feature > which has handled this differently. > > > > > >Thanks > > >Srinivasan > > >_______________________________________________ > > >dev mailing list > > >dev@openvswitch.org > > >http://openvswitch.org/mailman/listinfo/dev > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
