Open Stack

I think this discussion has several aspects from general direction to
implementation details.

TL;DR
My suggestion as a main maintainer of python-neutronclient is to
upstream all out-of-tree APIs, support all features in OSC and push
away 'neutron' CLI.

The long version;

In my basic understanding, OpenStack in general has chosen the way
that we don't accept vendor extensions in API from the POV of inter
operability. neutron still supports to load out-of-tree API
definitions but I think neutron is just behind it. Nova drops
out-of-tree extension support in the API in Pike as Matt mentioned,
and if we move the (micro-)versioning forward out-of-tree API
definition will have more difficulties. IMHO I would like to see all
APIs are upstreamed as others commented. I believe this point is most
important and we all needs to be in a same page. Hopefully all
out-of-tree APIs will be upstreamed.

My understanding is the current OSC and openstacksdk (in addition to
shade) adopts this position.

On the other hand, we also need to take care of existing users on the
'neutron' CLI side.
I think there are several options on python-neutronclient.
(a) keep the current deprecation and recommend out-of-tree API to be upstreamed
(b) no deprecation warning from neutron CLI but keep the deprecation
policy on 'neutron' CLI (which means no new feature and positive
maintenance is provided)
(c) changing the current deprecation policy and continue to add new
features to 'neutron' CLI

I think (a) or (b) is realistic.
(c) needs more developers and reviewers. (I personally supports OSC,
openstacksdk and shade.)

The deprecation means no features will be coming for 'neutron' CLI and
all new features are suggested to go to OSC. I believe this is the
future we agreed. We can keep 'neutron' CLI only for existing
features, even though no neutron (and stadium projects) need to
implement new features in 'neutron' CLI. neutron CLI will be gone even
if there is no deprecation notice. At some point, we can split out
*CLI* part of neutronclient to a hosted project if someone wants to
keep 'neutron' CLI.

There is another background which makes neutron CLI difficult to keep
backward compatibility. The neutron option parsing is ugly enough and
it is hard to be maintained. It breaks backward compatibility so
easily and prevents from changing option formats or introducing new
options which are considered better. Thus, as a main maintainer of
python-neutronclient, I would like to push away this feature
completely, but perhaps this is the feature which out-of-tree API
would like to leverage. Does anyone want to support the extra argument
mechanism in neutron CLI ([1] and [2] for more detail)?

[1] https://docs.openstack.org/python-neutronclient/latest/cli/neutron.html#extra-arguments-for-create-update-operation
[2] https://docs.openstack.org/python-neutronclient/latest/contributor/cli_option_guideline.html

Thanks,
Akihiro

2017-08-09 2:46 GMT+09:00 Boden Russell <bodenvmw at gmail.com>:
>
> On 8/8/17 10:29 AM, Akihiro Motoki wrote:
>> My reply applies to 'resource' extension but does not apply to
>> 'attribute extension'
>
> My apologies for using confusing terminology; as you pointed out we
> don't currently have a good solution for attribute extensions with OSC
> and I've tried to outline the technicals in the RFE style bug [1] where
> I hope we can continue this discussion.
>
> python-neutronclient does support these attribute extensions, but as of
> today neutronclient gives deprecation warnings when used; so users are
> "concerned" when they see this and we don't have a complete story for
> OSC. Perhaps we can suppress those deprecations until we figure out a
> path forward?
>
> Thanks
>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1705755
>
> __________________________________________________________________________
> 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