[openstack-dev] [cinder] Custom fields for versioned objects

Michał Dulko michal.dulko at intel.com
Tue Dec 15 09:52:43 UTC 2015


On 12/14/2015 03:59 PM, Ryan Rossiter wrote:
> Hi everyone,
>
> I have a change submitted that lays the groundwork for using custom enums and fields that are used by versioned objects [1]. These custom fields allow for verification on a set of valid values, which prevents the field from being mistakenly set to something invalid. These custom fields are best suited for StringFields that are only assigned certain exact strings (such as a status, format, or type). Some examples for Nova: PciDevice.status, ImageMetaProps.hw_scsi_model, and BlockDeviceMapping.source_type.
>
> These new enums (that are consumed by the fields) are also great for centralizing constants for hard-coded strings throughout the code. For example (using [1]):
>
> Instead of
>     if backup.status == ‘creating’:
>         <do_stuff>
>
> We now have
>     if backup.status == fields.BackupStatus.CREATING:
>         <do_stuff>
>
> Granted, this causes a lot of brainless line changes that make for a lot of +/-, but it centralizes a lot. In changes like this, I hope I found all of the occurrences of the different backup statuses, but GitHub search and grep can only do so much. If it turns out this gets in and I missed a string or two, it’s not the end of the world, just push up a follow-up patch to fix up the missed strings. That part of the review is not affected in any way by the RPC/object versioning.
>
> Speaking of object versioning, notice in cinder/objects/backup.py the version was updated to appropriate the new field type. The underlying data passed over RPC has not changed, but this is done for compatibility with older versions that may not have obeyed the set of valid values.
>
> [1] https://review.openstack.org/#/c/256737/
>
>
> -----
> Thanks,
>
> Ryan Rossiter (rlrossit)

Thanks for starting this work with formalizing the statuses, I've
commented on the review with a few remarks.

I think we should start a blueprint or bugreport to be able track these
efforts.




More information about the OpenStack-dev mailing list