Open Stack

> 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