> 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev