Open Stack

> On Jan 28, 2016, at 5:01 PM, Dan Smith <dms at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-----
Thanks,

Ryan Rossiter (rlrossit)