| *** mestery has joined #openstack-lbaas | 01:28 | |
| *** fnaval has quit IRC | 01:59 | |
| *** ptoohill_ has joined #openstack-lbaas | 02:02 | |
| *** fnaval has joined #openstack-lbaas | 02:04 | |
| *** HenryG has joined #openstack-lbaas | 02:21 | |
| *** vivek-ebay has joined #openstack-lbaas | 02:50 | |
| *** vivek-ebay has quit IRC | 03:39 | |
| *** fnaval has quit IRC | 05:04 | |
| *** blogan is now known as zz_blogan | 05:41 | |
| *** ptoohill has quit IRC | 06:27 | |
| *** ptoohill has joined #openstack-lbaas | 06:27 | |
| *** samuelbercovici has joined #openstack-lbaas | 06:33 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 06:43 | |
| *** samuelbercovici has quit IRC | 06:46 | |
| *** samuelbercovici1 is now known as samuelbercovici | 06:46 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 06:49 | |
| *** samuelbercovici has quit IRC | 06:53 | |
| *** samuelbercovici1 is now known as samuelbercovici | 06:53 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 06:58 | |
| *** samuelbercovici has quit IRC | 07:01 | |
| *** samuelbercovici1 is now known as samuelbercovici | 07:01 | |
| *** ptoohill_ has quit IRC | 07:16 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 07:29 | |
| *** samuelbercovici has quit IRC | 07:32 | |
| *** samuelbercovici1 is now known as samuelbercovici | 07:32 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 07:34 | |
| *** samuelbercovici has quit IRC | 07:37 | |
| *** samuelbercovici1 is now known as samuelbercovici | 07:37 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 07:41 | |
| *** samuelbercovici has quit IRC | 07:44 | |
| *** samuelbercovici1 is now known as samuelbercovici | 07:44 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 07:47 | |
| *** samuelbercovici has quit IRC | 07:50 | |
| *** samuelbercovici1 is now known as samuelbercovici | 07:50 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 07:57 | |
| *** samuelbercovici has quit IRC | 08:01 | |
| *** samuelbercovici1 is now known as samuelbercovici | 08:01 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 08:18 | |
| *** samuelbercovici has quit IRC | 08:21 | |
| *** samuelbercovici1 is now known as samuelbercovici | 08:21 | |
| *** ptoohill_ has joined #openstack-lbaas | 08:25 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 08:43 | |
| *** ptoohill_ has quit IRC | 08:45 | |
| *** samuelbercovici has quit IRC | 08:46 | |
| *** samuelbercovici1 is now known as samuelbercovici | 08:46 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:06 | |
| *** samuelbercovici has quit IRC | 09:09 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:09 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:20 | |
| *** samuelbercovici has quit IRC | 09:24 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:24 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:30 | |
| *** samuelbercovici has quit IRC | 09:33 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:34 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:36 | |
| *** samuelbercovici has quit IRC | 09:40 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:40 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:42 | |
| *** samuelbercovici has quit IRC | 09:46 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:46 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 09:56 | |
| *** samuelbercovici has quit IRC | 09:59 | |
| *** samuelbercovici1 is now known as samuelbercovici | 09:59 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 10:02 | |
| *** samuelbercovici has quit IRC | 10:06 | |
| *** samuelbercovici1 is now known as samuelbercovici | 10:06 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 10:15 | |
| *** samuelbercovici has quit IRC | 10:18 | |
| *** samuelbercovici1 is now known as samuelbercovici | 10:18 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 10:27 | |
| *** samuelbercovici has quit IRC | 10:30 | |
| *** samuelbercovici1 is now known as samuelbercovici | 10:30 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 10:34 | |
| *** samuelbercovici has quit IRC | 10:38 | |
| *** samuelbercovici1 is now known as samuelbercovici | 10:38 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 10:51 | |
| *** samuelbercovici has quit IRC | 10:54 | |
| *** samuelbercovici1 is now known as samuelbercovici | 10:54 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:11 | |
| *** samuelbercovici has quit IRC | 11:14 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:15 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:16 | |
| *** samuelbercovici has quit IRC | 11:20 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:20 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:25 | |
| *** samuelbercovici has quit IRC | 11:28 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:28 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:30 | |
| *** samuelbercovici has quit IRC | 11:33 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:33 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 11:37 | |
| *** samuelbercovici has quit IRC | 11:40 | |
| *** samuelbercovici1 is now known as samuelbercovici | 11:40 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 12:00 | |
| *** samuelbercovici has quit IRC | 12:03 | |
| *** samuelbercovici1 is now known as samuelbercovici | 12:04 | |
| *** woodster__ has joined #openstack-lbaas | 12:48 | |
| *** maishsk has joined #openstack-lbaas | 12:54 | |
| maishsk | good afternoon - anyone around? | 12:54 |
|---|---|---|
| dougwig | hiya | 12:58 |
| dougwig | crazy early morning for most of us, so I don't expect many will be here right now. i'm on an absurdly early flight, or i'd be asleep as well. :) | 12:59 |
| maishsk | dougwig - safe travels - middle of the day here... | 12:59 |
| dougwig | where is "here" for you? (i'm in idaho, US.) | 12:59 |
| dougwig | oh wait, not anymore. :) i'm here: http://flightaware.com/live/flight/SKW4529 | 13:00 |
| maishsk | Jerusalem - Israel | 13:06 |
| dougwig | nice. | 13:08 |
| dougwig | anything i can help with, or just saying hi? | 13:08 |
| maishsk | dougwig: Did I undertsnad correctly that Octavia - will be replaceing LBaaS ? | 13:13 |
| dougwig | not quite. octavia as currently defined is a replacement for the reference haproxy driver, and will use haproxy in conjunction with some internal service VMs to get haproxy off of the neutron node and provide scalability. the existing lbaas hooks in neutron will not change, and the existing haproxy ref driver isn't going anywhere in the juno timeframe. | 13:14 |
| dougwig | if lbaas as a project splits out of neutron entirely, then octavia is a subset of that larger project. | 13:14 |
| maishsk | so in the meantime - will any additional functionality be added into the current LBaaS? | 13:15 |
| maishsk | specifically - I am looking at how I should provide LB redundancy - and until I will have to maintain such a solution. | 13:16 |
| dougwig | do you represent a vendor, or working on the open source haproxy driver? | 13:16 |
| dougwig | yes, features are being added into lbaas. the new object model discussed at the atlanta summit, TLS/certs, L7 routing are all going into the neutron/lbaas project right now. | 13:17 |
| maishsk | I work for Cisco - but I would define myself as a representative | 13:17 |
| maishsk | would not* <- | 13:17 |
| dougwig | let me rephrase, are you looking to use lbaas with hardware, write a driver for hardware, or use the existing haproxy implementation? | 13:18 |
| maishsk | existing haproxy implementation | 13:18 |
| dougwig | if you want haproxy with redundancy, then you'd want the first version of octavia, due for juno. | 13:19 |
| dougwig | that or a hardware vendor solution are the only short-term HA options for lbaas. | 13:19 |
| maishsk | dougwig - talking Juno timeframe - will this project even go into incubation? | 13:20 |
| maishsk | or are we talking a number of versions down the line | 13:20 |
| maishsk | I can always deploy my own HAproxy solution - of course it will not be baked into Openstack - but at least that will provide the redundancy | 13:21 |
| dougwig | well, it's on stackforge as of the mid-cycle meetup last week, and has a lot of dedicated developers from rackspace, hp, and blue box, and they all need it to ship. i don't want to speak for them too much, but they're very motivated to get it out quickly. | 13:21 |
| dougwig | in about 3 hours they'll all be online. | 13:21 |
| maishsk | from your experience - how long do you expect Octavia will take until stable? 1,2,3 (or more releases) ? | 13:22 |
| maishsk | I will definately give them a ping | 13:22 |
| dougwig | just given the scope of it, i'd expect it to be experimental in Juno and stable in K. | 13:23 |
| maishsk | Interesting... :) | 13:23 |
| *** maishsk has quit IRC | 13:52 | |
| *** evgenyf has joined #openstack-lbaas | 13:55 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 14:12 | |
| *** samuelbercovici has quit IRC | 14:15 | |
| *** samuelbercovici1 is now known as samuelbercovici | 14:16 | |
| *** fnaval has joined #openstack-lbaas | 14:18 | |
| *** aburaschi has joined #openstack-lbaas | 14:20 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 14:32 | |
| *** samuelbercovici has quit IRC | 14:35 | |
| *** samuelbercovici1 is now known as samuelbercovici | 14:35 | |
| *** enikanorov_ has joined #openstack-lbaas | 14:36 | |
| *** fnaval has quit IRC | 14:40 | |
| *** ptoohill_ has joined #openstack-lbaas | 14:47 | |
| *** german_ has joined #openstack-lbaas | 15:04 | |
| *** ptoohill_ has joined #openstack-lbaas | 15:05 | |
| *** sbalukoff1 has quit IRC | 15:06 | |
| *** fnaval has joined #openstack-lbaas | 15:09 | |
| *** ptoohill_ has quit IRC | 15:09 | |
| *** fnaval_ has joined #openstack-lbaas | 15:09 | |
| *** fnaval has quit IRC | 15:13 | |
| *** fnaval_ has quit IRC | 15:25 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 15:27 | |
| *** sbfox has joined #openstack-lbaas | 15:29 | |
| *** aburaschi1 has joined #openstack-lbaas | 15:29 | |
| *** samuelbercovici has quit IRC | 15:30 | |
| *** samuelbercovici1 is now known as samuelbercovici | 15:30 | |
| *** aburaschi has quit IRC | 15:32 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 15:41 | |
| *** samuelbercovici has quit IRC | 15:45 | |
| *** samuelbercovici1 is now known as samuelbercovici | 15:45 | |
| *** zz_blogan is now known as blogan | 15:54 | |
| *** sbfox has quit IRC | 15:56 | |
| *** sbfox has joined #openstack-lbaas | 16:04 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 16:17 | |
| *** samuelbercovici has quit IRC | 16:20 | |
| *** samuelbercovici1 is now known as samuelbercovici | 16:20 | |
| *** jorgem has joined #openstack-lbaas | 16:24 | |
| *** sbfox has quit IRC | 16:37 | |
| *** sbfox1 has joined #openstack-lbaas | 16:37 | |
| *** evgenyf has quit IRC | 16:42 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 16:48 | |
| *** samuelbercovici has quit IRC | 16:51 | |
| *** samuelbercovici1 is now known as samuelbercovici | 16:51 | |
| *** dlundquist has joined #openstack-lbaas | 16:51 | |
| *** sbfox1 has quit IRC | 16:58 | |
| *** sbfox has joined #openstack-lbaas | 16:58 | |
| *** sbfox has quit IRC | 17:08 | |
| *** sbfox has joined #openstack-lbaas | 17:16 | |
| *** min has joined #openstack-lbaas | 17:20 | |
| *** jorgem has quit IRC | 17:32 | |
| *** blogan is now known as zz_blogan | 17:33 | |
| *** jorgem has joined #openstack-lbaas | 17:36 | |
| *** zz_blogan is now known as blogan | 17:37 | |
| *** dlundquist has left #openstack-lbaas | 17:40 | |
| *** samuelbercovici1 has joined #openstack-lbaas | 17:55 | |
| *** sbfox has quit IRC | 17:58 | |
| *** samuelbercovici has quit IRC | 17:58 | |
| *** samuelbercovici1 has quit IRC | 18:03 | |
| *** sbfox has joined #openstack-lbaas | 18:06 | |
| *** vivek-ebay has joined #openstack-lbaas | 18:14 | |
| *** markmcclain has joined #openstack-lbaas | 18:20 | |
| *** sbalukoff has joined #openstack-lbaas | 18:23 | |
| sbalukoff | Mornin' folks! | 18:23 |
| dougwig | morning. | 18:29 |
| dougwig | can i get some of your eyes on the latest no-op code? https://review.openstack.org/#/c/101084/ | 18:30 |
| sbalukoff | dougwin: I'll take a look at it later this afternoon, eh! | 18:41 |
| blogan | afternoon! | 18:47 |
| blogan | dougwig: any idea when your blueprint will get accepted? | 18:48 |
| dougwig | you mean code review? bp was accepted last week? | 18:48 |
| dougwig | as soon as i get a +1 from someone here, i'll ping markmcclain and ask him to take another look at the new unit test. | 18:49 |
| dougwig | alternately, you can go to the code review and git pull the changes into your branch. | 18:50 |
| *** vivek-ebay has quit IRC | 18:54 | |
| *** vivek-ebay has joined #openstack-lbaas | 18:55 | |
| *** vivek-ebay has quit IRC | 18:57 | |
| *** vivek-ebay has joined #openstack-lbaas | 19:02 | |
| blogan | dougwig: the active and failed methods, do those belong in the LBBaseManager class? | 19:04 |
| dougwig | arguable, indeed. the method of using update_status is painfully verbose and usually blows the 80 char limit, and every manager needs to access it. i put it in for convenience, since I did the same thing in my driver. i could go either way. | 19:05 |
| blogan | yeah me too | 19:06 |
| blogan | this is the basemanager for all managers though right? | 19:06 |
| blogan | by that i mean the listenermanager will be a subclass of LBBaseManager? | 19:07 |
| dougwig | yes, but there is no manager that doesn't use it, as it finishes the object status. unless we want to make it cleaner and have the plugin infer that a non-exception return from the driver means it can set active, and otherwise error. | 19:07 |
| *** evgenyf has joined #openstack-lbaas | 19:08 | |
| dougwig | already is. if you peek at logging_noop/driver.py, you'll see where it uses those methods. | 19:08 |
| *** crc32 has joined #openstack-lbaas | 19:08 | |
| blogan | but that means every manager will have an active failed method now right? | 19:09 |
| blogan | and some entities dont have a status field | 19:09 |
| dougwig | ahh, ok. which don't have status? | 19:09 |
| blogan | listener and health monitor | 19:10 |
| *** TrevorV has joined #openstack-lbaas | 19:11 | |
| dougwig | hmm, my current driver is doing this for health monitors: | 19:11 |
| dougwig | self.plugin.update_pool_health_monitor(context, | 19:11 |
| dougwig | health_monitor["id"], | 19:11 |
| dougwig | pool_id, | 19:11 |
| dougwig | constants.ACTIVE) | 19:11 |
| dougwig | which is decidedly not update_status. | 19:11 |
| blogan | yeah thats a bit odd, but healthmonitor doesn't have a status field now | 19:12 |
| blogan | i can definitely see an argument for it to have a status, same with listener | 19:12 |
| blogan | but i think if a listener's errors that should bubble up to the load balancer status | 19:12 |
| dougwig | i'm not even sure that the drivers should be worrying about that interface, to be honest with you. let's see, i could make a second base that has the status helpers, and derive that from the base, and then break out base managers for each functional area, derived from the appropriate manager. feels ugly, but it would be better from a documenting aspect, at | 19:14 |
| dougwig | least, and get those methods out of listener/hm. | 19:14 |
| *** evgenyf has quit IRC | 19:19 | |
| blogan | yeah i dont know about it, maybe if the plugin exposed an update_loadbalancer_status and update_member_status method and the driver can just call that when needed? | 19:19 |
| *** sbfox has quit IRC | 19:22 | |
| dougwig | sec, someone walked in. | 19:27 |
| dougwig | blogan: i'd support either the higher-level helpers you suggest in the plugin, or just stop monkeying with status at all in the drivers, and let the plugin infer status from the driver op success/failure (and failures should have a neutron exception with a msg attribute.) | 19:31 |
| dougwig | sbalukoff: isn't the tis object 1:n on the listener in the SNI case? | 19:32 |
| blogan | dougwig: I don't think the plugin can infer if it is being sent by agent | 19:41 |
| dougwig | the agent monkeys with the neutron db directly? ouch, ok. concur. | 19:42 |
| blogan | not directly, but through rpc back to the plugin | 19:42 |
| *** sbfox has joined #openstack-lbaas | 19:45 | |
| *** vivek-ebay has quit IRC | 19:54 | |
| *** vivek-ebay has joined #openstack-lbaas | 19:54 | |
| dougwig | i have to go food. back in a few. | 20:00 |
| blogan | ernjoy | 20:00 |
| blogan | and enjoy | 20:00 |
| german_ | food = good | 20:03 |
| sbalukoff | dougwig: So SNI policies / lists are 1:N with the listener, but every listener needs a default certificate if it does TLS termination, regardless of whether it's using SNI. | 20:04 |
| sbalukoff | So it's 1:1 for attributes like default_certificate_id, and probably also things like TLS version number or cipher selection, once those features get added. | 20:05 |
| *** markmcclain has quit IRC | 20:06 | |
| *** sbfox has quit IRC | 20:06 | |
| *** vivek-eb_ has joined #openstack-lbaas | 20:07 | |
| *** vivek-ebay has quit IRC | 20:07 | |
| blogan | sbalukoff: i get what you're saying, and that default_certificate_id would reference a barbican entity id? | 20:08 |
| sbalukoff | blogan: Yes. It's similar to what we're doing with SNI policies. | 20:08 |
| *** VijayB has joined #openstack-lbaas | 20:09 | |
| sbalukoff | But there are also probably going to (continue to be) attributes which apply to the whole TLS connection and not just the SNI part. | 20:09 |
| sbalukoff | So... It is somewhat a matter of opinion. | 20:09 |
| sbalukoff | But I'm not sure I'm convinced on the "cleaner" aspect of this. | 20:09 |
| sbalukoff | If we're going to split those fields off to another object, it should not be the SNI policy / list object. | 20:10 |
| sbalukoff | And the resulting object we create would have a 1:1 relationship with listener object | 20:10 |
| sbalukoff | (or 1:0-1) | 20:10 |
| sbalukoff | Since not every listener needs to have this extra object. | 20:10 |
| blogan | i guess the worry is if more attributes are added to the listener that have to do with the tls termination. | 20:11 |
| sbalukoff | I could certainly be talked into this if people can clarify / articulate their reasons for wanting it thus. :) | 20:11 |
| sbalukoff | Yes, and there will almost certainly be more attributes added. | 20:11 |
| blogan | the 1:1 argument is weak because we could have health monitors be 1:1 to a pool but we'd all agree it should still be a separate entity | 20:11 |
| sbalukoff | That's true. | 20:11 |
| sbalukoff | Note: | 20:11 |
| sbalukoff | We're going to have very similar concerns with 'default policy' when L7 happens too. | 20:12 |
| blogan | i really think what it comes down to is the separation of many attributes | 20:12 |
| sbalukoff | Right now, that's effectively hard-coded to "redirect to this pool" | 20:12 |
| *** VijayB has joined #openstack-lbaas | 20:12 | |
| sbalukoff | And you're right in that 'TLS stuff' seems to be one domain that doesn't always apply to 'Listener stuff' | 20:12 |
| VijayB | blogan: Hi Brandon! There? | 20:12 |
| blogan | VijayB: sure am | 20:13 |
| VijayB | Hey :) | 20:13 |
| sbalukoff | Hi Vijay | 20:13 |
| *** markmcclain has joined #openstack-lbaas | 20:13 | |
| VijayB | I made a bunch of changes for the pools and health monitors, but ran into your latest block of sixteen commits D: So I'll resolve those and push my changes in. | 20:13 |
| blogan | sbalukoff: yeah it doesn't, but it oculd be handled easily as an optional attribute of a listener, but if there is the possibility of more attributes being added that are only in the domain of the tls cert, we should make it a separate entity | 20:14 |
| sbalukoff | blogan: What I'm saying in my objections are "Sell it to me harder, please! Justify why we want to change a model that's taken us this long to get ratified." | 20:14 |
| blogan | VijayB: oh i thought you were going to do the listeners | 20:14 |
| VijayB | blogan: May take a while but I should be done in probably a couple of hours (am in a meeting) | 20:14 |
| VijayB | blogan: oh sorry my bad! | 20:14 |
| VijayB | blogan: I meant listeners and health monitors | 20:14 |
| sbalukoff | blogan: I would say it's almost certain there will be more attributes added. | 20:14 |
| sbalukoff | blogan: So, I'm becoming more convinced that's the right way to do it. :) | 20:15 |
| blogan | VijayB: its okay, I had to change the name of pools to nodepools because with the v1 api being active at the same time as v2, the attributes of the v1 pool were being added into teh v2 pool attributes | 20:15 |
| blogan | sbalukoff: have i sold it to you hard enough? | 20:15 |
| blogan | sbalukoff: or do i need to close the deal? | 20:15 |
| VijayB | blogan: ok.. I'll ping you in case I need any clarifications... | 20:15 |
| sbalukoff | blogan: Haha! Can you put that in an e-mail to the list so more people see it? | 20:16 |
| sbalukoff | Bulletted lists of reasons for doing it that way are a good way to drive the point home. | 20:16 |
| blogan | VijayB: okay, its something that will take some explanation, but it had to be done for now | 20:16 |
| VijayB | blogan: Ok.. | 20:16 |
| blogan | sbalukoff: i can send out an email | 20:16 |
| sbalukoff | Thank you! | 20:17 |
| blogan | or just respond to Vijay's thread | 20:17 |
| blogan | which i already did | 20:17 |
| sbalukoff | That's what I meant. :) | 20:17 |
| sbalukoff | Oh! | 20:17 |
| sbalukoff | Sorry, just got back from lunch. | 20:17 |
| sbalukoff | Haven't checked that yet. | 20:17 |
| blogan | oh no, its was just me saying i didn't know it wasn't goign to be a separate entity | 20:17 |
| blogan | so me admitting i was ignorant | 20:17 |
| sbalukoff | Get with the program, man! | 20:18 |
| sbalukoff | Actually, I'd be surprised if everyone were looking that closely. | 20:18 |
| *** TrevorV has quit IRC | 20:19 | |
| blogan | yeah i kinda think people are just waiting for the refactor to complete before giving that part the attention it deserves | 20:19 |
| sbalukoff | One of these times I'm going to suggest a model that includes a farhvergnugen field, just to see if people are paying attention. | 20:19 |
| blogan | which is what ive been doing | 20:19 |
| sbalukoff | Aah. | 20:19 |
| *** TrevorV has joined #openstack-lbaas | 20:20 | |
| sbalukoff | blogan: If you're engaged in other things, I can write the e-mail response which sells the two separate objects thing pretty hard. | 20:21 |
| sbalukoff | I already came up with another reason you didn't mention, as well. | 20:22 |
| sbalukoff | ;) | 20:22 |
| blogan | sbalukoff: reviewing our current tls termination needs, a default_certificate_id on the listener would satisfy all of our requirements | 20:25 |
| blogan | sbalukoff: what is the other reason? | 20:26 |
| *** rolledback has joined #openstack-lbaas | 20:26 | |
| sbalukoff | blogan: Keeping the TLS stuff "contained" to its own objects means we can have separate development resources on each and not worry as much about overlapping domains. | 20:36 |
| sbalukoff | So, it's "cleaner" from a development and testing perspective as well. | 20:36 |
| sbalukoff | (Understanding TLS stuff does have different knowledge domain than understanding TCP / UDP listeners.) | 20:37 |
| *** vivek-eb_ has quit IRC | 20:38 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:38 | |
| *** rolledback has quit IRC | 20:39 | |
| *** VijayB has quit IRC | 20:39 | |
| *** aburaschi1 has quit IRC | 20:39 | |
| blogan | sbalukoff: yeah that is another good reason | 20:39 |
| *** VijayB has joined #openstack-lbaas | 20:39 | |
| blogan | sbalukoff: i suppose each entity can now have a name and description, but what other attributes will there be? | 20:40 |
| sbalukoff | I'm certain the next revision / release of the TLS stuff is going to have TLS version and cipher selection stuff in it. I'm certain because based on what I've seen Samuel and Evgeny pushing for, I can tell Radware wants it (and really, there's no reason not to have it-- it's just probably more than we need for version 1) | 20:41 |
| blogan | wouldnt that be a part of barbican | 20:43 |
| dougwig | certs and ssl/tls are not joined things. | 20:43 |
| sbalukoff | blogan: Nope. | 20:43 |
| dougwig | (i'm back) | 20:43 |
| sbalukoff | welcome back. | 20:44 |
| sbalukoff | blogan: No, those are attributes / technologies used around the actual negotiation process for the TLS connection, certs are a part of that negotiation process as well, but not the only parts. | 20:44 |
| sbalukoff | And it doesn't make sense for barbican to store details about the kinds of TLS connection we allow. | 20:45 |
| blogan | okay that makes sense in some form to me, that part is something I'm not involved in much so my knowledge is lacking | 20:48 |
| blogan | dougwig: i -1 you're blueprint | 20:49 |
| blogan | and your | 20:49 |
| blogan | let me know if I'm crazy | 20:50 |
| german_ | sbalukoff +1 for using the mailing list for the TLS discussion. Every time I look at another window there are 100s of lines to read here :-) | 20:50 |
| sbalukoff | german_: I think it's good to use IRC for high-bandwidth hashing out of stuff like blogan just did. But in the end, I think the ML should then have at least a summary of what was discussed so people have a simpler time keeping up with the discussion without having to have an eye on IRC all day. | 20:52 |
| german_ | agreed. that's what I meant to say... | 20:52 |
| sbalukoff | I dislike having to be logged into instant messaging systems / keep an eye on IRC / jabber / skype / whatever all the time because then I have trouble getting work done that involves high concentration (like coding does). | 20:53 |
| sbalukoff | Cool! | 20:53 |
| blogan | i know what you mean sbalukoff | 20:53 |
| german_ | yep, I mostly gkimpse here unless I am summoned | 20:53 |
| sbalukoff | So on that note, I will not be offended if I ask you something on IRC and you don't get back to me for hours (or ever) on it. I only ask you extend the same courtesy to me. :) | 20:54 |
| german_ | +1 | 20:54 |
| blogan | i usually get offended when you say anything sbalukoff | 20:55 |
| sbalukoff | (This is also why I actually have trouble getting code done at a hackathon-- when there's conversation going on, my brain likes to latch onto that rather than what I'm typing. Well, and in the case of last week, I'm also a pretty crappy python coder. ;) ) | 20:55 |
| sbalukoff | blogan: Excellent! Then my efforts are paying off. | 20:56 |
| sbalukoff | blogan: I know I'm screwing up if people are agreeing with me too readily. ;) | 20:56 |
| VijayB | blogan: I've pushed in my code after resolving the conflicts - neutron-server seems to run fine and hopefully nothing's broken.. | 20:56 |
| blogan | sbalukoff: well somehow i've managed to get you to agree with me | 20:56 |
| blogan | VijayB: okay I'll pull down and try it out | 20:57 |
| sbalukoff | blogan: Because you sold it to me. (Hard, deep, and fast.) | 20:57 |
| sbalukoff | Really, like I've been saying: I will happily and quickly switch alliegances if you can back up your claim, and do so more convincingly than either the status quo or your competition. | 20:58 |
| german_ | sbalukoff, I have trouble wrapping my mind around the neutron code, too | 20:58 |
| sbalukoff | I try not to have much loyalty to memes, eh. | 20:58 |
| VijayB | blogan: Ok | 20:59 |
| *** markmcclain has quit IRC | 20:59 | |
| sbalukoff | german_: Wait, that's *code*? I thought it was instructions for finding a great bar on the east side of Moscow. | 20:59 |
| german_ | exactly, maybe I am doing it all wrong and should first go to the bar, have some drinks, and then see the light :-) | 21:00 |
| sbalukoff | Sounds like a plan to me! | 21:00 |
| VijayB | sbalukoff: Do you mean http://en.wikipedia.org/wiki/Moscow,_Idaho ? | 21:00 |
| sbalukoff | VijayB: No, I was talking about the Russian one. (And as a former resident of Moscow, ID, I can say there are no great bars there, let alone on the east side.) | 21:01 |
| *** markmcclain has joined #openstack-lbaas | 21:01 | |
| VijayB | sbalukoff: My lol!!! moment is getting trumped by the fact that you actually lived in Moscow ID!!! :p | 21:02 |
| german_ | lol | 21:02 |
| blogan | sbalukoff: maybe your father should run on the message of "better bars in Moscow, ID" | 21:04 |
| sbalukoff | VijayB: Heh! I actually wondered whether anyone would mention the Idaho Moscow in making my joke. XD University of Idaho is my alma mater. | 21:04 |
| sbalukoff | blogan: I shall relay the suggestion to him. XD | 21:05 |
| dougwig | blogan: saw that; only part i disagree on is that if the drivers are going to update status, we should abstract that a bit more than update_status. | 21:05 |
| blogan | dougwig: you mean an update_loadbalancer_status method? | 21:05 |
| dougwig | every single driver call has to deal with status somehow; seems silly to me to make every driver load constants (for ACTIVE or ERROR), or to have a reference to the neutron models class names. i'm almost wondering if the relevant managers should have an even more abstracted active() and failed(), which doesn't require passing the ldb model name or the | 21:09 |
| dougwig | constant and/or a handy decorator to wrap the driver methods. i'd live with it being verbose, but i hate repeated cruft. | 21:09 |
| VijayB | grp: I hereby propose that sbalukoff be made the official ambassador of Moscow, ID :p | 21:10 |
| german_ | dougwig, an exception model can't solve that | 21:10 |
| german_ | ? | 21:10 |
| dougwig | not with the agent | 21:10 |
| dougwig | i suggested that, blogan pointed out the agent. | 21:10 |
| dougwig | but i'm not worried about providing helpers to the agent; it can make a verbose call, since there's nothing there to abstract. | 21:11 |
| dougwig | blogan: holler when we should just have a short voice chat, because i think we're talking around each other here via text. | 21:13 |
| german_ | well, errors bubbling up to the lb really sound like exceptions in action -- anyhow... I will keep an eye on that discussion... | 21:14 |
| blogan | dougwig: sure let me go refresh myself on the agentmanager and agentdevicedriver code | 21:17 |
| VijayB | I'm not for the driver making any db changes.. every implementation could possibly do it in a different order, changes may be present between different core plugins and so on.. I would like us to define the interfaces to the driver layer. | 21:17 |
| blogan | VijayB: what about the driver making a call back to the plugin method that does the db call? | 21:17 |
| german_ | VijayB: absolutely -- that's why we started the neutron cleanup to create those interfaces | 21:17 |
| vivek-ebay | I agree. driver making DB changes will complicate things. | 21:18 |
| VijayB | blogan: we may need to build a layer to handle those callbacks... | 21:18 |
| dougwig | VijayB: i think the only thing blogan and i are debating is whether to put some friendly helpers into the driver layer; there are still calls into the plugin regardless. | 21:18 |
| dougwig | as an example, say the driver calls plugin.update_status(ACTIVE). right now, the plugin implements that as a db call. in the future, the plugin would implement that as a REST call to neutron. that's not a problem interface. | 21:19 |
| blogan | VijayB: well the agent has callbacks if it is used, but without the agent, currently it just calls the appropriate plugin method to update teh status | 21:19 |
| blogan | dougwig: yeah and that makes sense to me | 21:19 |
| dougwig | the problem interfaces are the driver calls that call db.query('SELECT ...'). :) | 21:19 |
| german_ | and they need to go | 21:20 |
| blogan | dougwig: that would be in the case of needing to update a neutron entity, such as port | 21:20 |
| *** sbfox has joined #openstack-lbaas | 21:20 | |
| dougwig | or fetching floating ip's. | 21:20 |
| *** jorgem has quit IRC | 21:21 | |
| german_ | yeah, this is what I was expecting the cleanup work to accomplish - put those in an API | 21:21 |
| sbalukoff | german_: +1 | 21:21 |
| VijayB | blogan/dougwig/german_: ok.. that sounds ok.. as the code shapes up, I'll shout out in case I see something differently.. | 21:23 |
| dougwig | german_: yes, but i think no one knows all the pain points, and the v1/v2 shim layer is what's going to end up shaking out of fair amount of that. | 21:24 |
| german_ | yeah, it's not as clear cut as I hoped but nevertheless we still should aim for it (and if after the work we find some instances treat them as bugs) | 21:25 |
| dougwig | blogan: this is the crux of what we're discussing, from what I understand. it's six and one half dozen in terms of what gets called where. if folks like the longer calls better, I'll switch (I don't): | 21:28 |
| dougwig | https://www.irccloud.com/pastebin/Bjw7jmyP | 21:28 |
| dougwig | literally every driver op looks similar. to the point where i'll just use a decorator in mine. | 21:28 |
| dougwig | there are some per manager variations, which we can encapsulate. | 21:29 |
| dougwig | some drivers don't raise an exception at the end in the failure case, which is ok behavior right now. | 21:29 |
| VijayB | dougwig: with helper looks better.. drivers better simply return errors than raise exceptions.. that's better left to the upper mgmt layers | 21:30 |
| dougwig | drivers can't return errors right now. they can set status, blow an exception (which is caught, logged, and is not fatal), but they effectively return void. | 21:31 |
| dougwig | (we could change that now, if desired.) | 21:31 |
| dougwig | exceptions in the driver __init__ are fatal to neutron server, and not in any other call, as a overly detailed tangent that is not helpful right now. | 21:32 |
| VijayB | dougwig: hmm.. so in case of a multiple agent architecture I guess the custom plugin part of the driver sets the status.. | 21:33 |
| german_ | yeah, I like helpers better, too. But I also prefer exceptions over the C style if call==-1 ... | 21:33 |
| *** sbfox1 has joined #openstack-lbaas | 21:33 | |
| VijayB | german_ : I'm just wondering about the remote agent scenario | 21:33 |
| VijayB | I guess the rpc takes care of passing back the op statuses | 21:34 |
| dougwig | remote agents don't have the same plugin interface as the driver; nor should they. i'm not sure that's a design point for driver interfaces. | 21:34 |
| VijayB | in which case, having helpers would just make it look cleaner | 21:34 |
| german_ | helpers +1 | 21:34 |
| VijayB | dougwig: yes they needn't be factored in for the driver interfaces, they should be abstracted away already | 21:35 |
| VijayB | we should go with helpers nevertheless, it's cleaner | 21:35 |
| *** sbfox1 has quit IRC | 21:35 | |
| *** sbfox1 has joined #openstack-lbaas | 21:35 | |
| *** sbfox has quit IRC | 21:36 | |
| VijayB | unless something prevents that.. | 21:36 |
| dougwig | right now, just bologna's objections. | 21:36 |
| dougwig | damnit, autocorrect. | 21:36 |
| german_ | I know who you mean :-) | 21:36 |
| blogan | ok im back | 21:36 |
| blogan | so what woudl the helpers be then? | 21:37 |
| blogan | just so i'm clear | 21:37 |
| dougwig | i'm thinking abstract them down to be more specific, so they don't need the models passed in, and they vary for health_monitor as needed, and don't exist for listener? | 21:38 |
| *** dlundquist has joined #openstack-lbaas | 21:40 | |
| dlundquist | dougwig: Stephen tells me you where trying to get a hold me this weekend | 21:41 |
| dougwig | it is an interesting mental exercise to interleave this conversation with the neutron meeting, after having gotten up at 3am this morning. | 21:41 |
| german_ | people have to get up at 3am in Idaho? No wonder they are looking for anew governor! | 21:41 |
| sbalukoff | dougwig: This is why you should sleep in on Mondays. Nothing good ever comes from getting up too early on a Monday. | 21:42 |
| dougwig | i flew to the mothership this morning. i'm currently in california. | 21:42 |
| dougwig | dlundquist: just checking in on the shim work, and seeing if you're still ok with it + your haproxy ref work, now that you've got a handle for how big that task will be. | 21:43 |
| sbalukoff | dougwig: And thus my comment is confirmed. ;) | 21:43 |
| blogan | dougwig: so you're saying the update_status methods would me implementable methods of the driver? | 21:43 |
| dougwig | got up at 4, flew to LA, so i could fly back up to SF. ahh, modern air travel. | 21:43 |
| dougwig | no, update_status would be in the plugin, and active/failed would be even more abstracted helpers in the managers, which call update_status. | 21:44 |
| dlundquist | dougwig and blogan: The more I look at it the more I think we need to build two adaptors, one to adapt the v1 driver to the v2 driver API, and a second to adapt the v2 LBaaS plugin back to the v1 plugin. Until the v2 LBaaS plugin takes a little more form I'm not sure how to proceed. | 21:45 |
| blogan | and they would be left out of the entity managers' that dont have a status? | 21:45 |
| dougwig | correct. | 21:45 |
| dlundquist | dougwig: I'm happy to pass this back, but I feel like to far it was a good learning excercise. | 21:45 |
| * dlundquist needs to sit down and diagram this all out | 21:46 | |
| blogan | dlundquist: wasn't I supposed to get you that diagram? | 21:46 |
| dougwig | dlundquist: i'm plenty busy, so i'm fine not doing it. but if it slows down octavia, it's a better split if i stay in the driver layer. | 21:46 |
| ptoohill | dlunndquist: on this note, im attempting to finish up, including some testing, what would be the v2 config updates. ill check this in a bit later | 21:46 |
| ptoohill | dlundquist | 21:47 |
| ptoohill | but, this may all change it sounds like | 21:47 |
| blogan | dlundquist: once the pluginv2 and dbv2 layers get completed it might be easier to see what needs to be done, they're close to being done, other than unit tests | 21:47 |
| dlundquist | blogan: your diagram/notes would be a help. | 21:48 |
| ptoohill | the stuff im working on is assuming v2(verifying against that branch) | 21:48 |
| *** fnaval has joined #openstack-lbaas | 21:48 | |
| dlundquist | ptoohill: do you need a hand with the HAProxy 1.5 TLS driver spec -- I know that is dependent on my work, but I'm happy to help with the spec | 21:48 |
| ptoohill | well | 21:48 |
| ptoohill | the tls: | 21:49 |
| ptoohill | https://review.openstack.org/#/c/98640, incompasses the change to the driver | 21:49 |
| *** sbfox1 has quit IRC | 21:49 | |
| ptoohill | so, after talking with adam and others i was assuming the work for the TLS namespace_driver update can be done under this BP | 21:49 |
| *** sbfox has joined #openstack-lbaas | 21:49 | |
| dougwig | dlundquist: what is the v1 plugin layer for? i thought we needed one to, but then realized the steps to infer create_vip are actually easily done by looking at associations, as you suggested. | 21:50 |
| ptoohill | reason im assuming this, is well need access to some of the features provided by the BP in order to call the driver refactor 'DONE' but, it could also be pulled out. This was just our train of thought on it. | 21:52 |
| dlundquist | dougwig: neutron.services.loadblanacer.plugin LoadBalancerPlugin vs LoadBalancerPluginv2 | 21:52 |
| dlundquist | ptoohill: oh, you just removed stunnel from that spec -- I'll look that one over again now that it just covers 1.5 | 21:52 |
| ptoohill | dlundquist, i have not updated the 'old' BP. im referring to the 'main' TLS spec, maybe i pasted wrong one | 21:53 |
| ptoohill | https://review.openstack.org/#/c/98640 | 21:53 |
| ptoohill | the 'old' one should go away in favor of being under this BP | 21:54 |
| dlundquist | dougwig: LoadBalancerPlugin provides methods such as populate_vip_graph which clearly do not apply to the v2 object model | 21:54 |
| VijayB | dlundquist: You probably already are looking at the same branch, but thought I'd repaste the branch Brandon and I are checking in code for the v2 APIs/object model to: the lbaasv2 branch git@github.com:brandonlogan/neutron.git | 21:54 |
| ptoohill | ^^ this is where im basing the stuff im currently working on. (config updates for: https://review.openstack.org/#/c/100977) | 21:55 |
| dlundquist | ptoohill: 98640 doesn't include any lbaas driver changes by my reading, it would just result in an API extension with a persistence layer | 21:55 |
| ptoohill | its there | 21:56 |
| ptoohill | theres one line referencing it | 21:56 |
| ptoohill | :/ | 21:56 |
| dlundquist | ptoohill: I didn't think it was included "Further TLS and Layer 7 content filtering/manipulation are outside the scope ofthis spec, but other specs may depend on this." | 21:56 |
| ptoohill | that was the 'old' spec right? | 21:57 |
| dlundquist | VijayB: Thanks, I've been working off that branch. | 21:57 |
| dlundquist | ptoohill: that was my spec (100977) | 21:57 |
| ptoohill | yea | 21:57 |
| ptoohill | i understand that, its not taking into consideration l7/tls | 21:58 |
| dlundquist | ptoohill: I thought you where going to submit a follow on spec to extend it with TLS support | 21:58 |
| ptoohill | I was until i got to talking to others about it | 21:58 |
| ptoohill | it was understood by majority that the 98640 spec will also handle the updates to the driver | 21:59 |
| ptoohill | i was working under your(our) spec to update the configs/driver to support the object model refactor. This does not include TLS/L7 etc.. | 22:00 |
| dlundquist | so there still is the piece to update the HAProxy driver with writing out keys/certificates and adding the TLS related parts to the haproxy config file. | 22:01 |
| VijayB | dlundquist: cool, good to know we're all working on the same branch | 22:01 |
| blogan | dlundquist: are you talking about an adapter that would go from someone creating a vip to the code actually creating a load balancer and listener? | 22:01 |
| ptoohill | dlundquist: correct, but that would be handled undert 98640 | 22:02 |
| dlundquist | dougwig: I had one more question re the updated driver: are we sure we only want to offer stats on the load balancer object? HAProxy can offer stats down pool or member granularity. I'm happy to sum across all the pools, but wasn't sure if that would be the best experience to the user. | 22:02 |
| dlundquist | blogan: I was talking about a shim driver so after we pull out the v1 persistence layer v1 LBaaS drivers would still work | 22:03 |
| ptoohill | which i have a comment in patch 10 of 98640 regarding the storing of the secrets | 22:03 |
| blogan | dlundquist: okay becuase you mentioned going v1 to v2, and v2 to v1 | 22:05 |
| blogan | dlundquist: i have these "workflow" images, where do you want them? | 22:05 |
| dougwig | dlundquist: i think it was vijay that suggested supporting stats() on all objects, and i fully support that (and figure we can slip it into the manager for all when we do it.) i was just trying to keep the first step more at parity, with an eye towards adding a stats() call for every manager down the road a little bit. | 22:05 |
| dougwig | dlundquist: regarding things like vip_graph, we are allowed to break current drivers temporarily, and comment out their unit tests, pending the vendor fixing their driver. if any particular call adds a LOT of complexity, it might be worth chatting with the driver author about whether it's less work to port the driver than to write that particular shim entry | 22:07 |
| dougwig | point. | 22:07 |
| *** markmcclain has quit IRC | 22:08 | |
| *** VijayB_ has joined #openstack-lbaas | 22:11 | |
| blogan | dlundquist: http://tinypic.com/r/14xp0lv/8 http://tinypic.com/r/28u1chf/8 | 22:11 |
| blogan | those are a little old and some may be wrong but i think the workflow is there | 22:11 |
| blogan | i'm terrible at diagrams | 22:12 |
| *** VijayB has quit IRC | 22:15 | |
| dlundquist | blogan: thank you | 22:15 |
| dlundquist | dougwig: I guess the shim driver isn't required | 22:16 |
| dlundquist | we'll just comment out their tests for now. I'm going focus back on the HAProxy driver | 22:16 |
| dougwig | i'm not sure that i said we could punt all the drivers. though maybe we can; one of us should email all of the maintainers and see about them doing updates, and timeframe. want me to start that? | 22:20 |
| blogan | i thought the point of the shim was so that they could do updates at their own pace | 22:21 |
| dougwig | +1 | 22:21 |
| dougwig | but part of that discussion was not supporting every little thing if they were using "problem" interfaces. | 22:21 |
| blogan | what is one of the problem interfaces? | 22:22 |
| blogan | many to many healthmonitors for sure | 22:22 |
| german_ | +1 | 22:22 |
| blogan | others? | 22:22 |
| german_ | subnet id | 22:22 |
| blogan | if there are more than one different subnet_ids | 22:23 |
| blogan | yeah | 22:23 |
| dougwig | i think in the context of that discussion, problem interfaces were anything that made the shim overly complicated, if it was one driver. update_status on ldb.Vip was one example, e.g. | 22:24 |
| dougwig | darn, i wish i'd documented that conversation now. | 22:24 |
| blogan | lol i wish i had documented many conversations | 22:24 |
| dlundquist | Here are the methods on the plugin object being used by in-tree LBaaS drivers: https://gist.github.com/dlundquist/8264773b77ffcf271c67 | 22:25 |
| blogan | ah yeah anything going to core_plugin would need to be an API call in the future if lbaas ever splits out | 22:27 |
| dougwig | dlundquist: nice list; certainly points to a second shim plugin being the path of least resistance, you're right. | 22:28 |
| dlundquist | So I'm thinking the lbaas driver shim should be composed of two parts: a v1 to v2 driver shim, a v2 to v1 plugin shim each with their own private methods to convert the object formats | 22:31 |
| dlundquist | no: in both cases we need to convert v2 DB object to v1 objects | 22:31 |
| dlundquist | so all the object conversion logic should be pulled out into a third file | 22:32 |
| dlundquist | Can you think of any case where a driver would need to create a v2 DB object? | 22:33 |
| dougwig | dlundquist: i think if we could, we would opt for a plugin method instead, else we'd be adding another problem interface. so, by definition, no. | 22:38 |
| blogan | oh the make_blah_dict are going away in favor of modelinstance.to_dict | 22:41 |
| blogan | i should make a baselbaasmodel class so that every model has that | 22:42 |
| *** sbfox has quit IRC | 22:51 | |
| *** sbfox has joined #openstack-lbaas | 22:51 | |
| dougwig | i read that as basebase model, and for a second, thought that was the most awesome thing ever. no sleep is not a good thing. | 23:03 |
| *** fnaval has quit IRC | 23:05 | |
| *** fnaval has joined #openstack-lbaas | 23:05 | |
| blogan | lol i could see that happening | 23:08 |
| *** fnaval has quit IRC | 23:09 | |
| *** markmcclain has joined #openstack-lbaas | 23:12 | |
| *** markmcclain1 has joined #openstack-lbaas | 23:13 | |
| *** fnaval has joined #openstack-lbaas | 23:15 | |
| *** markmcclain has quit IRC | 23:17 | |
| *** VijayB_ has quit IRC | 23:22 | |
| *** VijayB_ has joined #openstack-lbaas | 23:23 | |
| *** blogan is now known as zz_blogan | 23:25 | |
| *** fnaval has quit IRC | 23:36 | |
| *** fnaval has joined #openstack-lbaas | 23:36 | |
| VijayB_ | btw, I'm sorry if I got the name wrong, but was it Craig who was working on implementing the CLI for the new object model/api?? It would be good to have that code as well so I could run CLIs to test out the new api paths.. are we maintaining a separate python-neutronclient branch also on the lines of lbaasv2? | 23:40 |
| *** fnaval has quit IRC | 23:40 | |
| sbalukoff | VijayB_: I think it was Craig (ctracey here) who was working on CLI stuff, though exactly what I'm not certain. | 23:47 |
| VijayB_ | sbalukoff: Thanks Stephen! I'll wait for ctracey to ping us to confirm that... | 23:47 |
| ctracey | My changes are on gerrit with more coming | 23:49 |
| ctracey | All linked via the etherpad | 23:49 |
| *** vivek-ebay has quit IRC | 23:52 | |
| *** sbfox1 has joined #openstack-lbaas | 23:53 | |
| *** sbfox has quit IRC | 23:53 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!