[openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?
mriedem at linux.vnet.ibm.com
Fri Jan 29 11:31:41 UTC 2016
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:
> Cinder also has some already:
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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.
More information about the OpenStack-dev