Open Stack

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