To add to my previous note - the proposed reference type can be considered a "group" reference. The constraint being that the group cardinality (number of elemets referenced) should be > 0. If cardinality becomes zero, the entry is garbage-collected.
> -----Original Message----- > From: Ansari, Shad > Sent: Thursday, January 28, 2016 10:06 PM > To: dev@openvswitch.org > Cc: 'Ben Pfaff'; Srivatsan, Srinivasan > Subject: RE: [ovs-dev] NTP support with OpenSwitch > > > 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
