Hi, Ok, so you just need a noop driver, which you can find in the review link I posted a few emails back.
Thanks, doug > On Jun 2, 2015, at 6:23 PM, Wanjing Xu <wanjing...@hotmail.com> wrote: > > Doug > > Our current event consumer is listening to the queue with the topic specified > in neutron.conf as notification_topics = xxxxx. neutron will generate all > create/update/delete events(from api) to this queue including vip/member/pool > events. So we don't need to write a driver to generate the events. Neutron > base api has taken care of it. > > Regards! > > Wanjing > > From: doug...@parksidesoftware.com > Date: Tue, 2 Jun 2015 16:57:12 -0600 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron][LBaaS] No LBaaS agent? > > Hi, > > If you have an existing event consumer that you want to stick with, you could > write a driver that just generates events. There are some error status warts > that you’d either have to live with or handle, but you could do that later. > > Thanks, > doug > > On Jun 2, 2015, at 1:05 PM, Wanjing Xu <wanjing...@hotmail.com > <mailto:wanjing...@hotmail.com>> wrote: > > Thanks everybody. While I am trying to digest all the responses, I am here > to reply why we are not considering a driver. We already have an application > which listens to neutron events to do some other stuff, it might just be > easier for us if we reuse this framework and program the LBaasS from there. > If we use driver, there is this added efforts where we need to ask the user > to install our driver, modify the conf file, start the agent and restart > neutron. We might still go back to driver/agent later because it seemed > that it helps scale better. > > Thanks Doug, Kevin, Brandon and Kunal! You guys are so helpful. Will have > more questions later.... > > Wanjing > > From: doug...@parksidesoftware.com <mailto:doug...@parksidesoftware.com> > Date: Mon, 1 Jun 2015 18:04:02 -0600 > To: openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] No LBaaS agent? > > The reference implemenation for lbaas (using haproxy with namespaces) > requires the agent. There are vendor implementations that are agent-less, but > not the reference. > > There is a non-agent ref driver for lbaas v2, but there is no horizon support > for v2, and that driver is unsupported beyond dev use. > > If I may ask, why do you not want to run the agent? > > Thanks, > doug > > > On Jun 1, 2015, at 5:52 PM, Wanjing Xu <wanjing...@hotmail.com > <mailto:wanjing...@hotmail.com>> wrote: > > Is there a way to add an LBaaS service without having to use neutron > plugin/agent framework? > > I want to add a LBaaS service without an LBaaS agent running and still want > to have lb cli and horizon. When the user configure loadbalance via cli or > horizon, neutron will send the events(pool, member, vip create/delete > event)in the notification info queue and our application will listen to the > queue and program the LBaaS box. So far, I have tried to enable the > built-in HAProxy LBaaS(enable the service_plugin to be LoadBalancerPlugin and > service provider to be haproxy). By doing that , horizon and cli are all > enabled and our application can successfully program LBaaS box using the > notification events. The problem with that is that there is a haproxy agent > running in the background although we are not using its function. But if I > don't enable the agent, we can not use horizon. Currently we don't want to > write a LBaaS agent of our own. Is there a way to not to use LBaaS agent and > still be able to use horizon/cli to configure loadbalance? During openstack > summit at vancouver, I saw paypal loadbalance presentation, they use two > providers, one is agent , the other is agentless controller, not sure how > that controller works, could not find it through googling. > > Regards > Wanjing Xu > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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 > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <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
__________________________________________________________________________ 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
