[openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

Ian Cordasco sigmavirus24 at gmail.com
Tue Apr 5 21:28:53 UTC 2016


 

-----Original Message-----
From: Michael Still <mikal at stillhq.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: April 5, 2016 at 16:11:05
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [nova][glance] Proposal to remove `nova image-*` commands from novaclient

> 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.
>  
> 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:
>  
> self.glance = glance_client.Client('2', endpoint, token=token)
> 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.
>  
> 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.
>  

What if we just recommend everyone use the openstacksdk (https://pypi.python.org/pypi/openstacksdk)? We could add more developer resources by deprecating our individual client libraries to use that instead? It's consistent and well-designed and would probably benefit from us actively helping with each service's portion.

--  
Ian Cordasco




More information about the OpenStack-dev mailing list