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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
