Comment 14 for bug 1705755

Sorry for a long post.

I think there are several points in this discussion.
- (a) community-wide API direction,
- (b) neutron API future, and
- (c) CLI support for the CURRENT neutron API (with extension support)

Note that I use "extension" as the context of API extensions by third-party plugins/drivers.
APIs defined in neutron-lib are not considered as "API extensions" and they are "core" in this context.

Regarding (a), "inter-operability" across OpenStack clouds is an important aspect. This leads to a question on whether OpenStack will accept API extensions in future as a whole. In my understanding, the Foundation, TC, and API-SIG are suggesting not to use API extensions. Neutron is alone now because we are behind other projects (it's my fault in most parts....). I am not sure we continue the current approach. Ideally all API extensions provided by vendors should be part of the neutron official APIs. I think most of the feedback from the ML discussion are based on this direction (+ openstacksdk/shade development policies).

Regrading (b), IMHO the long-term goal is same as (a), but in the short/middle term we must take into account the current situation where we allow "API extensions" by vendors. Nova took long time to drop API extensions (as Matt mentioned in comment #2). We should assume the similar period (two or three years?) even if we drop API extensions).

Regarding (c), I think this is the main point that Boden would like to discuss.
There seems two ways: (c1) to convince OSC folks to accept third-party extension, or (c2) to keep
"neutron" CLI.

Even if we go to the route of (c1), we need to honor the middle/long term direction of OpenStack API. I cannot say much though I am not a fan of vendor extensions. On this route, we cannot determine the future only in the neutron team.

If we go to the router of (c2), the next question is which will be the priority for us, OSC vs "neutron" CLI. IMHO OSC is the long-term direction. If so, new features are supported by OSC and some volunteers need to catch up with them in 'neutron' CLI.

Ideally all vendor API extensions are upstreamed defined in neutron-lib, but this is perhaps not acceptable though.

From the implementation perspective, the extra argument mechanism is completely a mistake (at least to me). This requires us a super-loose argument parsing. "neutron" CLI completely depends on the order of arguments and we cannot provide an interface which is user-friendly and understood easily. We received a number of bugs on "neutron" CLI behaves in a confusing way if only the order of some arguments are changed. As a result, we have this kind of ugly argument definitions [1]. If we have some support of vendor API extension in OSC, the argument parsing must be more strict not to repeat the technical debt in neutron CLI.

# Personally I am tired of maintaining the extra argument mechanism. If we continue to keep it, some volunteer to maintain it other than me.

[1] http://git.openstack.org/cgit/openstack/python-neutronclient/tree/neutronclient/neutron/v2_0/subnet.py#n95