Open Stack

Akihiro,
thanks for sharing this on the mailing list.

I have some answers inline, but from a community process perspective I have
a feeling that a majority of contributors feel like well established
guidelines have been violated. This has been exacerbated by the fact that
these changes are landing at the end of the release cycle.
If there is a consensus that no change in our API evolution strategy should
occur in Kilo - because no change in this strategy has been agree upon -
then there is little to discuss - any new addition should be an extension.

I reckon the shortcomings of this approach have been communicated enough so
far, but if we are in a stall condition regarding how to evolve the API
then we should resort to the only mechanism that we've used in the past
extensions. This also means - in my opinion - that we should provisionally
revert or hide all core API changes until they're reproposed as extension.
But your proposal about using the extension mechanism to mark that the
feature is enabled for the sake of the API client makes sense and is worth
exploring too.

Salvatore

On 30 March 2015 at 19:35, Akihiro Motoki <amotoki at gmail.com> wrote:

> Hi Neutron folks
> (API folks may be interested on this)
>
> We have another discussion on Core vs extension in the subnet pool
> feature reivew
> https://review.openstack.org/#/c/157597/.
> We did the similar discussion on VLAN transparency and MTU for a
> network model last week.
> I would like to share my concerns on changing the core API directly.
> I hope this help us make the discussion productive.
> Note that I don't want to discuss the micro-versioning because it
> mainly focues on Kilo FFE BP.
>
> I would like to discuss this topic in today's neutron meeting,
> but I am not so confident I can get up in time, I would like to send this
> mail.
>
>
> The extension mechanism in Neutron provides two points for extensibility:
> - (a) visibility of features in API (users can know which features are
> available through the API)
> - (b) opt-in mechanism in plugins (plugin maintainers can decide to
> support some feature after checking the detail)
>
> My concerns mainly comes from the first point (a).
> If we have no way to detect it, users (including Horizon) need to do a
> dirty work around
> to determine whether some feature is available. I believe this is one
> important point in API.
>

This is true regarding VLAN transparency and MTU.
For the latter, it is clearly something that might be not supported. In the
absence of a better mechanism to detect enabled features, I agree it must
be an extension.
For VLAN transparency, the authors claim (from what I understand) that it's
always ok to set it. For deployments with ML2 an exception will be thrown
if no driver is available for implementing a vlan transparent network.
Plugins that do not support it should just ignore the setting. I don't know
how Horizon (or any other client for that matter) will ever realize that
the settings had no effect.

The subnetpool support instead has been implemented in the IPAM logic
contained in db_base_plugin_v2. This is why I supported its addition to the
core API. Basically, since it does not require specific plugin support, it
should always be available, and implemented by all plugins satisfying both
your criteria.
However, there is always an exception represented by plugins which either
override the base class or do not use it at all. When I reviewed the subnet
pool spec there was no plugin in the first category (at least no known
plugin), while I believe only a single plugin in the latter. My thought was
that I would not worry about plugins not included in the repository, but
now that most are not anymore in openstac/neutron this does not apply,
probably.
I still believe that it is ok to assume subnetpools are part of the core
API, but, as stated earlier, if we feel like we are unable to agree
anything about how evolve the API, then the only alternative is to keep
doing things as we've done today - only by extensions.



>
> On the second point, my only concern (not so important) is that we are
> making the core
> API change at this moment of the release. Some plugins do not consume
> db_base_plugin and
> such plugins need to investigate the impact from now on.
> On the other hand, if we use the extension mechanism all plugins need to
> update
> their extension list in the last moment :-(
>

Indeed it is always challenging when API changes land at the last milestone
- and it's probably even harder to handle now that the plugins have been
moved out of the main repo. I think this has been a failure of the drivers
and core team and we should address it with the appropriate changes for the
next release cycle.



>
> My vote at this moment is still to use an extension, but an extension
> layer can be a shim.
> The idea is to that all implementation can be as-is and we just add an
> extension module
> so that the new feature is visible thru the extension list.
>
It is not perfect but I think it is a good compromise regarding the first
> point.
>
>
This might be a very good compromise. We only need some sort of mechanism
to remove the corresponding resources and attributes from the attribute map
(or hide them) when the 'shim' extensions are not enabled.


>
> I know there was a suggestion to change this into the core API in the
> spec review
> and I didn't notice it at that time, but I would like to raise this
> before releasing it.
>

There is always time to revise any design decision. The specs are not and
will never be, a binding contract between the author and the rest of the
community.

>
> For longer term (and Liberty cycle),  we need to define more clear
> guideline
> on "Core vs extension vs micro-versioning" in spec reviews.
>

We had one [1], but it was deferred it exactly because of lack of consensus.

[1] https://review.openstack.org/#/c/136760/

>
> Thanks,
> Akihiro
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150330/99ddf12f/attachment-0001.html>