Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
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:arma...@gmail.com] Sent: Friday, July 01, 2016 3:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release On 30 June 2016 at 10:55, HU, BIN mailto:bh5...@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 m
Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
On 30 June 2016 at 10:55, HU, BIN 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:d...@danplanet.com] > Sent: Thursday, June 30, 2016 10:30 AM > To: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@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-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 > __ 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] [Nova] Deprecated Configuration Option in Nova Mitaka Release
On 06/30/2016 01:55 PM, HU, BIN 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. > > 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. > > What do you think? Neutron is the network API that we've agreed to in OpenStack, and have worked towards for years. Network backends should exist behind the OpenStack Network API (Neutron). If there are challenges in that software stack, then there is an upstream community to engage there to work with to get what you need out of that stack. I'd highly recommend that you do so sooner rather than later on that front. -Sean -- Sean Dague http://dague.net __ 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] [Nova] Deprecated Configuration Option in Nova Mitaka Release
On 6/30/2016 12:55 PM, HU, BIN 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. 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. What do you think? Thanks Bin The nova compute API understands how the nova-network API and neutron APIs work. nova-network is deprecated [1], and we're deprecating the API proxies for network resources out of the nova API [2]. We're also dropping API extensibility [3]. Having plugin implementations for the networking (or image, or volume, or identity) API can break Nova's API which breaks users. For anyone following along with nova development for the last several releases this shouldn't be a surprise. Plug points, hooks, and API extensions that can modify API requests/responses/resources are barriers to interoperability between OpenStack clouds. There is a big long thread [4] that goes into more details about why. But these also present issues for nova development upstream because people report bugs when we break these unversioned, untested, non-contractual interfaces which downstream people are plugging into. So if there is a use case that nova (or neutron) does not today support, we encourage people to not work in a vacuum but get involved with the development effort in the community, attend the summit design sessions, attend the meetups, be in IRC and the development mailing list, etc so that these things can be worked together in the open. [1] https://review.openstack.org/#/c/310539/ [2] http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/deprecate-api-proxies.html [3] http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html [4] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097349.html -- Thanks, Matt Riedemann __ 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] [Nova] Deprecated Configuration Option in Nova Mitaka Release
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. 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. What do you think? Thanks Bin -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Thursday, June 30, 2016 10:30 AM To: OpenStack Development Mailing List (not for usage questions) 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-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] [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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
Dan, Thank you for the information. Just curious - what is the motivation of removing the plug-ability entirely? Because of significant maintenance effort? Thanks Bin -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Thursday, June 30, 2016 9:52 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release > For those deprecated options, does it mean it won't be supported in > Mitaka and future release at all? Or is there a grace period so that > we, as a user, can gradually transition from Liberty to Mitaka? The deprecation period is usually one cycle for something like this. That means people get a chance to clean up their configs before we remove it which would cause an error if it's still in there. > What is the rationale of some deprecated options, for example, > "[DEFAULT]network_api_class". It seems to me that it provides end > users with flexibility in configuring backends. The rationale is that this is not a plugin interface. It's not stable in any way and not something we want to be randomly plug-able by people. The reason it's in there now is historical. We have removed almost all of the other plug points that work like this, and had neglected to remove this one because it is used internally by our nova-network/neutron switching. However, it need not be exposed for that, and the need for it even internally will be going away soon anyway. > So what is the rationale of deprecating this option and is there > equivalent method in Mitika to replace this option? There is not, and there are no plans to add one since we want to remove the plug-ability entirely. --Dan __ 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] [Nova] Deprecated Configuration Option in Nova Mitaka Release
> For those deprecated options, does it mean it won’t be supported in > Mitaka and future release at all? Or is there a grace period so that > we, as a user, can gradually transition from Liberty to Mitaka? The deprecation period is usually one cycle for something like this. That means people get a chance to clean up their configs before we remove it which would cause an error if it's still in there. > What is the rationale of some deprecated options, for example, > “[DEFAULT]network_api_class”. It seems to me that it provides end > users with flexibility in configuring backends. The rationale is that this is not a plugin interface. It's not stable in any way and not something we want to be randomly plug-able by people. The reason it's in there now is historical. We have removed almost all of the other plug points that work like this, and had neglected to remove this one because it is used internally by our nova-network/neutron switching. However, it need not be exposed for that, and the need for it even internally will be going away soon anyway. > So what is the rationale of deprecating this option and is there > equivalent method in Mitika to replace this option? There is not, and there are no plans to add one since we want to remove the plug-ability entirely. --Dan __ 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] [Nova] Deprecated Configuration Option in Nova Mitaka Release
On 30.06.2016 18:35, HU, BIN wrote: > Hello Nova team, > > I am a newbie of Nova. I read your documentation > http://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html > regarding new, updated and deprecated options in Mitaka for Compute. I have > a few questions: > > > - For those deprecated options, does it mean it won't be supported > in Mitaka and future release at all? Or is there a grace period so that we, > as a user, can gradually transition from Liberty to Mitaka? > No, they are still supported in Mitaka but will removed during Newton or have a new name. See [1] for more information. > - What is the rationale of some deprecated options, for example, > "[DEFAULT] network_api_class". It seems to me that it provides end users with > flexibility in configuring backends. So what is the rationale of deprecating > this option and is there equivalent method in Mitika to replace this option? > The rationales are available at [1]. The option you asked for is explained there. > Thank you very much > Bin > > > > > > __ > 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 > References: [1] http://docs.openstack.org/releasenotes/nova/unreleased.html -- Regards, Markus Zoeller (markus_z) __ 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-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release
Hello Nova team, I am a newbie of Nova. I read your documentation http://docs.openstack.org/mitaka/config-reference/tables/conf-changes/nova.html regarding new, updated and deprecated options in Mitaka for Compute. I have a few questions: - For those deprecated options, does it mean it won't be supported in Mitaka and future release at all? Or is there a grace period so that we, as a user, can gradually transition from Liberty to Mitaka? - What is the rationale of some deprecated options, for example, "[DEFAULT] network_api_class". It seems to me that it provides end users with flexibility in configuring backends. So what is the rationale of deprecating this option and is there equivalent method in Mitika to replace this option? Thank you very much Bin __ 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
