[openstack-dev] Creating new python-<new_project_name>client

Jamie Lennox jamielennox at redhat.com
Thu Jun 26 06:53:16 UTC 2014


On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
> On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen <aaronorosen at gmail.com>
> wrote:
>         I'm looking at creating a new python-<new_project_name>client
>         and I was wondering if there was any on going effort to share
>         code between the clients or not? I've looked at the code in
>         python-novaclient and python-neutronclient and both of them
>         seem to have their own homegrown HTTPClient and keystone
>         integration. Figured I'd ping the mailing list here before I
>         go on and make my own homegrown HTTPClient as well. 
> 
> 
> For things in the library level of a client please consider using
> keystoneclient's fairly new session layer as the basis of your HTTP
> layer.  That will also give you access to the new style auth plugins,
> assuming you want to do Keystone auth with this client.
> 
> 
> I'm not sure if Jamie has any examples of using this without leaning
> on the backward-compatibility bits that the existing clients need.
> 
> 
> The Python SDK is being built on a similar Session layer (without the
> backeard compat bits).
> 
> 
> dt 

I'd love to suggest following in the footsteps of the SDK, but it's just
a little early for that. 

Today the best thing i think would be to use the session from
keystoneclient, and copy and paste the adapter:
https://review.openstack.org/#/c/86237/ which is approved but not in a
release yet. A client object takes a session and kwargs and creates an
adapter with them.

Then reuse the managers from
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/apiclient/base.py
I'm personally not a fan, but most of the other clients use this layout
and I assume you're more interested in getting things done in a standard
way than arguing over client design (If you are interested in that the
SDK project could always use a hand). Pass the adapter to the managers. 

Don't write a CLI, you can extend OSC to handle your new service. There
are no docs for it (that i'm aware of) but the included services all use
the plugin interface so you can copy from one of those. 

I don't have a pure example of these things, but if any of the above is
unclear feel free to find me on IRC and i'll step you through it.

Jamie

> 
> 
> -- 
> 
> Dean Troyer
> dtroyer at gmail.com
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






More information about the OpenStack-dev mailing list