On Wed, Oct 12, 2016 at 03:51:33PM +0200, Wolfgang Bumiller wrote:
> On October 5, 2016 at 6:55 PM Ben Pfaff <b...@ovn.org> wrote:
> > I don't know what you're trying to deal with. The autogenerated code
> > provides a C view of all of the features that the underlying database
> > does. If you need something else, then it probably means extending the
> > database schema, at which point the autogenerated code will give a view
> > of whatever you add to the schema.
> I was just worried that the schema would be involved in interface/rpc
> code which could potentially break tools built with the old schema.
> (Considering it comes with a checksum)
> But I don't see another option.
> Would you generally prefer an additional boolean flag for a change like
> this or perhaps add -1 special value for the ingress_policing_rate.
> A quick glance at the existing schema didn't point out many existing
> special values other than a semi intuitive active_timeout where 0 means
> default and -1 means disabled. In the case of ingress_policing_rate 0
> would mean disabled and -1 would mean untouched.
Yes, we're very concerned about schema backward compatibility. Adding
special interpretations, or adding columns, doesn't break this kind of
I have two thoughts here.
One would be to use -1, as you say. These columns currently have a
constraint "minInteger": 0, which prevents -1 from being used. That
could prevent downgrading from a newer to an older schema if the -1
value were actually in use. That is probably a minor concern.
The other possibility I'm thinking of is to add an ingress_qos column
to the Port table, which would resemble the qos column except that it
would be used on ingress. Then we could define a collection of ingress
qdiscs like those used for egress, one of which would be a "noop"
qdisc. This is more future proof and does not have downgrade issues,
although it is a little more work.
discuss mailing list