deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "marios@redhat.com" <mandr...@redhat.com>
Subject Re: Can't detach volume in openstack driver?
Date Thu, 13 Dec 2012 08:11:10 GMT
Hi Ian:

On 12/12/12 21:53, Ian Main wrote:
> 
> Heya guys,
> 
> So everything is going great in the openstack driver except I can't seem
> to get the detach method on a volume to work.  I always get a 404 error
> back.

I just tried this - it is working fine against the setup i'm trying
with.. (though you've already discovered the real issue - more below)...
these aren't working for you but for reference:

attach: curl --user "username+tenant-name:password" -H "Accept:
application/xml" -X POST -d "instance_id=815253&device=/dev/sde"
http://localhost:3001/api/storage_volumes/120261/attach

detach: curl --user "username+tenant-name:password" -H "Accept:
application/xml" -X POST
http://localhost:3001/api/storage_volumes/120261/detach

> 
> 2012-12-11 16:55:02    DEBUG [requests.packages.urllib3.connectionpool]
> "POST /api/storage_volumes/14/detach HTTP/1.1" 404 18
> 
> I looked in the driver code and it looks like it wants an instance_id
> property set, so I tried:
> 
> 2012-12-11 17:32:16    DEBUG [requests.packages.urllib3.connectionpool]
> "POST /api/storage_volumes/14/detach?instance_id=adffbebb-382c-4743-a61d-3736769acde6
> HTTP/1.1" 404 18
> 
> Same idea.. I also notice that the instance knows it has a storage
> volume attached but the storage volume doesn't know the instance it is
> attached to.  Maybe a limitation of openstack?

right - so yes the driver wants the instance_id - because the current
openstack volumes attach/detach implementation isn't actually exposed
via Cinder but rather via the os-volumes extenstion of Nova. Like so:

attach: POST  v2/{tenant_id}/servers/{server_id}/os-volume_attachments

detach: DELETE
v2/{tenant_id}/servers/{server_id}/os-volume_attachments/{attachment_id}

However, you don't need to pass this instance_id in your request,
because the deltacloud code tries to grab it - see
server/lib/deltacloud/collections/storage_volumes.rb lines 74 + 75:


 74 volume = driver.storage_volume(credentials, :id => params[:id])$
 75 @storage_volume =  driver.detach_storage_volume(credentials, :id =>
volume.id,:instance_id => volume.instance_id,:device => volume.device)

i.e. we retrieve the volume and then grab the instance_id required for
the operation from the volume itself. So the real problem here is, as
you noted, that "instance knows it has a storage volume attached but the
storage volume doesn't know the instance it is attached to". So on line
75 above, 'volume.instance_id' likely resolves to 'nil'. I don't know
why this is the case on your particular setup. The quickest way to
resolve this is for me to have access to your openstack setup. Is this
possible?

thanks, marios



> 
> Thanks guys (Marios ;-))
> 
>     Ian
> 
> 


Mime
View raw message