Open Stack

Hi,
I am also fine with the shim extension.
Thanks
Gary

On 3/31/15, 1:44 AM, "Carl Baldwin" <carl at 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 <amotoki at 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 <carl at 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" <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.
>>>>
>>>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Akihiro Motoki <amotoki at gmail.com>
>>
>> 
>>_________________________________________________________________________
>>_
>> 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
>
>__________________________________________________________________________
>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