Open Stack

On 30 June 2016 at 10:55, HU, BIN <bh526r at att.com> wrote:

> I see, and thank you very much Dan. Also thank you Markus for unreleased
> release notes.
>
> Now I understand that it is not a plugin and unstable interface. And there
> is a new "use_neutron" option for configuring Nova to use Neutron as its
> network backend.
>
> When we use Neutron, there are ML2 and ML3 plugins so that we can choose
> to use different backend providers to actually perform those network
> functions. For example, integration with ODL.
>

There's no such a thing as ML3, not yet anyway and not in the same shape of
ML2.


>
> Shall we foresee a situation, where user can choose another network
> backend directly, e.g. ODL, ONOS? Under this circumstance, a stable plugin
> interface seems needed which can provide end users with more options and
> flexibility in deployment.
>

The networking landscape is dramatically different from the one Nova
experiences and even though I personally share the same ideals and desire
to strive for interoperability across OpenStack clouds, the Neutron team is
generally more open to providing extensibility and integration points. One
of these integration points we currently have is the ML2 interface, which
is considered stable and to be used by third parties.

Bear in mind that we are trying to strike a better balance between wild
wild west and tight control, so my suggestion would be to stay plugged with
the Neutron community to get a sense on how things evolve over time. That
should help avoiding surprises where you end up realizing that something
you relied on was indeed taken away from you.


> What do you think?
>


daada

>
> Thanks
> Bin
>
> -----Original Message-----
> From: Dan Smith [mailto:dms at danplanet.com]
> Sent: Thursday, June 30, 2016 10:30 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] Deprecated Configuration Option in
> Nova Mitaka Release
>
> > Just curious - what is the motivation of removing the plug-ability
> > entirely? Because of significant maintenance effort?
>
> It's not a plugin interface and has never been stable. We've had a
> long-running goal of removing all of these plug points where we don't
> actually expect people to write stable plugins.
>
> If you want to write against an unstable internal-only API and chase every
> little change we make to it, then just patch the code locally.
> Using these plug points is effectively the same thing.
>
> --Dan
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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/20160701/1607711b/attachment.html>