Open Stack

On 1/28/2016 11:01 PM, Dan Smith 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
>
> 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.
>
> --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
>

I also agree with deprecating the non-validation behavior and releasing 
with a major version bump (in theory) *but* because of the backward 
compat stance taken since liberty, we can't just drop this since it 
would break unit test jobs in several projects on stable/liberty, at 
least nova and cinder. And that's because (1) nova unit test jobs on 
liberty aren't using upper-constraints and (2) we aren't capping 
libraries in g-r in stable/liberty, because of said upper-constraints. I 
have my own issues with that, but that's the plan that everyone is 
working toward right now, so knowingly dropping the non-uuid support 
would break liberty and we can't allow that until it's gone from all of 
the projects, so we could be looking at mitaka-eol or newton-eol 
(assuming all projects were using UUIDField with real uuid's by the time 
stable/newton is created).  That sucks, I know, but that's the backward 
compat stance with upper-constraints (which I'm not a fan of) and right 
now everyone is having to deal with it until that changes, if that changes.

-- 

Thanks,

Matt Riedemann