[openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?
rlrossit at linux.vnet.ibm.com
Fri Jan 29 14:32:56 UTC 2016
> 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:
> Cinder also has some already:
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 
2) Put the new field in o.vo 
3) After o.vo is released, re-sync 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Ryan Rossiter (rlrossit)
More information about the OpenStack-dev