Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Monty Taylor]

On 08/07/2017 11:55 AM, Boden Russell wrote:


On 8/4/17 1:26 PM, Boris Pavlovic wrote:


That's not going to work for dozens of OpenStack projects. It's just
won't scale. Every project should maintain plugin for their project. And
it should be enough to say "pip install python-client" that
extend the Core OpenStack python client and adds support of new commands.

The whole core part should be only about how to make plugins interface
in such way that it's easy to extend and provide to end user nice user
experience from both side (shell & python) and nice and stable interface
for client developers .



I echo Boris's point; if the client side isn't pluggable and extendable
(in a reusable fashion), then how can we build a consistent CLI for
users of our APIs that do support pluggable (potentially out-of-tree)
extensions (ex: neutron)?


I think we're missing each other here.

Nothing about the SDK not having plugins will have anything to do with 
OSC plugins. OSC will still totally have plugins.


But OpenStack is a piece of cloud software that has a REST API that 
includes service and version discovery components that work the same 
across all of the sub-projects. There is nothing about any of the 
services that makes it valuable to have a separate library to consume 
it. In fact, if you look at our current python libraries you would think 
that our APIs are much more different than they actually are.



It's a concern with the current trajectory of OSC/SDK and one I
mentioned on the ML last week [1].

If we're going to reevaluate this client side "plumbing", I truly hope
we take into consideration how our users are interfacing with the CLI,
which today, includes the ability to handle API resource extensions in
the classic python client, but not in OSC.


Nothing about this is about OSC. There is no reason to not support all 
of the available API surface directly in the SDK. If the availability of 
the API in question can be discovered via a discovery/extension 
mechanism, then it can be supported. If it CAN'T- then the user isn't 
going to be able to use such a feature sanely anyway and we need to 
address that so that our users have a good experience.


Long story short - OpenStack is the thing this is a client for. It needs 
to support all of OpenStack - and it doesn't need to support things that 
are not OpenStack.



As per the bug/RFE linked in [1], I'm willing to throw some code down to
help make this happen; it's just not clear who the right team is to
queue this discussion/code up with.


If neutronclient could support doing [1] without plugins, then I see no 
reason we can't support doing is without plugins as well. Let's make a 
plan and get it done- I agree with you that supporting your use case is 
important.




[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.html

__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Boden Russell]

On 8/4/17 1:26 PM, Boris Pavlovic wrote:
> 
> That's not going to work for dozens of OpenStack projects. It's just
> won't scale. Every project should maintain plugin for their project. And
> it should be enough to say "pip install python-client" that
> extend the Core OpenStack python client and adds support of new commands. 
> 
> The whole core part should be only about how to make plugins interface
> in such way that it's easy to extend and provide to end user nice user
> experience from both side (shell & python) and nice and stable interface
> for client developers . 


I echo Boris's point; if the client side isn't pluggable and extendable
(in a reusable fashion), then how can we build a consistent CLI for
users of our APIs that do support pluggable (potentially out-of-tree)
extensions (ex: neutron)?

It's a concern with the current trajectory of OSC/SDK and one I
mentioned on the ML last week [1].

If we're going to reevaluate this client side "plumbing", I truly hope
we take into consideration how our users are interfacing with the CLI,
which today, includes the ability to handle API resource extensions in
the classic python client, but not in OSC.

As per the bug/RFE linked in [1], I'm willing to throw some code down to
help make this happen; it's just not clear who the right team is to
queue this discussion/code up with.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.html

__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Monty Taylor]

On 08/04/2017 04:03 PM, Dean Troyer wrote:

On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor  wrote:
[...]

* Both shade and python-openstackclient have investigated using openstacksdk
as their REST layer but were unable to because it puts some abstractions in
layers that make it impossible to do some of the advanced things we need.


OSC _does_ use the SDK for all Network API commands.  That was a
mistake in the sense that we did it before SDK 1.0 was released and
still do not have 1.0.


Yah - although it got you out of the competing cliff issue, so that was 
good.



* openstacksdk has internal implementations of things that exist at
different points in the stack. We just added full support for version
service and version discovery to keystoneauth, but openstacksdk has its own
layer for that so it both can't use the ksa implementation and is not
compliant with the API-WG consume guidelines.


This was intended to make it free from dependencies, when first
concieved, none of these other libs existed.


Oh - totally. It made total sense at the time ... it's just the 
surrounding context has changed.



I am coming around to believe that we need to slice a couple more
things up so they can be composed as needed rather then bite off the
entire thing in once piece.

[...]


I'd propose we have the shade team adopt the python-openstacksdk codebase.


++


This is obviously an aggressive suggestion and essentially represents a
takeover of a project. We don't have the luxury of humans to work on things
that we once had, so I think as a community we should be realistic about the
benefits of consolidation and the downside to continuing to have 2 different
python SDKs.


++

I thought it would be natural for OSC to adopt the SDK someday if
Brian did not get around to making it official, but the current
circumstances make it clear that we (OSC) do not have the resources to
do this.  This proposal is much better and leads to a natural
coalescence of the parallel goals and projects.


Doing that implies the following:

* Rework the underlying guts of openstacksdk to make it possible to replace
shade's REST layer with openstacksdk. openstacksdk still doesn't have a 1.0
release, so we can break the few things we'll need to break.


Sigh.  OSC has been using the Network components of the SDK for a long
time in spite of SDK not being at 1.0.  In retrospect that was a
mistake on my part but I believed at the time that 1.0 was close and
we had already ignored Network for far too long.  We already have one
compatibility layer in the SDK due to the proxy refactor work that was
supposed to be the last thing before 1.0.


I don't think we need to break the things you're using, fwiw. In fact, 
we can probably take it as a first-order requirement to not break OSC - 
unless we find something SUPER intractable - and even then we should 
talk about it first.



[...]


* Merge the two repos and retire one of them. Specifics on the mechanics of
this below, but this will either result in moving the resource and service
layer in openstacksdk into shade and adding appropriate attributes to the
shade.OpenStackCloud object, or moving the shade.OpenStackCloud into
something like openstack.cloud and making a shade backwards-compate shim. I
lean towards the first, as we've been telling devs "use shade to talk to
OpenStack" at hackathons and bootcamps and I'd rather avoid the messaging
shift. However, pointing to an SDK called "The Python OpenStack SDK" and
telling people to use it certainly has its benefits from a messaging
perspective.


I don't have a big concern about which repo is maintained.  For OSC I
want what amounts to a low-level REST API, one example of which can be
found in openstackclient.api.*.  Currently Shade is not quite the
right thing to back a CLI but now has the layer I want, and SDK does
not have that layer at all (it was proposed very early on and not
merged).


FWIW - now that we landed version discovery and microversion support in 
keystoneauth - I'd say keystoneauth Adapter is actually now the 
low-level REST API:


  client = keystoneauth1.adapter.Adapter(
session=session,
service_type='compute',
region_name='DFW',
min_version='2',
max_version='2.latest')
  endpoint_data = client.get_endpoint_data()
  print(
"Microversion range is: ",
endpoint_data.min_microversion,
endpoint_data.max_microversion)
  # want 2.31 of servers
  server_response = client.get('/servers', microversion='2.31')
  server = server_response.json()['servers'][0]
  # want 2.14 of keypairs
  keypair_response = client.get('/keypairs', microversion='2.14')
  # Don't care on volume attachments - don't specify one.
  volume_attachments_response = client.get(
  '/servers/{id}/os-volume_attachments'.format(id=server['id']))


Is it better to have a single monolithic thing that has three
conceptual layers internally that can be individually consumed or to
have three things that get layered as 

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Clark Boylan]

On Fri, Aug 4, 2017, at 02:37 PM, Kevin L. Mitchell wrote:
> On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote:
> > By the way stevedore is really providing very bad plugin experience
> > and should not be used definitely. 
> 
> Perhaps entrypointer[1]? ;)
> 
> [1] https://pypi.python.org/pypi/entrypointer
> -- 
> Kevin L. Mitchell 

The problems seem to be more with the use of entrypoints and the
incredible runtime cost for using them (which you've hinted at in
entrypointer's README). I don't think switching from $plugin lib to
$otherplugin lib changes much for tools like openstackclient unless we
first fix entrypoints (or avoid entrypoints all together). Until then
you must still rely on entrypoints to scan your python path which is
slow.

Clark

__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Kevin L. Mitchell]

On Fri, 2017-08-04 at 12:26 -0700, Boris Pavlovic wrote:
> By the way stevedore is really providing very bad plugin experience
> and should not be used definitely. 

Perhaps entrypointer[1]? ;)

[1] https://pypi.python.org/pypi/entrypointer
-- 
Kevin L. Mitchell 

signature.asc
Description: This is a digitally signed message part
__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Dean Troyer]

On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor  wrote:
[...]
> * Both shade and python-openstackclient have investigated using openstacksdk
> as their REST layer but were unable to because it puts some abstractions in
> layers that make it impossible to do some of the advanced things we need.

OSC _does_ use the SDK for all Network API commands.  That was a
mistake in the sense that we did it before SDK 1.0 was released and
still do not have 1.0.

> * openstacksdk has internal implementations of things that exist at
> different points in the stack. We just added full support for version
> service and version discovery to keystoneauth, but openstacksdk has its own
> layer for that so it both can't use the ksa implementation and is not
> compliant with the API-WG consume guidelines.

This was intended to make it free from dependencies, when first
concieved, none of these other libs existed.

I am coming around to believe that we need to slice a couple more
things up so they can be composed as needed rather then bite off the
entire thing in once piece.

[...]

> I'd propose we have the shade team adopt the python-openstacksdk codebase.

++

> This is obviously an aggressive suggestion and essentially represents a
> takeover of a project. We don't have the luxury of humans to work on things
> that we once had, so I think as a community we should be realistic about the
> benefits of consolidation and the downside to continuing to have 2 different
> python SDKs.

++

I thought it would be natural for OSC to adopt the SDK someday if
Brian did not get around to making it official, but the current
circumstances make it clear that we (OSC) do not have the resources to
do this.  This proposal is much better and leads to a natural
coalescence of the parallel goals and projects.

> Doing that implies the following:
>
> * Rework the underlying guts of openstacksdk to make it possible to replace
> shade's REST layer with openstacksdk. openstacksdk still doesn't have a 1.0
> release, so we can break the few things we'll need to break.

Sigh.  OSC has been using the Network components of the SDK for a long
time in spite of SDK not being at 1.0.  In retrospect that was a
mistake on my part but I believed at the time that 1.0 was close and
we had already ignored Network for far too long.  We already have one
compatibility layer in the SDK due to the proxy refactor work that was
supposed to be the last thing before 1.0.

[...]

> * Merge the two repos and retire one of them. Specifics on the mechanics of
> this below, but this will either result in moving the resource and service
> layer in openstacksdk into shade and adding appropriate attributes to the
> shade.OpenStackCloud object, or moving the shade.OpenStackCloud into
> something like openstack.cloud and making a shade backwards-compate shim. I
> lean towards the first, as we've been telling devs "use shade to talk to
> OpenStack" at hackathons and bootcamps and I'd rather avoid the messaging
> shift. However, pointing to an SDK called "The Python OpenStack SDK" and
> telling people to use it certainly has its benefits from a messaging
> perspective.

I don't have a big concern about which repo is maintained.  For OSC I
want what amounts to a low-level REST API, one example of which can be
found in openstackclient.api.*.  Currently Shade is not quite the
right thing to back a CLI but now has the layer I want, and SDK does
not have that layer at all (it was proposed very early on and not
merged).

Is it better to have a single monolithic thing that has three
conceptual layers internally that can be individually consumed or to
have three things that get layered as needed?

> * drop keystoneauth.Session subclass. It's over-riding things at the wrong
> layer. keystoneauth Adapter is the thing it wants to be.

FWIW, OSC has this problem too...

> * suitability for python-openstackclient. Dean and Steve have been laying in
> the groundwork for doing direct-REST in python-openstackclient because
> python-*client are a mess from an end-user perspective and openstacksdk
> isn't suitable. If we can sync on requirements hopefully we can produce
> something that python-openstackclient can honestly use for that layer
> instead of needing local code.

As I mentioned, we already use the Networking portions of SDK, even
without a 1.0, and it has bit us already a couple of times.  It has
long been my plan to convert to using the SDK, but that was when I
believed there would also be a lower-level API exposed that did not
require all of the application-level goodness and abstractions.

I personally feel like splitting out the low-level REST API layers
into a stand-alone piece that shade, SDK and OSC can all benefit from
would be our best course, but then I have been wrong about this
layering thing in the past, so I throw it out there to have something
that can be used to push against to get what everyone else seems to
want.

dt

-- 

Dean Troyer
dtro...@gmail.com

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Boris Pavlovic]

Monty,


* drop stevedore/plugin support. An OpenStack REST client has no need for
> plugins. All services are welcome. *note below*


Back to 60s style of development? Just copy paste things? no plugins? no
architecture? no libs?

That's not going to work for dozens of OpenStack projects. It's just won't
scale. Every project should maintain plugin for their project. And it
should be enough to say "pip install python-client" that
extend the Core OpenStack python client and adds support of new commands.

The whole core part should be only about how to make plugins interface in
such way that it's easy to extend and provide to end user nice user
experience from both side (shell & python) and nice and stable interface
for client developers .

By the way stevedore is really providing very bad plugin experience and
should not be used definitely.

Best regards,
Boris Pavlovic

On Fri, Aug 4, 2017 at 12:05 PM, Joshua Harlow 
wrote:

> Also note that this appears to exist:
>
> https://github.com/openstack/python-openstackclient/blob/mas
> ter/requirements.txt#L10
>
> So even if python-openstacksdk is not a top level project, I would assume
> that it being a requirement would imply that it is? Or perhaps neither the
> python-openstackclient or python-openstacksdk should really be used? I've
> been telling people that python-openstackclient should be good to use (I
> hope that is still correct, though I do have to tell people to *not* use
> python-openstackclient from python itself, and only use it from bash/other
> shell).
>
>
> Michael Johnson wrote:
>
>> Hi OpenStack developers,
>>
>> I was wondering what is the current status of the python-openstacksdk
>> project.  The Octavia team has posted some patches implementing our new
>> Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have
>> also
>> asked some questions in #openstack-sdks with no responses.
>> I see that there are some maintenance patches getting merged and a pypi
>> release was made 6/14/17 (though not through releases project).  I'm not
>> seeing any mailing list traffic and the IRC meetings seem to have ended in
>> 2016.
>>
>> With all the recent contributor changes, I want to make sure the project
>> isn't adrift in the sea of OpenStack before we continue to spend
>> development
>> time implementing the SDK for Octavia. We were also planning to use it as
>> the backing for our dashboard project.
>>
>> Since it's not in the governance projects list I couldn't determine who
>> the
>> PTL to ping would be, so I decided to ping the dev mailing list.
>>
>> My questions:
>> 1. Is this project abandoned?
>> 2. Is there a plan to make it an official project?
>> 3. Should we continue to develop for it?
>>
>> Thanks,
>> Michael (johnsom)
>>
>> [1]
>> https://review.openstack.org/#/q/project:openstack/python-op
>> enstacksdk+statu
>> s:open+topic:%255Eoctavia.*
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Joshua Harlow]

Also note that this appears to exist:

https://github.com/openstack/python-openstackclient/blob/master/requirements.txt#L10

So even if python-openstacksdk is not a top level project, I would 
assume that it being a requirement would imply that it is? Or perhaps 
neither the python-openstackclient or python-openstacksdk should really 
be used? I've been telling people that python-openstackclient should be 
good to use (I hope that is still correct, though I do have to tell 
people to *not* use python-openstackclient from python itself, and only 
use it from bash/other shell).


Michael Johnson wrote:

Hi OpenStack developers,

I was wondering what is the current status of the python-openstacksdk
project.  The Octavia team has posted some patches implementing our new
Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
asked some questions in #openstack-sdks with no responses.
I see that there are some maintenance patches getting merged and a pypi
release was made 6/14/17 (though not through releases project).  I'm not
seeing any mailing list traffic and the IRC meetings seem to have ended in
2016.

With all the recent contributor changes, I want to make sure the project
isn't adrift in the sea of OpenStack before we continue to spend development
time implementing the SDK for Octavia. We were also planning to use it as
the backing for our dashboard project.

Since it's not in the governance projects list I couldn't determine who the
PTL to ping would be, so I decided to ping the dev mailing list.

My questions:
1. Is this project abandoned?
2. Is there a plan to make it an official project?
3. Should we continue to develop for it?

Thanks,
Michael (johnsom)

[1]
https://review.openstack.org/#/q/project:openstack/python-openstacksdk+statu
s:open+topic:%255Eoctavia.*


__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Michael Johnson]

Awesome Monty. This is a great proposal.  I have no preference on which way 
these merge, but see huge value in straightening this out.  Frankly I think 
some of the tempest plugin work could benefit from having an official and well 
maintained SDK as well.

So, I am in favor of getting the ball rolling here. I was really hoping to be 
able to use this for our dashboard work in Queens, but giving the work here I 
may need to do something in the interim. Maybe if these patches merge for 
python-openstacksdk I can use that for now and migrate as new SDK becomes 
available.

Michael

-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com] 
Sent: Friday, August 4, 2017 9:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [python-openstacksdk] Status of 
python-openstacksdk project

Conclusion
--

As I mentioned at the top, I'd been thinking some of this already and had 
planned on chatting with folks in person at the PTG, but it seems we're at a 
place where that's potentially counter productive.

Depending on what people think I can follow this up with some governance 
resolutions and more detailed specs.

Thanks!
Monty

__
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Melvin Hillsman]

rage-quit

On Fri, Aug 4, 2017 at 11:52 AM, Monty Taylor  wrote:

> On 08/04/2017 03:24 AM, Thierry Carrez wrote:
>
>> Michael Johnson wrote:
>>
>>> I was wondering what is the current status of the python-openstacksdk
>>> project.  The Octavia team has posted some patches implementing our new
>>> Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have
>>> also
>>> asked some questions in #openstack-sdks with no responses.
>>> I see that there are some maintenance patches getting merged and a pypi
>>> release was made 6/14/17 (though not through releases project).  I'm not
>>> seeing any mailing list traffic and the IRC meetings seem to have ended
>>> in
>>> 2016.
>>>
>>> With all the recent contributor changes, I want to make sure the project
>>> isn't adrift in the sea of OpenStack before we continue to spend
>>> development
>>> time implementing the SDK for Octavia. We were also planning to use it as
>>> the backing for our dashboard project.
>>>
>>> Since it's not in the governance projects list I couldn't determine who
>>> the
>>> PTL to ping would be, so I decided to ping the dev mailing list.
>>>
>>> My questions:
>>> 1. Is this project abandoned?
>>> 2. Is there a plan to make it an official project?
>>> 3. Should we continue to develop for it?
>>>
>>
>> Thanks for raising this.
>>
>> Beyond its limited activity, another issue is that it's not an official
>> project while its name make it a "default choice" for a lot of users
>> (hard to blame them for thinking that
>> http://git.openstack.org/cgit/openstack/python-openstacksdk is not the
>> official Python SDK for OpenStack, but I digress). So I agree that the
>> situation should be clarified.
>>
>> I know that Monty has pretty strong feelings about this too, so I'll
>> wait for him to comment.
>>
>
> Oh boy. I'd kind of hoped we'd make it to the PTG before starting this
> conversation ... guess not. :)
>
> Concerns
> 
>
> I share the same concerns Thierry listed above. Specifically:
>
> * It is not an official project, but its name leads people to believe it's
> the "right" thing to use if they want to talk to OpenStack clouds using
> Python.
>
> * The core team is small to begin with, but recently got hit in a major
> way by shifts in company priorities.
>
> I think we can all agree that those are concerns.
>
> Three additional points:
>
> * The OpenStack AppDev group and the various appdev hackathons use shade,
> not openstacksdk. This is what we have people out in the world recommending
> people use when they write code that consumes OpenStack APIs. The Interop
> challenges at the Summits so far have all used Ansible's OpenStack modules,
> which are based on shade, because they were the thing that works.
>
> * Both shade and python-openstackclient have investigated using
> openstacksdk as their REST layer but were unable to because it puts some
> abstractions in layers that make it impossible to do some of the advanced
> things we need.
>
> * openstacksdk has internal implementations of things that exist at
> different points in the stack. We just added full support for version
> service and version discovery to keystoneauth, but openstacksdk has its own
> layer for that so it both can't use the ksa implementation and is not
> compliant with the API-WG consume guidelines.
>
> It's not all bad! There is some **great** work in openstacksdk and it's a
> shame there are some things that make it hard to consume. Brian, Qiming and
> Terry have done a bunch of excellent work - and I'd like to not lose it to
> the dustbin of corporate shifting interest.
>
> **warning** - there is a very large text wall that follows. If you don't
> care a ton on this topic, please stop reading now, otherwise you  might
> rage-quit computers altogether.
>
> Proposal
> 
>
> I'd propose we have the shade team adopt the python-openstacksdk codebase.
>
> This is obviously an aggressive suggestion and essentially represents a
> takeover of a project. We don't have the luxury of humans to work on things
> that we once had, so I think as a community we should be realistic about
> the benefits of consolidation and the downside to continuing to have 2
> different python SDKs.
>
> Doing that implies the following:
>
> * Rework the underlying guts of openstacksdk to make it possible to
> replace shade's REST layer with openstacksdk. openstacksdk still doesn't
> have a 1.0 release, so we can break the few things we'll need to break.
>
> * Update the shade mission to indicate its purpose in life isn't just
> hiding deployer differences but rather is to provide a holistic
> cloud-centric (rather than service-centric) end-user API library.
>
> * Merge the two repos and retire one of them. Specifics on the mechanics
> of this below, but this will either result in moving the resource and
> service layer in openstacksdk into shade and adding appropriate attributes
> to the shade.OpenStackCloud object, or moving the 

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Monty Taylor]

