Thanks Kevin, answers inline.
On 6 May 2015 at 00:28, Fox, Kevin M <kevin....@pnnl.gov> 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) 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 > >
__________________________________________________________________________ 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
