Re: [openstack-dev] Creating new python-new_project_nameclient

2014-06-26 Thread Jamie Lennox
On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
 On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:
 I'm looking at creating a new python-new_project_nameclient
 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
 dtro...@gmail.com
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Creating new python-new_project_nameclient

2014-06-26 Thread Aaron Rosen
Thanks guys, very helpful.

Aaron


On Wed, Jun 25, 2014 at 11:53 PM, Jamie Lennox jamielen...@redhat.com
wrote:

 On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:
  On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com
  wrote:
  I'm looking at creating a new python-new_project_nameclient
  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
  dtro...@gmail.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Creating new python-new_project_nameclient

2014-06-25 Thread Aaron Rosen
Hi,

I'm looking at creating a new python-new_project_nameclient 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.

Thanks!

Aaron
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Creating new python-new_project_nameclient

2014-06-25 Thread Brian Curtin
On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 I'm looking at creating a new python-new_project_nameclient 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.


It's still quite early, but this is one of the things we're working on with
python-openstacksdk[0][1]. As of today[2] there are reviews for the start
of how Neutron and Glance clients would work out, and I'm working on the
start of a Swift one myself. However, if you need your client written
today, this project isn't there yet.

[0] https://github.com/stackforge/python-openstacksdk
[1] https://wiki.openstack.org/wiki/PythonOpenStackSDK
[2]
https://review.openstack.org/#/q/status:open+project:stackforge/python-openstacksdk,n,z
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Creating new python-new_project_nameclient

2014-06-25 Thread Dean Troyer
On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 I'm looking at creating a new python-new_project_nameclient 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

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev