Open Stack

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-<projectname>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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>