Open Stack

Thanks Kevin,

answers inline.

On 6 May 2015 at 00:28, Fox, Kevin M <Kevin.Fox at 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 [sorlando at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/1e3ca3d4/attachment.html>