Thanks for your support, Akihiro. We will get this up for review very soon.
Carl On Mon, Mar 30, 2015 at 2:59 PM, Akihiro Motoki <amot...@gmail.com> wrote: > 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