Akihiro, If we go with the empty extension you proposed in the patch will that be acceptable?
We've got to stop killing new functionality on the very last day like this . It just kills progress. This proposal isn't new. Carl On Mar 30, 2015 11:37 AM, "Akihiro Motoki" <amot...@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. > > 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 :-( > > > 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. > > > 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. > > For longer term (and Liberty cycle), we need to define more clear > guideline > on "Core vs extension vs micro-versioning" in spec reviews. > > Thanks, > Akihiro > > __________________________________________________________________________ > 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
