Fields for statuses, formats, and other enums
Many fields used in cinder objects can be only one of a predefined set of values (such as a status, format, or type). These are usually held in objects as string fields that have no validation. The assignments and comparisons throughout the code on these fields also are hard-coded strings (thing.status == 'available'). Changing over these StringFields to become specified typed fields (relying on oslo.versionedo
Blueprint information
- Status:
- Not started
- Approver:
- Sean McGinnis
- Priority:
- Medium
- Drafter:
- Ryan Rossiter
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Add BackupStatus enum field
Addressed by: https:/
Add CGSnapshotStatus enum field
Addressed by: https:/
Add ConsistencyGrou
Addressed by: https:/
WIP: Add SnapshotStatus enum field
Addressed by: https:/
Tests: Don't assert on LOG.warn
Addressed by: https:/
Add VolumeAttachStatus Enum
Addressed by: https:/
Add ServiceTopic & ServiceDisabled
Addressed by: https:/
Add ServiceBinary Enum
Addressed by: https:/
[WIP]Add VolumeStatus enum field
Addressed by: https:/
Add VolumeStatus enum field-Part(2)
Addressed by: https:/
Use GroupStatus enum field
Addressed by: https:/
Use SnapshotStatus enum field
Addressed by: https:/
Use QoSConsumerValues enum field
Addressed by: https:/
Use GroupSnapshotStatus enum field
Addressed by: https:/
Add missing VolumeAttachStatus enum field
