<p dir="ltr">Akihiro,</p>
<p dir="ltr">If we go with the empty extension you proposed in the patch will that be acceptable?  </p>
<p dir="ltr">We've got to stop killing new functionality on the very last day like this . It just kills progress.  This proposal isn't new.</p>
<p dir="ltr">Carl</p>
<div class="gmail_quote">On Mar 30, 2015 11:37 AM, "Akihiro Motoki" <<a href="mailto:amotoki@gmail.com">amotoki@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Neutron folks<br>
(API folks may be interested on this)<br>
<br>
We have another discussion on Core vs extension in the subnet pool<br>
feature reivew<br>
<a href="https://review.openstack.org/#/c/157597/" target="_blank">https://review.openstack.org/#/c/157597/</a>.<br>
We did the similar discussion on VLAN transparency and MTU for a<br>
network model last week.<br>
I would like to share my concerns on changing the core API directly.<br>
I hope this help us make the discussion productive.<br>
Note that I don't want to discuss the micro-versioning because it<br>
mainly focues on Kilo FFE BP.<br>
<br>
I would like to discuss this topic in today's neutron meeting,<br>
but I am not so confident I can get up in time, I would like to send this mail.<br>
<br>
<br>
The extension mechanism in Neutron provides two points for extensibility:<br>
- (a) visibility of features in API (users can know which features are<br>
available through the API)<br>
- (b) opt-in mechanism in plugins (plugin maintainers can decide to<br>
support some feature after checking the detail)<br>
<br>
My concerns mainly comes from the first point (a).<br>
If we have no way to detect it, users (including Horizon) need to do a<br>
dirty work around<br>
to determine whether some feature is available. I believe this is one<br>
important point in API.<br>
<br>
On the second point, my only concern (not so important) is that we are<br>
making the core<br>
API change at this moment of the release. Some plugins do not consume<br>
db_base_plugin and<br>
such plugins need to investigate the impact from now on.<br>
On the other hand, if we use the extension mechanism all plugins need to update<br>
their extension list in the last moment :-(<br>
<br>
<br>
My vote at this moment is still to use an extension, but an extension<br>
layer can be a shim.<br>
The idea is to that all implementation can be as-is and we just add an<br>
extension module<br>
so that the new feature is visible thru the extension list.<br>
It is not perfect but I think it is a good compromise regarding the first point.<br>
<br>
<br>
I know there was a suggestion to change this into the core API in the<br>
spec review<br>
and I didn't notice it at that time, but I would like to raise this<br>
before releasing it.<br>
<br>
For longer term (and Liberty cycle),  we need to define more clear guideline<br>
on "Core vs extension vs micro-versioning" in spec reviews.<br>
<br>
Thanks,<br>
Akihiro<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>