| menn0 | thumper: here's the logsender worker (not wired up) http://reviews.vapour.ws/r/1244/ | 00:01 |
|---|---|---|
| mup | Bug #1434680 changed: Certificate generated by certupdater worker cannot be used by MongoDB <ci> <regression> <upgrade-juju> <juju-core:Fix Released by wallyworld> <juju-core 1.22:Fix Released by menno.smits> <juju-core 1.23:Fix Released by wallyworld> <https://launchpad.net/bugs/1434680> | 00:27 |
| thumper | menn0: ack | 00:28 |
| menn0 | thumper: i'm currently pushing branches and writing you a long email | 00:33 |
| * thumper nods | 00:33 | |
| thumper | sounds good | 00:33 |
| axw_ | wallyworld: sorry I didn't make the standup, I didn't get much sleep and wasn't feeling well | 00:43 |
| wallyworld | axw_: np at all, hope you're ok, take plenty of time to fell well again today if you need to | 00:44 |
| axw_ | wallyworld: last night I got the EBS provider working; it informs the provisioner that it needs a volume before it can proceed to CreateVolumes, and it sets DeleteOnTermination for the attachment if non-persistent | 00:44 |
| axw_ | wallyworld: just need to write lots of tests now | 00:44 |
| wallyworld | yay, awesome | 00:45 |
| axw_ | that will involve the new method in goamz too | 00:45 |
| wallyworld | ok | 00:45 |
| === kadams54 is now known as kadams54-away | ||
| jw4 | ocr ptal : forward port of previously reviewed changes into master: http://reviews.vapour.ws/r/1243/ | 01:00 |
| axw_ | wallyworld: is trunk still blocked? | 01:06 |
| wallyworld | axw_: no, i unblocked just before | 01:06 |
| axw_ | sweet, thanks | 01:06 |
| wallyworld | join the queue | 01:06 |
| axw_ | wallyworld: if you have time, http://reviews.vapour.ws/r/1227/ needs reviewing | 01:07 |
| wallyworld | axw_: sure, just need to do a 1.22.1 fix, review is next on my todol list | 01:07 |
| axw_ | nps, thanks | 01:07 |
| axw_ | anastasiamac: do you still want me to review your branch? I see wallyworld has +1d | 01:11 |
| === axw_ is now known as axw | ||
| anastasiamac | axw_: sure :D was trying to land but had a failure... if u could review, would be gr8 :D | 01:12 |
| axw | anastasiamac: don't wait for me, I'll just have a look and if there's anything just do it in a followup | 01:12 |
| anastasiamac | axw: sounds gr8! thnx :D | 01:13 |
| axw | anastasiamac: your latest changes look fine, thanks | 01:17 |
| anastasiamac | axw: tyvm :D have fix for failed tests :)) will try to land again! | 01:18 |
| wallyworld | axw: a small one https://github.com/juju/juju/pull/1922 | 01:47 |
| axw | wallyworld: looking | 01:53 |
| wallyworld | ty | 01:54 |
| axw | wallyworld: done | 01:56 |
| wallyworld | ty | 01:57 |
| wallyworld | axw: i've also added a quick drive by fix of an intermittent failure i introduced last night fixing the bug blocking trunk | 01:57 |
| axw | ok, looking | 01:58 |
| axw | wallyworld: why does that change make a difference? | 01:59 |
| wallyworld | axw: because it slightly delays the "now" time from which the expiry is calulated | 01:59 |
| wallyworld | to better reflect what is done when generating the cert | 02:00 |
| wallyworld | there's 2 expity times - one for ca cert, one for server cert | 02:00 |
| axw | wallyworld: and the cert time needs to be before "now" ? | 02:01 |
| wallyworld | the expiry tine needs to be before now+10 | 02:01 |
| wallyworld | and if now is slightly earlier, the expiry time is slightly after now+10 | 02:01 |
| wallyworld | ie don't determine"now" and then do stuff and then generate the cert | 02:02 |
| wallyworld | as the doing stuff delay is enough to cause the test to sometimes fail | 02:02 |
| axw | ok | 02:02 |
| axw | wallyworld: shipit | 02:02 |
| wallyworld | ta | 02:02 |
| wallyworld | this was a refactored test | 02:03 |
| wallyworld | the original used the same expiry time for ca cert and server cert | 02:03 |
| ericsnow | thumper: FYI, I believe I have that RB webhook unicode bug fixed | 02:28 |
| anastasiamac | ericsnow: \o/ | 02:33 |
| thumper | ericsnow: cool | 02:38 |
| natefinch | wallyworld_, thumper, anyone else: I need to change the "stateaddress" value in the machine's agent.conf (since I'm upgrading it to a state server, it needs to change to localhost). However, I can't see any code that can actually serialize a value out to that. | 02:53 |
| wallyworld_ | natefinch: hey, there's formatter.go files somewhere | 02:55 |
| wallyworld_ | let me have a look | 02:56 |
| natefinch | wallyworld_: I see it - juju/agent/format-1.18.go | 02:58 |
| wallyworld_ | natefinch: there's a format-1.18.go plus, if you have already loaded the config, you can use a ChangeConfig() callback to update | 02:58 |
| wallyworld_ | you don't then need to serialise the whole lot | 02:59 |
| natefinch | wallyworld_: ok, yeah, I did that, must have done something wrong, though. But it's good to know how the magic was happening. | 02:59 |
| wallyworld_ | natefinch: you need to use an AGentConfigWriter to invoke the Change callback | 03:00 |
| wallyworld_ | if you use an AgentConfig, it won't work | 03:00 |
| ericsnow | menn0: CI failure due to your upgrade fix? http://data.vapour.ws/juju-ci/products/version-2473/run-unit-tests-utopic-amd64/build-1747/consoleText | 03:00 |
| wallyworld_ | natefinch: i found that out the hard way last night doing a patch to unblock trunk | 03:01 |
| wallyworld_ | natefinch: if you look at the commit, you'll see how i did it | 03:01 |
| wallyworld_ | https://github.com/juju/juju/commit/97028ee0bc998026f0e1ef758ef6afadb1734ac4 | 03:01 |
| menn0 | ericsnow: that's actually wallyworld_'s | 03:01 |
| wallyworld_ | yep | 03:01 |
| ericsnow | menn0: ah | 03:01 |
| wallyworld_ | there's a fix proposed | 03:02 |
| wallyworld_ | intermittent | 03:02 |
| ericsnow | wallyworld_: cool :) | 03:02 |
| wallyworld_ | landing in 1.22, then 123, then master | 03:02 |
| wallyworld_ | sigh | 03:02 |
| * ericsnow hopes we can preempt another blocker bug in the morning :) | 03:02 | |
| wallyworld_ | oh yes, i will ensure it | 03:03 |
| ericsnow | wallyworld_: :) | 03:03 |
| natefinch | wallyworld_: awesome, thanks | 03:04 |
| wallyworld_ | natefinch: sure, let me know if you get stuck etc | 03:04 |
| ericsnow | thumper: about restore->recover... | 03:04 |
| ericsnow | thumper: "restore" gives the wrong idea about what it is for | 03:05 |
| ericsnow | thumper: "recover" seems to describe it really well though | 03:05 |
| thumper | I disagree | 03:05 |
| ericsnow | thumper: go on | 03:05 |
| thumper | rebuild? | 03:05 |
| thumper | backup / restore seems more natural | 03:05 |
| thumper | are you concerned that you don't restore an environment | 03:06 |
| thumper | but you recreate one? | 03:06 |
| ericsnow | thumper: restore is only meant to me used in the case that your environment blows up and you no longer have a state server | 03:06 |
| ericsnow | thumper: the way it is now at least | 03:06 |
| natefinch | wallyworld_: yeah, I was just using agent.ChangeCOnfig, not agent.AgentConfigWriter.ChangeConfig | 03:07 |
| ericsnow | thumper: so it covers only one part of what the name "restore" seems to promise | 03:07 |
| thumper | ericsnow: however, recover doesn't work either | 03:07 |
| menn0 | thumper: PTAL http://reviews.vapour.ws/r/1244/ | 03:07 |
| wallyworld_ | natefinch: that will work, but i think it uses a go routine or something to do it async | 03:07 |
| wallyworld_ | natefinch: not the right thing to use if you just want it done ad hoc on startup or something | 03:07 |
| ericsnow | thumper: sure, I'm not married to "recover" as the new name | 03:07 |
| thumper | in which case, I think we need some more bikeshedding :-) | 03:08 |
| ericsnow | thumper: no worries | 03:08 |
| natefinch | wallyworld_: actually, heh, I hadn't actually saved the changes in my buffer yet. That would probably help :0 | 03:08 |
| ericsnow | thumper: I opened the bug and the pull request at the very least to get things rolling | 03:08 |
| thumper | well... some take the pull request to be a slightly more agressive stance on the idea | 03:09 |
| ericsnow | thumper: wasn't planning on landing anything until there was more feedback | 03:09 |
| thumper | normally a PR is "this is they way I think it should be" | 03:09 |
| thumper | ericsnow: part of the problem is that people take things differently than they way you intend | 03:09 |
| thumper | it isn't obvious that it is a discussion point | 03:10 |
| thumper | it is a "here's the fix" | 03:10 |
| ericsnow | thumper: ah, makes sense | 03:10 |
| ericsnow | thumper: I'll discard the PR for now then | 03:11 |
| thumper | ok | 03:11 |
| thumper | cheers | 03:11 |
| mup | Bug #1435644 was opened: private cloud:( environment is openstack )index file has no data for cloud <juju-core:New> <https://launchpad.net/bugs/1435644> | 03:16 |
| ericsnow | anastasiamac: thanks for those reviews | 03:16 |
| anastasiamac | ericsnow: the least i could after u did an amazing review for me :D | 03:17 |
| ericsnow | anastasiamac: ha, thanks :) | 03:18 |
| anastasiamac | ericsnow: done :D but of course my shipit is not loaded with much power :D | 03:22 |
| ericsnow | wallyworld_: FYI, I think we're going to be okay leaving things alone in the simplestreams code: https://github.com/Altoros/juju-vmware/blob/master/provider/vmware/image_metadata.go | 03:22 |
| ericsnow | anastasiamac: thanks | 03:23 |
| wallyworld_ | ericsnow: looks reasonable - those are the standard extension points | 03:25 |
| wallyworld_ | axw: finally reviewed, sorry about delay | 03:25 |
| ericsnow | wallyworld_: yeah, that's what I came to realize | 03:25 |
| axw | wallyworld_: nps, thanks | 03:30 |
| ericsnow | thumper: finally got a nice big round tuit so I've set up the webhook on each of the repos that RB knows about (except for docs) | 03:36 |
| wallyworld_ | ericsnow: jorge's --journal backport to 1.22 also needs to get into 1.23 | 03:36 |
| ericsnow | thumper: I'll keep an eye on those to make sure they're working | 03:36 |
| ericsnow | wallyworld_: I thought he landed the original patch before the 1.23 branch was made | 03:37 |
| * ericsnow checks | 03:37 | |
| wallyworld_ | ericsnow: i could be wrong, but it only seemed to land 5 days ago and when i compared master to 1.23 branch it was missing | 03:37 |
| wallyworld_ | happy to be wrong though | 03:37 |
| ericsnow | wallyworld_: no, you're right, it isn't there | 03:39 |
| wallyworld_ | just need to cherrypick the commit | 03:39 |
| ericsnow | wallyworld_: I'll make sure that gets in | 03:39 |
| wallyworld_ | ty | 03:39 |
| wallyworld_ | i added the bug to the series and milestone | 03:40 |
| ericsnow | wallyworld_: thanks | 03:42 |
| ericsnow | wallyworld: FYI, that 1.23 backport patch is now waiting its turn (https://github.com/juju/juju/pull/1925) | 04:01 |
| wallyworld | \o/ ty | 04:01 |
| ericsnow | wallyworld: wish they were all that easy :) | 04:02 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | indeed | 04:02 |
| thumper | jam: ping | 04:24 |
| thumper | jam: we need to chat about some spec topics | 04:25 |
| thumper | jam: I'm half preparing dinner, so I'll check back in shortly | 04:25 |
| === thumper is now known as thumper-dinner | ||
| jam | thumper-dinner: k | 04:25 |
| thumper-dinner | jam: ah... you are there | 04:26 |
| thumper-dinner | jam: when is good? | 04:26 |
| jam | thumper-dinner: I'm around, so whenever is good for you | 04:26 |
| thumper-dinner | now? | 04:26 |
| thumper-dinner | jam: https://plus.google.com/hangouts/_/canonical.com/spec-chat | 04:26 |
| wallyworld | axw: have you ever had a git stash become corrupt? mine just did and I had to try and piece together commits from git fsck --unreachable, and even them i lost a bunch of work :-( | 04:49 |
| axw | wallyworld: nope, sorry :( | 04:50 |
| axw | wallyworld: that's why I don't ues stash so much... I create branches and push WIP to GH when it gets big enough for me to worry about loss of work | 04:50 |
| wallyworld | yeah, i'll have to consider that | 04:51 |
| wallyworld | i still have one more big branch to sort out, sigh | 04:52 |
| axw | dimitern: I'm adding ModifyInstanceAttribute, but having trouble writing a test as it involves a VPC knowledge that I don't have and don't really have time to learn right now. Would you prefer that I leave out support for SourceDestCheck, or that I put it in without a test for that attribute? | 06:43 |
| dimitern | axw, so what's the problem - it's just a flag set on a ec2test instance | 06:44 |
| jam | dimitern: just to check, request-address is part of the phase 1 networking stuff, right? | 06:45 |
| axw | dimitern: you can't set it on non-VPC instances. instances in the test double seem to be getting a VPC by default | 06:45 |
| dimitern | axw, yes, that's true - it wasn't even available pre-vpc api IIRC | 06:45 |
| dimitern | jam, yes, it is | 06:45 |
| jam | k, it came up as some other stuff | 06:46 |
| jam | is request-iface ? | 06:46 |
| axw | dimitern: so I can test the error path on my account, but I suspect the test will fail if there's a default VPC in the region | 06:46 |
| jam | (thinking about kvm containers, they could create their own iface if they had an IP to assign it, right? | 06:46 |
| jam | ) | 06:46 |
| dimitern | axw, how about a simple test like this: set sourcedestcheck, followed by Instances() checking the flag is set on the instance? | 06:46 |
| axw | dimitern: that's what I was trying to do, and got errors about not being able to create VPC or subnet or something in AZs | 06:47 |
| dimitern | jam, request-iface is on the roadmap as well (but lower in priority than the rest I guess) | 06:47 |
| jam | dimitern: sure, just checking if we actually need it for charms | 06:47 |
| jam | do they *need* juju to provide it, or could they do it with their own work after requesting ip | 06:47 |
| dimitern | jam, for *certain* very specific charms | 06:47 |
| dimitern | axw, are you using the shared aws account? this is a live test I guess | 06:48 |
| axw | dimitern: my own | 06:48 |
| axw | yes, live | 06:48 |
| dimitern | axw, well, if you don't mind adding the test and sending me a link, I can pull you branch and make sure the test pass, how about this? | 06:48 |
| axw | dimitern: sounds good, thanks | 06:49 |
| dimitern | jam, for charms that need a dedicated interface, e.g. like in the kvm appliance case, having native support in juju will definitely help | 06:49 |
| wallyworld | axw: i haven't looked really hard (not much work on storage today sadly), but kat has added some more to the goose cinder branch, hopefully can be landed when she comes on tomorrow https://github.com/go-goose/goose/pull/3 | 06:50 |
| axw | wallyworld: cool, will take a look | 06:50 |
| wallyworld | ta, have to head to soccer for a bit | 06:50 |
| axw | wallyworld: btw, should be able to deploy with tmpfs and rootfs on master now | 06:51 |
| axw | sure, ttyl | 06:51 |
| TheMue | morning o/ | 08:20 |
| dimitern | TheMue, hey, welcome back! | 08:21 |
| dimitern | TheMue, how was CeBIT? | 08:21 |
| TheMue | dimitern: a bit lame, the booth has been more like a recreation area, so we got only few audience | 08:22 |
| TheMue | dimitern: but used the time to visit other cloud providers and to tell them about the benefits of juju | 08:22 |
| dimitern | TheMue, ah :) | 08:22 |
| TheMue | dimitern: e.g. a guy of amazon ;) | 08:22 |
| dimitern | TheMue, nice! did you get to play with some power machines? | 08:22 |
| TheMue | dimitern: sadly not, those few which are installed by IBM are directly used for individual software products | 08:24 |
| TheMue | dimitern: those have been the types of booths we should have | 08:24 |
| dimitern | TheMue, yeah, I see | 08:24 |
| TheMue | dimitern: and also there has been a larger open-source area with many smaller booths | 08:25 |
| TheMue | dimitern: here we would have matched too | 08:25 |
| TheMue | dimitern: will this morning write the report for John, together with some photos of the IBM OpenPOWER area | 08:25 |
| dimitern | TheMue, so how many people where visiting appox ? | 08:25 |
| dimitern | TheMue, ah, nice! I'd appreciate if you share this with us as well :) | 08:26 |
| TheMue | dimitern: actively? one! for the rest I had to catch the people. the guy of redislabls had the same problem | 08:26 |
| TheMue | dimitern: yes, will sent you and Alexis a copy | 08:26 |
| dimitern | TheMue, ok :) | 08:27 |
| TheMue | dimitern: at least we've got a partner here in Germany, selling Ubuntu and OpenStack services. he's interested in doing more with Juju | 08:27 |
| * TheMue also the next days has to create a new slide deck for his Juju/Go talk. thankfully already have a lot of material. | 08:29 | |
| TheMue | dimitern: seen many usual reviewing and mergin mails during these days. anything else important happened? | 08:30 |
| dimitern | TheMue, great! | 08:31 |
| dimitern | TheMue, well, we had 2 releases :) | 08:32 |
| dimitern | 1.22.0 and 1.23-beta1 | 08:32 |
| TheMue | dimitern: hehe, yes, I've seen. fantastic! | 08:32 |
| axw | dimitern: I figured out why my test wasn't working; my AZs are different, so I had to (temporarily) change the default AZ in ec2t_test.go | 08:52 |
| dimitern | axw, hmm - ok, just beware this might lead to some failures | 08:53 |
| axw | dimitern: it's the same with the existing tests | 08:53 |
| dimitern | axw, e.g. t1.micro not being available in some AZs, but used in a few live tests | 08:54 |
| axw | dimitern: there's a flawed assumption in the live tests. AZs are account-specific | 08:54 |
| dimitern | axw, huh? | 08:55 |
| dimitern | axw, you mean there might be less in some accounts | 08:55 |
| axw | dimitern: yes, and they might be different | 08:55 |
| axw | dimitern: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#using-regions-availability-zones-describe | 08:56 |
| axw | search for "might be different" | 08:56 |
| axw | err sorry | 08:56 |
| axw | "might not be the same" | 08:56 |
| axw | dimitern: I'd appreciate a review of https://github.com/go-amz/amz/pull/44 when you have a moment | 08:58 |
| dimitern | axw, well, I learned something today :) | 08:59 |
| dimitern | axw, sure, will have a look in a bit | 08:59 |
| wallyworld | fwereade: no idea how busy you are, i have a status-get PR that needs reviewing. as soon as this lands, I have a status-set one ready to propose. if you have time, awesome, if not fine too. both status-get and status-set tested live with a custom charm. http://reviews.vapour.ws/r/1252/ | 09:11 |
| fwereade | wallyworld, awesome, I will take a look in a mo; in the meantime, I am a little bit baffled by cmd/jujud/unit.go:152 which was apparently yours (a long time ago...) in commit ead4f3ee | 09:13 |
| wallyworld | let me look | 09:13 |
| fwereade | wallyworld, is the unit agent starting a container provisioner? if so, why? if not, why are we doing that there? | 09:13 |
| wallyworld | fwereade: just got called for dinner, i'll get back to you | 09:14 |
| fwereade | wallyworld, np | 09:14 |
| dooferlad | dimitern: Morning o/ | 09:15 |
| dimitern | dooferlad, morning o/ | 09:16 |
| dooferlad | dimitern: Just proposed that names change: http://reviews.vapour.ws/r/1253/ | 09:16 |
| dimitern | dooferlad, cheers, will have a look in a bit | 09:18 |
| axw | dooferlad: what is a "space"? | 09:51 |
| voidspace | axw: spaces are a juju specific networking term | 09:51 |
| dooferlad | axw: A space is a security subdivision of a network. | 09:51 |
| voidspace | axw: it means a named group of subnets | 09:51 |
| axw | ok | 09:51 |
| voidspace | axw: so you can have a space that spans several availability zones (for example) | 09:52 |
| natefinch | space seems like a terrible name | 09:55 |
| natefinch | if it means a group, why not call it a group? | 09:56 |
| voidspace | natefinch: I believe Mark picked it | 09:56 |
| dimitern | axw, I'll pull your branch and test it locally before sending the review | 09:57 |
| natefinch | voidspace: :/ | 09:57 |
| voidspace | natefinch: conceptually it forms a single network space though, not a "group of subnets" | 09:57 |
| axw | dimitern: cheers | 09:57 |
| voidspace | natefinch: the point is to not [have to] think of it as a group | 09:57 |
| axw | gotta go out, will check back later | 09:57 |
| voidspace | but a group is what it is... | 09:58 |
| axw | just a bike shed, but something with "network" in the name would be more helpful. netspace perhaps. but sounds like it's already decided | 09:59 |
| wallyworld | fwereade: that diff shows the machine and unit agents informing the upgrader what tools version they are running. not sure what you mean about starting a container provisioner. the container provisioner is in worker/provisioner and is run by the machine agent | 10:04 |
| dimitern | dooferlad, standup? | 10:04 |
| fwereade | wallyworld, oh, I see, you took it out of upgrader but didn't move the api method, I didn't look at the diff properly and thought you just hacked an extra call in | 10:08 |
| fwereade | wallyworld, why does container initialisation depend on what tools the agent has reported to the state server though># | 10:09 |
| wallyworld | it doesn't does it? i'd have to look at the code again | 10:09 |
| wallyworld | fwereade: the container init stuff in the diff is just a drive by logging change it seems | 10:10 |
| wallyworld | from trace -> info | 10:10 |
| fwereade | wallyworld, the commit claims it's fixing a bug in which container initialisation fails because the toools haven't been set | 10:10 |
| fwereade | wallyworld, damn sorry bbs | 10:11 |
| wallyworld | sure | 10:11 |
| wallyworld | fwereade: so, container_initialisation.go, that has NewContainerSetupHandler(), this does indeed create a Broker to start containers, it needs tools to do that (of the right version). all this is set up in the machine agent, not the unit agent | 10:14 |
| wallyworld | machine agent has ths code handler := provisioner.NewContainerSetupHandler(params) | 10:14 |
| wallyworld | so if tools haven't been set, then when machine agent starts the container handler, the handler can't work properly | 10:15 |
| fwereade | wallyworld, I don't see why a provisioner ever needs to ask the api server for its own tools though | 10:25 |
| fwereade | wallyworld, it *knows* its tools | 10:25 |
| fwereade | wallyworld, the only tools it's guaranteed to be capable of using to provision another machine are the ones it's running already | 10:26 |
| fwereade | wallyworld, independent of what it might have told anyone else | 10:26 |
| wallyworld | fwereade: to start a container, it needs the tools tarball | 10:27 |
| fwereade | wallyworld, right, but all it needs to know is the version it's running -- not the version a separate worker told some other dude it was running | 10:28 |
| fwereade | wallyworld, it can ask the apiserver for the tools tarball corresponding to version.Current.Number for the target arch | 10:29 |
| fwereade | wallyworld, in fact it *must*, lest bugs like that one | 10:29 |
| wallyworld | fwereade:looking at the code now, the container initialiser gets a ToolsFInder interface which does what you say above i think | 10:30 |
| wallyworld | the ToolsFinder method is on provisioner.State | 10:32 |
| wallyworld | i think but am not sure that version.Current is passed in, nd a tools list is returned | 10:32 |
| fwereade | wallyworld, yeah, I'm trying to follow those same threads :) | 10:33 |
| fwereade | wallyworld, so then I *think* we should be ok to revert the agent changes and put the SetTools back in Upgrader? | 10:34 |
| wallyworld | fwereade: i have no idea, i haven't enough context | 10:34 |
| fwereade | wallyworld, fair enough :) | 10:35 |
| wallyworld | the change in that commit is from a while ago isn't it | 10:35 |
| wallyworld | fwereade: is this for a particular new bug? | 10:37 |
| fwereade | wallyworld, this is just because I'm trying to do something saner with the unit agent and I noticed that call (which I expected to be in Upgrader) squatting in the middle of APIWorkers() | 10:49 |
| wallyworld | fwereade: ah i see, it was maybe expedient at the time, i honestly can't recall. sorry :-( | 10:50 |
| fwereade | wallyworld, no worries at all, I see it was a copy from a release branch ;) | 10:50 |
| fwereade | voidspace, hey, iirc you were involved with the proxy-settings weirdness | 10:52 |
| voidspace | fwereade: right | 10:52 |
| voidspace | fwereade: for my sins, which are many... | 10:53 |
| mgz | dooferlad: want to be a guinea pig? | 10:53 |
| mgz | I'm going to gate the juju/names package in a sec | 10:53 |
| fwereade | voidspace, so, AIUI, we encounter problems if proxy settings get set too late | 10:53 |
| voidspace | fwereade: correct | 10:53 |
| voidspace | fwereade: anything that needs network access shouldn't run until after the proxy settings are made | 10:54 |
| fwereade | voidspace, (1) why exactly is that and (2) does that mean we restart the whole agent when we get new proxy settings? | 10:54 |
| fwereade | voidspace, (and if not why not) | 10:54 |
| voidspace | fwereade: so it was contacting the charm store specifically that failed | 10:54 |
| voidspace | fwereade: so the charmrevisionworker was one thing that had problems | 10:54 |
| voidspace | fwereade: I didn't look at what happens when proxy settings change so I can't answer 2 | 10:55 |
| fwereade | voidspace, ok, I am slightly worried that all we've done is mask the problem then | 10:55 |
| voidspace | fwereade: deploying charms failing was the specific bug that caused me to look at the problem | 10:55 |
| voidspace | fwereade: we don't block on waiting for the proxy settings to be set | 10:56 |
| voidspace | fwereade: so we knew we had only made a partial fix, and there's a bug for *that* | 10:56 |
| fwereade | voidspace, and that's specifically in the unit agent trying to download them then? | 10:56 |
| voidspace | fwereade: I believe so | 10:56 |
| fwereade | voidspace, I feel like that ought to be a self-healing problem | 10:57 |
| voidspace | fwereade: the *only* fix I made was to move starting the proxyupdater to be one of the first workers started | 10:57 |
| fwereade | voidspace, uniter tries to download a charm, fails out, gets restarted in 3s, by which time the proxysettingsupdater has run | 10:57 |
| voidspace | so definitely a band-aid rather than a fix | 10:57 |
| voidspace | fwereade: it was failing hard | 10:57 |
| dooferlad | mgz: sounds good | 10:57 |
| fwereade | voidspace, *unless* the proxysettingsupdater doesn't actually work | 10:57 |
| voidspace | fwereade: moving it solved *that* problem | 10:58 |
| voidspace | it's possible there's a bug around charm download retrying (worker doesn't die properly - or more likely reports a failed deploy causing the deploy to be cancelled and not retried?) | 10:59 |
| fwereade | voidspace, ok, I think I'll just try to preserve your approach and comment it | 11:00 |
| voidspace | cool | 11:00 |
| fwereade | voidspace, (and, hmm, I don't *think* that'd happen -- now or before -- I'm pretty sure the only special error is ErrConflict, and that only happens well after the charm is downloaded and verified) | 11:04 |
| fwereade | voidspace, (while I remain deeply suspicious about what *actually* happens to the http module when the magic env vars are changed from some random goroutine...) | 11:06 |
| dimitern | voidspace, hey | 11:14 |
| dimitern | voidspace, just about finishing the review on the addresser | 11:14 |
| dimitern | voidspace, considering you're already using interfaces for both the state and environ methods you need, why not just mock those in the test? | 11:15 |
| voidspace | dimitern: I did initially, but it's lot more work than just using the dummy provider | 11:16 |
| voidspace | dimitern: for no particular gain | 11:16 |
| dimitern | voidspace, really? | 11:16 |
| dimitern | voidspace, how so? | 11:16 |
| voidspace | dimitern: well I had an implementation of a mockReleaser and types for storing the calls | 11:17 |
| voidspace | dimitern: and then you call NewWorkerWithReleaser | 11:17 |
| voidspace | dimitern: instead of just breaking the environ method and listening on a channel to get the call | 11:17 |
| dimitern | voidspace, yeah | 11:18 |
| voidspace | dimitern: so I deleted my mockReleaser and ReleaseCall types - they just seemed unnecessary | 11:18 |
| mgz | dooferlad: okay, land with $$merge$$ in the mp when ready | 11:19 |
| dimitern | voidspace, there's juju/testing stub already there to support calling a type and inspecting the received calls | 11:19 |
| mgz | dooferlad: it's a more complex project, so may break first try, we'll see | 11:19 |
| voidspace | fwereade: the default Http transport we use specifically checks the environment variables | 11:19 |
| voidspace | dimitern: ok, interesting - I *am* having a problem right now with listening on the dummy channel | 11:20 |
| voidspace | dimitern: I seem to get the same call twice instead of the two different calls I expect | 11:20 |
| voidspace | dimitern: so maybe I should switch back | 11:20 |
| dimitern | voidspace, it does seem a bit more complicated than it needs to be | 11:20 |
| dimitern | voidspace, I'll add some comments with pointers | 11:21 |
| voidspace | dimitern: adding a mockReleaser won't make it less complicated | 11:21 |
| voidspace | dimitern: if you look at the latest diff the tests are quite clean now | 11:21 |
| voidspace | not that they're all passing... | 11:22 |
| voidspace | TestWorkerReleasesAlreadyDead doesn't get the correct release ops... | 11:22 |
| voidspace | dimitern: but thanks, I will appreciate comments! | 11:23 |
| dimitern | voidspace, ok, I really need to go out and catch the DMV before lunch break now | 11:23 |
| voidspace | dimitern: cool | 11:23 |
| voidspace | dimitern: I got your email - it looks fine by the way | 11:23 |
| dimitern | voidspace, I'll send the review I have so far and continue when I'm back - mostly tests remain | 11:23 |
| voidspace | dimitern: but enjoy the DMV... | 11:23 |
| voidspace | dimitern: ok | 11:24 |
| dimitern | :D yeah\ | 11:24 |
| dooferlad | mgz: waiting for bot... | 11:24 |
| dooferlad | mgz: library problem in Jenkins run | 11:25 |
| mgz | dooferlad: ta, checking | 11:25 |
| mgz | hm, go get golang.org/x/crypto and go get golang.org/x/crypto/... both exit non-zero for me | 11:30 |
| mgz | that's a bit of an issue | 11:30 |
| mgz | what's names actually using... | 11:30 |
| mgz | testing, utils, and mgo.v2 use various bits | 11:33 |
| natefinch | wwitzel3: I got ensure-availability --to 1,2 working, although it requires a manual reset of jujud... I think mongo just didn't have time to initialize before we restarted.... not sure why it's different in this case from a normal state server creation. | 11:33 |
| mgz | but only utils needs the custom one, and only pbkdf2 and ssh | 11:35 |
| mgz | dooferlad: landed | 11:37 |
| mgz | the log is a bit annoyingly out of order, I probably need to throw in flushes | 11:37 |
| dooferlad | mgz: cool. Thanks! | 11:37 |
| fwereade | voidspace, https://bugs.launchpad.net/juju-core/+bug/1403225 | 11:44 |
| mup | Bug #1403225: charm download behind the enterprise proxy fails <cloud-installer> <deploy> <proxy> <sync-tools> <cloud-installer:Fix Released by adam-stokes> <juju-core:Fix Released by mfoord> <juju-core 1.21:Won't Fix> <juju-core 1.22:Fix Released by mfoord> <https://launchpad.net/bugs/1403225> | 11:44 |
| fwereade | voidspace, comments 20-21 seem to indicate that unconditionally setting the env vars was sufficient to get a unit deploying | 11:45 |
| fwereade | voidspace, and charmrevisionworker is only needed on state servers iirc | 11:46 |
| fwereade | voidspace, was there another motivation for starting it early in the unit agent? | 11:47 |
| voidspace | fwereade: I believe I was mistaken about unconditionally setting the env vars | 12:00 |
| voidspace | fwereade: as once I'd started the proxyupdater early unconditionally setting env vars was not needed, but was considered harmless | 12:01 |
| voidspace | fwereade: my final conclusion was that the existing logic around setting env vars was correct, just started too late | 12:01 |
| voidspace | fwereade: and I didn't move charmrevisionworker - I moved proxyupdater | 12:01 |
| fwereade | voidspace, isn't it necessary? I strongly suspect it's possible for proxy settings to change | 12:01 |
| voidspace | fwereade: it is possible, but the logic that determines that was correct | 12:02 |
| fwereade | voidspace, right, but cmd/jujud/unit.go:158 | 12:02 |
| fwereade | voidspace, the unit agent doesn't run a crw | 12:02 |
| voidspace | fwereade: there was a suspicion that the logic around *first setting* was faulty - but that proved to be incorrect | 12:02 |
| voidspace | fwereade: but *anything* that needs external network access will need the proxy settings in place | 12:03 |
| voidspace | fwereade: so if we have proxy settings it seems like they ought to be put in place before we do anything else | 12:03 |
| fwereade | voidspace, but anything that doesn't have the proper network settings in place should just be exiting with an error and coming back up in a bit | 12:03 |
| fwereade | voidspace, and that will be everything that needs network access if the proxy settings change while an agent's running | 12:04 |
| voidspace | fwereade: if the agent is in process then it won't be a problem - the proxyupdater handles change to env vars without needing to restart | 12:04 |
| fwereade | voidspace, right, and so it's similarly not a problem if we start up with the wrong proxy settings | 12:05 |
| fwereade | voidspace, it's inelegant to bounce up and down drunkenly before settling, true | 12:05 |
| voidspace | fwereade: however in practise it *was a problem* (and is now less of a problem) | 12:05 |
| voidspace | fwereade: you're probably correct that moving the proxyupdater was papering over some other problem | 12:05 |
| voidspace | (why didn't charm download get retried) | 12:05 |
| fwereade | voidspace, there are two cases though | 12:05 |
| voidspace | however it did solve the immediate problem (which was specifically - demo in 3 days need a fix released) | 12:06 |
| voidspace | fwereade: I think charm revision worker was set to only retry once a day | 12:06 |
| voidspace | fwereade: and to *not* die on error | 12:07 |
| fwereade | voidspace, (I am not trying to rag on what you've done, just trying to work out what I can do that is not going to break stuff) | 12:07 |
| voidspace | but that's only on state server | 12:07 |
| voidspace | sure, no problem | 12:07 |
| voidspace | I'm just explaining *why* we went with that fix :-) | 12:07 |
| voidspace | "because it worked", essentially | 12:07 |
| fwereade | voidspace, yay empiricism :) | 12:08 |
| voidspace | but also worked for a sensible reason | 12:08 |
| fwereade | voidspace, I am comfortable with the machine agent fix | 12:08 |
| voidspace | fwereade: take the fix out on the unit agent, and try charm deploy behind a proxy | 12:09 |
| voidspace | fwereade: it maybe that the problem was charm download on the state server and the unit agent fix wasn't needed at all | 12:09 |
| fwereade | voidspace, that's the story I'm hesitantly inferring from the discussion on the bug | 12:10 |
| fwereade | voidspace, I'll look into it, thanks | 12:10 |
| voidspace | you may well be right | 12:10 |
| voidspace | fwereade: I wrote up reasonably simple instructions for creating a restricted environment to deploy juju to with kvm and ufw | 12:10 |
| voidspace | and the manual provider | 12:10 |
| fwereade | voidspace, hey actually I suddenly feel more sure of myself -- hasn't the unit agent always downloaded its charms from either the state server or environment storage? | 12:11 |
| fwereade | voidspace, I suppose it's not impossible that environment storage might go via proxy | 12:12 |
| fwereade | voidspace, but now we're always getting them from the state server I think | 12:12 |
| voidspace | fwereade: however, if the problem was proxy settings on the state server | 12:12 |
| voidspace | fwereade: the deploy command can only have been issued after the state server was running | 12:12 |
| voidspace | fwereade: so the "order we start workers on the state server" cannot have been the problem | 12:13 |
| voidspace | maybe it was environment storage access | 12:14 |
| voidspace | brb | 12:14 |
| * TheMue is at lunch | 12:21 | |
| voidspace | going on lunch | 13:01 |
| === Spads_ is now known as Spads | ||
| * dimitern is back | 13:21 | |
| mattyw | dimitern, just in time, got a moment? | 13:24 |
| dimitern | mattyw, hey, yeah | 13:24 |
| alexisb | morning/evening all | 13:25 |
| dimitern | alexisb, morning :) | 13:33 |
| dooferlad | alexisb: o/ | 13:33 |
| mup | Bug #1435857 was opened: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435857> | 13:44 |
| mup | Bug #1435860 was opened: certSuite.TestNewDefaultServer failure <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1435860> | 13:44 |
| sinzui | dimitern, natefinch : we need some to do many fixes or many rollbacks to address bug 1435857 | 13:45 |
| mup | Bug #1435857: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435857> | 13:45 |
| natefinch | alexisb: btw, made more progress on the HA feature. Works other than requiring me to kill jujud to make it restart... I am restarting it in code, but evidently it's not waiting for mongo to be ready or something similar. So just have to figure that out. | 13:45 |
| dimitern | sinzui, oh boy, let me have a look | 13:45 |
| alexisb | natefinch, awesome, thank you | 13:45 |
| dimitern | dooferlad, you have a review on the net cli PR | 13:45 |
| dooferlad | dimitern: thanks! | 13:46 |
| natefinch | dimitern, sinzui: gah, these stupid series bugs kill me | 13:47 |
| dimitern | natefinch, and it's always before a release, right? :) | 13:47 |
| sinzui | natefinch, but the irony is the commit it to ensure we can register the next series. Life is cruel | 13:47 |
| natefinch | dimitern: heh yep | 13:47 |
| === Spads_ is now known as Spads | ||
| tasdomas | dimitern, ping? | 13:55 |
| dimitern | tasdomas, pong | 13:58 |
| tasdomas | dimitern, hi - when you have a sec, could you take a look at http://reviews.vapour.ws/r/1070/ ? | 13:59 |
| dimitern | tasdomas, hey, sure, I'll have a look shortly | 13:59 |
| dooferlad | dimitern, TheMue, voidspace: networking interlock hangout time | 14:01 |
| TheMue | dooferlad: oh, thx | 14:01 |
| === kadams54 is now known as kadams54-away | ||
| === Spads_ is now known as Spads | ||
| voidspace | dooferlad: dammit, sorry | 14:19 |
| dimitern | voidspace, you haven't missed anything important - check the agenda/minutes doc from the meeting if you like | 14:28 |
| voidspace | dimitern: I will do, thanks | 14:30 |
| voidspace | dimitern: and thanks for the review | 14:30 |
| voidspace | working on it | 14:30 |
| dimitern | voidspace, np, I'm trying out a few suggestions around the tests locally before commenting | 14:31 |
| voidspace | ok | 14:33 |
| voidspace | dimitern: when you changed network.NewAddress you didn't change the ones in my PR | 14:41 |
| voidspace | dammit | 14:41 |
| dimitern | voidspace, I've only changed those in master | 14:42 |
| voidspace | dimitern: that's terrible | 14:42 |
| dimitern | voidspace, :) | 14:42 |
| voidspace | you're creating extra work! | 14:42 |
| dimitern | voidspace, ok, my bad then | 14:42 |
| voidspace | :-) | 14:43 |
| dimitern | voidspace, if it's so bad it deserves compensation, I'll give you one of the beers I promised in nuremberg :) | 14:43 |
| voidspace | haha | 14:43 |
| dimitern | s/I promised/I'm promised/ | 14:43 |
| voidspace | so I owe you one less then... | 14:44 |
| dimitern | I need to open a spreadsheet and tally them up :) | 14:44 |
| mgz | you need to not get alchohol poisoning :P | 14:45 |
| voidspace | dimitern: you want me to test that a no-op does nothing! (Test calling EnsureDead doesn't trigger a watcher...) | 14:46 |
| voidspace | dimitern: EnsureDead has an early return - which is tested | 14:46 |
| dimitern | voidspace, hmm | 14:46 |
| voidspace | dimitern: I don't think you're testing any code in the worker there | 14:46 |
| dimitern | voidspace, well, ok - change something else then | 14:46 |
| dimitern | voidspace, e.g. call SetState on a new alive address | 14:47 |
| voidspace | dimitern: but that's testing the watcher, which is a lifecycle watcher | 14:47 |
| voidspace | dimitern: so that's testing the lifecycle watcher not the worker | 14:47 |
| voidspace | dimitern: maybe change it to Dying? | 14:47 |
| voidspace | although there's no way to do that | 14:47 |
| dimitern | voidspace, hmm - exactly | 14:47 |
| voidspace | so, maybe there's no need to test it then | 14:47 |
| dimitern | voidspace, that test looked like it's testing the watcher | 14:48 |
| voidspace | dimitern: it's testing that the worker does something when the watcher is triggered | 14:48 |
| voidspace | dimitern: maybe I can create a new addres | 14:48 |
| voidspace | dimitern: which will have a life of Alive | 14:48 |
| voidspace | dimitern: and test that the worker doesn't kill it | 14:48 |
| voidspace | which I don't think is tested already | 14:48 |
| voidspace | the watcher will be triggered and there's code in the worker to check the Life, so that's a good test that's missing | 14:49 |
| dimitern | voidspace, ok, I'll have another look in case I've missed something | 14:50 |
| === kadams54-away is now known as kadams54 | ||
| dimitern | tasdomas, you've got a review | 15:01 |
| tasdomas | dimitern, much appreciated | 15:02 |
| dimitern | dooferlad, yours is also good to go | 15:06 |
| ericsnow | sinzui: I'm not sure what to make of it yet, but lxc-start just worked for me on vivid-slave-b | 15:06 |
| sinzui | ericsnow, updates arrived? | 15:07 |
| dimitern | voidspace, ah, you know what - I won't manage to finish that review with the mocked tests | 15:07 |
| ericsnow | sinzui: I expect so (but don't know) | 15:07 |
| dimitern | voidspace, just make sure it works reliably as-is, and let's go on | 15:07 |
| sinzui | ericsnow, I see more updates are available | 15:07 |
| voidspace | dimitern: ok, the tests are still a bit of a WIP anyway | 15:08 |
| voidspace | done today though | 15:08 |
| voidspace | reversing a string in umpteen languages. Go is amongst the longest. | 15:08 |
| voidspace | http://rosettacode.org/wiki/Reverse_a_string | 15:08 |
| dimitern | voidspace, it's fine, and I'm sure we'll get better very soon at writing tests with the stubs, esp. around the CLI work | 15:08 |
| voidspace | dimitern: cool | 15:08 |
| dimitern | :) | 15:08 |
| voidspace | dimitern: I did a version with stubs | 15:08 |
| voidspace | dimitern: but I wanted some actually hitting the provider as well - and they actually looked nicer | 15:09 |
| ericsnow | sinzui: and I just noticed that local-deploy-vivid-amd64 passed in 2473! | 15:09 |
| dimitern | voidspace, yeah, fair point | 15:09 |
| sinzui | ericsnow, \o/ | 15:09 |
| dimitern | dooferlad, sadly nobody will hear your $$merge$$ on that branch | 15:10 |
| sinzui | ericsnow, I am retesting the rev right now in CI ti give it another change to pass | 15:10 |
| dooferlad | dimitern: darn it! | 15:10 |
| ericsnow | sinzui: k | 15:10 |
| dimitern | dooferlad, or maybe I'm wrong? | 15:10 |
| dooferlad | dimitern: indeed | 15:10 |
| * ericsnow struggles to hold back the tears | 15:10 | |
| marcoceppi_ | hey dooferlad dimitern `juju space` is a terrible cmd name | 15:11 |
| sinzui | ericsnow, yep, I was so focused on the failures, I didn't see the pass in my open tab: http://reports.vapour.ws/releases/2473 | 15:11 |
| sinzui | I hope the precise failures were bad luck | 15:11 |
| ericsnow | sinzui: I so wish I had thought to check the LXC container log weeks ago! | 15:11 |
| ericsnow | sinzui: same here | 15:12 |
| dooferlad | marcoceppi_: i am following a spec for that. I am sure dimitern is happy to hear suggestions. | 15:12 |
| sinzui | ericsnow, we will see it pass again in about an hour. | 15:12 |
| marcoceppi_ | dooferlad dimitern why not `juju net` or `juju network` juju space is vague and will be hard to convey to people when talking | 15:12 |
| marcoceppi_ | dimitern: link to spec? I was about to comment but I missed it by 2 minutes :( | 15:13 |
| ericsnow | sinzui: awesome | 15:13 |
| sinzui | ericsnow, I think the bug is fix-released | 15:13 |
| dimitern | marcoceppi_, we have a verbal agreement to change it to "net-space" or something like that if it's too confusing | 15:13 |
| marcoceppi_ | but what even is "space" reading the code I had a hard time figuring it out | 15:13 |
| dimitern | marcoceppi_, pm you a link | 15:13 |
| dooferlad | marcoceppi_: https://docs.google.com/a/canonical.com/document/d/1Z7pWB-MT5UboTpeDCZWZtcp1blbrM0xiuqik-CWEaZ8/edit# | 15:14 |
| * dimitern is afk for a bit | 15:14 | |
| dooferlad | dimitern: IRC race condition! | 15:14 |
| mup | Bug #1432421 changed: vivid local failed to retrieve the template to clone <deploy> <local-provider> <vivid> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.23:Fix Released by ericsnowcurrently> <https://launchpad.net/bugs/1432421> | 15:14 |
| marcoceppi_ | dimitern: I'm a strong +1 for net-space, space is just too vague of a name in my opinion (imagine telling someone to type a command 'just type juju space..."space") | 15:16 |
| natefinch_ | marcoceppi_: good point on confusing space w/ spacebar-space | 15:23 |
| voidspace | I'm thinking of changing my email address to dot-space.dash@voidspace.org.uk | 15:23 |
| natefinch_ | voidspace: lol awesome | 15:24 |
| jw4 | voidspace: hilarious | 15:24 |
| marcoceppi_ | haha | 15:24 |
| voidspace | not my joke, but still funny | 15:24 |
| natefinch_ | voidspace: what you really need to do is change *someone else's* email to that | 15:24 |
| voidspace | natefinch_: heh, like my parents... | 15:24 |
| === natefinch_ is now known as natefinch | ||
| natefinch | cmars: why do we care that v5 is unstable? stability only matters to third parties and past releases. | 15:26 |
| cmars | natefinch, the unstable suffix is a gopkg convention for better or worse | 15:29 |
| natefinch | cmars: yes but, you're choosing to use it, and I don't understand why | 15:30 |
| cmars | natefinch, API versioning is used in a very strict sense here. if we branch something as "v5" then there are very specific rules about what can be changed in that branch and still be called v5 | 15:30 |
| cmars | natefinch, see http://labix.org/gopkg.in, heading "When to change the version" | 15:31 |
| natefinch | cmars: in theory, yes. But it's all convention. There nothing actually enforcing it | 15:31 |
| rick_h_ | natefinch: what's the harm? we've been bitten in the past with this where the api changed out from under things without a naming update. | 15:31 |
| cmars | natefinch, lying about API versions isn't nice | 15:32 |
| natefinch | rick_h_: it's just unnecessary churn. We already use godeps, so nothing can get broken from changes to the v5 repo... and then all you have to do is update the line in dependencies.tsv to point at the new revision | 15:32 |
| rick_h_ | natefinch: right, but when that update to the dep.tsv file is done it seems reasonable that a sanity check would be to find all use of something and make sure nothing between those revisions changed and would break the code? | 15:33 |
| rick_h_ | natefinch: or do you all just rely on CI/tests to catch it all? | 15:33 |
| cmars | natefinch, its not unnecessary. its explicit. by importing a v5-unstable, you're saying, "yes, I know this package may change its API contract, and I'm ok with that" | 15:33 |
| cmars | natefinch, by changing that to a "v5" proper, you're saying, I depend on this v5 API contract. its kind of similar to what we do for facade versions | 15:34 |
| cmars | natefinch, its also a nice indicator that adds pressure in the right places. if you see an unstable API import, it should make us all think about what it takes to stabilize the APIs we import. | 15:36 |
| natefinch | cmars, rick_h_: ok ok :) I guess if we can't just land all the changes for v5 in core at once, it's a useful marker to say "hey, this is not safe to release as-is" | 15:39 |
| mattyw | I'm staying out of this - but it's worth a simple reminder that core isn't the only "large" project that uses the charm package | 15:40 |
| rick_h_ | mattyw: lol, sucessfully dodged there :P | 15:40 |
| natefinch | mattyw: sure. but it's still all "us" | 15:41 |
| cmars | natefinch, thanks. yes, we want to release stable APIs. definitely. | 15:41 |
| dimitern | dooferlad, that test failure is genuine btw | 15:42 |
| natefinch | cmars: it sort of feels like landing broken code in master, is all. If we're intentionally landing code we know we can't release | 15:42 |
| dooferlad | dimitern: I know | 15:43 |
| dooferlad | dimitern: I missed the dependencies.tsv update | 15:43 |
| dimitern | dooferlad, ah, good point | 15:43 |
| cmars | natefinch, unstable here does not mean broken. it has a very precise meaning: "the package API is subject to change" | 15:43 |
| dimitern | dooferlad, but how about the main tests in cmd/juju? | 15:43 |
| natefinch | cmars: I said "sort of" :) .... it's code that means we can't release until it's fixed. | 15:44 |
| dooferlad | dimitern: just running them. Will see. | 15:45 |
| urulama | natefinch, cmars: out of curiosity, this v5-unstable change does not influence the 1.23 code, right? | 15:47 |
| urulama | natefinch, cmars: it should only be included for 1.24, for which we have enough time to make it into proper "v5" | 15:48 |
| natefinch | I promise I'm not trying to be a pain in the ass... It's just that this will become precedent, and we'll have to start doing it with every versioned package, so I want to make sure the process is well thought out. | 15:49 |
| cmars | urulama, right, its only for master | 15:49 |
| dooferlad | dimitern: you were right, looks like I missed adding "space" to a big array of strings. | 15:49 |
| dimitern | cmars, natefinch, urulama, btw, let's not release a version depending on anything -unstable, as I commented on that thread | 15:50 |
| urulama | dimitern: yes, 100% agree on that | 15:50 |
| dimitern | dooferlad, yep, that's it | 15:50 |
| dimitern | urulama, cool | 15:51 |
| dimitern | as a temporary step towards v5 it fine though IMO | 15:52 |
| dimitern | it's | 15:52 |
| natefinch | I think it's fine, or at least, close enough to fine that I don't need to argue about it any more. :) | 15:53 |
| urulama | natefinch: :) next time we introduce something "-unstable", we'll do proper announcement to avoid any "wth is this thing doing here" mild-hear-attacks :) | 15:55 |
| dimitern | urulama, it doesn't count unless there's also special landing page about it on ubuntu.com :D | 15:58 |
| urulama | dimitern: what about on jujucharms.com, we can do that :) | 15:59 |
| dimitern | urulama, tempting :) | 15:59 |
| dimitern | dooferlad, it looks like the bot doesn't love you today | 16:01 |
| dooferlad | dimitern: well, I haven't pushed the last fix yet. Thought at this rate I should tests on my machine(s) before trying again. | 16:02 |
| dimitern | dooferlad, :) | 16:03 |
| dimitern | ok, I think I should call it a day | 16:04 |
| dooferlad | dimitern: have a good evening! | 16:04 |
| dimitern | dooferlad, cheers, same to you! | 16:04 |
| natefinch | finally... disabled the stupid ctrl+q and ctrl+w so I don't accidentally close windows when I typo ctrl-s or ctrl-a | 16:12 |
| natefinch | ericsnow: btw, that code to restart the jujud service works like a charm | 16:24 |
| ericsnow | natefinch: awesome | 16:25 |
| ericsnow | natefinch: are you going to fix restore too? | 16:25 |
| natefinch | ericsnow: yeah, I'll do it as a separate patch after | 16:25 |
| ericsnow | cool | 16:25 |
| natefinch | ericsnow: it unfortunately (and totally unsurprisingly) does nothing to help make what happens after the restart work better. | 16:27 |
| cmars | sinzui, how is LP: #1435857 different from LP: #1427879 ? | 16:27 |
| mup | Bug #1435857: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1435857> | 16:27 |
| mup | Bug #1427879: juju cannot deploy when distro-info-data gets a new series <deploy> <series> <juju-core:Fix Committed by wallyworld> <juju-core 1.22:Fix Committed by wallyworld> <juju-core 1.23:Fix Committed by wallyworld> <https://launchpad.net/bugs/1427879> | 16:27 |
| cmars | sinzui, and does master need to be blocked on these? | 16:28 |
| sinzui | cmars, we cannot 80% of the tests because of that bug | 16:29 |
| sinzui | cmars, merging a an unproven change into every branch was risky | 16:29 |
| sinzui | cmars, master can be made unaffected by rolling the change out | 16:30 |
| sinzui | cmars, that bug is so massive that few tests can be run http://reports.vapour.ws/releases/2477 | 16:30 |
| cmars | sinzui, ok, thanks | 16:31 |
| ericsnow | sinzui: generate-docs.py (indirectly) runs juju. In the publish-revision job, which juju is it running? | 16:49 |
| ericsnow | sinzui: I would expect it to be the one that is being built, but it looks like it just gets juju from $PATH | 16:50 |
| sinzui | ericsnow, we are retesting an older rev of master hoping to find a bless | 16:50 |
| sinzui | ericsnow, I imaging you can reproduce the problem by running juju version using tip of any branch. Append a series to /usr/share/distro-info/ubuntu.csv | 16:51 |
| ericsnow | sinzui: I did that and it worked fine for me (added the Angsty one from the bug) | 16:52 |
| sinzui | ericsnow, That command was run in chroot building a package | 16:52 |
| ericsnow | sinzui: I should clarify, generate-doc.py finished successfully | 16:53 |
| sinzui | ericsnow, sorry, in meeting. | 17:05 |
| ericsnow | sinzui: np | 17:05 |
| sinzui | ericsnow, since packaging find this, and packaging is in a chroot, I think the angsty issue may not be in play. The only juju that can be used it the juju that was just built | 17:05 |
| mup | Bug #1435974 was opened: Copyright information is not available for some files <juju-core:New> <https://launchpad.net/bugs/1435974> | 17:09 |
| sinzui | ericsnow, when I am out of a meeting I will find the build script any of us can run locally with atarball | 17:13 |
| ericsnow | sinzui: k, thanks | 17:13 |
| === kadams54 is now known as kadams54-away | ||
| fwereade | gaaaaaaaah import cycles | 17:27 |
| === kadams54-away is now known as kadams54 | ||
| sinzui | ericsnow, yuck. Ci still doesn't save the successful source packages. I need to write up the steps that went from release tarball to build-package-with-dsc. I now suspect that since a chroot was involved, that NO the systems didn't have distro-info-data at all. | 18:11 |
| ericsnow | sinzui: I just updated the bug with what I've found (sans solution) | 18:13 |
| ericsnow | sinzui: the only way we would see the panic we do is if /usr/share/distro-info/ubuntu.csv was there and only slightly invalid (with respect to juju's expectations) | 18:14 |
| sinzui | ericsnow, I don't this vivid is an issue. publish-revision fails the first time it tries to make binary packages. Vivid just happens to be the first source package it is trying to make | 18:15 |
| ericsnow | sinzui: juju expects lines in that file to look like: "12.04 LTS,Precise Pangolin,precise,2011-10-13,2012-04-26,2017-04-26" | 18:15 |
| ericsnow | sinzui: from the logs I looked at utopic passed before it failed with vivid | 18:15 |
| ericsnow | sinzui: build-1625 | 18:16 |
| sinzui | oh, I missed that | 18:16 |
| sinzui | ericsnow, I see | 18:17 |
| ericsnow | sinzui: either that CSV file is busted on the slave on which we're building, they've released a busted file, or they've changed the format | 18:17 |
| sinzui | uhg | 18:17 |
| * sinzui thinks | 18:17 | |
| ericsnow | sinzui: it's on vivid-slave | 18:18 |
| ericsnow | sinzui: would it be the /usr/share/distro-info/ubuntu.csv that is still there? | 18:19 |
| ericsnow | sinzui: if so we can take a look at the file and see what's going on | 18:19 |
| sinzui | yes, the same slave that unit-tests run on. run-unit-test added the angsty line to ensure juju doesn't assume the series in ubuntu.csv | 18:19 |
| mup | Bug #1435999 was opened: juju run should have an --all-units option, --all is ambiguous and confusing <juju-core:New> <https://launchpad.net/bugs/1435999> | 18:21 |
| wwitzel3 | is there docs for the dev flow if you need to update a /juju package, that we import using gopkg.in? In this case, I have some changes to juju/charm | 18:26 |
| wwitzel3 | do I just change the import and then ensure the landing order is such that I update the import after the dep lands and have a new gopkg.in version? | 18:28 |
| katco | wwitzel3: i can't recall having to do that; what you suggest certainly sounds reasonable. | 18:33 |
| katco | wwitzel3: thumper would be a good person to ask; i think he's done a lot of work with juju/testing | 18:34 |
| sinzui | ericsnow, these are the two bugs I reported about vivid unit test https://bugs.launchpad.net/juju-core/+bug/1433577 and https://bugs.launchpad.net/juju-core/+bug/1408459 | 18:38 |
| mup | Bug #1433577: Vivid unit tests need to pass <ci> <test-failure> <vivid> <juju-core:Triaged> <https://launchpad.net/bugs/1433577> | 18:38 |
| mup | Bug #1408459: pingerSuite tests consistenly fail on trusty+386 and vivid+amd64 <ci> <i386> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1408459> | 18:38 |
| ericsnow | sinzui: I'll take a look at the failing tests in the most recent runs | 18:42 |
| sinzui | ericsnow, CI completed the build on vivid. I need to see a few more machines complete though. I fear more than one ubuntu.csv was tampered with | 18:45 |
| ericsnow | sinzui: okay | 18:46 |
| ericsnow | sinzui: looking at the most recent vivid unit test failures, there's a possibility that they could pass on the next build on master | 18:50 |
| sinzui | :) | 18:50 |
| ericsnow | sinzui: if not, they're pretty close to passing and I'll work on getting that resolved | 18:50 |
| ericsnow | natefinch: were you going to be able to review my two patches? | 18:54 |
| natefinch | ericsnow: yes, sorry, been heads down on the HA stuff, but I shouldn't shirk my reviewing responsibilities either | 18:56 |
| natefinch | ericsnow: I'll look now | 18:56 |
| ericsnow | natefinch: thanks | 18:56 |
| natefinch | katco: just saw your comment here about AgentConf doing too much.... what, passing effectively four copies of it to a single function is too much? :) https://github.com/juju/juju/blob/master/cmd/jujud/main.go#L126 | 19:13 |
| katco | natefinch: haha | 19:13 |
| katco | natefinch: you see why i did that though right? does the comment make sense? | 19:14 |
| natefinch | katco: not to mention that the line there is like embedding three factories into each other | 19:14 |
| natefinch | katco: oh yeah, totally | 19:15 |
| natefinch | katco: it makes it very clear that agentConf is doing too much, and in theory makes it easy to break out part of the functionality into separate bundles | 19:15 |
| katco | natefinch: ok good. at first glance i was like, "what the hell kind of code did i write?" | 19:15 |
| natefinch | I do like that the line is effectively | 19:16 |
| natefinch | jujud.Register(agentcmd.NewMachineAgentCmd(agentcmd.MachineAgentFactoryFn(&agentConf, &agentConf), &agentConf, &agentConf) | 19:16 |
| katco | hehe | 19:16 |
| natefinch | and by like... I mean it's atrocious, but I know that's not your fault :) | 19:16 |
| katco | natefinch: that is a great trick for breaking up large things: define finer-grained interfaces -- all of which the large thing implements. then you can peel off functionality | 19:16 |
| natefinch | katco: this is my favorite use of interfaces.... lets the function only call out what it needs, then you can replace what you pass it with impunity. | 19:17 |
| katco | the definition of an interface :) | 19:17 |
| * katco back to reading a spec full-screen. ping me if you need my attention. | 19:19 | |
| natefinch | :) | 19:19 |
| natefinch | sinzui: seen this? https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-03-23 | 19:24 |
| sinzui | natefinch, I had not, but that is exactly why Ubuntu removed it from its packages | 19:26 |
| mup | Bug #1435857 changed: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-ci-tools:Fix Released> <juju-core:Invalid> <juju-core 1.22:Invalid> <juju-core 1.23:Invalid> <https://launchpad.net/bugs/1435857> | 19:27 |
| ericsnow | natefinch: of my 2 patches, could you take a look at http://reviews.vapour.ws/r/1233/ first? | 19:32 |
| natefinch | ericsnow: looking | 19:33 |
| ericsnow | natefinch: thanks | 19:34 |
| mup | Bug #1435857 was opened: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-ci-tools:Fix Released> <juju-core:Invalid> <juju-core 1.22:Invalid> <juju-core 1.23:Invalid> <https://launchpad.net/bugs/1435857> | 19:36 |
| === kadams54 is now known as kadams54-away | ||
| mup | Bug #1435857 changed: panic: osVersion reported an error: Could not determine series <ci> <packaging> <regression> <vivid> <juju-ci-tools:Fix Released> <juju-core:Invalid> <juju-core 1.22:Invalid> <juju-core 1.23:Invalid> <https://launchpad.net/bugs/1435857> | 19:48 |
| natefinch | 3 hours sleep makes me a much slower reviewer, I've figured out | 19:52 |
| === kadams54-away is now known as kadams54 | ||
| natefinch | thumper: I know you have a stand up now, but afterward, I'd like to ask about why workers can all shutdown like this, and not cause jujud restart: http://paste.ubuntu.com/10672321/ | 20:00 |
| katco | natefinch: i know your pain. i *know* it... | 20:00 |
| katco | natefinch: re: 3h of sleep | 20:01 |
| katco | natefinch: i was sick all last weekend, and my daughter decided this was the perfect time to stay up all night, every night, growing teeth. | 20:01 |
| natefinch | katco: heh.. yeah, the baby normally sleeps great, but last night he decided it was time to wake up at 3am.. tried for an hour and a half to get him to go back to sleep to no avail. So I got up with him, made some coffee... and of course then he fell asleep. Since I have been getting up at 5am, I decided to just stay up | 20:01 |
| natefinch | katco: ouch | 20:02 |
| * katco nods | 20:02 | |
| katco | the only positive was that it was the weekend | 20:02 |
| katco | but was up at 4:30 this morning o.0 | 20:02 |
| natefinch | katco: I feel ya | 20:03 |
| natefinch | ericsnow: https://github.com/juju/utils/blob/master/shell/renderer.go#L41 passing "" to indicate runtime.GOOS is very non-intuitive, IMO. | 20:04 |
| * natefinch loves that github has blame just a click away ;) | 20:05 | |
| ericsnow | natefinch: :) | 20:05 |
| ericsnow | natefinch: it's meant to be a convenience so you don't have to import runtime for what should be the common case | 20:05 |
| natefinch | ericsnow: I'd prefer to split it out into a separate function. Actually... the fact that you pass in a bunch of magic strings into this function is suboptimal in general. | 20:06 |
| ericsnow | natefinch: if it is confusing then it would probably be better to not bother | 20:07 |
| natefinch | ericsnow: renderer.NewOSRenderer() | 20:07 |
| ericsnow | natefinch: ah, that would work | 20:07 |
| natefinch | ericsnow: actually... these are all publicly exposed values it's returning... why does this method need to exist? | 20:08 |
| ericsnow | natefinch: the magic string thing corresponds to what runtime.GOOS might give you | 20:08 |
| katco | natefinch, ericsnow : fwiw, i like ctors because they document the minimum needed parameters | 20:09 |
| natefinch | ericsnow: I mean, doing it based on runtime.GOOS is fine... but when are you going to pass "powershell" and not just instead do &renderer.PowershellRenderer{} | 20:09 |
| natefinch | katco: but if the types are exposed, then I have to figure out when I need the constructor and when I can just use the type | 20:09 |
| ericsnow | natefinch: yeah, that is probably a bit premature :) | 20:10 |
| katco | natefinch: wouldn't you just assume to use the ctor if it's present? | 20:10 |
| ericsnow | natefinch: it probably would be better to just yank all that aliasing stuff | 20:10 |
| katco | natefinch: i mean if not, i guess you can use the raw type if you like. but the author seems to be saying: "here's how you allocate me" with ctors | 20:11 |
| ericsnow | (for "shell names") | 20:11 |
| ericsnow | natefinch: NewRenderer is still useful in the case of targeting linux from windows or vice versa | 20:12 |
| === kadams54 is now known as kadams54-away | ||
| thumper | rick_h_: hey there | 20:17 |
| thumper | rick_h_: can we book a chat sometime soon? | 20:17 |
| rick_h_ | thumper: sure thing, I'm actually out until next week after tomorrow | 20:18 |
| thumper | rick_h_: so soon then... | 20:18 |
| rick_h_ | thumper: have 45min now or can do tomorrow evening | 20:19 |
| rick_h_ | thumper: or can do next wed (your thurs morning?) | 20:19 |
| === kadams54-away is now known as kadams54 | ||
| thumper | rick_h_: on a call now | 20:23 |
| rick_h_ | thumper: rgr | 20:23 |
| thumper | rick_h_: wanting to talk about shared delta state | 20:23 |
| rick_h_ | thumper: yea, talked (well emailed) with jam and he noted we should touch base | 20:24 |
| natefinch | ericsnow: at the very least, the magic (non-OS) strings should be factored out into an enum of some sort. There's no way, other than looking at the implementation, that anyone would know to pass in "bat" right now. | 20:31 |
| ericsnow | natefinch: there's no need for them so I'm dropping them | 20:32 |
| ericsnow | natefinch: but that's not happening in the commit you're reviewing :) | 20:32 |
| natefinch | ericsnow: right | 20:32 |
| ericsnow | natefinch: I'll put something up in a bit | 20:33 |
| sinzui | Can someone help triage https://bugs.launchpad.net/juju-core/+bug/1431286 ? comment 6 has a log that shows everything looking good until the moment the jujud is stated and it just exits because of "no instances found" | 20:33 |
| mup | Bug #1431286: juju bootstrap fails when http_proxy is set in environments.yaml <ubuntu-openstack> <juju-core:Incomplete> <https://launchpad.net/bugs/1431286> | 20:33 |
| natefinch | katco: I guess I always try to make sure there's only one way to do it, otherwise someone is bound to do it the Wrong Way™ | 20:34 |
| natefinch | katco: yes, in theory, if the constructor is there, you should use it, but it's not always clear that you shouldn't just create the types, too.... it's tricky. | 20:34 |
| katco | natefinch: i agree. i prefer ctors, so i guess i look for them. | 20:35 |
| katco | natefinch: actually in go, they're more like factories aren't they? | 20:35 |
| katco | natefinch: because they're only tied to the type in that they return an instance | 20:36 |
| natefinch | katco: yep. I prefer just being able to create a type, but that's not always possible with complicated values | 20:36 |
| katco | natefinch: i like knowing which fields i have to populate | 20:36 |
| natefinch | katco: absolutely. If the default values aren't valid, then a constructor is the way to go. But I hate having confusion about public types that look like you can construct them manually. Like I said, it's tricky. Sometimes a constructor function is absolutely the right thing. | 20:38 |
| natefinch | ericsnow: what's the second one you need reviewed? | 20:41 |
| ericsnow | natefinch: http://reviews.vapour.ws/r/1234/ | 20:41 |
| ericsnow | natefinch: http://reviews.vapour.ws/r/1256/ too, now | 20:42 |
| natefinch | ericsnow: I think you can write code faster than I can review it ;) | 20:42 |
| ericsnow | natefinch: maybe on a day when you are having trouble keeping your eyes open :) | 20:43 |
| natefinch | ericsnow: holy crap that's a lot of commits | 20:47 |
| ericsnow | natefinch: yeah, but they're all little | 20:47 |
| natefinch | ericsnow: yeah, just surprised me | 20:47 |
| ericsnow | natefinch: :) | 20:47 |
| natefinch | ericsnow: I can't do this review justice right now, with the time I have left. I gotta go. Sorry.. | 20:48 |
| ericsnow | (╯°□°)╯︵ ┻━┻ | 20:48 |
| jw4 | coreycb: is it possible for you to add the environment config file for your bug 1431286 (scrubbed of any private info of course) | 20:51 |
| mup | Bug #1431286: juju bootstrap fails when http_proxy is set in environments.yaml <ubuntu-openstack> <juju-core:Incomplete> <https://launchpad.net/bugs/1431286> | 20:51 |
| coreycb | jw4, should already be in there I think | 20:52 |
| jw4 | coreycb: is it in that proxy logs archive? | 20:52 |
| jw4 | coreycb: hmm not seeing it there, I must just be missing it | 20:53 |
| coreycb | jw4, sorry terrible name, "console log" | 20:53 |
| jw4 | coreycb: lol | 20:53 |
| jw4 | okay thanks | 20:53 |
| coreycb | jw4, thank you | 20:54 |
| jw4 | coreycb: for my education; does the bootstrap work when http-proxy is commented out? i.e. can the juju command "see" the vm's without the proxy? | 20:56 |
| coreycb | jw4, yes it works fine without http-proxy or https-proxy | 20:56 |
| coreycb | jw4, I'm currently hard-coding http(s)_proxy into the charm code as a work around | 20:56 |
| jw4 | coreycb: okay, and the proxy (http://squid.internal:3128) does normally successfully relay openstack http/https requests other than from juju? | 20:57 |
| coreycb | jw4, everything openstack-related should be behind the proxy | 21:02 |
| jw4 | coreycb: got it | 21:02 |
| thumper | is cmars around? | 21:06 |
| cmars | thumper, hey | 21:06 |
| thumper | hey, you busy, or want to chat with our 1:1? | 21:06 |
| ericsnow | wallyworld_: thanks for the review; I've updated the patch | 22:12 |
| wallyworld_ | ericsnow: ty, looking | 22:13 |
| wallyworld_ | ericsnow: that patched newTimer now appears to not change anything | 22:15 |
| ericsnow | wallyworld_: it allows us to call Reset on it before the expected failure | 22:16 |
| wallyworld_ | oh, i see | 22:16 |
| wallyworld_ | was that the area where the test was flakey then? | 22:17 |
| ericsnow | wallyworld_: it's that we were using a 50 ms timeout and on some hosts that isn't long enough | 22:18 |
| wallyworld_ | ok | 22:18 |
| ericsnow | wallyworld_: my patch takes a more direct approach by manually controlling the timeout | 22:18 |
| redelmann | hi everyone! | 22:32 |
| redelmann | todaby i notice im using juju 1.23-beta1, but all my agents are 1.22.0 | 22:33 |
| redelmann | today <= todaby | 22:33 |
| redelmann | its that ok? | 22:33 |
| ericsnow | wallyworld_: I don't think my patch is testing what needs to be tested (that a Ping resets the timeout) | 22:38 |
| ericsnow | wallyworld_: I'll have an update shortly | 22:38 |
| wallyworld_ | ok | 22:38 |
| wallyworld_ | redelmann: that's ok, 1.23 CLI can talk to 1.22 agents just fine | 22:39 |
| redelmann | wallyworld__ Thank, any online howto to upgrade agents? | 22:41 |
| wallyworld_ | "juju upgrade-juju" | 22:41 |
| ericsnow | wallyworld_: I've updated the patch with a check that Ping does reset the timeout | 22:58 |
| wallyworld_ | ok | 22:58 |
| ericsnow | waigani: thanks for the review :) | 22:59 |
| wallyworld_ | ericsnow: i think it looks good to go, reset count was a nice addition | 23:01 |
| ericsnow | wallyworld_: oh good, ideally we could have left that test alone but the whole timeout/sleep-induced failures makes the situation messier | 23:02 |
| wallyworld_ | yeah | 23:02 |
| axw | katco: when I replied to your G+ post, I didn't realise I was commenting on YouTube ;( | 23:35 |
| axw | I try to keep out of that comment cess pit | 23:35 |
| katco | axw: yeah, they're linked now =/ | 23:45 |
| katco | axw: asynch. convo (have to draw bath for daughter). had you heard of her there? | 23:46 |
| katco | (in aus) | 23:46 |
| axw | katco: I have not, but I don't listen to the radio much or pay close attention to local-ish music | 23:46 |
| axw | haven't been listening to this type of music for a while now either, really | 23:47 |
| katco | finally get cinder support into goose. wallyworld_ gets the authored credit. way to be a manager wallyworld_! ;) | 23:56 |
| wallyworld_ | katco: noooooo :-( | 23:57 |
| katco | haha | 23:57 |
| katco | hey what is the last number in the dependencies.tsv file for? | 23:59 |
| katco | it looks like it's probably the commit date/time? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!