14:01:58 #startmeeting neutron lbaas 14:01:59 Meeting started Thu Feb 20 14:01:58 2014 UTC and is due to finish in 60 minutes. The chair is enikanorov_. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:02 The meeting name has been set to 'neutron_lbaas' 14:02:12 hello 14:02:20 today we're going to finalize what has been discussed recently over ML 14:02:39 great 14:02:44 Yay! 14:02:48 i've just updated the wiki page on the discussion 14:02:50 #link https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion 14:02:58 thanks sbalukoff for cool pictures 14:11:40 so far we agreed to go with model number 3 14:11:41 so I'll start with basic terminology to set things clear 14:11:42 main configuration objects in model #3 that are changed in comparison to existing model are VIP, Pool, Listener 14:11:44 I'm not talking right now about instance/loadbalancer, we'll discuss that later 14:11:44 so one of the concerns that was discussed the most is that we are mixing implementation detail with public API 14:11:54 and impl details are, in particular, a deployment scheme of logical config to a backend 14:11:54 so, VIP in new model #3 is the new root object 14:11:54 so any kind of bindings, and association which users does or doesn't controll are attached to VIP 14:11:54 Listener represent a listening socket on the same address but possibly with different port/protocol 14:11:55 Pool mostly remains the same, however it looses its 'root' role 14:11:55 To describe the essense of the change, let me provide you a workflow example 14:15:30 so tenant wants to create 2 pools and 2 listeners, 1listener will point to 1 pool (default) ,and another lsitener will point to 1st pol as a default and to another pool via l7 rules 14:15:30 the sequence canl be the following: 14:15:30 1) create pool1 14:15:30 2) craete pool2 14:15:30 pools creation doesn't effect in scheduling and backend consumption 14:15:30 3) create VIP 14:15:30 4) create listener 1 for VIP 14:15:30 5) create listener 2 for VIP 14:15:30 6) set pool1 as default pool for listener1 14:15:30 7) set pool1 as default pool for listener2 14:15:30 8) set pool2 as L7 pool for listener2 14:15:30 some of those steps can be combined in one 14:15:30 No problem! 14:15:49 sbalukoff: loadbalancer and cluster are HA related in your proposal, right? 14:15:51 Yes. 14:15:56 sbalukoff: I think HA may be added to the model at any moment and that can be done in a backward compatible way 14:15:58 enikanorov: It might be trivial, but could we have quick recap, of why new object model. 14:15:58 It started with having pools in the same device for L7 config. 14:16:00 Moved to EndPoint IPs / Virtual IPs have to be hosted in same device and the drive was proposed to make IP the focal point for placement. 14:16:00 obondarev: By delegating HA to the driver? 14:16:01 sbalukoff: no 14:16:04 sbalukoff: not necessarily 14:16:04 obondarev: Could you please explain how? Would adding HA require a model change? 14:16:15 sbalukoff: it might require, but that would be backward compatible additions to the model 14:16:16 sbalukoff: so, #3 picture seems enough to me at the moment 14:16:16 sbalukoff: as we can add HA later 14:16:16 what prevents us from adding it to the model now? 14:16:16 sbalukoff: as we can add HA laterI know you have concerns that #3 model doesn't handle HA 14:16:17 how do you maintain backward-compat with #3? 14:16:17 iwamoto_: it can be done 14:16:18 when you attach the pool to a listener, it starts to belong to a backend, and cant be shared by another backend (that's the API limitation we'd like to preserve) 14:16:18 so one of the discussion points was around the ability of sharing pools between VIPs (which may represent different backends) 14:16:18 vjay: right 14:16:18 let's not interleave threads; we can discuss HA later 14:16:18 so, are there questions on object model? 14:16:18 about vip-pool-listener relationships? 14:16:26 network is stormy today 14:16:36 yeah.. wondering if we want to defer 14:16:43 I'm only getting half of the conversation 14:16:47 iwamoto_: mostly the visible API change is around 'provider' attribute 14:16:55 and the eavesdrop logs seem incomplete 14:16:59 markmcclain: you're getting in and out 14:17:36 honestly i'd be glad to defer, because i'm not feeling well. 14:18:04 I'm OK with deferring, eh. People haven't had much time to think of implications of new model anyway. 14:18:09 enikanorov, sorry to hear that you are not doing well 14:18:16 enikanorov: backward-compat API doesn't have listener. how can listener be handled? 14:18:30 enikanorov: sorry you're sick 14:18:31 +1 for deferring 14:18:50 thanks, no prob folks :) 14:18:57 ok, let me find the slot 14:19:10 Feel better, dude! 14:19:29 we can just meeting next week at the scheduled time 14:19:34 s/meeting/meet/ 14:19:44 I'm OK with that. 14:19:59 hm, ok then. it will give more time for everyone to dig through our large poems in ML 14:20:04 take care enikanorov 14:20:07 me too. I need exra time to catch-up. 14:20:28 ok. thanks every one for joining. lets end the meeting 14:20:34 Thanks 14:20:35 bye 14:20:35 enikanorov: hope you get well soon 14:20:46 thanks! 14:20:46 bye 14:20:46 bye 14:20:47 #endmeeting