Open Stack

Thank you Matt and Armando for additional background information, and offer to help us. We really appreciate it.

Let me explain our requirement a bit.

We are telco operators, and we are moving toward NFV domain, which is a whole new domain of business and technology. New domain means 2 folds

-          Brand new business opportunities and market segments

-          Brand new technologies that need exploration and experiment, especially in NFV networking.

NFV brings opportunities, which also means new challenges. For example, there are new NFV networking use cases today, such as MPLS and L3VPN. But more importantly, because of the **green field** nature of NFV, we foresee there will be whole new NFV networking use cases (that bring new business) in near future. And the challenge to us is to:

-          Quickly catch the business opportunity

-          Execute it in agile way so that we can accelerate the time-to-market and improve our business agility in offering our customers with those new NFV services.

“Interoperability” is always our favorite term. Being an operator, we know how important the interoperability is. Without interoperability, there is no global mobile network for users to have one device and connect anywhere.

However, in a **green field** of NFV, when the services and technologies is being developed, and every service provider is offering diversified, innovative services and brings to the customers in an agile way, “interoperability” is not a top priority at this moment IMHO. Quick development and deployment, time-to-market and business agility is the key to grow everyone’s business in the **green field**. When NFV services get stabilized at later stage, then we need to emphasize the “interoperability” at that time.

All of the background brings an interesting challenge to Nova and Neutron too – how can we better balance the need of interoperability (i.e. tight control) v.s. the need of penetrating new market opportunity of NFV green field (i.e. wild west)?

That is why we developed Gluon, a model-driven, extensible framework for NFV networking services. This framework aims to:

-          Work with and interoperate with Neutron for any existing networking services that Neutron is supporting today

-          Provides extensibility to support new, unknown NFV networking services in green field in an agile way, i.e. NFV networking on-demand.

Think about early days of Nova networking, everything was exploratory and experimental. It gets matured over time. In a green field of NFV networking, we need exploration and experiment too, because it encourages innovation. When a NFV service gets matured, we focus on its interoperability then.

We are looking forward to working with Nova and Neutron team to consolidate Gluon with Nova and Neutron. The goal is to

-          Make sure current interoperability model of stable APIs and services will keep as is

-          Make sure current networking services and ongoing effort supported by Neutron will keep going as is

-          Allow an extensibility model/framework (Gluon), which can connect with Nova and Neutron too, for us to explore the green field in NFV networking services and business in an agile way, and meet the time-to-market need, because of its **unknown* nature of new, innovative services in NFV green field

-          Whenever NFV networking services and business get stabilized and matured, turn it to interoperability model for those stable APIs and services as we are currently doing

Let me know what you think and we are looking forward to working with you.

Thanks
Bin

From: Armando M. [mailto:armamig at gmail.com]
Sent: Friday, July 01, 2016 3:32 PM
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



On 30 June 2016 at 10:55, HU, BIN <bh526r at att.com<mailto: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<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<mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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/20160702/6b1eea23/attachment.html>