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 <boden...@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-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