14:00:30 <enikanorov> #startmeeting neutron-lbaas
14:00:31 <openstack> Meeting started Thu Nov 14 14:00:30 2013 UTC and is due to finish in 60 minutes.  The chair is enikanorov. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:33 <obondarev> hi
14:00:35 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:54 <enikanorov> hi, who;s around?
14:01:13 <obondarev> o/
14:01:34 <iwamoto> me too
14:02:04 <ilyashakhat> enikanorov: what's the agenda?
14:02:11 <enikanorov> ok, not too many of us
14:02:31 <enikanorov> the agenda for the meeting is
14:02:42 <enikanorov> 1. BPs to be proposed for I-1
14:02:57 <enikanorov> 2. QA and 3rd party testing
14:03:05 <enikanorov> 3. Dev resources evaluation
14:03:22 <enikanorov> 4. Additiona lbaasl features to consider in Icehouse
14:03:41 <enikanorov> #topic Blueprints to be proposed for Icehouse-1
14:04:11 <enikanorov> we've got big plans for Icehouse in terms of features
14:04:24 <enikanorov> even more in terms of blueprints
14:04:36 <enikanorov> and even more in terms of expected patchsets
14:05:29 <enikanorov> however currently we experience problems with neutron gating
14:05:39 <enikanorov> lots of patches baing stuck
14:05:50 <obondarev> is there anything already proposed for I1?
14:05:58 <obondarev> I mean blueprints
14:06:04 <avishayb> hi - i just joined
14:06:13 <enikanorov> yeah, from my side it would be:
14:06:24 <enikanorov> #link https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance
14:06:32 <enikanorov> #link https://blueprints.launchpad.net/neutron/+spec/lbaas-extensions
14:06:59 <obondarev> do you plan this for I1?
14:07:07 <obondarev> ore for I2 maybe?
14:07:19 <enikanorov> I plan that implementation will be ready in I-1
14:07:24 <avishayb> from radware side: SSL + L7
14:07:27 <enikanorov> however since we only have 3 weeks left in I-1
14:07:39 <obondarev> yeah
14:07:40 <iwamoto> #link https://blueprints.launchpad.net/neutron/+spec/lbaas-support-routed-service-insertion
14:07:47 <enikanorov> i doubt that everything will land
14:07:57 <enikanorov> regarding SSL and L7
14:08:02 <avishayb> lots on the plate .. :-)
14:08:05 <enikanorov> these are two different features
14:08:14 <obondarev> avishayb: can you provide links?
14:08:18 <enikanorov> so their bp are separate
14:08:42 <avishayb> let me try and do that.. sam created the BP's - i will find it
14:09:11 <enikanorov> i think those are here: https://etherpad.openstack.org/p/icehouse-neutron-lbaas
14:09:50 <obondarev> from my side I have registered l7 rules for haproxy
14:09:52 <enikanorov> so while I'd encourage you to work on SSL or L7, both features have dependency on some others
14:09:54 <Vijay_> Hi Avishay, Eugene; Vijay from Citrix. We would also be able to contribute to SSL + L7
14:09:55 <obondarev> #link https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules-haproxy
14:10:18 <obondarev> it depends on generic L7 rules blueprint
14:10:26 <enikanorov> ok, let me explain the dependencies
14:10:26 <Vijay_> https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination
14:10:28 <avishayb> https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules
14:10:49 <Vijay_> is the SSL termination blue print
14:10:52 <enikanorov> L7 feature depends on multiple pools per vip, which has to be implemented first
14:11:01 <obondarev> yeah
14:11:06 <Vijay_> yeah
14:11:12 <enikanorov> so in order to go in parallel, we may start with API changes
14:11:31 <obondarev> it wasn't listed by the way
14:11:42 <enikanorov> which one?
14:11:54 <obondarev> multiple vips per pool
14:12:01 <obondarev> I mean the link
14:12:05 <enikanorov> i will not propose it for I-1
14:12:14 <obondarev> oh, ok
14:12:20 <enikanorov> it's more complex than service instance
14:12:32 <enikanorov> and it's design is not yet agreed on
14:12:50 <obondarev> yeah, but with many dependencies - isn't it better to implement it first of all?
14:13:02 <ilyashakhat> but service instance will also require lots of changes from db to client
14:13:09 <ilyashakhat> isn't it?
14:13:10 <Vijay_> The basis for all this is the loadbalancer container object implementation, right?
14:13:26 <enikanorov> multiple pools/vips depend on 'loadbalancer instance' that's why it goes first
14:13:33 <enikanorov> Vijay_: correct
14:13:37 <obondarev> oh, got it, right
14:13:57 <enikanorov> So, again, we could propose everything for I-1
14:14:07 <enikanorov> but realistically, it's only 3 weeks left
14:14:14 <enikanorov> and we have all those gating problems
14:14:25 <enikanorov> and hundreds of patches on review
14:14:41 <enikanorov> so it's better for us to work on code without pushing core team too much
14:14:49 <ilyashakhat> enikanorov: let's start with loadbalancing instance, l7 staff depends on it
14:14:50 <enikanorov> but ahving our code ready and covered by tests
14:14:56 <enikanorov> *having
14:15:07 <enikanorov> also, important note:
14:15:27 <enikanorov> #action everyone proposing BP for the sprint needs to have wiki page with design description
14:16:05 <Vijay_> ok
14:16:29 <enikanorov> Vijay_: avishayb: please keep in touch with each other and colalborate on ssl feature
14:16:48 <enikanorov> ssl will depend on extension framework, but it's minor dependency, i'd say
14:17:20 <enikanorov> any questions/announcements on Icehouse-1 plans?
14:17:29 <avishayb> OK
14:17:47 <Vijay_> sure we will co-ordinate between ourselves.
14:18:12 <Vijay_> Citrix's NetScaler , Driver can be sent for review next week.
14:18:13 <iwamoto> l7 could be implemented without service instances ithink
14:18:20 <s3wong> Is there any particular areas/implementations of these bps that need help on?
14:18:21 <enikanorov> I'll appreciate if  you also will keep us in the loop :)
14:18:34 <iwamoto> just to make later changes easier?
14:18:46 <enikanorov> s3wong: that will be the next topic :)
14:19:07 <enikanorov> iwamoto: l7 depends on multiple pools per vip which depends on serviec instance
14:19:10 <s3wong> enikanorov: Cool :-)
14:19:20 <enikanorov> #topic QA & third-party testing
14:19:22 <avishayb> question: whay ssl has dependency on extension framework? I thought this it is not related to extension.
14:19:34 <avishayb> *why
14:19:45 <enikanorov> avishayb: that's the decision from the design session
14:20:01 <enikanorov> so, going back to QA
14:20:06 <avishayb> ok.. I wans not aware.
14:20:27 <enikanorov> obondarev started to work on adding scenario tests to tempest for lbaas
14:20:37 <enikanorov> obondarev: do you want do update us with your progress?
14:20:52 <obondarev> well, work in progress:)
14:21:02 <obondarev> want to implement basic lbaas workflow
14:21:11 <enikanorov> good to know :)
14:21:21 <obondarev> and validate loadbalancing is happening actually
14:21:37 <obondarev> IOW automate this test: https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun#Validation
14:21:50 <enikanorov> ok, cool
14:22:19 <enikanorov> avishayb: do you guys start working on setting up smoke test system in your environment?
14:22:40 <enikanorov> #link http://ci.openstack.org/third_party.html
14:22:46 <avishayb> no - not yet
14:23:07 <s3wong> obondarev: there is a periodic task pulling stats, right? Should that be exposed to verify LBaaS instance is working and doing something?
14:23:18 <enikanorov> it's expected at I-2, which is actually just 2 months away
14:23:42 <enikanorov> obondarev: btw, don't forget that test should not be haproxy-specific
14:23:50 <sgran> sorry I'm a bit late, I'm running between rooms at a conference.  I'd have a few things on my mind if there is time.  I see there is already a pretty full agenda, so please get to me last :)
14:23:53 <enikanorov> since we are going to run the same tests for all vendors
14:23:54 <obondarev> s3wong: not sure
14:24:09 <obondarev> enikanorov: yeah
14:24:14 <enikanorov> sgran: i guess we will have time for the open discussion
14:24:21 <sgran> great, thanks
14:25:19 <Vijay_> obondarev: will the tests check the data path by sending traffic to the the VIP ?
14:26:06 <enikanorov> it should
14:26:09 <obondarev> Vijay_:yes, as it described on the wiki
14:26:53 <enikanorov> ok, i suggest we count our heads and see who's doing what
14:27:06 <enikanorov> #topic dev resources evaluation
14:27:15 <enikanorov> i'll start with myself
14:27:30 <enikanorov> as i said, i'm going to work on service instance and extension framework
14:27:48 <enikanorov> obondarev: ?
14:28:06 <obondarev> I need to wait untill can start working on lbaas-l7-rules, now working on the tests
14:28:18 <obondarev> can help with any bp for I1
14:28:29 <enikanorov> ok, good to know
14:28:32 <enikanorov> avishayb: ?
14:28:39 <Vijay_> eugene, just for my own clarity; service instance is the loadbalancer container/wrapper instance right?
14:28:50 <enikanorov> Vijay_: correct
14:29:08 <avishayb> we are two people working on the SSL and L7 blueprints
14:29:31 <s3wong> I can help with any bp for l1 as well
14:29:51 <enikanorov> avishayb: who is the other one?
14:30:05 <avishayb> Evgeny Fedoruk
14:30:11 <enikanorov> i see, good
14:30:29 <Vijay_> from my side, i will work with avishayb to cleanup the blueprint on SSL & L7 BluePrints and design doc
14:30:37 <enikanorov> Vijay_: cool
14:30:47 <enikanorov> s3wong: sgran: you guys?
14:31:07 <sgran> hi
14:31:24 <sgran> I'm writing a plugin for the neutron LBaaS, to manage stingray loadbalancer
14:31:27 <enikanorov> s3wong: I'll see if I could share something to help me with
14:31:44 <s3wong> enikanorov: please let me know where I can lend my hand
14:31:47 <enikanorov> sgran: i guessed that! :)
14:32:02 <sgran> http://www.riverbed.com/products-solutions/products/application-delivery-stingray/Stingray-Traffic-Manager.html
14:32:05 <sgran> :)
14:32:14 <enikanorov> so then one of the tasks will be to keep your code in sync
14:32:26 <enikanorov> with the master
14:32:29 <sgran> I'm watching https://review.openstack.org/#/c/40381/ with interest, so that I know what to sync
14:32:35 <enikanorov> good
14:33:16 <sgran> my concern at the moment (I left a note at the bottom of that review) is that the in-memory cache in the agent_manager looks to me like it will make it difficult to have multiple agents for HA
14:33:18 <enikanorov> sgran: you are also required to setup test environment for your driver, you know
14:33:36 <enikanorov> sgran: yeah, let's discuss it at the end of the meeting
14:33:36 <sgran> you mean make a test environment available?
14:33:45 <obondarev> sgran: yeah, working on that comment..
14:33:48 <sgran> I have a test environment at work that I'm using to test my code
14:33:56 <enikanorov> sgran: right, implement http://ci.openstack.org/third_party.html
14:34:29 <enikanorov> should be fairly simple if you pass your company's security hounds :)
14:34:55 <sgran> I doubt that that will be possible, but I have contacts at riverbed.  I'll see what they can do for us
14:35:37 <sgran> I don't actually work for riverbed, so this would mean my company would be paying licensing costs to bring one up to run gate tests on
14:35:44 <sgran> I don't think they'll like that :)
14:36:24 <enikanorov> i see
14:36:25 <sgran> but yeah, looks straight forward enough
14:36:33 <sgran> maybe I can do it with a dev licensed model
14:36:40 <sgran> I'll ask riverbed, and ask what we can do
14:37:09 <enikanorov> isn't riverbed insterested in adding support for their solution to neutron?
14:37:39 <sgran> they are, yeah, but they seem to be moving slowly, which is why I'm ending up writing it :)
14:37:48 <enikanorov> i see
14:38:10 <sgran> as I say, I'll talk to them.  They have some people at this conference, so I may be able to get a fast answer
14:38:19 <enikanorov> ok, i think we can move to the next topic
14:38:30 <enikanorov> #topic Additional features requested by users.
14:38:54 <enikanorov> those are the features that we missed in the design session and in our vendor discussions
14:39:06 <enikanorov> but folks raised them at the lbaas presentation
14:39:27 <enikanorov> one is to add HA for at least HAProxy provider
14:39:45 <enikanorov> that is one of the most expected feature
14:39:57 <obondarev> can you please clarify?
14:40:08 <enikanorov> high availability
14:40:12 <obondarev> yeah)
14:40:28 <sgran> haproxy driver is a SPoF - you lose the host, you lose the LB
14:40:32 <enikanorov> users want haproxy to be highly available, which means that you have more then one balanecer
14:40:34 <obondarev> currently we can run multiple agents
14:40:40 <enikanorov> if one fails another one picks up the traffic
14:40:48 <sgran> but each vip/lb/pool is only on one host
14:41:00 <sgran> this touches on my concern about the in-memory cache in the agent_manager
14:41:01 <obondarev> sgran: right
14:41:02 <s3wong> enikanorov: Is that just having the ability to bind frontend VIP to two haproxy instances? or do people expect things like sticky entries to be in sync between the two haproxy instances?
14:41:10 <enikanorov> sgran: there are secveral approaches to this
14:41:23 <enikanorov> since currently HAProxy VIP is on tenant network
14:41:43 <enikanorov> HA could be done with switching Floating IP from failed haproxy VIP to active one
14:41:55 <enikanorov> but that's kinda external monitoring
14:42:11 <enikanorov> I'd like to see generic HA design for lbaas
14:42:19 <sgran> you don't want to use a floating IP, do you?  You'd want another adress on the same port
14:42:20 <enikanorov> that could be implemented withing the service
14:42:34 <enikanorov> sgran: i'm not saying that
14:42:48 <enikanorov> i'm saying that solution for HAProxy will be HAProxy-specific
14:43:08 <enikanorov> and it looks like a 'foreign' system to neutron (at first glance)
14:43:12 <enikanorov> anyway
14:43:17 <sgran> enikanorov: so I think that there are two parts here: whether there are any design decisions that make it hard to have HA LBaaS agents
14:43:26 <sgran> and then how to make the implementation itself HA
14:43:28 <enikanorov> if someone is willing to design and implement this feature - you're welcome!
14:43:32 <s3wong> enikanorov: agree, the LBaaS HA framework should allow driver to specify how they want to sync dynamic states
14:44:03 <obondarev> o/
14:44:10 <enikanorov> sgran: i think it's more about HA balancers than agents
14:44:13 <obondarev> want to work on this
14:44:28 <enikanorov> because we already may have several lbaas agents
14:44:41 <enikanorov> and if some agent fail, neutron-server is notified about it
14:44:41 <sgran> not really
14:44:54 <sgran> we can have multiple agents managing different sets of LB/pool/VIP
14:44:58 <sgran> not managing the same set
14:45:03 <s3wong> enikanorov: what is the monitoring framework to detect LBaaS instance failure?
14:45:05 <enikanorov> sgran: correct
14:45:05 <obondarev> can think of HA for agents in terms of handling one lbaas instance by multiple agents
14:45:15 <enikanorov> s3wong: there is none
14:45:28 <obondarev> as a first step at least
14:45:29 * sgran nods obondarev
14:45:35 <sgran> that is exactly what I'm thinking of
14:45:36 <enikanorov> ok, it seems that HA agents is a separate topic
14:45:50 <sgran> the implementation I'm working on configures the appliance via a rest api
14:46:04 <sgran> so in theory, any agent could pick up the update and configure the appliance
14:46:19 <sgran> it doesn't need a cache of running processes or anything
14:46:45 <obondarev> sgran: yeah, that what your comment was all about)
14:47:02 <enikanorov> sgran: right, for such case it's a bit easier
14:47:21 <enikanorov> but still, HA is for balancers themselves, agents is different topic
14:47:21 <sgran> that's it exactly - I'm trying to make sure that we don't accidentally design the higher level classes in such a way that it makes the implementation classess harder
14:47:22 <enikanorov> IMO
14:47:35 <sgran> fair enough, splitting the topic makes sense
14:48:46 <obondarev> agree
14:48:48 <enikanorov> ok, so would be good if someone could pick this up.
14:48:56 <enikanorov> this is really expected
14:49:04 <obondarev> I'm ready
14:49:17 <s3wong> I can help here also
14:49:24 <enikanorov> ok, good
14:49:30 <obondarev> I'll register a bp for this
14:49:32 <sgran> I am happy to be part of it.  I've started an etherpad with a braindump
14:49:38 <sgran> great, thanks
14:49:42 <enikanorov> cool
14:49:59 <enikanorov> any other items?
14:50:06 <enikanorov> #topic Open discussion
14:52:11 <iwamoto> is anyone planning router type loadbalancers (i.e. LVS-like)?
14:52:24 <iwamoto> I wonder if I'm alone
14:53:02 <enikanorov> it's up to vendors
14:53:30 <Vijay_> Are there enhancements planned on the Horizon side for LBaaS? Currently it restricts to configure VIPs only in Pool Networks.
14:53:31 <enikanorov> i think driver framework and extension framework should allow you to do any wiring you want
14:53:57 <enikanorov> Vijay_: it could be filed as a bug, because it's really should not be so
14:54:22 <sgran> there's no such restriction in neutron, so yeah, that's a horizon bug
14:54:47 <enikanorov> that was implementation hardcoded to available provider (at grizzly point)
14:54:54 <enikanorov> now it should be changed
14:55:13 <sgran> time for me to run to another room
14:55:34 <sgran> obondarev: if you can leave a note with your thoughts on that change, I'm happy to help
14:55:36 <obondarev> enikanorov: can add an action iten on it
14:55:42 <sgran> thanks for your time, everyone
14:55:52 <Vijay_> can the same driver be loaded as two providers?
14:56:06 <enikanorov> #action file a bug for horizon project to change restriction for the VIP subnet
14:56:09 <sgran> for differnt load balancers?  Yes
14:56:10 <Vijay_> sure
14:56:22 <enikanorov> Vijay_: not at this point
14:56:31 <enikanorov> Vijay_: why are you asking?
14:57:07 <Vijay_> we have management layer between which sends the calls to the ultimate device.
14:57:26 <Vijay_> would like to ideally give choices to user
14:57:31 <Vijay_> to pick providers
14:57:54 <enikanorov> how those providers differ one from another?
14:57:56 <Vijay_> and accordingly configure the VIP/Pools in a device which is according to the provider selection
14:58:56 <Vijay_> currently we are subclassing the plugin driver and created 2 drivers.
14:59:16 <Vijay_> because provider and driver are one to one mapping
14:59:34 <enikanorov> yeah, so what will be the difference between providers utilizing the same driver?
14:59:41 <enikanorov> we have 1 minute left
14:59:51 <enikanorov> we can continue on #neutron-lbaas
15:00:02 <Vijay_> ok
15:00:02 <enikanorov> let's go there
15:00:06 <enikanorov> #endmeeting