Hi Ian:
On 01/11/12 22:01, Ian Main wrote:
>
> Howdy guys,
>
> So I've been using the openstack driver as a backend for heat ->
> deltacloud work. I just posted a few patches to resolve issues that I
> have run into but I've now hit a more serious roadblock and that is the
great thanks for those but I need some clarification:
"Add user-data support to openstack driver"
in this patch - are you trying to add the ability to push user-data into
a launched instance (as opposed to server metadata, which is different)?
If you are then Openstack has a different way of doing this, called
'server personality' [1] which we already have implemented. You have to
pass a hash that matches the data you want pushed with where on the
server you want it, like: {path1='server_path1'. content1='contents1',
path2='server_path2', content2='contents2'}
When testing this against openstack@HPcloud, I was able to inject data
but only into /etc (see comment at [2] for more info). As an example,
the cURL command for launching an Openstack instance via deltacloud,
complete with user data looks like:
curl -ivX POST --user "foo:bar" -F "image_id=foo" -F
"path1=/etc/my_file1" -F "content1=another test 1 here" -F
"path2=/etc/anotherfile" -F "content2=this is a test"
"http://localhost:3001/api/instances?format=xml";
> lack of volume support for openstack.
>
great - this is something i've been meaning to do for a while. But
again, need some clarification/info. Until now, there is no mention of
'Volumes' in the Nova 'API Proper' [3]. It *has* been available as an
API extension. This is not a problem as I've already implemented other
extensions such as 'floating IPs' and 'keypairs' for the Openstack
rubygem [4]. However, I am also aware that there is a 'new' service
called 'Cinder' which is meant to be the 'Volume API'. I suspect that
what was formerly an extension has now (in folsom?) become the seperate
'cinder' aka 'Volume' service - though the API is not yet available at
[5]. So my question is - what are you using? Have you deployed the
Volume service (I guess this is the case but I need to know so I can
proceed for implementation),
thanks! marios
[1]
http://docs.openstack.org/api/openstack-compute/2/content/Server_Personality-d1e2543.html
[2]https://issues.apache.org/jira/browse/DTACLOUD-205?focusedCommentId=13403989&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13403989
[3] http://docs.openstack.org/api/openstack-compute/2/content/index.html
[4] https://github.com/ruby-openstack/ruby-openstack
[5] http://docs.openstack.org/api/api-specs.html
> In heat we do create:
>
> vol = self.nova('volume').volumes.create(self.properties['Size'],
> display_name=self.physical_resource_name(),
> display_description=self.physical_resource_name())
>
>
> Check state and delete:
>
> vol = self.nova('volume').volumes.get(self.instance_id)
> if vol.status == 'in-use':
> logger.warn('cant delete volume when in-use')
> raise exception.Error("Volume in use")
>
> self.nova('volume').volumes.delete(self.instance_id)
>
> Attachment with verify:
>
> va = volapi.create_server_volume(server_id=server_id,
> volume_id=volume_id,
> device=self.properties['Device'])
>
> vol = self.nova('volume').volumes.get(va.id)
> while vol.status == 'available' or vol.status == 'attaching':
> eventlet.sleep(1)
> vol.get()
> if vol.status == 'in-use':
> self.instance_id_set(va.id)
>
>
> Removal and verify:
>
> volapi.delete_server_volume(server_id,
> volume_id)
>
> vol = self.nova('volume').volumes.get(volume_id)
>
> logger.info('un-attaching %s, status %s' % (volume_id, vol.status))
> while vol.status == 'in-use':
> logger.info('trying to un-attach %s, but still %s' %
> (volume_id, vol.status))
> eventlet.sleep(1)
> try:
> volapi.delete_server_volume(server_id,
> volume_id)
>
>
> This can all be found in the volume.py:
>
> https://github.com/heat-api/heat/blob/master/heat/engine/resources/volume.py
>
> I'm going to be out of the office Friday & Monday so if anyone has a chance to
> look at this during that time, that'd be great!
>
> Thanks!
>
> Ian
>
