Not return volume type id but name when nova gets volume object from cinder

Bug #1276888 reported by John Haan
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Wishlist
Unassigned

Bug Description

when nova gets volume object and untranslate its, volume_type_id regards vol.volume_type.

Actually volume_type is returned not an id but a name.

However, some unittest defines volume_type_id to defferent type value.

1. in nova/tests/fake_volumes.py

'volume_type_id': 99

2. in nova/test/api/openstack/fakes.py

'volume_type_id': 'fakevoltype'

I think we should change the name of volume_type_id to volume_type for appropriate meaning of value.

Otherwise, volume_type_id should be a one type.

Tags: volumes
Revision history for this message
Matt Riedemann (mriedem) wrote :

This is the value in the data model:

volume_type_id = Column(Integer)

So are you talking about just making a change in the tests so they are consistently using an int, or something else? Otherwise if we're talking about changing the actual column in the database I don't think this probably warrants a new database migration.

tags: added: volumes
Revision history for this message
John Haan (yongiman) wrote :

No, I don't mention of database model.

I just say nova regards volume_type as a volume_type_id even it means type name when it gets volume object from cinder.

in nova/volume/cinder.py

def _untranslate_volume_summary_view(context, vol):
.
.
    d['volume_type_id'] = vol.volume_type
    d['snapshot_id'] = vol.snapshot_id

Therefore it is easy to think volume_type_id as a int type. Actually it includes volume type name.

John Haan (yongiman)
Changed in nova:
assignee: nobody → John Haan (yongiman)
John Haan (yongiman)
Changed in nova:
status: New → In Progress
Sean Dague (sdague)
Changed in nova:
status: In Progress → Confirmed
importance: Undecided → Wishlist
assignee: John Haan (yongiman) → nobody
Revision history for this message
Migi (michal-pryc-w) wrote :

Isn't there a bigger issue then just naming convention?

What I found is that in Nova the field is represented in the data model as:

    volume_type_id = Column(Integer)

However in the Cinder which is provider for the volume the same data is represented as:

   volume_type_id = Column(String(36))

The volume_type_id can represent UUID of the volume that can be attached to the VM.

Revision history for this message
Migi (michal-pryc-w) wrote :

Actually I see more inconsistency between Cinder and Nova DB schemas, as an example:

volumes -> ec2_id is String(255) in Nova and Integer in Cinder.

Should there be a test that covers consistency check between DB models from various OpenStack components?

Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote :

This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on.

Changed in nova:
status: Confirmed → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.