[openstack-dev] [nova] Volume attachment APIs CRUD inconsistencies

Sam Matzek matzeksam at gmail.com
Fri Dec 11 19:48:12 UTC 2015

The CRUD operations for Nova volume attachments have inconsistencies
between documentation and implementation.  Additionally, the read/get
operation is implemented twice under different URIs.  What is Nova's
direction for volume attachment APIs and how should the following
discrepancies be resolved?

The current state of affairs is:
CREATE (volume attach) is documented twice under two different URIs: [1]
and [2], but only os-volume_attachments [1] is implemented [3].
Attach volume as an action on the servers URI appears to have been part of
the Nova V3 API, but its implementation no longer exists.
Is it the future direction to have volume attach and detach done as server

READ is implemented twice and documented twice under two different URIs:
os-volume_attachments [5] and server details [6]
The two implementations do not return the same information and the only bit
of information that is common between them is the volume ID.
Why do we have two implementations and is one preferred over the other?
Should one be deprecated and eventually removed with all enhancements going
into the other?

UPDATE is implemented [4] but not documented.

DELETE (detach) only appears to be implemented and documented once: [7]

A blueprint proposal exists [8] to enhance the attach and update APIs to
set and modify the delete_on_termination flag.  The discrepancies in the
create and read operations calls into question whether the update change
should be on the PUT /servers API to match the server's read [6] or if the
os-volume_attachments update API should be modified to line up with
os-volume_attachments read.

[1] http://developer.openstack.org/api-ref-compute-v2-ext.html#attachVolume
[2] http://developer.openstack.org/api-ref-compute-v2.1.html#attach
[5] http://developer.openstack.org/api-ref-compute-v2-ext.html#attachVolume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/ae957587/attachment.html>

More information about the OpenStack-dev mailing list