It's an easy fix. I sent a patch for review:
http://openvswitch.org/pipermail/dev/2016-April/069067.html
On Sat, Apr 02, 2016 at 05:12:50AM +0000, Elluru, Krishna Mohan wrote:
> HI Ben,
> Please ignore my earlier mail. You are right, having mutable:false
> disabled for weak reference should resolve the issue. Can you guide me the
> process of raising this bug and necessary logs you may need for fixing it?
>
> Thanks
> Krishna Mohan.
>
> -----Original Message-----
> From: Ben Pfaff [mailto:[email protected]]
> Sent: Friday, April 01, 2016 8:48 PM
> To: Elluru, Krishna Mohan <[email protected]>
> Cc: [email protected]
> Subject: Re: [ovs-discuss] Clarification regarding Mutable attribute in the
> column
>
> On Fri, Apr 01, 2016 at 04:55:59AM +0000, Elluru, Krishna Mohan wrote:
> > Elluru, Krishna Mohan wrote:
> > > I am observing one of the behavior with ovsdb(2.5), for which I
> > > would like to seek clarity. As per the RFC 7047, if a column on
> > > table X with attribute is set to mutable:false, the value can't be
> > > changed after creation and on attempt the constraint violation error
> > > would be thrown to the caller. However, if the column is a weak
> > > reference and pointing to UUID of another table (say y) with
> > > mutable:false on the column, and on row deletion in Y table, what is
> > > the intended action on table X's row?. Currently my observation
> > > shows that the corresponding row in Table X is being deleted. Is
> > > this behavior is a bug or intended behavior?
> >
> > Ben Pfaff wrote:
> > > This is a hole in the constraint system that had not previously been
> > > brought to my attention.
> > >
> > > I'd prefer to solve it by forbidding weak references from immutable
> > > columns. Does this suit you?
> >
> > Elluru, Krishna Mohan wrote:
> > > I have two versions here. I am actually happy with this behavior,
> > > in real use case. For Ex: I have a port table referenced from
> > > nexthop table with uuid and mutable property set to false. Due to
> > > above behavior, when I delete the port table row, without flushing
> > > the entries in nexthop table, port row was allowed to be
> > > deleted(ofcourse after clearing other strong references) and the
> > > nextop rows were garbage collected. This is a nice behavior
> > > according to me, since the row itself is being deleted(I meant
> > > garbage collected), I didn't feel the need to raise it earlier, till
> > > someone quoted it as a bug to me.
> > > Open to views and suggestions.
> >
> > My goal, when I included immutable columns into OVSDB, was to enable
> > clients to treat them as invariants. This simplifies some of the
> > logic of the clients. That's why, for example, the "name" column in
> > the Open_vSwitch schema's Interface table is immutable; it simplified
> > logic in some places in ovs-vswitchd and I didn't see any significant
> > downsides.
> >
> > I am not sure of other reasons why columns would be invariant. In
> > your example above for example, why is it valuable for the column
> > (that actually changes due to deletion of the row to which it refers)
> > to be invariant? Does it simplify something? That is, why not make
> > the column mutable?
> >
> > ELMOHAN> the advantage is more from the automatic cleanup by the DB,
> > ELMOHAN> than the code doing it. If I delete a port row, without
> > ELMOHAN> worrying(scanning) 10k(just an example) references from
> > ELMOHAN> nexthop table to it, and DB taking care of flushing those
> > ELMOHAN> automatically (with internal logic ., may be gc). However,
> > ELMOHAN> with mutable property set to true, my work still be there of
> > ELMOHAN> clearing all 10k records + port record in same commit txn, I
> > ELMOHAN> feel that is large txn (sorry if I am exaggerating).
> > ELMOHAN> Regarding the constraint violation, I viewed it as we didn't
> > ELMOHAN> modified the column actually, when the txn violated the
> > ELMOHAN> constraint, the corresponding row has been deleted and the DB
> > ELMOHAN> is brought stable due to that. I could be wrong here, for me
> > ELMOHAN> it looks like a nice feature to have.
>
> I don't understand yet. I understand this much: when you delete a port row,
> you'd like the references to it to disappear. That works just as well
> whether the referring column is mutable or immutable. So why is it important
> for it to be immutable?
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
