Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature
Hi, I am also fine with the shim extension. Thanks Gary On 3/31/15, 1:44 AM, Carl Baldwin c...@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 amot...@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 c...@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 amot...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature
Akihiro, thanks for sharing this on the mailing list. 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. 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. 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. Salvatore On 30 March 2015 at 19:35, Akihiro Motoki amot...@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. This is true regarding VLAN transparency and MTU. 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. 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. 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. 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. 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. 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 :-( 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. 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
Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature
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 amot...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature
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:amot...@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 c...@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 amot...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 c...@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 amot...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature
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 amot...@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 c...@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 amot...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akihiro Motoki amot...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
