> On Jan 28, 2016, at 5:01 PM, Dan Smith <d...@danplanet.com> wrote: > >> I know we have some projects (heat, I think?) that don't have UUIDs at >> all. Are they using oslo.versionedobjects? I suppose we could move them >> to a string field instead of a UUID field, instead of flipping the >> enforcement flag on. Alternately, if we add a new class we wouldn't have >> to ever actually deprecate the UUIDField class, though we might add a >> warning to the docs that it isn't doing any validation and the new class >> is preferred. > > If a project isn't using UUIDs then they have no reason to use a > UUIDField and thus aren't affected. If they are, then they're doing > something wrong. > >> I'll be curious to see what Dan and Sean have to say when they catch up >> on this thread. > > I think Ryan summed it up very well earlier, but I will echo and > elaborate here for clarity. > > To be honest, I think the right thing to do is deprecate the > non-validating behavior and have projects use in-project validating > fields for UUIDs (i.e. their own UUIDField implementation). When we can, > release a major version with the validating behavior turned on. > > I don't like the validate=False flag because it's hard (or at least > ugly) to deprecate. Even allowing the call signature to tolerate it for > compatibility but still doing the validation is terrible, IMHO. If > people feel it is absolutely critical to have an implementation in o.vo > right now, then we can do the parallel class option, but we basically > just have to alias the old one to the new one when we "drop" the > non-validating functionality, IMHO, which is just more baggage. To quote > Ryan, "if you know you're going to break people, just don't do it." > > This is a really minor issue in my opinion -- the amount of code a > project needs to replicate is exceedingly small, especially if they just > subclass the existing field and override the one method required to > ensure coercion. For a point of reference, nova has a lot of these > fields which are too nova-specific to put into o.vo; adding one more for > this is immeasurably small: > > https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L76-L621 > > Cinder also has some already: > > https://github.com/openstack/cinder/blob/master/cinder/objects/fields.py
You’re welcome for the extra Cinder evidence, Dan ;). > > And to again echo Ryan's comments, we have always landed things in nova, > sync'd them to o.vo and removed our local copy once we can depend on a > new-enough o.vo release. This is effectively the same behavior for this > change and really just isn't that big of a deal. Please, let's do the > safest thing for the projects that consume our library, and for the > people who have to use the same gate as all the rest of us. For anyone who cares how this works, here’s a typical process for doing custom fields: 1) Put the field in Nova [1] 2) Put the new field in o.vo [2] 3) After o.vo is released, re-sync [3] [1] https://github.com/openstack/nova/commit/b9247f52d17e18d075b995ac8a438ec5e65eacbf [2] https://github.com/openstack/oslo.versionedobjects/commit/2e083bce6e4b325cb89baea4b1d6173d58c8f5bd [3] https://github.com/openstack/nova/commit/3c83a47bb70ad9db6c7900e6c752f08777fa0787 > > --Dan > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ----- Thanks, Ryan Rossiter (rlrossit) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev