Open Stack

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:amotoki at 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 <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