<div dir="ltr"><div>Akihiro,</div>thanks for sharing this on the mailing list.<div><br></div><div>I have some answers inline, but from a community process perspective I have a feeling that a majority of contributors feel like well established guidelines have been violated. This has been exacerbated by the fact that these changes are landing at the end of the release cycle.</div><div>If there is a consensus that no change in our API evolution strategy should occur in Kilo - because no change in this strategy has been agree upon - then there is little to discuss - any new addition should be an extension.</div><div><br></div><div>I reckon the shortcomings of this approach have been communicated enough so far, but if we are in a stall condition regarding how to evolve the API then we should resort to the only mechanism that we've used in the past extensions. This also means - in my opinion - that we should provisionally revert or hide all core API changes until they're reproposed as extension. But your proposal about using the extension mechanism to mark that the feature is enabled for the sake of the API client makes sense and is worth exploring too.</div><div><br></div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2015 at 19:35, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>This is true regarding VLAN transparency and MTU.</div><div>For the latter, it is clearly something that might be not supported. In the absence of a better mechanism to detect enabled features, I agree it must be an extension.</div><div>For VLAN transparency, the authors claim (from what I understand) that it's always ok to set it. For deployments with ML2 an exception will be thrown if no driver is available for implementing a vlan transparent network. Plugins that do not support it should just ignore the setting. I don't know how Horizon (or any other client for that matter) will ever realize that the settings had no effect.</div><div><br></div><div>The subnetpool support instead has been implemented in the IPAM logic contained in db_base_plugin_v2. This is why I supported its addition to the core API. Basically, since it does not require specific plugin support, it should always be available, and implemented by all plugins satisfying both your criteria.</div><div>However, there is always an exception represented by plugins which either override the base class or do not use it at all. When I reviewed the subnet pool spec there was no plugin in the first category (at least no known plugin), while I believe only a single plugin in the latter. My thought was that I would not worry about plugins not included in the repository, but now that most are not anymore in openstac/neutron this does not apply, probably.</div><div>I still believe that it is ok to assume subnetpools are part of the core API, but, as stated earlier, if we feel like we are unable to agree anything about how evolve the API, then the only alternative is to keep doing things as we've done today - only by extensions.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div><br></div><div>Indeed it is always challenging when API changes land at the last milestone - and it's probably even harder to handle now that the plugins have been moved out of the main repo. I think this has been a failure of the drivers and core team and we should address it with the appropriate changes for the next release cycle.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It is not perfect but I think it is a good compromise regarding the first point.<br>
<br></blockquote><div><br></div><div>This might be a very good compromise. We only need some sort of mechanism to remove the corresponding resources and attributes from the attribute map (or hide them) when the 'shim' extensions are not enabled.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div><br></div><div>There is always time to revise any design decision. The specs are not and will never be, a binding contract between the author and the rest of the community. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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></blockquote><div><br></div><div>We had one [1], but it was deferred it exactly because of lack of consensus.</div><div> </div><div>[1] <a href="https://review.openstack.org/#/c/136760/">https://review.openstack.org/#/c/136760/</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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><br></div></div></div>