[Openstack] Python-novaclient version 2.11.1
Hi Everyone, I pushed another version of python novaclient (2.11.1) to pypi[1]. There was a bug[2] with using the gnome keyring that was affecting some users, so the only change from 2.11.0 is the inclusion of a fix for the bug. [1] http://pypi.python.org/pypi/python-novaclient/ [2] https://bugs.launchpad.net/python-novaclient/+bug/1116302 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] python-novaclient errors on dashboard
Hi, I'm running the latest pull from github of python-novaclient and
I'm having trouble when the dashboard attempt to view any of the
images services:
http://10.61.2.243/nova/images_and_snapshots/
NotFound at /nova/images_and_snapshots/
n/a (HTTP 404)
Request Method: GET
Request URL:http://10.61.2.243/nova/images_and_snapshots/
Django Version: 1.3
Exception Type: NotFound
Exception Value:
n/a (HTTP 404)
Exception Location: /opt/stack/python-novaclient/novaclient/client.py
in request, line 104
Python Executable: /usr/bin/python
Python Version: 2.7.2
Python Path:
['/opt/stack/horizon/openstack-dashboard/dashboard/wsgi/../..',
'/opt/stack/devstack/src/openstack',
'/opt/stack/devstack/src/python-keystoneclient',
'/opt/stack/keystone',
'/opt/stack/glance',
'/opt/stack/python-novaclient',
'/usr/local/lib/python2.7/dist-packages/nosexcover-1.0.7-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/suds-0.4-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/python_gflags-1.3-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/python_daemon-1.5.5-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/carrot-0.10.5-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/anyjson-0.2.4-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/amqplib-0.6.1-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/pylint-0.19.0-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/Markdown-2.1.0-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/openstackx-0.2-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages',
'/opt/stack/nova',
'/opt/stack/horizon/horizon',
'/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PIL',
'/usr/lib/python2.7/dist-packages/gtk-2.0',
'/opt/stack/horizon/openstack-dashboard/dashboard']
The last trace is:
/opt/stack/python-novaclient/novaclient/client.py in request
body = json.loads(body)
except ValueError, e:
pass
else:
body = None
if resp.status in (400, 401, 403, 404, 408, 413, 500, 501):
raise exceptions.from_response(resp, body)
return resp, body
def _cs_request(self, url, method, **kwargs):
if not self.management_url:
self.authenticate()
\u25bc Local vars
VariableValue
body
'404 Not Found\n\nThe resource could not be found.\n\n '
e
ValueError('Extra data: line 1 column 4 - line 5 column 4 (char 4 - 52)',)
resp
{'content-length': '52',
'content-type': 'text/plain; charset=UTF-8',
'date': 'Thu, 22 Dec 2011 06:46:50 GMT',
'status': '404'}
args
(u'http://nova.local:8774/v1.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96',
'GET')
kwargs
{'headers': {'User-Agent': 'python-novaclient',
'X-Auth-Project-Id': u'05a72d14b4434a848c07f00544069d20',
'X-Auth-Token': u'53c2c6ba-ae53-4c95-ae53-14ea6a0df0a4'}}
self
novaclient.client.HTTPClient object at 0x7f3cda3563d0
Now if I do a:
GET
http://nova.local:8774/v1.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
I get no response and no log output from nova, glance or keystone.
But if I do a:
GET
http://nova.local:8774/v2.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
I get:
{choices: [{status: CURRENT, media-types: [{base:
application/xml, type:
application/vnd.openstack.compute+xml;version=2}, {base:
application/json, type:
application/vnd.openstack.compute+json;version=2}], id: v2.0,
links: [{href:
http://nova.local:8774/v2/v2.0/os-quota-sets/05a72d14b4434a848c07f00544069d20;,
rel: self}]}]}
and log output:
== /var/log/nova/nova-api.log ==
2011-12-22 18:08:36,028 INFO nova.api.openstack.wsgi [-] GET
http://10.61.2.246:8774/v2.1/os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
2011-12-22 18:08:36,028 DEBUG nova.api.openstack.wsgi [-] Unrecognized
Content-Type provided in request from (pid=26556) deserialize_body
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:257
2011-12-22 18:08:36,029 INFO nova.api.openstack.wsgi [-]
http://10.61.2.246:8774/v2.1/os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
returned with HTTP 300
I am not sure how to debug this problem. Anyone help?
Cheers,
Den
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient errors on dashboard
Looks like you are missing the %tenant_id% in the service endpoint catalog
$BIN_DIR/keystone-manage $* endpointTemplates add RegionOne nova
http://%HOST_IP%:8774/v1.1/%tenant_id%
http://%HOST_IP%:8774/v1.1/%tenant_id%
http://%HOST_IP%:8774/v1.1/%tenant_id% 1 1
On Wed, Dec 21, 2011 at 11:10 PM, denmat tu2bg...@gmail.com wrote:
Hi, I'm running the latest pull from github of python-novaclient and
I'm having trouble when the dashboard attempt to view any of the
images services:
http://10.61.2.243/nova/images_and_snapshots/
NotFound at /nova/images_and_snapshots/
n/a (HTTP 404)
Request Method: GET
Request URL: http://10.61.2.243/nova/images_and_snapshots/
Django Version: 1.3
Exception Type: NotFound
Exception Value:
n/a (HTTP 404)
Exception Location: /opt/stack/python-novaclient/novaclient/client.py
in request, line 104
Python Executable: /usr/bin/python
Python Version: 2.7.2
Python Path:
['/opt/stack/horizon/openstack-dashboard/dashboard/wsgi/../..',
'/opt/stack/devstack/src/openstack',
'/opt/stack/devstack/src/python-keystoneclient',
'/opt/stack/keystone',
'/opt/stack/glance',
'/opt/stack/python-novaclient',
'/usr/local/lib/python2.7/dist-packages/nosexcover-1.0.7-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/suds-0.4-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/python_gflags-1.3-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/python_daemon-1.5.5-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/carrot-0.10.5-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/anyjson-0.2.4-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/amqplib-0.6.1-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/pylint-0.19.0-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/Markdown-2.1.0-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages/openstackx-0.2-py2.7.egg',
'/usr/local/lib/python2.7/dist-packages',
'/opt/stack/nova',
'/opt/stack/horizon/horizon',
'/usr/lib/pymodules/python2.7',
'/usr/lib/python2.7',
'/usr/lib/python2.7/plat-linux2',
'/usr/lib/python2.7/lib-tk',
'/usr/lib/python2.7/lib-old',
'/usr/lib/python2.7/lib-dynload',
'/usr/lib/python2.7/dist-packages',
'/usr/lib/python2.7/dist-packages/PIL',
'/usr/lib/python2.7/dist-packages/gtk-2.0',
'/opt/stack/horizon/openstack-dashboard/dashboard']
The last trace is:
/opt/stack/python-novaclient/novaclient/client.py in request
body = json.loads(body)
except ValueError, e:
pass
else:
body = None
if resp.status in (400, 401, 403, 404, 408, 413, 500, 501):
raise exceptions.from_response(resp, body)
return resp, body
def _cs_request(self, url, method, **kwargs):
if not self.management_url:
self.authenticate()
\u25bc Local vars
Variable Value
body
'404 Not Found\n\nThe resource could not be found.\n\n '
e
ValueError('Extra data: line 1 column 4 - line 5 column 4 (char 4 - 52)',)
resp
{'content-length': '52',
'content-type': 'text/plain; charset=UTF-8',
'date': 'Thu, 22 Dec 2011 06:46:50 GMT',
'status': '404'}
args
(u'http://nova.local:8774/v1.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96',
'GET')
kwargs
{'headers': {'User-Agent': 'python-novaclient',
'X-Auth-Project-Id': u'05a72d14b4434a848c07f00544069d20',
'X-Auth-Token': u'53c2c6ba-ae53-4c95-ae53-14ea6a0df0a4'}}
self
novaclient.client.HTTPClient object at 0x7f3cda3563d0
Now if I do a:
GET
http://nova.local:8774/v1.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
I get no response and no log output from nova, glance or keystone.
But if I do a:
GET
http://nova.local:8774/v2.1//os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
I get:
{choices: [{status: CURRENT, media-types: [{base:
application/xml, type:
application/vnd.openstack.compute+xml;version=2}, {base:
application/json, type:
application/vnd.openstack.compute+json;version=2}], id: v2.0,
links: [{href:
http://nova.local:8774/v2/v2.0/os-quota-sets/05a72d14b4434a848c07f00544069d20;,
rel: self}]}]}
and log output:
== /var/log/nova/nova-api.log ==
2011-12-22 18:08:36,028 INFO nova.api.openstack.wsgi [-] GET
http://10.61.2.246:8774/v2.1/os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
2011-12-22 18:08:36,028 DEBUG nova.api.openstack.wsgi [-] Unrecognized
Content-Type provided in request from (pid=26556) deserialize_body
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:257
2011-12-22 18:08:36,029 INFO nova.api.openstack.wsgi [-]
http://10.61.2.246:8774/v2.1/os-quota-sets/05a72d14b4434a848c07f00544069d20?fresh=1324536410.96
returned with HTTP 300
I am not sure how to debug this problem. Anyone help?
Cheers,
Den
[Openstack] python-novaclient moved into gerrit
Thanks the James and the rest of the CI team, python-novaclient is now moved from github to gerrit. Once we've migrated the old bugs over we'll nuke that repo. You know the drill ... see ya there. -S ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient moved into gerrit
Hi Sandy, On Wed, Nov 16, 2011 at 7:50 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Thanks the James and the rest of the CI team, python-novaclient is now moved from github to gerrit. Once we've migrated the old bugs over we'll nuke that repo. Great, but we are going to keep github as a readonly mirror right? (I guess moved in openstack account), You know the drill ... see ya there. Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient moved into gerrit
Yes. Same model as the rest of the projects - github readonly mirror in the openstack org for your convenience. Thanks! Monty On 11/16/2011 09:26 PM, Chmouel Boudjnah wrote: Hi Sandy, On Wed, Nov 16, 2011 at 7:50 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: Thanks the James and the rest of the CI team, python-novaclient is now moved from github to gerrit. Once we've migrated the old bugs over we'll nuke that repo. Great, but we are going to keep github as a readonly mirror right? (I guess moved in openstack account), You know the drill ... see ya there. Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Python novaclient boot command parameters
On Sat, Oct 22, 2011 at 3:19 AM, Unmesh Gurjar unmesh.gur...@vertex.co.inwrote: Hi All, ** ** I had recently submitted changes to the Python novaclient repo for adding the support to specify user_data, availability_zone and security_groups in the ‘nova boot’ command. The OpenStack API v1.1 spec for the create server API does not mention these parameters. Shouldn’t these parameters be a part of the create server API spec? ** ** Would it be suitable to have these parameters (user data, availability zone, security groups, networks) in the ‘nova boot’ command or whether there should be a new ‘nova boot-ext’ command that will accept these parameters? Should I remove the support that I have earlier added for the above parameters in ‘nova boot’ command? I will also be adding support to specify ‘networks’ at the time of instance creation. Should this also be a part of ‘nova boot-ext’ command? Hi Unmesh, I actually just recently did the work to specify networks as part of the nova boot command, hopefully this saves you some work. Pull request is here: https://github.com/rackspace/python-novaclient/pull/137 I added it as an optional parameter to the main boot command, but would be fine if others felt that a boot-ext command was more appropriate. Dan ** ** Thanks, Unmesh G. ** ** ** ** ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 twitter: danwendlant ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] python-novaclient vs. python-openstack.compute
python-novaclient[0] is the client for Nova that we maintain ourselves. It is a fork of jacobian's python-cloudservers. python-openstack.compute is jacobian's new branch of python-cloudservers. I wonder if there's any point in having two distinct, but very similar libraries to do same thing. If not, how do we move forward? Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. However, we need client tools to exercise new features exposed in the API, so I'm not sure we can reasonably live without a set of tools that we maintain ourselves to expose all the new functionality. Thoughts? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
I agree with all of your points. Having to maintain a client library wasn't on our list of fun things to do. The only thing I can see in Jacobian's python-openstack.compute branch that differs from his old Rackspace API library is the addition of the auth URL and a rebranding. We added that functionality to his old project last year, issued a pull request and were ignored. Perhaps his stance on working with us has changed since? Moreover, since that first pull request we've really moved on with the project and there is much more functionality in the library: - the new zone capabilities - api versioning - new OS 1.1 features - better error handling and reporting - better debugging That said, the more we deal with the library the more we realize we should re-evaluate its use. It's a very chatty implementation ... frequently round-tripping to the server to fetch more detailed information. This is fine for a CLI, but as an internal library too inefficient. Rather than merging these two efforts perhaps we should consider a new tack? https://github.com/jacobian/openstack.compute https://github.com/rackspace/python-novaclient -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Wednesday, May 18, 2011 3:17 AM To: openstack@lists.launchpad.net Subject: [Openstack] python-novaclient vs. python-openstack.compute python-novaclient[0] is the client for Nova that we maintain ourselves. It is a fork of jacobian's python-cloudservers. python-openstack.compute is jacobian's new branch of python-cloudservers. I wonder if there's any point in having two distinct, but very similar libraries to do same thing. If not, how do we move forward? Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. However, we need client tools to exercise new features exposed in the API, so I'm not sure we can reasonably live without a set of tools that we maintain ourselves to expose all the new functionality. Thoughts? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
Whoops, I could be mistaken on the new 1.1 features part of that email. Versioning is in a pending pull request. I'd like to hear from the Titan team on their plans ... especially around 1.1 support. And, dare I say it, making the client library data-driven so it will change whenever the server-side API changes would be ideal. Right now it's a pita to have to update the client library every time something on the server changes. This also brings us back to the discussion of whether novaclient (or something) should be in the nova source tree and not separate. -S From: Sandy Walsh Sent: Wednesday, May 18, 2011 9:07 AM To: Soren Hansen; openstack@lists.launchpad.net Subject: RE: [Openstack] python-novaclient vs. python-openstack.compute I agree with all of your points. Having to maintain a client library wasn't on our list of fun things to do. The only thing I can see in Jacobian's python-openstack.compute branch that differs from his old Rackspace API library is the addition of the auth URL and a rebranding. We added that functionality to his old project last year, issued a pull request and were ignored. Perhaps his stance on working with us has changed since? Moreover, since that first pull request we've really moved on with the project and there is much more functionality in the library: - the new zone capabilities - api versioning - new OS 1.1 features - better error handling and reporting - better debugging That said, the more we deal with the library the more we realize we should re-evaluate its use. It's a very chatty implementation ... frequently round-tripping to the server to fetch more detailed information. This is fine for a CLI, but as an internal library too inefficient. Rather than merging these two efforts perhaps we should consider a new tack? https://github.com/jacobian/openstack.compute https://github.com/rackspace/python-novaclient -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Wednesday, May 18, 2011 3:17 AM To: openstack@lists.launchpad.net Subject: [Openstack] python-novaclient vs. python-openstack.compute python-novaclient[0] is the client for Nova that we maintain ourselves. It is a fork of jacobian's python-cloudservers. python-openstack.compute is jacobian's new branch of python-cloudservers. I wonder if there's any point in having two distinct, but very similar libraries to do same thing. If not, how do we move forward? Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. However, we need client tools to exercise new features exposed in the API, so I'm not sure we can reasonably live without a set of tools that we maintain ourselves to expose all the new functionality. Thoughts? -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
Hey Sandy, So the API version works in the sense that if you hit /v1.0 you'll get the older v1.0 style API. Likewise for /v1.1. The big things still in flux as far as v1.1 support in nova: -making the JSON and XML serialization match the spec. On the JSON side there are some collections changes that need making. On the XML side I'm not sure we always adhere to the SPEC. -ID and HREFs (the ability to specify a custom glance image HREF when creating an instance). The implementation for this in cactus just chopped of the image ID from the URL and used that as the image_id for the image service. --- When updating a v1.0 binding to v1.1 you'll have to look at changes in metadata, new image metadata support, and some things moved around (change password moved from an update to an action), extensions, etc. --- I wouldn't be opposed to maintaining bindings outside of the project. Like Soren points out it does keep us honest. The downside of this is the bindings probably won't have any niche features and may lag new features a bit. I see external bindings as being more end user friendly and as such you may have a hard time getting features we add for administrative API's implemented (zones, users, etc.). In Ruby land... We have started bumping the Openstack Compute Ruby bindings to support v1.1 features. There is a branch in the works here: lp:~ironcamel/ruby-openstack-compute/v11 which takes care of most of the metadata changes, ID's and HREFs, formats, etc. We weren't planning on pushing the new Ruby gem with v1.1 support until the serialization stuff finally settles down. Hope this helps. Dan -Original Message- From: Sandy Walsh sandy.wa...@rackspace.com Sent: Wednesday, May 18, 2011 8:20am To: Soren Hansen so...@linux2go.dk, openstack@lists.launchpad.net openstack@lists.launchpad.net Subject: Re: [Openstack] python-novaclient vs. python-openstack.compute Whoops, I could be mistaken on the new 1.1 features part of that email. Versioning is in a pending pull request. I'd like to hear from the Titan team on their plans ... especially around 1.1 support. And, dare I say it, making the client library data-driven so it will change whenever the server-side API changes would be ideal. Right now it's a pita to have to update the client library every time something on the server changes. This also brings us back to the discussion of whether novaclient (or something) should be in the nova source tree and not separate. -S From: Sandy Walsh Sent: Wednesday, May 18, 2011 9:07 AM To: Soren Hansen; openstack@lists.launchpad.net Subject: RE: [Openstack] python-novaclient vs. python-openstack.compute I agree with all of your points. Having to maintain a client library wasn't on our list of fun things to do. The only thing I can see in Jacobian's python-openstack.compute branch that differs from his old Rackspace API library is the addition of the auth URL and a rebranding. We added that functionality to his old project last year, issued a pull request and were ignored. Perhaps his stance on working with us has changed since? Moreover, since that first pull request we've really moved on with the project and there is much more functionality in the library: - the new zone capabilities - api versioning - new OS 1.1 features - better error handling and reporting - better debugging That said, the more we deal with the library the more we realize we should re-evaluate its use. It's a very chatty implementation ... frequently round-tripping to the server to fetch more detailed information. This is fine for a CLI, but as an internal library too inefficient. Rather than merging these two efforts perhaps we should consider a new tack? https://github.com/jacobian/openstack.compute https://github.com/rackspace/python-novaclient -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Wednesday, May 18, 2011 3:17 AM To: openstack@lists.launchpad.net Subject: [Openstack] python-novaclient vs. python-openstack.compute python-novaclient[0] is the client for Nova that we maintain ourselves. It is a fork of jacobian's python-cloudservers. python-openstack.compute is jacobian's new branch of python-cloudservers. I wonder if there's any point in having two distinct, but very similar libraries to do same thing. If not, how do we move forward? Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. However, we need client tools to exercise new features exposed in the API, so I'm not sure we can reasonably live without a set of tools that we maintain
Re: [Openstack] python-novaclient vs. python-openstack.compute
On May 18, 2011, at 2:17 AM, Soren Hansen wrote: Yielding to jacobian (or someone else external to the project) helps keep us honest, since someone outside the project would look at the API docs to extend their client tools, and will hopefully point out if there's divergence between the API docs and the actual exposed API. I don't think it's that simple. Right now, novaclient isn't simply a tool for external access to the API; with the advent of zones, it's also the glue that connects zones together and manages all inter-zone communication. None of that would probably ever make it into a tool developed and maintained by a non-nova developer. If we go with relying on external versions of the client, we'll definitely need to at least extend it or replace it for the zone communication parts. -- Ed Leafe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
Thanks Dan, I wasn't so much worried about the technical details but rather if your group plans on making a new client or contributing to python-novaclient (or something)? Cheers, -Sandy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
Hey Sandy, We hadn't shifted our focus over to the client yet - our assumption had been that the best course would be to version the existing library and move forward. However, that was definitely an assumption and if people have experience that says maybe we should explore a new client tied more closely with nova, then we should look into that. This is my way of saying I don't know, but whichever direction we go, we can help if that's where we are needed. Anyone who has looked at the client, Titan or otherwise, should educate us here. To Soren's original point, we've already said that python-novaclient is a requirement for nova, and relying on an external party to keep that up-to-date is a little bit of a concern to me. We are going to rely on this to maintain our deployments, so it seems a little risky to rely on someone not on the project to keep it up to date. We do have other language bindings that can keep us honest as far as honoring the spec, so hopefully we still get that protection from ourselves from that quarter. Gabe On Wednesday, May 18, 2011 10:03am, Sandy Walsh sandy.wa...@rackspace.com said: Thanks Dan, I wasn't so much worried about the technical details but rather if your group plans on making a new client or contributing to python-novaclient (or something)? Cheers, -Sandy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
Cool ... thanks Gabe. I agree (and to Ed's point) that having to depend on an external source for close to rock-face development is too risky and that there are other ways to keep honest. Once we nail this down, perhaps having a side discussion about what a new client library might look like might be useful regardless. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Gabe Westmaas [gabe.westm...@rackspace.com] Sent: Wednesday, May 18, 2011 11:53 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] python-novaclient vs. python-openstack.compute Hey Sandy, We hadn't shifted our focus over to the client yet - our assumption had been that the best course would be to version the existing library and move forward. However, that was definitely an assumption and if people have experience that says maybe we should explore a new client tied more closely with nova, then we should look into that. This is my way of saying I don't know, but whichever direction we go, we can help if that's where we are needed. Anyone who has looked at the client, Titan or otherwise, should educate us here. To Soren's original point, we've already said that python-novaclient is a requirement for nova, and relying on an external party to keep that up-to-date is a little bit of a concern to me. We are going to rely on this to maintain our deployments, so it seems a little risky to rely on someone not on the project to keep it up to date. We do have other language bindings that can keep us honest as far as honoring the spec, so hopefully we still get that protection from ourselves from that quarter. Gabe On Wednesday, May 18, 2011 10:03am, Sandy Walsh sandy.wa...@rackspace.com said: Thanks Dan, I wasn't so much worried about the technical details but rather if your group plans on making a new client or contributing to python-novaclient (or something)? Cheers, -Sandy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] python-novaclient vs. python-openstack.compute
In the mean time, I'm working on addressing one of Sandy's issues by making the client less chatty. On Wed, May 18, 2011 at 10:35 AM, Sandy Walsh sandy.wa...@rackspace.comwrote: Cool ... thanks Gabe. I agree (and to Ed's point) that having to depend on an external source for close to rock-face development is too risky and that there are other ways to keep honest. Once we nail this down, perhaps having a side discussion about what a new client library might look like might be useful regardless. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net[openstack-bounces+sandy.walsh= rackspace@lists.launchpad.net] on behalf of Gabe Westmaas [ gabe.westm...@rackspace.com] Sent: Wednesday, May 18, 2011 11:53 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] python-novaclient vs. python-openstack.compute Hey Sandy, We hadn't shifted our focus over to the client yet - our assumption had been that the best course would be to version the existing library and move forward. However, that was definitely an assumption and if people have experience that says maybe we should explore a new client tied more closely with nova, then we should look into that. This is my way of saying I don't know, but whichever direction we go, we can help if that's where we are needed. Anyone who has looked at the client, Titan or otherwise, should educate us here. To Soren's original point, we've already said that python-novaclient is a requirement for nova, and relying on an external party to keep that up-to-date is a little bit of a concern to me. We are going to rely on this to maintain our deployments, so it seems a little risky to rely on someone not on the project to keep it up to date. We do have other language bindings that can keep us honest as far as honoring the spec, so hopefully we still get that protection from ourselves from that quarter. Gabe On Wednesday, May 18, 2011 10:03am, Sandy Walsh sandy.wa...@rackspace.com said: Thanks Dan, I wasn't so much worried about the technical details but rather if your group plans on making a new client or contributing to python-novaclient (or something)? Cheers, -Sandy ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] python-novaclient
Just FYI: I've set up a couple of Jenkins jobs for python-novaclient: python-novaclient-tarball: builds tarballs of python-novaclient on commits to trunk. python-novaclient-ppa: applies packaging magic and uploads the above mentioned tarballs to the nova-core/trunk ppa. This means you can always get the freshest python-novaclient from the nova-core/trunk ppa. Enjoy. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