On 08/04/2017 03:24 AM, Thierry Carrez wrote:

Michael Johnson wrote:

I was wondering what is the current status of the python-openstacksdk
project.  The Octavia team has posted some patches implementing our new
Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
asked some questions in #openstack-sdks with no responses.
I see that there are some maintenance patches getting merged and a pypi
release was made 6/14/17 (though not through releases project).  I'm not
seeing any mailing list traffic and the IRC meetings seem to have ended in
2016.

With all the recent contributor changes, I want to make sure the project
isn't adrift in the sea of OpenStack before we continue to spend development
time implementing the SDK for Octavia. We were also planning to use it as
the backing for our dashboard project.

Since it's not in the governance projects list I couldn't determine who the
PTL to ping would be, so I decided to ping the dev mailing list.

My questions:
1. Is this project abandoned?
2. Is there a plan to make it an official project?
3. Should we continue to develop for it?


Thanks for raising this.

Beyond its limited activity, another issue is that it's not an official
project while its name make it a "default choice" for a lot of users
(hard to blame them for thinking that
http://git.openstack.org/cgit/openstack/python-openstacksdk is not the
official Python SDK for OpenStack, but I digress). So I agree that the
situation should be clarified.

I know that Monty has pretty strong feelings about this too, so I'll
wait for him to comment.


Oh boy. I'd kind of hoped we'd make it to the PTG before starting this 
conversation ... guess not. :)


Concerns


I share the same concerns Thierry listed above. Specifically:

* It is not an official project, but its name leads people to believe 
it's the "right" thing to use if they want to talk to OpenStack clouds 
using Python.


* The core team is small to begin with, but recently got hit in a major 
way by shifts in company priorities.


I think we can all agree that those are concerns.

Three additional points:

* The OpenStack AppDev group and the various appdev hackathons use 
shade, not openstacksdk. This is what we have people out in the world 
recommending people use when they write code that consumes OpenStack 
APIs. The Interop challenges at the Summits so far have all used 
Ansible's OpenStack modules, which are based on shade, because they were 
the thing that works.


* Both shade and python-openstackclient have investigated using 
openstacksdk as their REST layer but were unable to because it puts some 
abstractions in layers that make it impossible to do some of the 
advanced things we need.


* openstacksdk has internal implementations of things that exist at 
different points in the stack. We just added full support for version 
service and version discovery to keystoneauth, but openstacksdk has its 
own layer for that so it both can't use the ksa implementation and is 
not compliant with the API-WG consume guidelines.


