I will quickly spin another patch set with the shim extension. Hopefully this will be all it takes to get subnet allocation merged.
-Ryan -----Original Message----- From: Akihiro Motoki [mailto:amot...@gmail.com] Sent: Monday, March 30, 2015 2:00 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature Hi Carl, I am now reading the detail from Salvatore, but would like to response this first. I don't want to kill this useful feature too and move the thing forward. I am fine with the empty/shim extension approach. The subnet pool is regarded as a part of Core API, so I think this extension can be always enabled even if no plugin declares to use it. Sorry for interrupting the work at the last stage, and thank for understanding. Akihiro 2015-03-31 5:28 GMT+09:00 Carl Baldwin <c...@ecbaldwin.net>: > 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 > -- Akihiro Motoki <amot...@gmail.com> __________________________________________________________________________ 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
