[
https://issues.apache.org/jira/browse/LIBCLOUD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13177105#comment-13177105
]
Gary Wilson edited comment on LIBCLOUD-137 at 12/29/11 10:36 AM:
-----------------------------------------------------------------
Changed the title from Rackspace not OpenStack_1_0_NodeDriver compliant
It makes sense to provide the sha1 hash of the node id due to the multi
providers and their naming conventions as pointed out. However would it not
make sense to still return the original provider node id as well?
The uuid has no context in further operations, it cannot be reused on the fly
surely it would be more useful in all cases to return the provider node id as
well, for example:
<Node: uuid=a05c637f548f64d1c847d85abe50bfda46789bec, providerid=10085881,
name=zpf-controller-dev-2-10g-ruk, state=0, public_ips=[xxx.xxx.xxx.xxx'],
provider=Rackspace (UK) ...>
In the case of a provider that does not return a node ID (e.g. GoGrid) the
providerid could just be set to whatever the uuid hash was generated from e.g.
public IP address or none and the user would then have to implement workarounds.
If the providerid is not returned one has to keep their own hash table of uuids
=> providerids, which seems a bit silly and inconvenient in the context of
automated provisioning and node management or adoption of libcloud into
existing provisioned infrastructures.
I see that the sha1 uuid hash is not applied to Node Images and thus the data
return by the driver.list_images() is reusable on the fly.
Use case - the user wants to rebuild a Rackspace node on the fly (automated):
1. Validate the node is running - driver.list_nodes() | grep "$NODE_NAME" |
grep -c "state=0"
2. It is running, so we can rebuild
3. We know the name of image the node should use so we get its NodeImage id as
images do not have sha1 uuids so the returned data can be reused on the fly -
driver.list_images() | sed -e 's/\[</\[\n</g;s/>, />,\n/g;s/>\]/>\n\]/g' | grep
"$_cloud_server_image" | sed -e 's/.*id=//g;s/,.*//g'
4. We now want to rebuild the node with ex_rebuild(node_id, node_image) - BUT
without having the providerid and only having the uuid, that is not possible.
I am sure there is a much better way of doing that ^
I see no reason why the original providerid cannot still be returned along with
the uuid. In this scenario the user still has to query the provider API to
determine what the node id (or maintain a uuid => providerid hash table) =
additional operational overhead.
The original nature of the issue still remains true, the rackspace/openstack
driver does not return the required data to allow a user to execute many of the
rackspace/openstack compute functions. The user has to jump through hoops and
implement workarounds to match libcloud's uuid data to the provider's id, this
seems to somewhat defeat the purpose of using libcloud to abstract away
differences among multiple cloud provider APIs (IMHO).
So at the moment none of the following rackspace node operations can be carried
out without the user directly querying the rackspace API for the node id.
_change_password_or_name(self, node, name=None, password=None)
ex_set_password(self, node, password)
ex_set_server_name(self, node, name)
ex_resize(self, node, size)
ex_confirm_resize(self, node)
ex_revert_resize(self, node)
ex_rebuild(self, node_id, image_id)
ex_create_ip_group(self, group_name, node_id=None)
ex_share_ip(self, group_id, node_id, ip, configure_node=True)
ex_unshare_ip(self, node_id, ip)
ex_list_ip_addresses(self, node_id)
_reboot_node(self, node, reboot_type='SOFT')
_node_action(self, node, body)
ex_save_image(self, node, name)
destroy_node(self, node)
reboot_node(self, node)
ex_get_node_details(self, node_id)
ex_soft_reboot_node(self, node)
ex_hard_reboot_node(self, node)
Anyway just a thought. Please feel free to close.
was (Author: earthgecko):
Changed the title from Rackspace not OpenStack_1_0_NodeDriver compliant
It makes sense to provide the sha1 hash of the node id due to the multi
providers and their naming conventions as pointed out. However would it not
make sense to still return the original provider node id as well?
The uuid has no context in further operations, it cannot be reused on the fly
surely it would be more useful in all cases to return the provider node id as
well, for example:
<Node: uuid=a05c637f548f64d1c847d85abe50bfda46789bec, providerid=10085881
name=zpf-controller-dev-2-10g-ruk, state=0, public_ips=[xxx.xxx.xxx.xxx'],
provider=Rackspace (UK) ...>
In the case of a provider that does not return a node ID (e.g. GoGrid) the
providerid could just be set to whatever the uuid hash was generated from e.g.
public IP address or none and the user would then have to implement workarounds.
If the providerid is not returned one has to keep their own hash table of uuids
=> providerids, which seems a bit silly and inconvenient in the context of
automated provisioning and node management or adoption of libcloud into
existing provisioned infrastructures.
I see that the sha1 uuid hash is not applied to Node Images and thus the data
return by the driver.list_images() is reusable on the fly.
Use case - the user wants to rebuild a Rackspace node on the fly (automated):
1. Validate the node is running - driver.list_nodes() | grep "$NODE_NAME" |
grep -c "state=0"
2. It is running, so we can rebuild
3. We know the name of image the node should use so we get its NodeImage id as
images do not have sha1 uuids so the returned data can be reused on the fly -
driver.list_images() | sed -e 's/\[</\[\n</g;s/>, />,\n/g;s/>\]/>\n\]/g' | grep
"$_cloud_server_image" | sed -e 's/.*id=//g;s/,.*//g'
4. We now want to rebuild the node with ex_rebuild(node_id, node_image) - BUT
without having the providerid and only having the uuid, that is not possible.
I am sure there is a much better way of doing that ^
I see no reason why the original providerid cannot still be returned along with
the uuid. In this scenario the user still has to query the provider API to
determine what the node id (or maintain a uuid => providerid hash table) =
additional operational overhead.
The original nature of the issue still remains true, the rackspace/openstack
driver does not return the required data to allow a user to execute many of the
rackspace/openstack compute functions. The user has to jump through hoops and
implement workarounds to match libcloud's uuid data to the provider's id, this
seems to somewhat defeat the purpose of using libcloud to abstract away
differences among multiple cloud provider APIs (IMHO).
So at the moment none of the following rackspace node operations can be carried
out without the user directly querying the rackspace API for the node id.
_change_password_or_name(self, node, name=None, password=None)
ex_set_password(self, node, password)
ex_set_server_name(self, node, name)
ex_resize(self, node, size)
ex_confirm_resize(self, node)
ex_revert_resize(self, node)
ex_rebuild(self, node_id, image_id)
ex_create_ip_group(self, group_name, node_id=None)
ex_share_ip(self, group_id, node_id, ip, configure_node=True)
ex_unshare_ip(self, node_id, ip)
ex_list_ip_addresses(self, node_id)
_reboot_node(self, node, reboot_type='SOFT')
_node_action(self, node, body)
ex_save_image(self, node, name)
destroy_node(self, node)
reboot_node(self, node)
ex_get_node_details(self, node_id)
ex_soft_reboot_node(self, node)
ex_hard_reboot_node(self, node)
Anyway just a thought. Please feel free to close.
> Return uuid and provider id
> ---------------------------
>
> Key: LIBCLOUD-137
> URL: https://issues.apache.org/jira/browse/LIBCLOUD-137
> Project: Libcloud
> Issue Type: Improvement
> Components: Compute
> Affects Versions: 0.7.1
> Reporter: Gary Wilson
> Labels: compute, id,, node, uuid
>
> libcloud.compute.drivers.rackspace.RackspaceUKNodeDriver inherits
> OpenStack_1_0_NodeDriver and this does not return the required data with
> regards to node details that are required to manage rackspace nodes, not with
> the OpenStack driver in any case. Specifically driver.list.nodes() returns
> uuid stings for nodes e.g.:
> <Node: uuid=a05c637f548f64d1c847d85abe50bfda46789bec,
> name=zpf-controller-dev-2-10g-ruk, state=0, public_ips=[xxx.xxx.xxx.xxx'],
> provider=Rackspace (UK) ...>
> The uuid is not usable in the Rackspace Server or Server Action operations
> (as defined in their API) as they all require the id parameter.
> The inherited OpenStack ex_rebuild errors with:
> <snip>
> /usr/bin/python /opt/zpf/scripts/libcloud.rebuild.ruk.node $NODE_UUID
> $NODEIMAGE_UUID
> /opt/zpf/scripts/libcloud.rebuild.ruk.node
> a05c637f548f64d1c847d85abe50bfda46789bec
> 10458692
> Traceback (most recent call last):
> File "/opt/zpf/scripts/libcloud.rebuild.ruk.node", line 33, in <module>
> driver.ex_rebuild(sys.argv[1], sys.argv[2])
> File
> "/usr/lib/python2.6/site-packages/libcloud/compute/drivers/openstack.py",
> line 467, in ex_rebuild
> data=ET.tostring(elm))
> File
> "/usr/lib/python2.6/site-packages/libcloud/compute/drivers/openstack.py",
> line 139, in request
> method=method, headers=headers)
> File "/usr/lib/python2.6/site-packages/libcloud/common/openstack.py", line
> 267, in request
> return super(OpenStackBaseConnection, self).request(**kwargs)
> File "/usr/lib/python2.6/site-packages/libcloud/common/base.py", line 509,
> in request
> connection=self)
> File
> "/usr/lib/python2.6/site-packages/libcloud/compute/drivers/openstack.py",
> line 242, in __init__
> super(OpenStack_1_0_Response, self).__init__(*args, **kwargs)
> File "/usr/lib/python2.6/site-packages/libcloud/common/base.py", line 74,
> in __init__
> raise Exception(self.parse_error())
> Exception: 404 Not Found The requested path could not be found.;
> javax.ws.rs.WebApplicationException: java.lang.NumberFormatException: For
> input string: "a05c637f548f64d1c847d85abe50bfda46789bec"
> </snip>
> The Rackspace API returns id on all "server" requests e.g.
> wget --no-check-certificate --server-response -O ruk.servers.no.detail
> --header "X-Auth-Token: xxxxxxxxxxx"
> https://lon.servers.api.rackspacecloud.com/v1.0/xxxxx/servers
> {"servers":[{"id":10085881,"name":"base-centos-6-ruk"},{"id":10087553,"name":"zpf-controller-dev-1-10g-ruk"},{"id":10087643,"name":"zpf-controller-dev-2-10g-ruk"}]}
> Am I doing something incorrect or is the OpenStack driver not compatible with
> Rackspace? If not then surely libcloud should remove Rackspace from this
> list of Providers. It would at least save people the time and effort of
> figuring that out themselves.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
