On 04/05/2016 05:07 PM, Michael Still wrote:
As a recent newcomer to using our client libraries, my only real
objection to this plan is that our client libraries as a mess [1][2].
The interfaces we expect users to use are quite different for basic
things like initial auth between the various clients, and by introducing
another library we insist people use we're going to force a lot of devs
to eventually go through having to understand how those other people did
that thing.
The big misunderstanding is thinking that our client libs are for our
users. I made that mistake early on. Our client libs are really for
server to server communication.
If you want a client lib that works - use either openstacksdk or shade.
Which of the you use depends on what you want to accomplish.
openstacksdk is a well designed interface to the OpenStack APIs. Of
course, the OpenStack APIs are really hard to use across clouds. Shade
hides the incompatibilities between the clouds, but is not a direct
mapping to REST API docs.
I guess I could ease my concerns here if we could agree to some sort of
standard for what auth in a client library looks like...
Some examples of auth at the moment:
If you want a client object from one of the client libraries, I STRONGLY
suggest using os-client-config to construct them instead of using the
constructors directly. This is because the constructors are really only
for other OpenStack services.
http://inaugust.com/posts/simple-openstack-clients.html
self.glance = glance_client.Client('2', endpoint, token=token)
There are next to zero cases where the thing you want to do is talk to
glance using a token and an endpoint. In fact, outside of being inside
of nova and making proxy calls, the only 'valid' use case is keystone
service catalog bootstrapping ... and that got replaced with something
sane in mitaka.
What you want is this:
client = os_client_config.make_client(
'network',
auth_url='https://example.com', username='my-user',
password='awesome-password', project_name='my-project',
region_name='the-best-region')
You should ALWAYS pass an auth_url, a username, a password and a
project_name. Otherwise, the keystoneauth Session will not be able to
re-auth you. Also, it saves you having to construct a token yourself.
self.ironic = ironic_client.get_client(1, ironic_url=endpoint,
os_auth_token=token)
self.nova = nova_client.Client('2', bypass_url=endpoint, auth_token=token)
Note how we can't decide if the version number is a string or an int,
and the argument names for the endpoint and token are different in all
three. Its like we're _trying_ to make this hard.
The python-*client libraries are exceptionally painful to use. Any time
you want to use them, I recommend not using them, as above.
Michael
1: I guess I might be doing it wrong, but in that case I'll just mutter
about the API docs instead.
2: I haven't looked at the unified openstack client library to see if
its less crazy.
On Wed, Apr 6, 2016 at 5:46 AM, Matt Riedemann
<mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote:
As we discuss the glance v2 spec for nova, questions are coming up
around what to do about the nova images API which is a proxy for
glance v1.
I don't want to add glance v2 support to the nova API since that's
just more proxy gorp.
I don't think we can just make the nova images API fail if we're
using glance v2 in the backend, but we'll need some translation
later for:
user->nova-images->glance.v2->glance.v1(ish)->user
But we definitely want people to stop using the nova images API.
I think we can start by deprecating the nova images-* commands in
python-novaclient, and probably the python API bindings in
novaclient too.
People should be using python-glanceclient or python-openstackclient
for the CLI, and python-glanceclient or some SDK for the python API
bindings.
We recently removed the deprecated nova volume-* stuff from
novaclient, this would be the same idea.
Does anyone have an issue with this?
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Rackspace Australia
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
