[openstack-dev] [neutron][lbaas] Trying to set up LBaaS V2 on Juno with DVR
I have been trying to set up LBaaS v2 in a juno-based environment.
I have successfully done this in devstack by setting it up based on
stable/juno, then grabbing https://review.openstack.org/#/c/123491/ and the
client from https://review.openstack.org/#/c/111475/, and then editing
neutron.conf to include the
neutron.services.loadbalancer.plugin.LoadBalancerPluginv2 service_plugin and
service_provider=LOADBALANCERV2:Haproxy:neutron.services.loadbalancer.drivers.haproxy.synchronous_namespace_driver.HaproxyNSDriver:default.
I have also enabled DVR,
With this setup in devstack, I can use the LBaaS V2 CLI commands to set up a
working V2 loadbalancer.
The problem comes in when I try to do this in an openstack installation. I
have set up a three node installation based on Ubuntu 14.04 following the
procedure in
http://docs.openstack.org/juno/install-guide/install/apt/openstack-install-guide-apt-juno.pdf.
I have a controller node for the API services, a network node, and a compute
node. I can boot instances and create V1 loadbalancers.
When I bring in the LBaaS V2 code into this environment, it is more complex. I
need to add it to the neutron API server on the controller, but also the
compute node (the goal here is to test it with DVR). So on the compute node I
install the neutron-lbaas-agent package, bring in the 123491 patch, and make
the neutron.conf edits. In this configuration, the lbaas agent fails with an
RPC timeout:
2015-01-22 16:10:52.712 14795 ERROR
neutron.services.loadbalancer.agent.agent_manager [-] Unable to retrieve ready
devices
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager Traceback (most recent call
last):
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/neutron/services/loadbalancer/agent/agent_manager.py,
line 148, in sync_state
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager ready_instances =
set(self.plugin_rpc.get_ready_devices())
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/neutron/services/loadbalancer/agent/agent_api.py,
line 38, in get_ready_devices
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager
self.make_msg('get_ready_devices', host=self.host)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/neutron/common/log.py, line 36, in wrapper
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager return method(*args,
**kwargs)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/neutron/common/rpc.py, line 175, in call
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager context, msg,
rpc_method='call', **kwargs)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/neutron/common/rpc.py, line 201, in
__call_rpc_method
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager return func(context,
msg['method'], **msg['args'])
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/client.py, line 389, in
call
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager return
self.prepare().call(ctxt, method, **kwargs)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/client.py, line 152, in
call
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager retry=self.retry)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/oslo/messaging/transport.py, line 90, in
_send
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager timeout=timeout,
retry=retry)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/amqpdriver.py, line
408, in send
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager retry=retry)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
/usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/amqpdriver.py, line
397, in _send
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager result =
self._waiter.wait(msg_id, timeout)
2015-01-22 16:10:52.712 14795 TRACE
neutron.services.loadbalancer.agent.agent_manager File
[openstack-dev] [devstack][lbaas] devstack clean.sh not calling clean for external plugins
I'm working on the external devstack plugin for neutron-lbaas and found that it was leaving behind stale ip network namespaces after running clean.sh. Comparing to unstack.sh, which calls run_phase unstack I saw that clean.sh was not calling run_phase clean, and thus my cleanup code wasn't running. I just submitted https://review.openstack.org/157856 that adds this to clean.sh. Please have a look. Thanks, Al __ 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] [devstack][octavia] Loading one devstack plugin from another devstack plugin.
Hi Devstack people, I have developed two devstack plugins (for neutron-lbaas and octavia), and I think I am stretching the capabilities of the devstack plugin architecture. Neutron-lbaas is the load balancer framework for OpenStack. By default it uses a fairly simple haproxy-based agent to actually perform its load balancing tasks. It has a devstack plugin that works well, all I need to do is add the appropriate enable_plugin and enable_service lines to my local.conf and the plugin code sets up everything nicely. So far so good. Octavia is a reference implementation (currently in stackforge) that will plug in to neutron-lbaas and provide scalable, HA-capable load balancing agents above and beyond the default implementation. I have also written a devstack plugin for Octavia, and it also works reasonably well (I still need to finish up a few loose ends in it). That plugin works well too, by adding the appropriate enable_plugin and enable_service entries to local.conf. So adding this: enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_plugin octavia https://git.openstack.org/stackforge/octavia enable_service q-lbaasv2 enable_service octavia enable_service o-cw enable_service o-hk enable_service o-hw to my local.conf results in a working lbaasv2/Octavia devstack. Now what I would like to do is automate as much of this Octavia-specific information as possible in neutron-lbaas. In principle, if I could specify enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_service q-lbaasv2 enable_service octavia All there remaining knowledge could be written into neutron-lbaas/devstack. So I tried this, and added code to the neutron-lbaas plugin.sh that enabled the Octavia plugin and services. I have tried running enable_plugin octavia from various points in the neutron_lbaas/devstack/plugin.sh, but it appears that by the time we begin loading plugins it is too late to be doing this. Does this seem like something that could be made to work, or does it sound too fragile, dangerous, etc? I would appreciate any comments. Thanks, Al __ 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] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team
I really appreciate the opportunity to participate as a core reviewer and would like to thank everyone who has helped me come up to speed on OpenStack and LBaaS. Al From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Monday, July 06, 2015 9:22 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team Since all cores have responded, I’m going to end this early. Welcome to the core team, Al. Thanks, doug On Jul 5, 2015, at 6:27 PM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: +1 for Al! On Thu, Jul 2, 2015 at 5:16 PM, Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com wrote: Hi all, As the Lieutenant of the advanced services, I would like to nominate Al Miller to be a member of the neutron-lbaas core reviewer team. Review stats are in line with other cores[2] and feedback on patches has been great. Additionally, he has been instrumental in our devstack support and octavia work. Existing cores, please vote +1/-1 for his addition to the team (that’s Brandon, Phil, and Kyle.) Thanks, doug 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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.orgmailto: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] [Neutron]How to configure lbaas api v2 on devstack?
The quick answer is “enable_service q-lbaasv2”. A longer answer is that the neutron-lbaas repository contains sample local.con and local.sh files that set up a working loadbalancer devstack setup using LBaaS V2. They are in neutron-lbaas/devstack/samples. Putting those files, along with webserver.sh into your devstack directory and running stack.sh will set up a V2 loadbalancer with two member instances. More details are at https://chapter60.wordpress.com/2015/04/14/sample-scripts-to-automatically-set-up-lbaas-v2-loadbalancers-in-devstack/ Al On Jul 18, 2015, at 5:13 PM, 姚威 wilence@gmail.commailto:wilence@gmail.com wrote: Hi all, To enable lbaas on devstack with haproxy, I added `enabled_service q-lbaas` in devstack/loacl.conf. ButI find that lbaas api is v1, which means I could use `neutron lb-xxx` instead of `neutron lbaas-xxx`. If I want to use api v2, what should I do with devstack/local.conf? Wilence Yao __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [Neutron]How to configure lbaas api v2 on devstack?
The quick answer is “enable_service q-lbaasv2”. A longer answer is that the neutron-lbaas repository contains sample local.con and local.sh files that set up a working loadbalancer devstack setup using LBaaS V2. They are in neutron-lbaas/devstack/samples. Putting those files, along with webserver.sh into your devstack directory and running stack.sh will set up a V2 loadbalancer with two member instances. More details are at https://chapter60.wordpress.com/2015/04/14/sample-scripts-to-automatically-set-up-lbaas-v2-loadbalancers-in-devstack/ Al On Jul 18, 2015, at 5:13 PM, 姚威 wilence@gmail.commailto:wilence@gmail.com wrote: Hi all, To enable lbaas on devstack with haproxy, I added `enabled_service q-lbaas` in devstack/loacl.conf. ButI find that lbaas api is v1, which means I could use `neutron lb-xxx` instead of `neutron lbaas-xxx`. If I want to use api v2, what should I do with devstack/local.conf? Wilence Yao __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [neutron][vpnaas] VPNaaS project status
Paul, I echo the prior comments. Your hard work and persistence in getting the recent new features written, as well as your review suggestions are very much appreciated! Thanks, Al From: Paul Michali [mailto:p...@michali.net] Sent: Thursday, November 12, 2015 8:56 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron][vpnaas] VPNaaS project status Neutron community, During the past several releases, while leading the VPNaaS project, I've seen many great enhancements and features added to the VPNaaS project by the community, including support for StrongSwan, Libreswan, completion of the project split out, functional and rally tests, endpoint groups, multiple local subnets, vendor drivers, etc. There is still work needed (certificate support the most important, followed by documentation and scale testing), but there is a solid (in my bias and subjective opinion :) foundation in place for people to play with this capability. As I mentioned to Armando at the summit, it's time for me to move on to other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping up work on the project over the next few weeks. I'll still try to review VPNaaS commits as much as possible, and be available to advise in this area. Towards that end, I've updated the VPNaaS wiki page (https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are outstanding work that can be done in this area, from important to wish items. Meetings have transitioned to on-demand, and future meetings can either be done as an on-demand topic in the Neutron IRC meeting, or as an on-demand special meeting. I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my opinion of importance, priority, relevance, etc. Regards, PCM (pc_m) __ 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] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team
+1 Al > -Original Message- > From: Doug Wiegley [mailto:doug...@parksidesoftware.com] > Sent: Wednesday, September 16, 2015 3:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for > neutron-lbaas core team > > Hi all, > > As the Lieutenant of the advanced services, I nominate Michael Johnson to > be a member of the neutron-lbaas core reviewer team. > > Review stats are in line with other cores[2], and Michael has been > instrumental in both neutron-lbaas and octavia. > > Existing cores, please vote +1/-1 for his addition to the team (that’s > Brandon, > Phil, Al, and Kyle.) > > Thanks, > doug > > 1. http://docs.openstack.org/developer/neutron/policies/core- > reviewers.html#core-review-hierarchy > 2. http://stackalytics.com/report/contribution/neutron-lbaas/90 > > > __ > > 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
