blogan | well that wouldn't standardize pecan, but it woudl be a standard library that can be used | 00:00 |
---|---|---|
dougwig | lbaas v2, coming to you in 2016. | 00:01 |
*** fnaval has quit IRC | 00:01 | |
sbalukoff | ;_; | 00:01 |
blogan | well at least we got plenty of time | 00:01 |
*** fnaval has joined #openstack-lbaas | 00:01 | |
sbalukoff | *sigh* | 00:01 |
blogan | would yall be okay if lbaas v2 was always async no matter what driver is being used? | 00:02 |
sbalukoff | I don't mind. But then, I suppose that's more a question for vendors. :) | 00:03 |
blogan | ahem dougwig | 00:03 |
dougwig | hum a few more bars, please. | 00:03 |
blogan | ahem ahem | 00:03 |
dougwig | lol | 00:04 |
dougwig | either you're typing a long description of what you're thinking, or you should be. :) | 00:06 |
blogan | im not sure if dougwig is dodging the question, not answering, or writing a book about it | 00:06 |
blogan | lol | 00:06 |
*** fnaval has quit IRC | 00:06 | |
dougwig | jinx! | 00:06 |
blogan | what more do i need to add? | 00:06 |
blogan | always async, or the driver determines the synchronousity? (is that a word?) | 00:07 |
dougwig | i 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 |
dougwig | or did you have another idea come up? | 00:07 |
blogan | yeah thats what im talkinga bout essentially | 00:07 |
blogan | okay what weret he use cases? if an entity causes another entity to error? | 00:08 |
dougwig | this is a kilo discussion, right? (dougwig asks with fear) | 00:08 |
blogan | well who knows, pending further clarification about the incubation projects | 00:08 |
blogan | its not somethign that will be done soon | 00:08 |
dougwig | yes, 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 |
blogan | but something that shouldn't be done when its mature | 00:09 |
dougwig | if 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 |
blogan | so currently if that happened, the driver would create everything supported but then set the specific entity to ERROR? | 00:10 |
dougwig | and possibly raise Unsupported(), depending on how much they cared about notifying the user. | 00:11 |
dougwig | let 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 |
blogan | maybe 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 calls | 00:12 |
blogan | i'd be totally find with shoving entire lb trees down, i don't think many vendors would be fine with it | 00:12 |
dougwig | radware 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 |
blogan | i'd hate to come out with another driver interface soon | 00:14 |
dougwig | then the per-object status probably goes away, and some finer-grained status description comes back for LB. | 00:14 |
blogan | and i'd be fine with that, i wanted taht in the beginning really, only status on the loadbalancer | 00:15 |
dougwig | eh, it's not a user facing interface. we'll be paralyzed if we can't try one out and then refactor it. | 00:15 |
blogan | well 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 time | 00:15 |
sbalukoff | I'm not sure that was my suggestion originally, but I'll totally take credit. ;) | 00:15 |
sbalukoff | I don't think it's necessarily "all the time" | 00:16 |
dougwig | eh, they have to maintain them "all the time" anyway. tis, l7, etc. | 00:16 |
sbalukoff | Once we get the v2 model, we're only adding smaller componenet to it. | 00:16 |
blogan | well 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 call | 00:16 |
dougwig | (until the v3 model. hahahahahaha.) | 00:16 |
sbalukoff | components | 00:16 |
*** vivek-ebay has joined #openstack-lbaas | 00:17 | |
blogan | am i missing why you keep saying tis instead of tls? | 00:17 |
sbalukoff | Ok, true-- supporting additional features means adding to the model. | 00:17 |
dougwig | one 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 |
dougwig | blogan: sorry, it's likely autocorrect | 00:18 |
sbalukoff | dougwig: I demand perfection before release. | 00:18 |
sbalukoff | Or not. | 00:18 |
dougwig | i'm gonna vote for 2. | 00:18 |
blogan | well i hope we don't redo what we have in juno | 00:18 |
sbalukoff | Sorry, sarcasm again. | 00:18 |
blogan | i forget you're probably on a phone dougwig | 00:18 |
dougwig | sbalukoff: i took it as a joke. | 00:18 |
blogan | sbalukoff: you will be disappointed with octavia with that demand | 00:19 |
dougwig | if we do change this, i'm changing out project name to "duke nukem forever". | 00:20 |
dougwig | /out/our/ | 00:20 |
sbalukoff | Haha! | 00:21 |
dougwig | blogan: 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 |
sbalukoff | Speaking of which, I need to get back to working on this v0.5 design doc... | 00:21 |
dougwig | i don't like the drivers calling query(), but manager helpers don't bother me at all. | 00:22 |
blogan | alright well i gotta go home | 00:24 |
blogan | im sure ill be on later | 00:24 |
dougwig | latr | 00:27 |
*** sbfox has joined #openstack-lbaas | 00:29 | |
rm_work | https://review.openstack.org/#/c/107845/ | 00:40 |
rm_work | MAYBE the last patch | 00:40 |
rm_work | :P | 00:40 |
rm_work | (also its dependency) | 00:40 |
sbalukoff | Heh! | 00:51 |
*** rm_you has joined #openstack-lbaas | 00:52 | |
*** mlavalle has quit IRC | 01:04 | |
*** ptoohill1 has joined #openstack-lbaas | 01:29 | |
*** ptoohill1 has quit IRC | 01:30 | |
*** ptoohill1 has joined #openstack-lbaas | 01:30 | |
*** ptoohill1 has quit IRC | 01:55 | |
*** vivek-ebay has quit IRC | 01:57 | |
sbfox | Hey dougwig! | 02:11 |
dougwig | sbfox: are you wanting to move everything to another server, or just one load balancer? | 02:11 |
dougwig | hiya | 02:11 |
sbfox | just one haproxy | 02:12 |
sbfox | im assuming multiple neutrons can be in the same l3 subnet? | 02:12 |
dougwig | yes. | 02:12 |
dougwig | are any of our haproxy denizens around? blogan was just here. | 02:13 |
dougwig | hang on, i'm double-checking, since the haproxy guys aren't here anymore. | 02:18 |
sbfox | okies | 02:18 |
*** fnaval has joined #openstack-lbaas | 02:23 | |
dougwig | ok, 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 |
dougwig | is it possible to delete and re-create? | 02:25 |
dougwig | i am not finding a way to update via the api, unless i'm missing it. | 02:34 |
*** sbalukoff has quit IRC | 02:36 | |
*** vivek-ebay has joined #openstack-lbaas | 02:42 | |
*** sbfox has quit IRC | 02:44 | |
*** fnaval has quit IRC | 02:50 | |
*** fnaval has joined #openstack-lbaas | 02:50 | |
*** fnaval has quit IRC | 02:55 | |
*** sbfox has joined #openstack-lbaas | 03:17 | |
*** fnaval has joined #openstack-lbaas | 03:28 | |
*** vivek-ebay has quit IRC | 03:34 | |
*** vivek-ebay has joined #openstack-lbaas | 03:35 | |
sbfox | Thanks for figuring that out dougwig, ill be trying that tomorrow :) | 04:06 |
*** fnaval has quit IRC | 04:16 | |
*** fnaval has joined #openstack-lbaas | 04:16 | |
*** vjay has joined #openstack-lbaas | 04:46 | |
*** fnaval has quit IRC | 05:24 | |
*** fnaval has joined #openstack-lbaas | 05:25 | |
*** fnaval has quit IRC | 05:30 | |
*** crc32 has quit IRC | 06:50 | |
*** vivek-ebay has quit IRC | 07:07 | |
*** vjay has quit IRC | 07:08 | |
*** sbalukoff has joined #openstack-lbaas | 07:19 | |
*** sbfox has quit IRC | 08:15 | |
*** vjay has joined #openstack-lbaas | 08:29 | |
*** vjay has quit IRC | 08:34 | |
*** Youcef_ has joined #openstack-lbaas | 10:20 | |
*** sbalukoff1 has joined #openstack-lbaas | 10:21 | |
*** Youcef has quit IRC | 10:23 | |
*** sbalukoff has quit IRC | 10:23 | |
*** enikanorov has quit IRC | 12:05 | |
*** vjay has joined #openstack-lbaas | 12:36 | |
*** rolledback has joined #openstack-lbaas | 12:41 | |
*** rolledback has quit IRC | 12:42 | |
*** rolledback has joined #openstack-lbaas | 12:43 | |
*** vjay has quit IRC | 12:57 | |
*** fnaval has joined #openstack-lbaas | 13:04 | |
*** vjay has joined #openstack-lbaas | 13:06 | |
*** rolledback has quit IRC | 13:27 | |
*** vjay has quit IRC | 13:50 | |
*** rolledback has joined #openstack-lbaas | 13:53 | |
*** rolledback has quit IRC | 13:58 | |
*** fnaval has quit IRC | 14:02 | |
*** rolledback has joined #openstack-lbaas | 14:11 | |
*** fnaval has joined #openstack-lbaas | 14:26 | |
*** enikanorov has joined #openstack-lbaas | 14:30 | |
*** rolledback has quit IRC | 14:36 | |
*** rolledback has joined #openstack-lbaas | 14:46 | |
*** rolledback has quit IRC | 14:51 | |
*** rolledback has joined #openstack-lbaas | 14:51 | |
*** sbfox has joined #openstack-lbaas | 14:56 | |
*** markmcclain has joined #openstack-lbaas | 14:58 | |
*** sbfox has quit IRC | 14:59 | |
*** sbfox has joined #openstack-lbaas | 14:59 | |
*** sbfox has quit IRC | 15:03 | |
*** rolledback has quit IRC | 15:06 | |
ptoohill | mornin' | 15:16 |
*** rolledback has joined #openstack-lbaas | 15:16 | |
rm_work | mornin' | 15:17 |
*** xgerman has joined #openstack-lbaas | 15:25 | |
*** xgerman has quit IRC | 15:26 | |
*** Youcef_ has quit IRC | 15:29 | |
dougwig | morning | 15:33 |
*** xgerman has joined #openstack-lbaas | 15:39 | |
*** BBG_Stephen has joined #openstack-lbaas | 15:59 | |
*** sbalukoff1 has quit IRC | 16:01 | |
rm_work | https://review.openstack.org/#/c/107845/ | 16:13 |
rm_work | more +1s again please :P | 16:13 |
johnsom | rm_work I will take a look this morning | 16:14 |
rm_work | :) | 16:14 |
rm_work | this change was already workflowed once, but got blocked due to a tempest testing issue (not related to the change) | 16:15 |
rm_work | if that helps :P | 16:15 |
dougwig | i'll +1 if you admit that you're really a bot that just repeats "recheck no bug" | 16:17 |
rm_work | heh | 16:17 |
rm_work | well, I *finally* fixed the root cause | 16:17 |
rm_work | https://review.openstack.org/#/c/112735/ | 16:17 |
rm_work | freaking uWSGI bug | 16:18 |
dougwig | rm_work: seriously, i hadn't +1'ed because i had a question about the uwsgi fix | 16:18 |
rm_work | lame workaround | 16:18 |
rm_work | heh | 16:18 |
dougwig | is that fix for dev use only? | 16:18 |
rm_work | yeah, uwsgi is only used for devstack | 16:18 |
rm_work | i hope to god no one would use it or those configs in production O_o | 16:18 |
dougwig | because if so, and it's in an INI file, it WILL end up in production everywhere. | 16:18 |
rm_work | those configs are already super borked for production use | 16:18 |
rm_work | they're set up to be single-threaded | 16:19 |
rm_work | and use no keystone auth | 16:19 |
rm_work | lol | 16:19 |
dougwig | are 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_work | i mean, no one should ever use uWSGI in production at all | 16:19 |
rm_work | it's really not a good webserver <_< | 16:19 |
rm_work | and 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_work | let's just say that if they're using those configs and uWSGI in production, this is the LEAST of their problems | 16:21 |
*** jorgem has joined #openstack-lbaas | 16:22 | |
dougwig | heh. | 16:24 |
rm_work | so yeah, +1 plox :P | 16:26 |
dougwig | i'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_work | dougwig: well, the problem is that the devstack configs are inside the barbican repo | 16:28 |
rm_work | in their entirety | 16:28 |
rm_work | there is nowhere else to put them | 16:28 |
dougwig | as 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 they | 16:30 |
dougwig | do, it will get misused in the field. | 16:30 |
dougwig | won't be fatal, just annoying, but it's a bad precedent. | 16:30 |
rm_work | i mean, I wish our devstack stuff was IN DEVSTACK but it isn't | 16:31 |
xgerman | I disagree on uwsgi production readiness... | 16:33 |
dougwig | so, umm, move it? | 16:33 |
rm_work | dougwig: lol, you say that | 16:33 |
rm_work | I will suggest it | 16:33 |
rm_work | xgerman: O_o | 16:34 |
dougwig | i 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_work | dougwig: i mean, that one is already merged | 16:34 |
rm_work | and your comment wouldn't make sense on the consumer reg CR | 16:34 |
rm_work | :P | 16:34 |
xgerman | yeah, but you can still -1 it - after the fact | 16:34 |
rm_work | lol | 16:34 |
rm_work | well, 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 altogether | 16:35 |
xgerman | well, 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 IRC | 16:37 | |
dougwig | xgerman: for lightweight GET requests, that kind of change will seriously affect scalability, even with a front-end reverse proxy. | 16:38 |
xgerman | I am more respomding to rm_work's blamket statement "no one should ever use uWSGI in production at all | 16:39 |
xgerman | it's really not a good webserver" | 16:39 |
xgerman | I looked at all of that python stuff and uwsgi is one of the better ones... | 16:40 |
*** rolledback has joined #openstack-lbaas | 16:42 | |
*** mlavalle has joined #openstack-lbaas | 16:45 | |
*** mlavalle_ has joined #openstack-lbaas | 16:48 | |
*** vjay has joined #openstack-lbaas | 16:48 | |
rm_work | you wouldn't want to go with something like mod_uwsgi? | 16:48 |
*** sbfox has joined #openstack-lbaas | 16:48 | |
dougwig | apache is so 90's. | 16:50 |
dougwig | :) | 16:50 |
*** mlavalle has quit IRC | 16:50 | |
*** mlavalle_ is now known as mlavalle | 16:50 | |
dougwig | haven't played with the event mpm, so they might've fixed it's scalability issues. | 16:50 |
*** rolledback has quit IRC | 16:51 | |
*** sbfox has quit IRC | 16:58 | |
*** fnaval has quit IRC | 17:06 | |
*** fnaval has joined #openstack-lbaas | 17:07 | |
dougwig | ctracey: your 3rd cli review needs an automatic rebase. | 17:07 |
*** sbfox has joined #openstack-lbaas | 17:10 | |
*** fnaval has quit IRC | 17:11 | |
*** fnaval has joined #openstack-lbaas | 17:29 | |
*** markmcclain has quit IRC | 17:30 | |
*** sbfox1 has joined #openstack-lbaas | 17:33 | |
*** sbfox has quit IRC | 17:35 | |
*** vivek-ebay has joined #openstack-lbaas | 17:53 | |
*** vjay has quit IRC | 17:55 | |
*** fnaval has quit IRC | 17:55 | |
*** fnaval has joined #openstack-lbaas | 17:56 | |
*** sbfox1 has quit IRC | 17:58 | |
*** sbfox has joined #openstack-lbaas | 17:59 | |
*** fnaval has quit IRC | 18:00 | |
*** rolledback has joined #openstack-lbaas | 18:05 | |
*** rolledback has quit IRC | 18:17 | |
blogan | ping dougwig | 18:23 |
dougwig | At lunch, but here | 18:23 |
blogan | dougwig: it can wait till you get done | 18:24 |
dougwig | Ok. 15 mins. | 18:25 |
*** VijayB has joined #openstack-lbaas | 18: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/107845 | 18:47 |
rm_work | what what | 18:48 |
dougwig | blogan: here, what's up? | 18:52 |
*** rolledback has joined #openstack-lbaas | 18:59 | |
*** rolledback has quit IRC | 18:59 | |
*** rolledback has joined #openstack-lbaas | 19:00 | |
*** rolledback has quit IRC | 19:07 | |
TrevorV | I'm unable to "./stack.sh" in devstack, anyone else seeing issues? | 19:10 |
*** fnaval has joined #openstack-lbaas | 19:10 | |
*** rolledback has joined #openstack-lbaas | 19:21 | |
*** jorgem1 has joined #openstack-lbaas | 19:22 | |
*** jorgem has quit IRC | 19:22 | |
blogan | dougwig: what are you looking for in the managers to call fail? | 19:26 |
blogan | for the entity to be set to status? | 19:26 |
blogan | set to error status i mean | 19:26 |
dougwig | yes, to call manager.failed(reason_str) | 19:27 |
dougwig | sorry, i mean manager.failed(context, id) | 19:27 |
dougwig | so ERROR | 19:27 |
blogan | well the plugin will automatically set it to error if an exception is not caught in the driver | 19:28 |
dougwig | currently, you're just leaving it in deferred, even though you know it'll never succeed. it's done at that point. | 19:28 |
dougwig | i thought we removed that? | 19:28 |
blogan | not the error piece | 19:28 |
blogan | the automatic activate | 19:28 |
blogan | its more just a failsafe | 19:28 |
dougwig | doesn'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_work | xgerman: for the record, one of the main uwsgi guys was just a bit concerned that I expose uwsgi directly to the internet :P | 19:30 |
rm_work | or at least, very surprised :P | 19:30 |
blogan | it will only set the particular entity to ERROR | 19:30 |
blogan | not the entire tree | 19:30 |
dougwig | right, 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 |
dougwig | you've just forced an ERROR on the lb that the driver may not agree with. | 19:31 |
blogan | ahh | 19:31 |
blogan | so 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 functioning | 19:32 |
dougwig | yes, exactly that. | 19:32 |
*** jorgem1 has quit IRC | 19:33 | |
dougwig | that was my understanding of vjay's use case, anyway. | 19:33 |
blogan | well its still possible, they'd just have to catch the exception in the driver, but thats not the best way | 19:33 |
blogan | they'd have to do that everywhere and tahts just dumb | 19:33 |
dougwig | yeah, i had been pondering that, and that gets hella messy, hella fast. | 19:34 |
dougwig | easier to make the plugin dumber. | 19:34 |
blogan | well then again, they still need to catch exceptions | 19:34 |
blogan | so what if the driver doesn't catch an exception and it remains uncaught and the loadbalancer isn't functioning but says ACTIVE | 19:34 |
xgerman | rm_work -- yes all those python things prefer to run behind some niginx, | 19:34 |
blogan | and by that i mean the entire tree says ACTIVE | 19:35 |
blogan | is it just the fault of the driver then? | 19:35 |
blogan | and blame it on the driver | 19:35 |
blogan | which isn't a good user experience, no matter where the fault lies | 19:35 |
dougwig | this 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 |
dougwig | then you can not-catch the non-fatal ones. | 19:36 |
blogan | yeah | 19:36 |
blogan | thats what i was leading into | 19:36 |
dougwig | i agree. i wonder if that's not a kilo thing, and we should live with drivers dealing with it in juno. | 19:36 |
blogan | adn similar to how I was going to solve other issues if we ever decided to revisit the driver not making db calls at all | 19:36 |
dougwig | i agree with that approach. what should we put in place now? | 19:37 |
blogan | we could have a LoadBalancerException, ListenerException, PoolException, MemberException, HealthMonitorException, and whichever one is thrown that entity gets set to error | 19:38 |
dougwig | what if i have multiples. :) | 19:38 |
blogan | i knew you were going there | 19:38 |
dougwig | we're rapidly heading back to passing down trees, because i think that's the right interface. | 19:38 |
blogan | then we have a generic EntityException with instance booleans for the entities | 19: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 case | 19:39 |
blogan | well i think it makes many things simpler, but I know there will be people who do not agree | 19:39 |
rm_work | so, there we have it. use add-header= | 19:40 |
dougwig | ok, circle back. our plan of record is still juno, so we need a juno plan for the short-term. | 19:40 |
dougwig | unless you're suggesting we re-design this for juno, which i know you're not. :) | 19:41 |
dougwig | i hope. | 19:41 |
dougwig | oh 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 |
blogan | yes! | 19:43 |
blogan | redesign everything! | 19:43 |
blogan | sorry was distracted by jorge | 19:43 |
blogan | he's very good at that | 19:43 |
blogan | but no im fine with leaving it how it is and adding it in later | 19:43 |
blogan | unless this whole experimental extension thing happens and we're not subject to code freeze then we can discuss it further | 19:43 |
dougwig | oh heck yes. | 19:44 |
blogan | is that a sarcastic "oh heck yes" or a "oh yeah didn't think about that, oh heck yes" | 19:45 |
*** jorgem has joined #openstack-lbaas | 19:46 | |
openstackgerrit | A change was merged to stackforge/octavia: Documenting project direction and design https://review.openstack.org/110563 | 19:46 |
dougwig | it'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 |
blogan | ok great | 19:48 |
*** rolledback has quit IRC | 19:55 | |
rm_work | dougwig / 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 compliant | 20:05 |
rm_work | [15:04:17] <unbit> yes for sure | 20:05 |
rm_work | [15:04:25] <unbit> as well gunicorn is not expected to be put on the public network | 20:05 |
rm_work | [15:04:34] <unbit> as well as basically every application server | 20:05 |
rm_work | so there's that. | 20:05 |
xgerman | yep, 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 directly | 20:06 |
rm_work | [15:06:48] <unbit> absolutely | 20:06 |
rm_work | yeah T_T | 20:06 |
xgerman | for 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_work | dougwig: does that answer your concerns at all? :P | 20:07 |
rm_work | xgerman: yeah ok, but "one of the best" of "a bunch of bad options" is not great :P | 20:07 |
xgerman | don't even try HTTP chunked with those (u)wsgi jokers | 20:09 |
xgerman | <rant>you would think in order to be a web server you would support the HTTP standard </rant> | 20:09 |
blogan | no ranting allowed | 20:10 |
xgerman | even if I mark it clearly :-) | 20:10 |
blogan | even if you mark it clearly in xml! | 20:10 |
blogan | especially xml! | 20:10 |
rm_work | lol | 20:10 |
blogan | shoudla done json, it would have been more poignant | 20:10 |
rm_work | just wanted to see if that made dougwig any more comfortable with my change earlier :P | 20:11 |
*** rolledback has joined #openstack-lbaas | 20:17 | |
*** openstackgerrit has quit IRC | 20:20 | |
*** rolledback has quit IRC | 20:24 | |
*** markmcclain has joined #openstack-lbaas | 20:25 | |
ctracey | dougwig: is there a reason you -1'd me? | 20:25 |
rm_work | ctracey: it's his way of showing affection | 20:27 |
ctracey | maybe | 20:27 |
ctracey | but some context could help :) | 20:27 |
rm_work | I believe he said as much earlier :P | 20:27 |
ctracey | oh the rebase? | 20:28 |
ctracey | im confused as to why that is a -1, but still | 20:30 |
dougwig | no, it was for the comment. | 20:32 |
dougwig | sec, on a call. | 20:32 |
ctracey | there is no comment | 20:33 |
dougwig | nuts, it's on patch set 1, but still applies. sec. | 20:34 |
dougwig | updated | 20:34 |
ctracey | dougwig: updated | 20:44 |
*** rolledback has joined #openstack-lbaas | 20:50 | |
*** rolledback has quit IRC | 20:55 | |
*** vivek-ebay has quit IRC | 20:55 | |
*** vivek-ebay has joined #openstack-lbaas | 20:55 | |
*** vivek-ebay has quit IRC | 20:59 | |
dougwig | ctracey: 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 |
ctracey | dougwig: akihiro in the 3rd one | 21:03 |
ctracey | first patch set | 21:04 |
ctracey | in client.py iirc | 21:04 |
*** vivek-ebay has joined #openstack-lbaas | 21:04 | |
dougwig | ahh, i was viewing this patch on its own merits. can't say as i agree with that feedback, but ok. | 21:05 |
ctracey | dougwig: im indifferent just need one or the other. agree it would be nice to squash it into params | 21:06 |
dougwig | there you go. | 21:26 |
dougwig | rm_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 |
dougwig | seriously, it's ok. :) | 21:28 |
rm_work | heh | 21:34 |
rm_work | dougwig: was referring to running them all by themselves | 21:34 |
dougwig | no one does that, that's insane. | 21:34 |
rm_work | right :P | 21:36 |
rm_work | except Barbican | 21:36 |
rm_work | they do that | 21:37 |
rm_work | T_T | 21:37 |
*** ptoohill1 has joined #openstack-lbaas | 21:45 | |
*** fnaval has quit IRC | 21:55 | |
*** fnaval has joined #openstack-lbaas | 21:56 | |
*** fnaval has quit IRC | 22:00 | |
*** fnaval has joined #openstack-lbaas | 22:13 | |
ctracey | indeed they do | 22:24 |
ctracey | found that out the hard way | 22:24 |
rm_work | oh, current barbican looks to have a bug preventing my from retrieving decrypted secrets T_T | 22:26 |
rm_work | at least locally | 22:26 |
rm_work | I hope it doesn't affect real deployments <_< | 22:26 |
*** crc32 has joined #openstack-lbaas | 22:31 | |
*** jorgem has quit IRC | 22:35 | |
*** openstackgerrit has joined #openstack-lbaas | 22:39 | |
*** mlavalle has quit IRC | 23:03 | |
*** ptoohill1 has quit IRC | 23:39 | |
*** markmcclain has quit IRC | 23:46 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!