It's not all bad! There is some **great** work in openstacksdk and it's 
a shame there are some things that make it hard to consume. Brian, 
Qiming and Terry have done a bunch of excellent work - and I'd like to 
not lose it to the dustbin of corporate shifting interest.


**warning** - there is a very large text wall that follows. If you don't 
care a ton on this topic, please stop reading now, otherwise you  might 
rage-quit computers altogether.


Proposal


I'd propose we have the shade team adopt the python-openstacksdk codebase.

This is obviously an aggressive suggestion and essentially represents a 
takeover of a project. We don't have the luxury of humans to work on 
things that we once had, so I think as a community we should be 
realistic about the benefits of consolidation and the downside to 
continuing to have 2 different python SDKs.


Doing that implies the following:

* Rework the underlying guts of openstacksdk to make it possible to 
replace shade's REST layer with openstacksdk. openstacksdk still doesn't 
have a 1.0 release, so we can break the few things we'll need to break.


* Update the shade mission to indicate its purpose in life isn't just 
hiding deployer differences but rather is to provide a holistic 
cloud-centric (rather than service-centric) end-user API library.


* Merge the two repos and retire one of them. Specifics on the mechanics 
of this below, but this will either result in moving the resource and 
service layer in openstacksdk into shade and adding appropriate 
attributes to the shade.OpenStackCloud object, or moving the 
shade.OpenStackCloud into something like openstack.cloud and making a 
shade backwards-compate shim. I lean towards the first, as we've been 
telling devs "use shade to talk to OpenStack" at hackathons and 
bootcamps and I'd rather avoid the messaging shift. However, pointing to 
an SDK called "The Python OpenStack SDK" and 

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

[Thierry Carrez]

Michael Johnson wrote:
> I was wondering what is the current status of the python-openstacksdk
> project.  The Octavia team has posted some patches implementing our new
> Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
> asked some questions in #openstack-sdks with no responses.
> I see that there are some maintenance patches getting merged and a pypi
> release was made 6/14/17 (though not through releases project).  I'm not
> seeing any mailing list traffic and the IRC meetings seem to have ended in
> 2016.
> 
> With all the recent contributor changes, I want to make sure the project
> isn't adrift in the sea of OpenStack before we continue to spend development
> time implementing the SDK for Octavia. We were also planning to use it as
> the backing for our dashboard project.
> 
> Since it's not in the governance projects list I couldn't determine who the
> PTL to ping would be, so I decided to ping the dev mailing list.
> 
> My questions:
> 1. Is this project abandoned?
> 2. Is there a plan to make it an official project?
> 3. Should we continue to develop for it?

Thanks for raising this.

Beyond its limited activity, another issue is that it's not an official
project while its name make it a "default choice" for a lot of users
(hard to blame them for thinking that
http://git.openstack.org/cgit/openstack/python-openstacksdk is not the
official Python SDK for OpenStack, but I digress). So I agree that the
situation should be clarified.

I know that Monty has pretty strong feelings about this too, so I'll
wait for him to comment.

-- 
Thierry Carrez (ttx)

__
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-dev] [python-openstacksdk] Status of python-openstacksdk project

[Michael Johnson]

Hi OpenStack developers,

I was wondering what is the current status of the python-openstacksdk
project.  The Octavia team has posted some patches implementing our new
Octavia v2 API [1] in the SDK, but we have not had any reviews.  I have also
asked some questions in #openstack-sdks with no responses.
I see that there are some maintenance patches getting merged and a pypi
release was made 6/14/17 (though not through releases project).  I'm not
seeing any mailing list traffic and the IRC meetings seem to have ended in
2016.

With all the recent contributor changes, I want to make sure the project
isn't adrift in the sea of OpenStack before we continue to spend development
time implementing the SDK for Octavia. We were also planning to use it as
the backing for our dashboard project.

Since it's not in the governance projects list I couldn't determine who the
PTL to ping would be, so I decided to ping the dev mailing list.

My questions:
1. Is this project abandoned?
2. Is there a plan to make it an official project?
3. Should we continue to develop for it?

Thanks,
Michael (johnsom)

[1]
https://review.openstack.org/#/q/project:openstack/python-openstacksdk+statu
s:open+topic:%255Eoctavia.*


__
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