Hi, I am also fine with the shim extension. Thanks Gary On 3/31/15, 1:44 AM, "Carl Baldwin" <c...@ecbaldwin.net> wrote:
>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 __________________________________________________________________________ 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
