Open Stack

Hi Saverio,

First, please note, in the future the best tag for load balancing is
[octavia] as it is no longer part of the neutron project.

I am sorry that you are so anxious and confused about the current state of
load balancing for OpenStack.  Let me clarify a few things:

1. LBaaSv2 is not going away and is not deprecated.  The neutron-lbaas code
base is going into deprecation in favor of the octavia code base.  I will
highlight two things, among others, we are doing to ease this transition for
operators:
a. For some time into the future you will be able to continue to use LBaaSv2
via neutron using the proxy driver in neutron-lbaas.
b. There will be migration procedures and scripts that will move, in place,
load balancers from neutron-lbaas into octavia.
2. Deprecation means we will not continue to develop features for
neutron-lbaas, but it will remain in the code base for at least two more
releases and continue to receive bug fixes.  It's a formal way of saying,
hey, in the future we are going to remove this.
3. New features will be added to the octavia code base.  It is only
neutron-lbaas that will be going into feature freeze for new feature
development due to the transition.
4. Any tools written against the neutron endpoint for neutron-lbaas using
the LBaaSv2 API will work with Octavia by updating the endpoint you are
pointing to from neutron to octavia.
5. We are not making any changes to stable/liberty, stable/mitaka,
stable/newton, or stable/ocata releases.  I will note, per OpenStack stable
release policy, liberty is EOL and mitaka will be next month and we are not
allowed to add new features to any previous releases.   Please see the
OpenStack stable policy here:
https://docs.openstack.org/project-team-guide/stable-branches.html
6. Octavia was available and, in fact, the reference load balancing driver
in Liberty.
7. Multiple operators are represented on the core review team for octavia.
We try really hard to listen to feedback we get and to do what is best for
folks using load balancing in OpenStack.  It is unfortunate our
presentations at the Barcelona summit were denied and we did not get an
opportunity to share our plan with the community and get feedback.  If you
have concerns I encourage you to reach out to us via our weekly IRC
meetings, our channel on IRC #openstack-lbaas, or via the mailing list with
the [octavia] tag.  As you know, I have been responding to your emails with
load balancing questions.

To answer Zhi's e-mail:

This is correct, if you are using the legacy haproxy namespace driver, and
not the octavia driver, there is currently no easy method to migrate the
ownership of a load balancer from one agent to another.
The legacy haproxy namespace driver is/was not intended for high
availability.  If you want a highly available open source load balancing
option, I highly recommend you use the octavia driver instead of the haproxy
namespace driver.  It was designed to provide scale and availability.  You
would not have the issue you are describing with the octavia driver.

That said, if you want to continue to develop new features for the haproxy
namespace driver, we should start planning to do so in the octavia code
base.
We will be starting work on a port of the haproxy namespace driver into
octavia soon.  We are however discussing what the future should be for this
driver given its limitations.  I think the best plan will be to port it over
into a standalone driver that folks can contribute to if they have a need
for it and we can deprecate it if there is no longer support for it.

Michael


-----Original Message-----
From: Saverio Proto [mailto:saverio.proto at switch.ch] 
Sent: Friday, March 17, 2017 4:55 AM
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][lbaasv2] Migrate LBaaS instance

Hello there,

I am just back from the Ops Midcycle where Heidi Joy Tretheway reported some
data from the user survey.

So if we look at deployments with more than 100 servers NO ONE IS USING
NEWTON yet. And I scream this loud. Everyone is still in Liberty or Mitaka.

I am just struggling to upgrade to LBaaSv2 to hear that is already going
into deprecation. The feature Zhi is proposing is important also for me once
I go to production.

I would encourage devs to listen more to operators feedback. Also you devs
cant just ignore that users are running still Liberty/Mitaka so you need to
change something in this way of working or all the users will run away.

thank you

Saverio


On 16/03/17 16:26, Kosnik, Lubosz wrote:
> Hello Zhi,
> Just one small information. Yesterday on Octavia weekly meeting we 
> decided that we're gonna add new features to LBaaSv2 till Pike-1 so 
> the windows is very small.
> This decision was made as LBaaSv2 is currently Octavia delivery, not 
> Neutron anymore and this project is going into deprecations stage.
> 
> Cheers,
> Lubosz
> 
>> On Mar 16, 2017, at 5:39 AM, zhi <changzhi1990 at gmail.com 
>> <mailto:changzhi1990 at gmail.com>> wrote:
>>
>> Hi, all
>> Currently, LBaaS v2 doesn't support migration. Just like router 
>> instances, we can remove a router instance from one L3 agent and add 
>> it to another L3 agent.
>>
>> So, there is a single point failure in LBaaS agent. As far as I know, 
>> LBaaS supports " allow_automatic_lbaas_agent_failover ". But in many 
>> cases, we want to migrate LBaaS instances manually. Do we plan to do
this?
>>
>> I'm doing this right now. But I meet a question. I define a function 
>> in agent_scheduler.py like this:
>>
>>     def remove_loadbalancer_from_lbaas_agent(self, context, agent_id,
>> loadbalancer_id):
>>         self._unschedule_loadbalancer(context, loadbalancer_id, 
>> agent_id)
>>
>> The question is, how do I notify LBaaS agent? 
>>
>> Hope for your reply.
>>
>>
>>
>> Thanks
>> Zhi Chang
>> _____________________________________________________________________
>> _____ OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscrib
>> e 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
> 


--
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15,
direct +41 44 268 1573 saverio.proto at switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__________________________________________________________________________
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