| *** barclaac|2 has joined #openstack-lbaas | 00:14 | |
| *** barclaac has quit IRC | 00:18 | |
| *** sbfox has quit IRC | 00:26 | |
| openstackgerrit | A change was merged to stackforge/octavia: Allow .diag file extensions in spec reviews https://review.openstack.org/131300 | 00:45 |
|---|---|---|
| *** mwang2 has quit IRC | 00:46 | |
| *** fnaval has quit IRC | 00:47 | |
| *** mlavalle has quit IRC | 00:57 | |
| *** barclaac has joined #openstack-lbaas | 01:04 | |
| *** fnaval has joined #openstack-lbaas | 01:06 | |
| *** barclaac|2 has quit IRC | 01:07 | |
| *** vivek-ebay has quit IRC | 01:16 | |
| openstackgerrit | Stephen Balukoff proposed a change to stackforge/octavia: Specification of reference haproxy amphora API https://review.openstack.org/126801 | 02:05 |
| rm_you | sbalukoff: I use 422 codes a lot | 02:17 |
| rm_you | noticed they're lacking from your API spec | 02:17 |
| rm_you | possibly nothing that uses them I guess, but curious if you were avoiding them out of more than just coincidence :P | 02:17 |
| sbalukoff | I'm thinking I'm using 409 where you would use 422 | 02:18 |
| sbalukoff | Isn't 422 WebDAV specific? | 02:18 |
| rm_you | hmm yeah i can see that | 02:18 |
| rm_you | well | 02:18 |
| rm_you | it was introduced in an official RFC | 02:18 |
| rm_you | happens to have WebDAV as primary use-case | 02:18 |
| rm_you | but I don't think it says anywhere "this is only for WebDAV" | 02:18 |
| *** vivek-ebay has joined #openstack-lbaas | 02:19 | |
| rm_you | the code is EXACTLY what we need for things like SSL certs being out of date or stuff like that... | 02:19 |
| rm_you | "the server | 02:19 |
| rm_you | understands the content type of the request entity (hence a | 02:19 |
| rm_you | 415(Unsupported Media Type) status code is inappropriate), and the | 02:19 |
| rm_you | syntax of the request entity is correct (thus a 400 (Bad Request) | 02:19 |
| rm_you | status code is inappropriate) but was unable to process the contained | 02:19 |
| rm_you | instructions" | 02:19 |
| rm_you | but I can revise my spec to reference 409 instead if that's the direction we want to go | 02:20 |
| sbalukoff | Hmmm... I think the first time I put this together I was using lighttpd as the webserver, and it didn't understand 422. | 02:20 |
| sbalukoff | I'm honestly not sure what's the most approriate thing here. | 02:21 |
| sbalukoff | It would be trivial to change in either case. | 02:21 |
| rm_you | I suppose | 02:21 |
| rm_you | trying to get ducks in a row so we look like we know what we're doing when you guys show off Octavia stuff in Paris :P | 02:21 |
| sbalukoff | Haha! | 02:22 |
| rm_you | I was actually a little bit curious if the WebDAV thing was a big deal | 02:22 |
| rm_you | I normally just use whatever code seems most appropriate (including 420) but now I'm writing for a large community :P | 02:23 |
| sbalukoff | We should just use code 418 | 02:23 |
| rm_you | lol | 02:23 |
| rm_you | I discussed that whole spec at length in my first interview at RS | 02:23 |
| rm_you | apparently none of my interviewers had seen it and i am pretty sure they thought i was nuts | 02:24 |
| rm_you | i guess i didn't end up getting that position... <_< | 02:24 |
| sbalukoff | Heh! | 02:24 |
| rm_you | but yeah, much prefer 420 to 429... but... >_> | 02:25 |
| sbalukoff | Haha | 02:25 |
| sbalukoff | But, you don't live in Washington! | 02:26 |
| rm_you | I lived there for 18 years :P | 02:26 |
| sbalukoff | (Or Colorado) | 02:26 |
| sbalukoff | Not now, though. | 02:26 |
| sbalukoff | You should move back. ;) | 02:26 |
| rm_you | it's still my home state... | 02:26 |
| rm_you | yeah, thinking about it, but stuck here for a few years while my GF finishes her masters | 02:26 |
| rm_you | and i've learned not to plan more than like 6 months in advance >_< | 02:27 |
| sbalukoff | I hear you there, eh. | 02:29 |
| rm_you | sbalukoff: "Also note that some topology changes can take several minutes to enact" holy shit what would take several minutes | 02:38 |
| rm_you | several minutes is *pain* | 02:38 |
| rm_you | i really hope there isn't any possible operation that will take more than ~1s | 02:38 |
| rm_you | maybe ~2s | 02:38 |
| sbalukoff | That's a worst-case scenario, and that has to do with changing from single to active-standby. If you're using corosync/pacemaker to do this, the participating members will hold an election to determine the cluster master... and this can take a few minutes. | 02:39 |
| rm_you | dear god | 02:39 |
| sbalukoff | Again, worst-case scenario. For the most part, it's just a second or two. | 02:39 |
| rm_you | k | 02:39 |
| rm_you | lol, every single one of these resources returns hostname/uuid :P | 02:40 |
| rm_you | ah ok not 100%, just close | 02:41 |
| sbalukoff | Yeah, that's a habit I'm in. Don't know if it'll be used, but it's handy for a sanity check. | 02:41 |
| rm_you | this is long enough that I started scanning at some point and I just realized I was doing it <_< | 02:42 |
| sbalukoff | Heh! | 02:43 |
| sbalukoff | Sorry-- David wanted to see example output for pretty much everything. | 02:43 |
| rm_you | "Get SSL certificate PEM file" this is not something we should allow | 02:44 |
| rm_you | SSL goes in -> nothing comes out | 02:44 |
| sbalukoff | I'm OK with that. Add that comment? | 02:44 |
| *** vivek-ebay has quit IRC | 02:45 | |
| rm_you | err, ok I guess cert, but not private key | 02:45 |
| rm_you | which I see is in there | 02:45 |
| sbalukoff | No... | 02:45 |
| rm_you | will comment | 02:45 |
| sbalukoff | We probably don't need it... ever. | 02:45 |
| rm_you | yeah | 02:45 |
| sbalukoff | That's one case where "write-only" probably makes sense. | 02:45 |
| rm_you | just good policy to never give back private SSL data | 02:45 |
| sbalukoff | I'd been debating dropping that. | 02:45 |
| sbalukoff | Well... | 02:45 |
| sbalukoff | Hmmm... | 02:45 |
| sbalukoff | It might be good to return some meta-data on the cert in place. | 02:45 |
| sbalukoff | But realistically... | 02:45 |
| rm_you | yeah, CERT is ok | 02:46 |
| rm_you | private key is not | 02:46 |
| sbalukoff | If the controller wants to make sure a given cert is the one it's expecting, it's just going to over-write it anyway. | 02:46 |
| rm_you | yep | 02:46 |
| rm_you | last comment going in: | 02:50 |
| rm_you | Did we officially wrap up discussion of whether the config is generated in the driver or on the amphora? This is the driver-generated config model, but there is something to be said for keeping the driver generic and communicating with a more abstracted language, and having the Amphora API build the config (since it'll be sitting around anyway). That would allow Amphorae of differing types to be flipped around seamlessly in the | 02:51 |
| rm_you | background if that were necessary/warranted. I think German was advocating that model previously as well? | 02:51 |
| rm_you | the -1 is 99% for the PK thing tho :) | 02:52 |
| rm_you | pretty thorough for a first draft | 02:52 |
| rm_you | anywho, brb | 02:52 |
| *** fnaval has quit IRC | 02:53 | |
| *** fnaval has joined #openstack-lbaas | 02:53 | |
| sbalukoff | Yes, we did draw that discussion to a close. | 02:54 |
| sbalukoff | The reason behind rendering the haproxy config in the controller is: 1) Drivers should be specific to the type of amphora. If you want to write an haproxy-based amphora, that means you're going to be writing a new driver, too. 2) Centralize intelligence, decentralize workload. 3) If you need to make a minor change to the haproxy configuration template, it's easier to update a few dozen controllers rather than 10,000+ a | 02:56 |
| sbalukoff | mphorae. | 02:56 |
| *** sbfox has joined #openstack-lbaas | 03:43 | |
| *** fnaval has quit IRC | 03:43 | |
| *** fnaval has joined #openstack-lbaas | 03:44 | |
| *** fnaval has quit IRC | 03:48 | |
| *** fnaval has joined #openstack-lbaas | 04:18 | |
| *** sbfox has quit IRC | 04:23 | |
| *** vivek-ebay has joined #openstack-lbaas | 04:35 | |
| *** vivek-ebay has quit IRC | 04:55 | |
| *** sbfox has joined #openstack-lbaas | 05:02 | |
| rm_you | sbalukoff: ah, right. the one that really makes sense there is #3, you should lead with that. the rest are pretty debatable :P | 05:54 |
| *** fnaval has quit IRC | 06:10 | |
| *** fnaval has joined #openstack-lbaas | 06:11 | |
| *** fnaval has quit IRC | 06:15 | |
| *** sbfox has quit IRC | 06:31 | |
| *** jschwarz has joined #openstack-lbaas | 06:31 | |
| *** sbfox has joined #openstack-lbaas | 06:59 | |
| *** kobis has joined #openstack-lbaas | 07:44 | |
| *** vivek-ebay has joined #openstack-lbaas | 07:56 | |
| *** woodster_ has quit IRC | 08:00 | |
| *** vivek-ebay has quit IRC | 08:01 | |
| *** sbfox has quit IRC | 08:32 | |
| *** markmcclain has joined #openstack-lbaas | 10:36 | |
| *** markmcclain has quit IRC | 10:53 | |
| *** markmcclain has joined #openstack-lbaas | 10:53 | |
| *** jschwarz has quit IRC | 11:30 | |
| *** markmcclain has quit IRC | 12:00 | |
| *** markmcclain has joined #openstack-lbaas | 13:11 | |
| *** markmcclain1 has joined #openstack-lbaas | 13:12 | |
| *** markmcclain1 has quit IRC | 13:12 | |
| *** markmcclain has quit IRC | 13:16 | |
| *** fnaval has joined #openstack-lbaas | 13:17 | |
| *** fnaval has quit IRC | 13:27 | |
| *** woodster_ has joined #openstack-lbaas | 14:03 | |
| *** ptoohill_ has quit IRC | 14:48 | |
| *** markmcclain has joined #openstack-lbaas | 14:50 | |
| *** fnaval has joined #openstack-lbaas | 15:00 | |
| ptoohill | Mornin' | 15:18 |
| *** ptoohill_ has joined #openstack-lbaas | 15:21 | |
| *** ajmiller has joined #openstack-lbaas | 15:40 | |
| *** jorgem has joined #openstack-lbaas | 15:57 | |
| *** mlavalle has joined #openstack-lbaas | 16:00 | |
| blogan | mornin | 16:00 |
| *** amotoki has joined #openstack-lbaas | 16:05 | |
| TrevorV | mernin! (late-ish) | 16:17 |
| sballe | morning | 16:30 |
| *** vivek-ebay has joined #openstack-lbaas | 16:38 | |
| *** vivek-ebay has quit IRC | 16:44 | |
| *** vivek-ebay has joined #openstack-lbaas | 16:45 | |
| *** markmcclain has quit IRC | 16:45 | |
| *** vivek-ebay has quit IRC | 16:47 | |
| *** intr1nsic has quit IRC | 16:48 | |
| *** vivek-ebay has joined #openstack-lbaas | 16:48 | |
| *** intr1nsic has joined #openstack-lbaas | 16:48 | |
| *** sbfox has joined #openstack-lbaas | 16:49 | |
| *** sbfox has quit IRC | 16:50 | |
| *** intr1nsic has quit IRC | 16:50 | |
| *** sbfox has joined #openstack-lbaas | 16:51 | |
| *** sbfox has quit IRC | 16:52 | |
| *** sbfox has joined #openstack-lbaas | 16:52 | |
| *** mwang2 has joined #openstack-lbaas | 16:54 | |
| *** sbfox has quit IRC | 16:55 | |
| *** intr1nsic has joined #openstack-lbaas | 16:56 | |
| *** sbfox1 has joined #openstack-lbaas | 16:58 | |
| *** kobis has quit IRC | 17:13 | |
| *** amotoki has quit IRC | 17:33 | |
| *** vivek-ebay has quit IRC | 17:36 | |
| *** vivek-ebay has joined #openstack-lbaas | 17:37 | |
| *** markmcclain has joined #openstack-lbaas | 17:51 | |
| *** markmcclain has quit IRC | 17:55 | |
| *** sbfox1 has quit IRC | 17:57 | |
| *** vivek-ebay has quit IRC | 18:25 | |
| *** vivek-ebay has joined #openstack-lbaas | 18:26 | |
| *** sbfox has joined #openstack-lbaas | 18:27 | |
| *** sbfox has quit IRC | 18:49 | |
| *** sbfox has joined #openstack-lbaas | 19:00 | |
| *** mestery has quit IRC | 19:07 | |
| *** mestery has joined #openstack-lbaas | 19:09 | |
| *** codekobe has joined #openstack-lbaas | 19:15 | |
| blogan | ping sbalukoff | 19:20 |
| *** ggirard27 has joined #openstack-lbaas | 19:32 | |
| sbalukoff | blogan: Pong | 19:32 |
| blogan | is the amphora api going to be synchronous? | 19:36 |
| codekobe | i was wondering that | 19:36 |
| codekobe | this is steven from emc | 19:37 |
| blogan | hi steven | 19:37 |
| intr1nsic | Hey steven | 19:37 |
| sbalukoff | blogan: I was hoping so. Do you anticipate a reason it wouldn't be? | 19:38 |
| sbalukoff | Howdy, howdy! | 19:38 |
| blogan | sbalukoff: you did mention the possibility of topology changes taking several minutes worst case scenario | 19:39 |
| codekobe | i was assuming there will be a need for some kind of queue, and worker type nodes | 19:39 |
| blogan | so that could possibly be asynchronous | 19:39 |
| codekobe | at least from a users perspective | 19:39 |
| codekobe | when i make a change to an LB | 19:40 |
| blogan | codekobe there will be a queue | 19:40 |
| codekobe | i would imagine a "building" state | 19:40 |
| blogan | codekobe there is the User/Operator API that will definitely be async | 19:40 |
| codekobe | as changes are propogated | 19:40 |
| ptoohill | There will be a queue if it remains sync? | 19:40 |
| codekobe | ah gotcha, you are referring to an api that lives on the amphora | 19:41 |
| blogan | but then there is an api that each amphora spun up will have for communication to start the actual laod balancing software | 19:41 |
| codekobe | so is this mainly to send changes to the amphora's configuration? | 19:41 |
| codekobe | IE: add a new webhead in the rotation | 19:42 |
| sbalukoff | blogan: I did. You're right. But in that case, I would prefer to set the amphora in to the 'TOPOLOGY-CHANGE' status / state and return 503's for additional amphora commands rather than deal with queue on the amphora itself. | 19:42 |
| sbalukoff | codekobe: Those kinds of commands should be doable synchronously. | 19:43 |
| codekobe | sounds reasonable | 19:44 |
| codekobe | the amphora communicates its status back to the controller? | 19:44 |
| *** ggirard27 has quit IRC | 19:44 | |
| codekobe | when it is done performing its TOPOLOGY-CHANGE | 19:44 |
| blogan | sbalukoff: so then that would be an async element to the api, and you'd be doing the same thing as the user api does when a load balancer is in an immutable state | 19:45 |
| sbalukoff | codekobe: That's not yet defined. The controller could probe the amphora until it's no longer in that state. But there will need to be a small-ish API that the controller / driver runs on the back-side that amphorae talk to. | 19:45 |
| blogan | except i dont agree with the 503 code, but that's minor | 19:45 |
| sbalukoff | blogan: Yes. | 19:45 |
| sbalukoff | blogan: Which code would you prefer? | 19:46 |
| sbalukoff | (I'm not too picky about codes, so long as they're well defined somewhere.) | 19:46 |
| blogan | sbalukoff: 422 | 19:46 |
| rm_work | lol | 19:46 |
| sbalukoff | Except it's not a client-side problem. ;) | 19:46 |
| ptoohill | :P | 19:46 |
| sbalukoff | It should be a 5xx code of some kind. | 19:46 |
| sbalukoff | Also, rm_work and I talked about this: Isn't 422 a WebDAV error code? | 19:47 |
| rm_work | https://www.youtube.com/watch?v=xKKP_cZuk54 | 19:47 |
| blogan | i think it is a client side problem, a client is trying to make a change to an entity that it can't | 19:47 |
| sbalukoff | blogan: But the same request repeated 5 seconds later will probably work. | 19:47 |
| sbalukoff | The server isn't in a state to accept the command. | 19:48 |
| sbalukoff | There's nothing wrong with the command itself. | 19:48 |
| codekobe | sbalukoff: just thinking out loud, if you polled the amphora for its state, that means it will be preserving its state somewhere | 19:48 |
| sbalukoff | codekobe: Yes. | 19:48 |
| codekobe | so it would preserver that in memory or in the db? | 19:48 |
| codekobe | just getting a feel for the model here | 19:49 |
| blogan | sbalukoff: i would say the command itself is not allowed, but yeah it sounds like a gray area | 19:49 |
| sbalukoff | codekobe: the amphorae won't have access "to the DB" as it were. So in memory, or in a file in the filesystem... doesn't really matter. | 19:49 |
| sbalukoff | The amphorae don't have to keep much state. ;) | 19:49 |
| rm_work | I think in this case 503 is right | 19:50 |
| rm_work | my debate was about 422 vs 409 | 19:50 |
| sbalukoff | blogan: I prefer 4xx errors to mean "Client, you're being stupid. Fix your request if you want to try again." And 5xx errors to mean, "I'm afraid I can't do that (right now), Dave" | 19:50 |
| rm_work | :P | 19:50 |
| sbalukoff | Haha! | 19:51 |
| blogan | you might be convincing me... | 19:51 |
| blogan | but i dont want you to | 19:51 |
| sbalukoff | Haha | 19:51 |
| sbalukoff | I'm a jerk that way. | 19:51 |
| codekobe | a 409 wouldnt make sense? for a conflict | 19:51 |
| rm_work | just listen to some old-school beach boys and chill | 19:51 |
| rm_work | codekobe: it's not a conflict | 19:52 |
| sbalukoff | Heh! | 19:52 |
| codekobe | since the resource is in the TOPOLOGY-CHANGE state | 19:52 |
| rm_work | that's not a conflict | 19:52 |
| blogan | well depends on yoru definition of a conflict | 19:52 |
| blogan | the state conflicts with what the user wants to do | 19:52 |
| rm_work | :P ok that's technically correct | 19:52 |
| rm_work | but not really sensical | 19:52 |
| sbalukoff | So, the 409 versus 422 thing is actually coming from the fact that the first iteration of one of these APIs I wrote I powered with lighttpd because it's... well, friggen light-weight. And lighttpd didn't understand 422 errors. | 19:52 |
| codekobe | i think 503 makes more sense | 19:52 |
| blogan | i know, but its an interpretation issue | 19:52 |
| codekobe | i think 409 is telling the user there is an action to take to fix the conflict | 19:53 |
| blogan | wsme doesn't allow 422 either? | 19:53 |
| blogan | no ? | 19:53 |
| blogan | that was a statement | 19:53 |
| ptoohill | wha??!? | 19:53 |
| codekobe | when in this case, the service will return after a delay, which is more like a 503 | 19:53 |
| sbalukoff | Honestly, if 422 is a more appropriate code (in rm_work's and my debate), and if the webserver understands it, I'm OK with it. | 19:53 |
| rm_work | 503 makes sense for this, 422 makes sense when the user passes a syntactically correct request but one of the elements inside it is not correct somehow upon further inspection | 19:53 |
| rm_work | IE, certificate issues | 19:53 |
| sbalukoff | blogan: Does wsme allow 422? | 19:55 |
| sbalukoff | (I'm confused by your statements above) | 19:55 |
| blogan | sbalukoff: no but we can patch it in | 19:55 |
| sbalukoff | ... | 19:55 |
| blogan | i know my ? messed it up | 19:55 |
| sbalukoff | really? | 19:55 |
| sbalukoff | Why not just use 409 and be done with it? | 19:55 |
| blogan | i did | 19:55 |
| blogan | for now | 19:55 |
| sbalukoff | :) | 19:55 |
| sbalukoff | Ok. | 19:55 |
| blogan | i didnt like it | 19:55 |
| sbalukoff | So version 0.2 of this API can use 422. | 19:55 |
| sbalukoff | Once wsme is patched. | 19:55 |
| blogan | well it may use 503 | 19:55 |
| rm_work | gonna link https://www.youtube.com/watch?v=xKKP_cZuk54 again in case anyone missed it | 19:56 |
| sbalukoff | (in upstream... I'd really rather avoid using monkey-patching) | 19:56 |
| blogan | but i still have qualms about 503 | 19:56 |
| sbalukoff | Haha | 19:56 |
| blogan | you well use monkey patching and like it | 19:56 |
| sbalukoff | blogan: I was actually talking about rm_work's and my debate. | 19:56 |
| sbalukoff | In the case of the temporary unavailability of running certain commands... 503 makes sense. | 19:56 |
| rm_work | yeah the 503 and 422/409 thing aren't really related | 19:57 |
| sbalukoff | (Commands which are otherwise correct.) | 19:57 |
| blogan | the case Im speaking about si when a load balalncer in the user api is in a PENDING_UPDATE state, i'm not allowing it to modified until its ACTIVE | 19:57 |
| sbalukoff | rm_work: Yes, sorry I wasn't being clear about that. | 19:57 |
| codekobe | 422 is not in the w3 list of http codes.. but then again neither is 418 I'M A LITTLE TEAPOT | 19:57 |
| rm_work | T_T | 19:58 |
| sbalukoff | blogan: I'm still thinking 503 is right in that case, too. | 19:58 |
| rm_work | yeah though both technically have w3 RFCs... | 19:58 |
| blogan | sbalukoff: it would be the same case, but I'm going to look and see what nova does | 19:58 |
| sbalukoff | blogan: Sounds good. | 19:58 |
| sbalukoff | Ok, I gotta run off for a bit. | 19:58 |
| blogan | okay | 19:58 |
| sbalukoff | Catch ya'll in an hour or so. | 19:59 |
| sbalukoff | y'all. | 19:59 |
| *** sbfox has quit IRC | 20:04 | |
| *** sbfox has joined #openstack-lbaas | 20:06 | |
| *** markmcclain has joined #openstack-lbaas | 20:09 | |
| *** markmcclain1 has joined #openstack-lbaas | 20:10 | |
| *** markmcclain has quit IRC | 20:12 | |
| *** jorgem1 has joined #openstack-lbaas | 20:15 | |
| *** markmcclain1 has quit IRC | 20:15 | |
| *** jorgem1 has quit IRC | 20:16 | |
| *** jorgem has quit IRC | 20:18 | |
| *** vivek-ebay has quit IRC | 20:26 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:27 | |
| *** xgerman has joined #openstack-lbaas | 20:30 | |
| *** vivek-ebay has quit IRC | 20:31 | |
| *** markmcclain1 has joined #openstack-lbaas | 20:37 | |
| *** markmcclain1 has quit IRC | 20:37 | |
| *** markmcclain1 has joined #openstack-lbaas | 20:39 | |
| *** vivek-ebay has joined #openstack-lbaas | 20:51 | |
| dougwig | http://abcnews.go.com/International/divers-unearth-piece-roman-empire-2000-year-shipwreck/story?id=26505641 | 20:55 |
| ptoohill | Awesome! | 21:01 |
| *** markmcclain1 has quit IRC | 21:27 | |
| rm_work | :P | 21:41 |
| ptoohill | many amphorae at ze bottom of ze ocean | 21:57 |
| blogan | sbalukoff: nova uses 409 for the same case | 22:17 |
| rm_work | https://www.youtube.com/watch?v=frtVqCZub-0 | 22:18 |
| * rm_work needs an autoresponder for that | 22:18 | |
| *** ptoohill_ has quit IRC | 22:21 | |
| sbalukoff | blogan: Okeedokee. | 22:22 |
| *** vivek-ebay has quit IRC | 22:33 | |
| *** xgerman has quit IRC | 22:43 | |
| *** vivek-ebay has joined #openstack-lbaas | 22:43 | |
| *** xgerman has joined #openstack-lbaas | 22:43 | |
| *** vivek-ebay has quit IRC | 23:14 | |
| *** mlavalle has quit IRC | 23:15 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:20 | |
| *** sbfox has quit IRC | 23:22 | |
| *** vivek-ebay has quit IRC | 23:31 | |
| *** vivek-ebay has joined #openstack-lbaas | 23:33 | |
| *** ajmiller has quit IRC | 23:42 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!