[openstack-dev] [python-openstacksdk] Status of python-openstacksdk project
mordred at inaugust.com
Mon Aug 7 19:36:32 UTC 2017
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 .
> 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 , 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  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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev