Friday, 2014-08-08

bloganwell that wouldn't standardize pecan, but it woudl be a standard library that can be used00:00
dougwiglbaas v2, coming to you in 2016.00:01
*** fnaval has quit IRC00:01
sbalukoff;_;00:01
bloganwell at least we got plenty of time00:01
*** fnaval has joined #openstack-lbaas00:01
sbalukoff*sigh*00:01
bloganwould yall be okay if lbaas v2 was always async no matter what driver is being used?00:02
sbalukoffI don't mind. But then, I suppose that's more a question for vendors. :)00:03
bloganahem dougwig00:03
dougwighum a few more bars, please.00:03
bloganahem ahem00:03
dougwiglol00:04
dougwigeither you're typing a long description of what you're thinking, or you should be.  :)00:06
bloganim not sure if dougwig is dodging the question, not answering, or writing a book about it00:06
bloganlol00:06
*** fnaval has quit IRC00:06
dougwigjinx!00:06
bloganwhat more do i need to add?00:06
bloganalways async, or the driver determines the synchronousity? (is that a word?)00:07
dougwigi think we talked about having every driver be an agent driver.  is that what you're referring to?  a few use cases have come up that make auto-statuses problematic, so that's less of an easy status solution than we were thinking earlier.00:07
dougwigor did you have another idea come up?00:07
bloganyeah thats what im talkinga bout essentially00:07
bloganokay what weret he use cases? if an entity causes another entity to error?00:08
dougwigthis is a kilo discussion, right?  (dougwig asks with fear)00:08
bloganwell who knows, pending further clarification about the incubation projects00:08
bloganits not somethign that will be done soon00:08
dougwigyes, if you're building the tree and have some non-fatal part unsupported, right now you can make it anyway, set status appropriately, then raise an exception.  that flexibility goes away.00:09
bloganbut something that shouldn't be done when its mature00:09
dougwigif the synchronous drivers don't gain anything but added operational complexity, then in general i don't see the point (they're still synchronous, even if we choose to make everyone use an async path.)  the interesting question is whether we need any agent drivers at all, once octavia is at play.00:10
bloganso currently if that happened, the driver would create everything supported but then set the specific entity to ERROR?00:10
dougwigand possibly raise Unsupported(), depending on how much they cared about notifying the user.00:11
dougwiglet me back up and raise a different point, which is that with the lack of a root object, this question and many others are making me rethink stephens? earlier proposal of just shoving down whole LB trees to drivers instead of objects.00:12
bloganmaybe im just trying to solve for something that no one cares about, but i just don't like the drivers having to worry about making db calls00:12
blogani'd be totally find with shoving entire lb trees down, i don't think many vendors would be fine with it00:12
dougwigradware builds them in their driver.  i'd be fine with it.  it's also something we could add as a v3 driver interface, and phase out v2, at which point we cleanup that code.00:13
blogani'd hate to come out with another driver interface soon00:14
dougwigthen the per-object status probably goes away, and some finer-grained status description comes back for LB.00:14
bloganand i'd be fine with that, i wanted taht in the beginning really, only status on the loadbalancer00:15
dougwigeh, it's not a user facing interface.   we'll be paralyzed if we can't try one out and then refactor it.00:15
bloganwell refactoring it would cause all the drivers to be refactored, and i'm not sure vendors would like having to refactor their drivers all the time00:15
sbalukoffI'm not sure that was my suggestion originally, but I'll totally take credit. ;)00:15
sbalukoffI don't think it's necessarily "all the time"00:16
dougwigeh, they have to maintain them "all the time" anyway.  tis, l7, etc.00:16
sbalukoffOnce we get the v2 model, we're only adding smaller componenet to it.00:16
bloganwell our v1.0 lbaas project here at rackspace takes the entire lbaas tree, but we've only got one create call and tahts creating the entire lbaas tree in one call00:16
dougwig(until the v3 model.  hahahahahaha.)00:16
sbalukoffcomponents00:16
*** vivek-ebay has joined #openstack-lbaas00:17
bloganam i missing why you keep saying tis instead of tls?00:17
sbalukoffOk, true-- supporting additional features means adding to the model.00:17
dougwigone of two things happens today: 1) we redo what we have in juno, and pray the churn doesn't screw us all over, 2) we ship what we've got, stop worrying about it, realize we'll make some mistakes, but that this train has left the station, and we WILL make it better next time.00:17
dougwigblogan: sorry, it's likely autocorrect00:18
sbalukoffdougwig: I demand perfection before release.00:18
sbalukoffOr not.00:18
dougwigi'm gonna vote for 2.00:18
bloganwell i hope we don't redo what we have in juno00:18
sbalukoffSorry, sarcasm again.00:18
blogani forget you're probably on a phone dougwig00:18
dougwigsbalukoff: i took it as a joke.00:18
blogansbalukoff: you will be disappointed with octavia with that demand00:19
dougwigif we do change this, i'm changing out project name to "duke nukem forever".00:20
dougwig /out/our/00:20
sbalukoffHaha!00:21
dougwigblogan: i'd say leave it to the drivers for juno.  we can clean it up later by just null'ing out the manager helpers.00:21
sbalukoffSpeaking of which, I need to get back to working on this v0.5 design doc...00:21
dougwigi don't like the drivers calling query(), but manager helpers don't bother me at all.00:22
bloganalright well i gotta go home00:24
bloganim sure ill be on later00:24
dougwiglatr00:27
*** sbfox has joined #openstack-lbaas00:29
rm_workhttps://review.openstack.org/#/c/107845/00:40
rm_workMAYBE the last patch00:40
rm_work:P00:40
rm_work(also its dependency)00:40
sbalukoffHeh!00:51
*** rm_you has joined #openstack-lbaas00:52
*** mlavalle has quit IRC01:04
*** ptoohill1 has joined #openstack-lbaas01:29
*** ptoohill1 has quit IRC01:30
*** ptoohill1 has joined #openstack-lbaas01:30
*** ptoohill1 has quit IRC01:55
*** vivek-ebay has quit IRC01:57
sbfoxHey dougwig!02:11
dougwigsbfox: are you wanting to move everything to another server, or just one load balancer?02:11
dougwighiya02:11
sbfoxjust one haproxy02:12
sbfoxim assuming multiple neutrons can be in the same l3 subnet?02:12
dougwigyes.02:12
dougwigare any of our haproxy denizens around?  blogan was just here.02:13
dougwighang on, i'm double-checking, since the haproxy guys aren't here anymore.02:18
sbfoxokies02:18
*** fnaval has joined #openstack-lbaas02:23
dougwigok, this is not terribly pleasant, but you can run multiple lbaas agents on different servers.  when you create an lb, it gets randomly assigned to an agent host.  if you want to move it, you have to manually move the haproxy files and update the PoolLoadbalancerAgentBinding table that contains the location of that lb's agent.02:24
dougwigis it possible to delete and re-create?02:25
dougwigi am not finding a way to update via the api, unless i'm missing it.02:34
*** sbalukoff has quit IRC02:36
*** vivek-ebay has joined #openstack-lbaas02:42
*** sbfox has quit IRC02:44
*** fnaval has quit IRC02:50
*** fnaval has joined #openstack-lbaas02:50
*** fnaval has quit IRC02:55
*** sbfox has joined #openstack-lbaas03:17
*** fnaval has joined #openstack-lbaas03:28
*** vivek-ebay has quit IRC03:34
*** vivek-ebay has joined #openstack-lbaas03:35
sbfoxThanks for figuring that out dougwig, ill be trying that tomorrow :)04:06
*** fnaval has quit IRC04:16
*** fnaval has joined #openstack-lbaas04:16
*** vjay has joined #openstack-lbaas04:46
*** fnaval has quit IRC05:24
*** fnaval has joined #openstack-lbaas05:25
*** fnaval has quit IRC05:30
*** crc32 has quit IRC06:50
*** vivek-ebay has quit IRC07:07
*** vjay has quit IRC07:08
*** sbalukoff has joined #openstack-lbaas07:19
*** sbfox has quit IRC08:15
*** vjay has joined #openstack-lbaas08:29
*** vjay has quit IRC08:34
*** Youcef_ has joined #openstack-lbaas10:20
*** sbalukoff1 has joined #openstack-lbaas10:21
*** Youcef has quit IRC10:23
*** sbalukoff has quit IRC10:23
*** enikanorov has quit IRC12:05
*** vjay has joined #openstack-lbaas12:36
*** rolledback has joined #openstack-lbaas12:41
*** rolledback has quit IRC12:42
*** rolledback has joined #openstack-lbaas12:43
*** vjay has quit IRC12:57
*** fnaval has joined #openstack-lbaas13:04
*** vjay has joined #openstack-lbaas13:06
*** rolledback has quit IRC13:27
*** vjay has quit IRC13:50
*** rolledback has joined #openstack-lbaas13:53
*** rolledback has quit IRC13:58
*** fnaval has quit IRC14:02
*** rolledback has joined #openstack-lbaas14:11
*** fnaval has joined #openstack-lbaas14:26
*** enikanorov has joined #openstack-lbaas14:30
*** rolledback has quit IRC14:36
*** rolledback has joined #openstack-lbaas14:46
*** rolledback has quit IRC14:51
*** rolledback has joined #openstack-lbaas14:51
*** sbfox has joined #openstack-lbaas14:56
*** markmcclain has joined #openstack-lbaas14:58
*** sbfox has quit IRC14:59
*** sbfox has joined #openstack-lbaas14:59
*** sbfox has quit IRC15:03
*** rolledback has quit IRC15:06
ptoohillmornin'15:16
*** rolledback has joined #openstack-lbaas15:16
rm_workmornin'15:17
*** xgerman has joined #openstack-lbaas15:25
*** xgerman has quit IRC15:26
*** Youcef_ has quit IRC15:29
dougwigmorning15:33
*** xgerman has joined #openstack-lbaas15:39
*** BBG_Stephen has joined #openstack-lbaas15:59
*** sbalukoff1 has quit IRC16:01
rm_workhttps://review.openstack.org/#/c/107845/16:13
rm_workmore +1s again please :P16:13
johnsomrm_work I will take a look this morning16:14
rm_work:)16:14
rm_workthis change was already workflowed once, but got blocked due to a tempest testing issue (not related to the change)16:15
rm_workif that helps :P16:15
dougwigi'll +1 if you admit that you're really a bot that just repeats "recheck no bug"16:17
rm_workheh16:17
rm_workwell, I *finally* fixed the root cause16:17
rm_workhttps://review.openstack.org/#/c/112735/16:17
rm_workfreaking uWSGI bug16:18
dougwigrm_work: seriously, i hadn't +1'ed because i had a question about the uwsgi fix16:18
rm_worklame workaround16:18
rm_workheh16:18
dougwigis that fix for dev use only?16:18
rm_workyeah, uwsgi is only used for devstack16:18
rm_worki hope to god no one would use it or those configs in production O_o16:18
dougwigbecause if so, and it's in an INI file, it WILL end up in production everywhere.16:18
rm_workthose configs are already super borked for production use16:18
rm_workthey're set up to be single-threaded16:19
rm_workand use no keystone auth16:19
rm_worklol16:19
dougwigare you going to communicate to packstack/heat/ooo/and the million orchestrators out there to remove it?  what about the hand install guide, which is already absurdly long?16:19
rm_worki mean, no one should ever use uWSGI in production at all16:19
rm_workit's really not a good webserver <_<16:19
rm_workand technically it will still "work fine" in production, it just won't allow persistent connections (which I think python-barbicanclient tries to use, but falls back to individual connections fine)16:21
rm_worklet's just say that if they're using those configs and uWSGI in production, this is the LEAST of their problems16:21
*** jorgem has joined #openstack-lbaas16:22
dougwigheh.16:24
rm_workso yeah, +1 plox :P16:26
dougwigi'm not +1's the wsgi change, since i don't think dev settings should be checked in (but rather, devstack should set them), but it doesn't look like you need my review there.  standby on the real review.16:27
rm_workdougwig: well, the problem is that the devstack configs are inside the barbican repo16:28
rm_workin their entirety16:28
rm_workthere is nowhere else to put them16:28
dougwigas someone that has installed openstack by hand far too many times (i.e. more than once), i'm used to adding keystone, configuring the db connection, and then any project specific stuff.  i do NOT go hunting for things like persistent connections being turned off.  if the default install that the major distributions use does not use uwsgi, no big.  if they16:30
dougwigdo, it will get misused in the field.16:30
dougwigwon't be fatal, just annoying, but it's a bad precedent.16:30
rm_worki mean, I wish our devstack stuff was IN DEVSTACK but it isn't16:31
xgermanI disagree on uwsgi production readiness...16:33
dougwigso, umm, move it?16:33
rm_workdougwig: lol, you say that16:33
rm_workI will suggest it16:33
rm_workxgerman: O_o16:34
dougwigi can say it on the review if you like.  i don't mind being the fall guy.  or being wrong a lot.16:34
rm_workdougwig: i mean, that one is already merged16:34
rm_workand your comment wouldn't make sense on the consumer reg CR16:34
rm_work:P16:34
xgermanyeah, but you can still -1 it - after the fact16:34
rm_worklol16:34
rm_workwell, I don't think anyone disagreed that it was a hack, but they also all agreed it should be fine for the time being before we move away from uWSGI altogether16:35
xgermanwell, be it as it may. Most of those Python web servers need to be behind some nginx, ssl offloaded, etc to scale - so uwsgi or not doesn't really matter...16:37
*** rolledback has quit IRC16:37
dougwigxgerman: for lightweight GET requests, that kind of change will seriously affect scalability, even with a front-end reverse proxy.16:38
xgermanI am more respomding to rm_work's blamket statement "no one should ever use uWSGI in production at all16:39
xgerman it's really not a good webserver"16:39
xgermanI looked at all of that python stuff and uwsgi is one of the better ones...16:40
*** rolledback has joined #openstack-lbaas16:42
*** mlavalle has joined #openstack-lbaas16:45
*** mlavalle_ has joined #openstack-lbaas16:48
*** vjay has joined #openstack-lbaas16:48
rm_workyou wouldn't want to go with something like mod_uwsgi?16:48
*** sbfox has joined #openstack-lbaas16:48
dougwigapache is so 90's.16:50
dougwig:)16:50
*** mlavalle has quit IRC16:50
*** mlavalle_ is now known as mlavalle16:50
dougwighaven't played with the event mpm, so they might've fixed it's scalability issues.16:50
*** rolledback has quit IRC16:51
*** sbfox has quit IRC16:58
*** fnaval has quit IRC17:06
*** fnaval has joined #openstack-lbaas17:07
dougwigctracey: your 3rd cli review needs an automatic rebase.17:07
*** sbfox has joined #openstack-lbaas17:10
*** fnaval has quit IRC17:11
*** fnaval has joined #openstack-lbaas17:29
*** markmcclain has quit IRC17:30
*** sbfox1 has joined #openstack-lbaas17:33
*** sbfox has quit IRC17:35
*** vivek-ebay has joined #openstack-lbaas17:53
*** vjay has quit IRC17:55
*** fnaval has quit IRC17:55
*** fnaval has joined #openstack-lbaas17:56
*** sbfox1 has quit IRC17:58
*** sbfox has joined #openstack-lbaas17:59
*** fnaval has quit IRC18:00
*** rolledback has joined #openstack-lbaas18:05
*** rolledback has quit IRC18:17
bloganping dougwig18:23
dougwigAt lunch, but here18:23
blogandougwig: it can wait till you get done18:24
dougwigOk.  15 mins.18:25
*** VijayB has joined #openstack-lbaas18:41
rm_work[12:52:03]  <openstackgerrit> A change was merged to openstack/barbican: Add support to Barbican for consumer registration  https://review.openstack.org/10784518:47
rm_workwhat what18:48
dougwigblogan: here, what's up?18:52
*** rolledback has joined #openstack-lbaas18:59
*** rolledback has quit IRC18:59
*** rolledback has joined #openstack-lbaas19:00
*** rolledback has quit IRC19:07
TrevorVI'm unable to "./stack.sh" in devstack, anyone else seeing issues?19:10
*** fnaval has joined #openstack-lbaas19:10
*** rolledback has joined #openstack-lbaas19:21
*** jorgem1 has joined #openstack-lbaas19:22
*** jorgem has quit IRC19:22
blogandougwig: what are you looking for in the managers to call fail?19:26
bloganfor the entity to be set to status?19:26
bloganset to error status i mean19:26
dougwigyes, to call manager.failed(reason_str)19:27
dougwigsorry, i mean manager.failed(context, id)19:27
dougwigso ERROR19:27
bloganwell the plugin will automatically set it to error if an exception is not caught in the driver19:28
dougwigcurrently, you're just leaving it in deferred, even though you know it'll never succeed.  it's done at that point.19:28
dougwigi thought we removed that?19:28
blogannot the error piece19:28
bloganthe automatic activate19:28
bloganits more just a failsafe19:28
dougwigdoesn't that break the use case that came up the other day?  where you want to throw unsupported in order to give some status to the user, but set the core parts to active?19:29
rm_workxgerman: for the record, one of the main uwsgi guys was just a bit concerned that I expose uwsgi directly to the internet :P19:30
rm_workor at least, very surprised :P19:30
bloganit will only set the particular entity to ERROR19:30
blogannot the entire tree19:30
dougwigright, but if it's an LB, and it's the last object, and a health monitor down the deferred tree fails for some minor reason...19:31
dougwigyou've just forced an ERROR on the lb that the driver may not agree with.19:31
bloganahh19:31
bloganso if say a health monitor has been created, and when the driver tries to link in that health monitor, that particular configuration of health monitor and load balancer is not supported, but the driver still wants to have the load balancer functioning19:32
dougwigyes, exactly that.19:32
*** jorgem1 has quit IRC19:33
dougwigthat was my understanding of vjay's use case, anyway.19:33
bloganwell its still possible, they'd just have to catch the exception in the driver, but thats not the best way19:33
bloganthey'd have to do that everywhere and tahts just dumb19:33
dougwigyeah, i had been pondering that, and that gets hella messy, hella fast.19:34
dougwigeasier to make the plugin dumber.19:34
bloganwell then again, they still need to catch exceptions19:34
bloganso what if the driver doesn't catch an exception and it remains uncaught and the loadbalancer isn't functioning but says ACTIVE19:34
xgermanrm_work -- yes all those python things prefer to run behind some niginx,19:34
bloganand by that i mean the entire tree says ACTIVE19:35
bloganis it just the fault of the driver then?19:35
bloganand blame it on the driver19:35
bloganwhich isn't a good user experience, no matter where the fault lies19:35
dougwigthis is really around Unsupported() exceptions, and how to distinguish the ones that are fatal and the ones that are not.  i wonder if we should add two exceptions for that, and standardize.19:35
dougwigthen you can not-catch the non-fatal ones.19:36
bloganyeah19:36
bloganthats what i was leading into19:36
dougwigi agree.  i wonder if that's not a kilo thing, and we should live with drivers dealing with it in juno.19:36
bloganadn similar to how I was going to solve other issues if we ever decided to revisit the driver not making db calls at all19:36
dougwigi agree with that approach.  what should we put in place now?19:37
bloganwe could have a LoadBalancerException, ListenerException, PoolException, MemberException, HealthMonitorException, and whichever one is thrown that entity gets set to error19:38
dougwigwhat if i have multiples.  :)19:38
blogani knew you were going there19:38
dougwigwe're rapidly heading back to passing down trees, because i think that's the right interface.19:38
bloganthen we have a generic EntityException with instance booleans for the entities19:38
rm_work[14:36:07]  <unbit> Connection: close handlign requires parsing the output (so it will be slower)19:39
rm_work[14:36:32]  <unbit> i still think that adding connection close with —add-header (or the routing subsystem) will be better for your case19:39
bloganwell i think it makes many things simpler, but I know there will be people who do not agree19:39
rm_workso, there we have it. use add-header=19:40
dougwigok, circle back.  our plan of record is still juno, so we need a juno plan for the short-term.19:40
dougwigunless you're suggesting we re-design this for juno, which i know you're not.  :)19:41
dougwigi hope.19:41
dougwigoh man, you're scaring me with this long pause.  either you're up getting coffee, or there's a novel headed my way.19:43
bloganyes!19:43
bloganredesign everything!19:43
blogansorry was distracted by jorge19:43
bloganhe's very good at that19:43
bloganbut no im fine with leaving it how it is and adding it in later19:43
bloganunless this whole experimental extension thing happens and we're not subject to code freeze then we can discuss it further19:43
dougwigoh heck yes.19:44
bloganis that a sarcastic "oh heck yes" or a "oh yeah didn't think about that, oh heck yes"19:45
*** jorgem has joined #openstack-lbaas19:46
openstackgerritA change was merged to stackforge/octavia: Documenting project direction and design  https://review.openstack.org/11056319:46
dougwigit's whole-hearted agreement that if the structure of the project changes, we can skip some of this process related short-term hackery.19:47
bloganok great19:48
*** rolledback has quit IRC19:55
rm_workdougwig / xgerman:20:05
rm_work[15:04:03]  <rm_work> so basically, uWSGI is not intended to be operated without another proxy?20:05
rm_work[15:04:12]  <rm_work> and by itself is not RFC compliant20:05
rm_work[15:04:17]  <unbit> yes for sure20:05
rm_work[15:04:25]  <unbit> as well gunicorn is not expected to be put on the public network20:05
rm_work[15:04:34]  <unbit> as well as basically every application server20:05
rm_workso there's that.20:05
xgermanyep, but from all the python stuff I think uwsgi is one of the better ones :-)20:06
rm_work[15:06:41]  <rm_work> so you would never recommend we expose uWSGI directly20:06
rm_work[15:06:48]  <unbit> absolutely20:06
rm_workyeah T_T20:06
xgermanfor the really scalable websites we have Java, and for the Rest RoR... (or you get a compiler team to invent your own language/make PhP better)20:07
rm_workdougwig: does that answer your concerns at all? :P20:07
rm_workxgerman: yeah ok, but "one of the best" of "a bunch of bad options" is not great :P20:07
xgermandon't even try HTTP chunked with those (u)wsgi jokers20:09
xgerman<rant>you would think in order to be a web server you would support the HTTP standard </rant>20:09
bloganno ranting allowed20:10
xgermaneven if I mark it clearly :-)20:10
bloganeven if you mark it clearly in xml!20:10
bloganespecially xml!20:10
rm_worklol20:10
bloganshoudla done json, it would have been more poignant20:10
rm_workjust wanted to see if that made dougwig any more comfortable with my change earlier :P20:11
*** rolledback has joined #openstack-lbaas20:17
*** openstackgerrit has quit IRC20:20
*** rolledback has quit IRC20:24
*** markmcclain has joined #openstack-lbaas20:25
ctraceydougwig: is there a reason you -1'd me?20:25
rm_workctracey: it's his way of showing affection20:27
ctraceymaybe20:27
ctraceybut some context could help :)20:27
rm_workI believe he said as much earlier :P20:27
ctraceyoh the rebase?20:28
ctraceyim confused as to why that is a -1, but still20:30
dougwigno, it was for the comment.20:32
dougwigsec, on a call.20:32
ctraceythere is no comment20:33
dougwignuts, it's on patch set 1, but still applies.  sec.20:34
dougwigupdated20:34
ctraceydougwig: updated20:44
*** rolledback has joined #openstack-lbaas20:50
*** rolledback has quit IRC20:55
*** vivek-ebay has quit IRC20:55
*** vivek-ebay has joined #openstack-lbaas20:55
*** vivek-ebay has quit IRC20:59
dougwigctracey: sorry for the delay.  so, your review should be about 10 lines, but for all the parent_id stuff.  who asked for it to be broken out?21:03
ctraceydougwig: akihiro in the 3rd one21:03
ctraceyfirst patch set21:04
ctraceyin client.py iirc21:04
*** vivek-ebay has joined #openstack-lbaas21:04
dougwigahh, i was viewing this patch on its own merits.  can't say as i agree with that feedback, but ok.21:05
ctraceydougwig: im indifferent just need one or the other. agree it would be nice to squash it into params21:06
dougwigthere you go.21:26
dougwigrm_work: nginx + uwsgi isn't one of the best of bad options.  nginx + unicorn is one of the best deployment models for RoR, and it's a similar architecture.21:28
dougwigseriously, it's ok.  :)21:28
rm_workheh21:34
rm_workdougwig: was referring to running them all by themselves21:34
dougwigno one does that, that's insane.21:34
rm_workright :P21:36
rm_workexcept Barbican21:36
rm_workthey do that21:37
rm_workT_T21:37
*** ptoohill1 has joined #openstack-lbaas21:45
*** fnaval has quit IRC21:55
*** fnaval has joined #openstack-lbaas21:56
*** fnaval has quit IRC22:00
*** fnaval has joined #openstack-lbaas22:13
ctraceyindeed they do22:24
ctraceyfound that out the hard way22:24
rm_workoh, current barbican looks to have a bug preventing my from retrieving decrypted secrets T_T22:26
rm_workat least locally22:26
rm_workI hope it doesn't affect real deployments <_<22:26
*** crc32 has joined #openstack-lbaas22:31
*** jorgem has quit IRC22:35
*** openstackgerrit has joined #openstack-lbaas22:39
*** mlavalle has quit IRC23:03
*** ptoohill1 has quit IRC23:39
*** markmcclain has quit IRC23:46

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!