Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in
Thanks Bob. Two answers/comments below. On 6 May 2015 at 14:59, Bob Melander (bmelande) wrote: > Hi Salvatore, > > Two questions/remarks below. > > From: Salvatore Orlando > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: onsdag 6 maj 2015 00:13 > To: OpenStack Development Mailing List > Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in > > #5 Plugin/Vendor specific APIs > > Neutron is without doubt the project with the highest number of 3rd > party (OSS and commercial) integration. After all it was mostly vendors who > started this project. > Vendors [4] use the extension mechanism to expose features in their > products not covered by the Neutron API or to provide some sort of > value-added service. > The current proposal still allows 3rd parties to attach extensions to the > neutron API, provided that: > - they're not considered part of the Neutron API, in terms of versioning, > documentation, and client support > > BOB> There are today vendor specific commands in the Neutron CLI client. > Such commands are prepended with the name of the vendor, like > cisco_ and nec_. > I think that makes it quite visible to the user that the command is > specific to a vendor feature and not part of neutron core. Would it be > possible to allow for that also going forward? I would think that from a > user perspective it can be convenient to be able to access vendor add-on > features using a single CLI client. > In a nutshell no, but maybe. Vendor extensions are not part of the Neutron API, but if the community decides to support them in the official client anyway, you will still be able to run vendor-specific CLI commands. Otherwise vendors will have to provide their own client tools, which is feasible as well. Personally, I would be against having vendor-specific CLI commands in python-neutronclient. To me it will be tantamount to saying: yes please do versioning, but don't take extensions away from us. However the developer, user, and operator community might have a different opinion, and as usual the decision will derive from community consensus. > >- they do not redefine resources defined by the Neutron API. > > BOB> Does “redefine" here include extending a resource with additional > attributes? > In my opinion yes. But I do not have a very strong point here. Also, enforcing this will require many vendors to do backward incompatible changes in the API, and therefore we would need a deprecation cycle. So let's say that ideally modifying the shape of neutron resource by adding attributes, might be considered a "discouraged, but not forbidden" practice. For instance if you want to attach a qos profile to a port rather then adding a 'vendor_qos_profile' to the port resource you might add a vendor_port_info resource with a reference to the vendor_qos_profile_id and the neutron port_id. >- they do not live in the neutron source tree > The aim of the provisions above is to minimize the impact of such > extensions on API portability. > > Thanks for reading and thanks in advance for your feedback, > Salvatore > > The title of this post has been inspired by [2] (the message in the > banner may be unintelligible to readers not fluent in european football) > > [1] https://review.openstack.org/#/c/136760/ > [2] > http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc > [3] > http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html > [4] By "vendor" here we refer either to a cloud provider or a company > providing Neutron integration for their products. > > __ > 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][api] Extensions out, Micro-versions in
Hi Salvatore, Two questions/remarks below. From: Salvatore Orlando mailto:sorla...@nicira.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: onsdag 6 maj 2015 00:13 To: OpenStack Development Mailing List mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support BOB> There are today vendor specific commands in the Neutron CLI client. Such commands are prepended with the name of the vendor, like cisco_ and nec_. I think that makes it quite visible to the user that the command is specific to a vendor feature and not part of neutron core. Would it be possible to allow for that also going forward? I would think that from a user perspective it can be convenient to be able to access vendor add-on features using a single CLI client. - they do not redefine resources defined by the Neutron API. BOB> Does “redefine" here include extending a resource with additional attributes? - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By "vendor" here we refer either to a cloud provider or a company providing Neutron integration for their products. __ 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][api] Extensions out, Micro-versions in
Thanks Kevin, answers inline. On 6 May 2015 at 00:28, Fox, Kevin M wrote: > so... as an operator looking at #3, If I need to support lbaas, I'm > getting pushed to run more and more services, like octavia, plus a > neutron-lbaas service, plus neutron? This seems like an operator > scalability issue... What benifit does splitting out the advanced services > into their own services have? > You have a valid point here. In the past I was keen on insisting that neutron was supposed to be a management layer only service for most networking services. However, the consensus seems to move toward a microservices-style architecture. It would be interesting to get some feedback regarding the additional operational burden of managing a plethora of services, even if it is worth noting that when one deploys neutron with its reference architecture there are already plenty of moving parts. Regardless, I need to slaps your hand because this discussion is not really pertinent to this thread, which is specifically about having a strategy for the Neutron API. I would be happy to have a separate thread for defining a strategy for neutron services. I'm pretty sure Doug will be more than happy to slap your hands too. > Thanks, > Kevin > -- > *From:* Salvatore Orlando [sorla...@nicira.com] > *Sent:* Tuesday, May 05, 2015 3:13 PM > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [neutron][api] Extensions out, Micro-versions > in > > There have now been a few iterations on the specification for Neutron > micro-versioning [1]. > It seems that no-one in the community opposes introducing versioning. In > particular API micro-versioning as implemented by Nova and Ironic seems a > decent way to evolve the API incrementally. > > What the developer community seems not yet convinced about is moving > away from extensions. It seems everybody realises the flaws of evolving the > API through extensions, but there are understandable concerns regarding > impact on plugins/drivers as well as the ability to differentiate, which is > something quite dear to several neutron teams. I tried to consider all > those concerns and feedback received; hopefully everything has been > captured in a satisfactory way in the latest revision of [1]. > With this ML post I also seek feedback from the API-wg concerning the > current proposal, whose salient points can be summarised as follows: > > #1 extensions are not part anymore of the neutron API. > > Evolution of the API will now be handled through versioning. Once > microversions are introduced: >- current extensions will be progressively moved into the Neutron > "unified" API >- no more extension will be accepted as part of the Neutron API > > #2 Introduction of "features" for addressing diversity in Neutron plugins > > It is possible that the combination of neutron plugins chosen by the > operator won't be able to support the whole Neutron API. For this reason a > concept of "feature" is included. What features are provided depends on the > plugins loaded. The list of features is hardcoded as strictly dependent on > the Neutron API version implemented by the server. The specification also > mandates a minimum set of features every neutron deployment must provide > (those would be the minimum set of features needed for integrating Neutron > with Nova). > > #3 Advanced services are still extensions > > This a temporary measure, as APIs for load balancing, VPN, and Edge > Firewall are still served through neutron WSGI. As in the future this API > will live independently it does not make sense to version them with Neutron > APIs. > > #4 Experimenting in the API > > One thing that has plagued Neutron in the past is the impossibility of > getting people to reach any sort of agreement over the shape of certain > APIs. With the proposed plan we encourage developers to submit experimental > APIs. Experimental APIs are unversioned and no guarantee is made regarding > deprecation or backward compatibility. Also they're optional, as a deployer > can turn them off. While there are caveats, like forever-experimental APIs, > this will enable developer to address user feedback during the APIs' > experimental phase. The Neutron community and the API-wg can provide plenty > of useful feeback, but ultimately is user feedback which determines whether > an API proved successful or not. Please note that the current proposal goes > in a direction different from that approved in Nova when it comes to > experimental APIs [3] > > #5 Plugin/Vendor specific APIs > > Neutron is without doubt the project with the highest number of 3rd > party (OSS and commercial) integrati
Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in
so... as an operator looking at #3, If I need to support lbaas, I'm getting pushed to run more and more services, like octavia, plus a neutron-lbaas service, plus neutron? This seems like an operator scalability issue... What benifit does splitting out the advanced services into their own services have? Thanks, Kevin From: Salvatore Orlando [sorla...@nicira.com] Sent: Tuesday, May 05, 2015 3:13 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in There have now been a few iterations on the specification for Neutron micro-versioning [1]. It seems that no-one in the community opposes introducing versioning. In particular API micro-versioning as implemented by Nova and Ironic seems a decent way to evolve the API incrementally. What the developer community seems not yet convinced about is moving away from extensions. It seems everybody realises the flaws of evolving the API through extensions, but there are understandable concerns regarding impact on plugins/drivers as well as the ability to differentiate, which is something quite dear to several neutron teams. I tried to consider all those concerns and feedback received; hopefully everything has been captured in a satisfactory way in the latest revision of [1]. With this ML post I also seek feedback from the API-wg concerning the current proposal, whose salient points can be summarised as follows: #1 extensions are not part anymore of the neutron API. Evolution of the API will now be handled through versioning. Once microversions are introduced: - current extensions will be progressively moved into the Neutron "unified" API - no more extension will be accepted as part of the Neutron API #2 Introduction of "features" for addressing diversity in Neutron plugins It is possible that the combination of neutron plugins chosen by the operator won't be able to support the whole Neutron API. For this reason a concept of "feature" is included. What features are provided depends on the plugins loaded. The list of features is hardcoded as strictly dependent on the Neutron API version implemented by the server. The specification also mandates a minimum set of features every neutron deployment must provide (those would be the minimum set of features needed for integrating Neutron with Nova). #3 Advanced services are still extensions This a temporary measure, as APIs for load balancing, VPN, and Edge Firewall are still served through neutron WSGI. As in the future this API will live independently it does not make sense to version them with Neutron APIs. #4 Experimenting in the API One thing that has plagued Neutron in the past is the impossibility of getting people to reach any sort of agreement over the shape of certain APIs. With the proposed plan we encourage developers to submit experimental APIs. Experimental APIs are unversioned and no guarantee is made regarding deprecation or backward compatibility. Also they're optional, as a deployer can turn them off. While there are caveats, like forever-experimental APIs, this will enable developer to address user feedback during the APIs' experimental phase. The Neutron community and the API-wg can provide plenty of useful feeback, but ultimately is user feedback which determines whether an API proved successful or not. Please note that the current proposal goes in a direction different from that approved in Nova when it comes to experimental APIs [3] #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support - they do not redefine resources defined by the Neutron API. - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By "vendor" here we refer either to a cloud provider or a company providing Neutron integration for their products. ___
[openstack-dev] [neutron][api] Extensions out, Micro-versions in
There have now been a few iterations on the specification for Neutron micro-versioning [1]. It seems that no-one in the community opposes introducing versioning. In particular API micro-versioning as implemented by Nova and Ironic seems a decent way to evolve the API incrementally. What the developer community seems not yet convinced about is moving away from extensions. It seems everybody realises the flaws of evolving the API through extensions, but there are understandable concerns regarding impact on plugins/drivers as well as the ability to differentiate, which is something quite dear to several neutron teams. I tried to consider all those concerns and feedback received; hopefully everything has been captured in a satisfactory way in the latest revision of [1]. With this ML post I also seek feedback from the API-wg concerning the current proposal, whose salient points can be summarised as follows: #1 extensions are not part anymore of the neutron API. Evolution of the API will now be handled through versioning. Once microversions are introduced: - current extensions will be progressively moved into the Neutron "unified" API - no more extension will be accepted as part of the Neutron API #2 Introduction of "features" for addressing diversity in Neutron plugins It is possible that the combination of neutron plugins chosen by the operator won't be able to support the whole Neutron API. For this reason a concept of "feature" is included. What features are provided depends on the plugins loaded. The list of features is hardcoded as strictly dependent on the Neutron API version implemented by the server. The specification also mandates a minimum set of features every neutron deployment must provide (those would be the minimum set of features needed for integrating Neutron with Nova). #3 Advanced services are still extensions This a temporary measure, as APIs for load balancing, VPN, and Edge Firewall are still served through neutron WSGI. As in the future this API will live independently it does not make sense to version them with Neutron APIs. #4 Experimenting in the API One thing that has plagued Neutron in the past is the impossibility of getting people to reach any sort of agreement over the shape of certain APIs. With the proposed plan we encourage developers to submit experimental APIs. Experimental APIs are unversioned and no guarantee is made regarding deprecation or backward compatibility. Also they're optional, as a deployer can turn them off. While there are caveats, like forever-experimental APIs, this will enable developer to address user feedback during the APIs' experimental phase. The Neutron community and the API-wg can provide plenty of useful feeback, but ultimately is user feedback which determines whether an API proved successful or not. Please note that the current proposal goes in a direction different from that approved in Nova when it comes to experimental APIs [3] #5 Plugin/Vendor specific APIs Neutron is without doubt the project with the highest number of 3rd party (OSS and commercial) integration. After all it was mostly vendors who started this project. Vendors [4] use the extension mechanism to expose features in their products not covered by the Neutron API or to provide some sort of value-added service. The current proposal still allows 3rd parties to attach extensions to the neutron API, provided that: - they're not considered part of the Neutron API, in terms of versioning, documentation, and client support - they do not redefine resources defined by the Neutron API. - they do not live in the neutron source tree The aim of the provisions above is to minimize the impact of such extensions on API portability. Thanks for reading and thanks in advance for your feedback, Salvatore The title of this post has been inspired by [2] (the message in the banner may be unintelligible to readers not fluent in european football) [1] https://review.openstack.org/#/c/136760/ [2] http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc [3] http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html [4] By "vendor" here we refer either to a cloud provider or a company providing Neutron integration for their products. __ 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
