Re: [openstack-dev] [neutron] Microversioning work questions and kick-start
On 12 June 2015 at 16:58, Henry Gessau ges...@cisco.com wrote: On Thu, Jun 11, 2015, Salvatore Orlando sorla...@nicira.com wrote: Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL and the API lieutenants would ok with agreeing to have a team of developers meeting regularly, working towards implementing this feature, and report progress and/or issues to the general Neutron meeting. Yes, I am ok with agreeing to form such a team. ;) With an effort this complex it makes sense to have tl;dr type summaries in the general meeting. This has worked well for large-effort features before, and when the work winds down the topic can fold back into the main meeting. Thanks Henry! So I would say that perhaps we could gather interest from developers - either using this thread or another one - and once we have a critical mass of, for instance, 5 developers, we will kick off the activities, book a weekly slot for more or less regular meetings, set expectations, review design, discuss implementation, and hopefully get this thing done. Salvatore __ 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] Microversioning work questions and kick-start
On 12 June 2015 at 12:22, Sean Dague s...@dague.net wrote: On 06/11/2015 06:03 PM, Salvatore Orlando wrote: As most of you already know, work is beginning to move forward on the micro-versioned Neutron API, for which a specification is available at [1] From a practical perspective there is one non-negligible preliminary issue that needs attention. then Neutron API URI prefix includes the full version number - currently 2.0. For instance: http://neutron_server:9696/v2.0/networks.json This clearly makes a microversioned approach a bit weird - if you have to use, for instance, 2.0 as a URI prefix for API version 2.12. On the one hand it might make sense to start the micro-versioned API as a sort of clean slate, possibly using a version-agnostic URI prefix or no prefix at all; also as pointed out by some community members it will give a chance to validate this versioned API approach. This will have however the drawback that both the unversioned, extension-based so-called 2.0 API will keep living and evolving side-by-side with the versioned API, and then switching to the versioned API will not be transparent to clients. It would be good to receive some opinions from the developer and user community on the topic. It will definitely be challenging to have both evolving at once. The Nova team had a lot of pains in that happening in the 18 months of v3.0 work. Once we got the microversion mechanism in place we hard froze v2.0. That being said we actually had 2 internal code bases, so our situation was a bit gorpier than yours. Well, we'd have both extensions and revisions evolving at the same time. The situation won't be nearly as difficult to handle as nova v3.0, but it still be a hassle. While I understand where people advocating for not freezing the current extension-based mechanisms until microversioning is proved and tested, on the other hand my concern is that this effort is already on the failure road as it's pretty much an experimental alternative to the current way of evolving the API for the foreseeable future. Therefore I would say that the community might accept that if microversioning is functionally complete and reliably working in version X (where X is an openstack release), then automatically the old API will be frozen in the same version, deprecated in X+1 and killed in X+2. On the version in the url: My expectation is at some point the future we'll privot out of having a version string in our URL entirely, but it's one of those things that can come later. The url root is mostly important from a service catalog perspective, in that what's there matches what the code returns in all it's internal links. Honestly, long term, it would be great if 1) we actually developer standards for naming in the service catalog 2) the API services stop having their API url in code, but instead reflect it back from the catalog. Which would fix one of the gorpiest parts of putting your API servers behind haproxy or ssl termination. I.e. I wouldn't be too concerned on that front, it looks a little funny, but won't really get in anyone's way. Furthermore, another topic that has been brought up is whether plugins should be allowed to control the version of the API server, like specifying minimum and maximum version. My short answer is no, because the plugin should implement the API, not controlling it. Also, the spec provides a facility for plugins to disable features if they are unable to support them. Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL and the API lieutenants would ok with agreeing to have a team of developers meeting regularly, working towards implementing this feature, and report progress and/or issues to the general Neutron meeting. Salvatore [1] https://review.openstack.org/#/c/136760/ __ 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 -- Sean Dague http://dague.net __ 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] Microversioning work questions and kick-start
On 06/11/2015 06:03 PM, Salvatore Orlando wrote: As most of you already know, work is beginning to move forward on the micro-versioned Neutron API, for which a specification is available at [1] From a practical perspective there is one non-negligible preliminary issue that needs attention. then Neutron API URI prefix includes the full version number - currently 2.0. For instance: http://neutron_server:9696/v2.0/networks.json This clearly makes a microversioned approach a bit weird - if you have to use, for instance, 2.0 as a URI prefix for API version 2.12. On the one hand it might make sense to start the micro-versioned API as a sort of clean slate, possibly using a version-agnostic URI prefix or no prefix at all; also as pointed out by some community members it will give a chance to validate this versioned API approach. This will have however the drawback that both the unversioned, extension-based so-called 2.0 API will keep living and evolving side-by-side with the versioned API, and then switching to the versioned API will not be transparent to clients. It would be good to receive some opinions from the developer and user community on the topic. It will definitely be challenging to have both evolving at once. The Nova team had a lot of pains in that happening in the 18 months of v3.0 work. Once we got the microversion mechanism in place we hard froze v2.0. That being said we actually had 2 internal code bases, so our situation was a bit gorpier than yours. On the version in the url: My expectation is at some point the future we'll privot out of having a version string in our URL entirely, but it's one of those things that can come later. The url root is mostly important from a service catalog perspective, in that what's there matches what the code returns in all it's internal links. Honestly, long term, it would be great if 1) we actually developer standards for naming in the service catalog 2) the API services stop having their API url in code, but instead reflect it back from the catalog. Which would fix one of the gorpiest parts of putting your API servers behind haproxy or ssl termination. I.e. I wouldn't be too concerned on that front, it looks a little funny, but won't really get in anyone's way. Furthermore, another topic that has been brought up is whether plugins should be allowed to control the version of the API server, like specifying minimum and maximum version. My short answer is no, because the plugin should implement the API, not controlling it. Also, the spec provides a facility for plugins to disable features if they are unable to support them. Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL and the API lieutenants would ok with agreeing to have a team of developers meeting regularly, working towards implementing this feature, and report progress and/or issues to the general Neutron meeting. Salvatore [1] https://review.openstack.org/#/c/136760/ __ 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 -- Sean Dague http://dague.net __ 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] Microversioning work questions and kick-start
On Thu, Jun 11, 2015, Salvatore Orlando sorla...@nicira.com wrote: Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL and the API lieutenants would ok with agreeing to have a team of developers meeting regularly, working towards implementing this feature, and report progress and/or issues to the general Neutron meeting. Yes, I am ok with agreeing to form such a team. ;) With an effort this complex it makes sense to have tl;dr type summaries in the general meeting. This has worked well for large-effort features before, and when the work winds down the topic can fold back into the main meeting. __ 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] Microversioning work questions and kick-start
On Thu, Jun 11, 2015 at 5:03 PM, Salvatore Orlando sorla...@nicira.com wrote: As most of you already know, work is beginning to move forward on the micro-versioned Neutron API, for which a specification is available at [1] Yes, I just approved the spec in fact. From a practical perspective there is one non-negligible preliminary issue that needs attention. then Neutron API URI prefix includes the full version number - currently 2.0. For instance: http://neutron_server:9696/v2.0/networks.json This clearly makes a microversioned approach a bit weird - if you have to use, for instance, 2.0 as a URI prefix for API version 2.12. On the one hand it might make sense to start the micro-versioned API as a sort of clean slate, possibly using a version-agnostic URI prefix or no prefix at all; also as pointed out by some community members it will give a chance to validate this versioned API approach. This will have however the drawback that both the unversioned, extension-based so-called 2.0 API will keep living and evolving side-by-side with the versioned API, and then switching to the versioned API will not be transparent to clients. It would be good to receive some opinions from the developer and user community on the topic. I'll defer to your judgement here Salv, but it seems as if we move to no prefix at all, that's where we want to eventually be. And it has the benefit of letting us test this out. Furthermore, another topic that has been brought up is whether plugins should be allowed to control the version of the API server, like specifying minimum and maximum version. My short answer is no, because the plugin should implement the API, not controlling it. Also, the spec provides a facility for plugins to disable features if they are unable to support them. Agree with your short answer. Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL and the API lieutenants would ok with agreeing to have a team of developers meeting regularly, working towards implementing this feature, and report progress and/or issues to the general Neutron meeting. Yes, this makes sense. I'll defer to you, Henry and Akihiro to setup a time for this. Syncing weekly as you and the team work through this would hopefully expedite the work! Thanks! Kyle Salvatore [1] https://review.openstack.org/#/c/136760/ __ 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
