[00:04] works for me [00:10] yeah... [00:10] I think my cache was fubared [00:12] thumper: are you using 8.8.8.8 by any chance ? [00:12] nope [00:12] squid-deb-proxy in the way [00:13] but does that use 8.8.8.8 ? [00:13] as your name server [02:21] Bug #1482015 opened: featuretest: panic on ppc64le [06:39] Bug #1482074 opened: worker: environSuite.TestInvalidConfig fails on ppc64 [07:43] jam: hi, i'm off to soccer soon, but i made some changes to the resources doc. i also posed a question about specifying series. i've also put down a brain dump on mongo migration which i'll share. it's a start [07:43] wallyworld: k [07:43] enjoy soccer [07:43] will try to [07:44] link sent [09:01] dimitern: hangout? [09:02] dooferlad, omw [10:01] dooferlad: dimitern: ready for review http://reviews.vapour.ws/r/2303/ [10:01] voidspace: *click* [10:02] voidspace, looking [10:03] relatively straightforward in the end [10:10] the estimation for spaces list state is 2 [10:11] I think that's quite an underestimation given how much subnets need to change [10:11] :-/ [10:13] voidspace: and that is why we review and re-estimate :-| [10:14] yeah [10:14] "Thinking Fast and Slow" (a book on experimental psychology) has a good section on project estimation [10:15] and why humans will always tend to underestimate the time a project takes [10:15] I think that agile velocity measuring is actually a pretty good counterbalance against that, but he (Daniel Kahneman I believe) does suggest some other mitigation strategies [10:16] Bug #1482155 opened: lxc restriction on multiple state servers [10:16] the "optimisim bias" is one reason and "What You See Is All There Is" is another reason [10:16] the main mitigation strategy is to not estimate based on how long you think a task will take [10:17] but first take *how long other similar tasks actually took* as your baseline, and then think of reasons to move from the baseline [10:17] voidspace: I have used two point estimation (worst case, best case) and three point (worst, gut feel for how it should be, best case) and none seem to do any better than what we are doing [10:18] right, but starting from a baseline that is not related to thinking about the current task is slightly different [10:18] it's effectively a statistical approach [10:18] "statistically how long is this likely to take based on similar tasks" [10:19] experiments demonstrate that even *knowing* the baseline doesn't affect people's estimation (they still underestimate wildly) unless they *specifically* start from the baseline [10:19] sounds about right! [10:19] very interesting book [10:19] I reccommend it for all sorts of reasons [10:19] it just happens that section is relevant [10:20] I would add it to my to-read list, but it is way too long anyway. [10:20] heh [10:20] I know the feeling [10:20] I just need a solid 10 years in a cave to make a decent dent. [10:20] a cave without net access. [10:20] :-) [10:21] and then you really will have an "emerging from the cave" experience (a-la Plato) [10:21] and some magic anti-aging time machine [10:26] talking about PERT? [10:27] PERT? [10:28] E = (P + 6L + O) / 6 with U = ((P - O) / 6)^2 [10:28] that didn't help... [10:28] :-p [10:28] voidspace: https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique [10:28] TheMue: thanks :-) [10:29] a very simplified model for software cost estimation, opposite to FPA oder even COCOMO II [10:30] in the first line P is pessimistic, L is likely and O is optimistic, E is the effort and U the uncertanity [10:31] * TheMue once needs to translate his 70 slides about the different ways for SCE from German to English ... [10:31] contains reasons about wrong estimations too, and all the factors that are part of a full process [10:32] TheMue: it's not clear to me that PERT uses a baseline for individual task estimation [10:32] okay, different topic, back to work [10:32] so I'm not sure it's directly the sort of estimation I was talking about [10:33] voidspace: only seens that sentence with three points, so jumped on the wagon to quickly ;) [10:33] seen [10:33] heh [10:33] Kahneman talks about a statistical approach to individual task estimation - not just for a whole project [10:34] it seems that PERT will still be subject to the optimist bias and availability bias even in the pessimistic estimation case [10:34] and Kahneman has experimental data to back up his assertions about the way we estimate [10:34] I once managed a 7 people/3 year project very good with a mix of FPA and COCOMO II, but we had very clear requirements, so it worked [10:35] tracking a velocity is a good counterbalance, but it won't tend to improve estimation - merely correct for the inherent errors [10:35] right, lunch [10:35] voidspace: yep, matches my experience [10:36] cool [10:50] dimitern: do we have a way to inject a value into a running watcher? would like it to return the tag of an illegal IP address to provoke an error [10:52] * TheMue steps out for lunch, reads answer later [10:57] TheMue, not outside the state package, as this will require inserting an invalid document in the collection the watcher is watching [10:58] TheMue, alternatively, you can use a mock watcher of course [11:24] dimitern: hmm, mocking would be an alternative. seems like the only way to kill my worker in a bad way :) [11:30] dimitern: it's a funny test, after hardening the worker show, that it still can die after an internal error [11:55] dooferlad: the nice thing about a magic space name ("diediedie") is that space name is already passed down from BackingInstance to Space to Subnets [11:56] dooferlad: to add another way to configure Subnets to fail (as I only have access to the backing instance) requires adding infrastructure to pass that knowledge down from BackingInstance to Spaces to Subnets [11:56] dooferlad: all for that one test [11:56] dooferlad: in terms of obfuscation, I thought "diediedie" was pretty clear... [11:56] :-) [12:03] dimitern: I replied to two of your review comments [12:11] mock-di-di mock-di-da *sing* [12:19] dimitern: also, you said it was "mostly done, apart from the apiserver method signature" [12:19] dimitern: what do you mean by the apiserver method signature, and what isn't done about it? [12:19] dimitern: you mean I missed something? [12:24] voidspace, did you get my other 2 comments? [12:25] voidspace, I've replied [12:26] dimitern: yeah, about to push the other two changes [12:26] voidspace: it isn't just the diediedie thing, it is the looking at subnet IDs and using that to decide how to construct the fake subnet. [12:26] dooferlad: that's not what the comment says [12:27] dooferlad: it's just constructing precanned data [12:27] dooferlad: deterministically constructing it from input [12:27] dooferlad: I don't think it's unclear [12:27] dooferlad: we only have SubnetIds on the Space [12:28] dooferlad: and really it needs to stay like that because AddSpace takes a subnetId not a subnet [12:28] dooferlad: so unless we want our backing stub to start growing a full implementation, we need a way of going from subnet id to full subnet details [12:29] dooferlad: I could turn it into a function that does it, store the generated subnets and have AddSpace use it to generate a subnet [12:29] dooferlad: but it would be exactly the same thing, just extra work [12:29] voidspace, that's why i asked did you get my other comments - I tried to explain there about the signature [12:30] dimitern: ah! [12:30] dimitern: you mean lose the Error on the result and return an error instead [12:30] dimitern: hmmm... isn't it normal for result params to have an Error field? [12:37] dooferlad: I've added my explanation (including why I don't like the alternatives - especially for the CIDR magic) as a comment to the review [12:38] dooferlad: getting rid of "diediedie" would be easier, not too much work - just a method on BackingInstance and a corresponding flag on FakeSpace I think [12:38] dooferlad: so maybe it's worth it [12:39] (I agree in general that magic names aren't ideal.) [12:39] dooferlad: and subnet.get_params()! You've been doing too much Python :-) [12:39] (method name casing) [12:41] voidspace: You could put the code to generate those subnets in StubBacking.SetUp so at least all the set up is in one place. [12:41] dooferlad: no, see the comment about AddSpace [12:41] dooferlad: we need to do it on the fly too [12:42] dooferlad: so in terms of "one place", Subnets is the best place [12:42] dooferlad: we could do it in SetUp *and* AddSpace [12:42] but that seems worse [12:42] to me anyway [12:43] and we'd need to add an extra field to FakeSpace to store them [12:44] there will also be a method to add a subnet to an existing space as well [12:44] that will then be a third place needing to do the generation [12:45] dooferlad: I could add a comment to the SetUp, so anyone investigating where the data is generated will be able to find it easily [12:45] I guess the question really is should the stub emulate state well enough to accomplish this and will it be useful for other tests. That I don't have an answer for without giving it some thought, but leaving it as it is now and adding comments seems good. [12:46] dooferlad: currently it's just for this test [12:46] that way the giving it some thought gets done as part of writing other bits [12:46] dooferlad: and I don't like writing code for imaginery future use cases [12:46] but, yes, comments++ [12:46] if we have a need for BackingInstance to better emulate state then we should add that at the point we need it [12:46] indeed [12:47] dimitern: you've got mail about an idea. let me know what you think. [12:47] so I'll get rid of diediedie and add a comment about subnet data generation to SetUp [12:47] I see TheMue is now using IRC as a push email notification. Next, telnet to ping people about IRC messages :-D [12:48] dooferlad: you have a params.SpaceResult - presumably the result of calling CreateSpace [12:48] dooferlad: it just holds a Tag and an Error [12:48] I'm about to create params.Space (a rename of params.SpaceListResult) [12:48] dooferlad: they have no fields in common... but still I wonder if they should be unified? [12:48] dooferlad: yep, working on a bot to automate it [12:48] voidspace, result structs have Error fields only when part of a bulk call of some sort (entities -> someresults, error) [12:49] dimitern: so just returning the error is sufficient? ok. I'm already doing that anyway, I'll just kill the Error field [12:49] TheMue: but where will I telnet to? Perhaps you could call me? [12:49] voidspace, in this case we have the same results (assuming no filtering) [12:50] voidspace, well, ListSpaces is not a bulk call anyway and can either return all results or error out (no partial results possible) [12:50] dooferlad: ok, will add a pluggable channel adaptor, so you can add your telnet module [12:51] TheMue: sweet. I will post you a letter with my phone number. [12:51] dooferlad: hmmm, missing the fax here [12:51] dimitern: yep, cool [12:52] TheMue, I like your proposal actually, but how do you estimate the work? [12:52] TheMue: oh dear, I don't know your address and I won't be able to see smoke signals at this distance. Oh well. [12:53] TheMue, not what do you mean by "the ip address watcher would be part of networking api" [12:53] TheMue, s/not/not sure/ [12:54] dimitern: ah, great. it should be pretty simple with the made experiences, I'm only angry that I didn't wrote it down earlier [12:55] TheMue, as a professor of mine liked to say "once you've done with a task, you already know how you should've done it" :) [12:55] dimitern: IMHO as it is a business domain I would put all networking related functionality into one API, not like e.g. now the extra addresser, which only makes sense for the addresser worker [12:55] dimitern: a good professor, indeed [12:56] dooferlad: how about a carrier pigeon? [12:57] TheMue: thought about that but with neither of us having a pigeon trained to fly to the others address, I think we are out of luck. [12:58] dooferlad: will use the London sprint to work on a solution. maybe installing a direct wire for telegraphing [12:58] TheMue, I'm not sure about a networking api in general - let's keep that in mind for the time when we'll have pluggable brokers/providers [12:58] dimitern: ok [13:01] * TheMue continues mocking for an API error [13:04] dimitern: will make a more concrete outline to see, if a later change of the approach would make sense [13:11] dimitern: dooferlad: review updated [13:11] dimitern: ah damn, forget JSON tags [13:11] dimitern: will do that now [13:11] dooferlad: see the SetSpaceSubnetsFail monstrosity you're responsible for [13:12] voidspace: you have answered all my queries. Have a +1 [13:12] dooferlad: thanks [13:32] TheMue, ok [13:32] voidspace, please don't forget json tags [13:34] dimitern: done [13:34] dimitern: as I have a +1 from dooferlad I'm going to merge [13:34] who could I talk to about actions in juju-core ? [13:37] voidspace, ahh.. now I got it why you like the verbose slice-item multi-line formatting to the shorter []X{{\nF: 42,\n}, {\nF: 2,\n}} [13:37] voidspace, it looks more pythonic :) [13:38] voidspace, and you have a +1 from me as well [13:42] dimitern: I'm not sure it's more pythonic, I think it's more readable [13:43] dimitern: it adds one line per slice member, and when you have nested slices (as in this example) it's very clear what type you're looking t [13:43] dimitern: take a look at http://paste.ubuntu.com/12013753/, that would be the API function. api.releaseIPAddress() is adopted from the original code, only changed the parameter to be an address. [13:43] *at [13:43] dimitern: it's pretty small ;) [13:43] dimitern: if it wasn't a nested slice I wouldn't do it [13:44] but nested "untyped" slice members is a bit hard to read (you need to keep a state stack to remember which type you're reading) [13:44] dimitern: anyway, thanks [13:45] dimitern: should I go to space list (api) or space list (state) [13:45] dimitern: I'm not sure which is more logical as a next step, I've been looking at state but it occurs to me that (api) might be more logical [13:45] or should that be done last... [13:46] dimitern: the list card says that it assumes that "create" has already been done [13:47] dimitern: but I think that assumption is for the estimate only, not actually a requirement of implementation order [13:54] voidspace, so far I found it's best to do cli -> apiserver -> api -> state [13:54] dimitern: so api next then [13:54] col [13:54] *cool [13:56] mgz: I may be a cpl min late [13:57] xwwt: no probs, poke me when ready [14:14] TheMue, CleanupIPAddresses should not return the first error - it's better to keep going and return a typed error like "some addresses not released (will retry)" [14:14] TheMue, and I'll suggest adding some debug logging around the steps [14:15] I was just wondering what the allen v watcher was and why we named a watcher after someone... [14:15] dimitern: yeah, thought about that too [14:15] dimitern: but this is only an outline to show how small it would be [14:19] TheMue, +1 [14:20] dimitern: say ok and I quickly create a new branch, copy the reusable code of my current branch and go with it *lol* [14:25] * perrito666 considers moving to uk just to be able to see tgbbo sooner [14:26] ehehe, baking nut [14:26] I have to wait a whole day to see it on the internet [14:26] and months to get it on bbc [14:26] our version of bbc is quite subpar [14:28] mgz: I am now into a whole new level of torture, watching cooking shows while on a diet :p [14:29] perrito666: so don't do that :) [14:29] natefinch: I assume you are talking about the diet [14:29] lol [14:29] no [14:30] natefinch: one doesn't miss tgbbo, it is not an option, even living in the spanish colonies as I do :p [14:30] perrito666: never heard of it [14:32] * perrito666 slaps natefinch with a cookbook by mary berry [14:39] be back in ~25 minutes === natefinch is now known as natefinch-afk [14:41] aghh why on earth noboy uses /away instead of doing that? [14:56] ericsnow: wwitzel3: natefinch-afk: ok planning time [14:56] katco: rgr, refilling my water [14:57] anyone seen fwereade lately? [14:57] does anyone have information on using the garage MAAS? I need an environment where I can deploy KVM containers. [14:59] * dooferlad wonders if he is the only person who gets annoyed by KVM being called a container when it isn't. [15:00] dooferlad: you most likely are :p since we all call it that [15:00] dimitern: some changes at http://paste.ubuntu.com/12014105/, also contains the important part of the worker. only missing part now is the correct signal, that it's no hard error but a try-again [15:01] dimitern: so yes, missing some QA aspects, but shows the idea how few code it is [15:01] terminology aside, my question stands :) [15:01] dimitern: simply by moving logic to the server side [15:02] sorry cherylj, no. I work in a converted garage and it has a MAAS in it, but that isn't what you were asking about :-| [15:03] dooferlad: nice, and where did you put the car? [15:03] perrito666: it never went in the garage anyway. Left part at the front for bikes. [15:05] * perrito666 went for the laundry room [15:09] wwitzel3: natefinch-afk - so i've done quite a bit of hacking on the containerizer i wanted to land for tracking branches but the sizes are quite large and I dont really recommend a 2.8gb container image from the registry. So if you want/need any of these branch bins in an isolated space just lmk. I'm abandoning the effort to get these published in an automated fashion. [15:09] it turned into quite the rabbit hole [15:13] natefinch-afk: ping? [15:13] lazyPower: ahh ok [15:14] lazyPower: thanks, yeah, I'd love to look at what you have [15:17] wwitzel3: https://github.com/chuckbutler/jujubox/tree/nightly [15:17] repo is a little messy, i still have cleanup to do in there [15:23] natefinch-afk: ping? [15:35] natefinch-afk: ping? [15:37] * TheMue hears an echo on the channel, ...annel, ...nel, ...l [15:39] tasdomas: did you get your actions questions answered? === natefinch-afk is now known as natefinch [15:42] bbl [18:02] perrito666: natefinch: team meeting [18:46] evening all [18:46] evening fwereade [18:46] heya fwereade ! [18:47] hey katco sorry got a doctor appt and wasnt out of there in time [18:47] did you get power back? [18:47] fwereade: hey, welcome bacl [18:47] so far I have had four public officials and two electricians hemming and hawing and replacing one bit after another [18:47] there was going to be a third electrician today but he turned out to be fictional [18:48] I am more than somewhat vexed by the situation [18:48] am currently in a bar up the road for the wifi [18:48] fwereade: well, now you know how everyone else sees software engineers debugging [18:48] and kinda sorta for the alcohol too now I think of it [18:48] interestingly, the electricity meter (replaced this morning) dated from 1966 [18:49] didn't *quite* make it 50 years [18:49] anyway I'm mainly on to fetch and rebase and maybe push a couple of branches if they're clean [18:49] fwereade: one would think that, of all possible poblems a house can have, electricity supply is one of the easiest to debug by simple binary search [18:50] fwereade: your extremely big pr to master was merged [18:50] but if I can do anything for anyone while I'm here, well, I'm here [18:50] perrito666, I saw, thanks :) [18:50] fwereade, I sent you mail on a critical bug [18:50] just fyi [18:51] fwereade: beer makes you code better, or at least think you are. [18:51] beer has that affect for many popular activities [18:51] katco: beer makes you code like this https://www.youtube.com/watch?v=KEkrWRHCDQU [18:54] alexisb, ok, menn0's explanation sounds like it's on the money [18:54] alexisb, I will look into it [18:54] thanks [20:34] try ssh whoami.filippo.io [20:34] (it's harmless but interesting) [21:00] wallyworld: leme know when you are here [21:06] perrito666: hey, just about to drive my wife to work, hopefully back soonish [21:07] wallyworld: np, just ping me whenever you feel like [21:07] :) [21:08] I have literally nothing better to o [21:08] do [21:08] wallyworld, congrats on the spotlight award :-) [21:08] * perrito666 will ask an autograph on the next meeting === beisner is now known as beisner-afk === beisner-afk is now known as beisner [21:48] wallyworld: dude! the spotlight award! congratulations!!! :D [21:48] wallyworld: definitely well deserved :D [21:49] katco: we at tanzanite are thinking on changing the name to Ian's people [21:49] and also wearing Ian's face on t-shirts [21:50] and off course, tatoos [21:50] * perrito666 np: Men at work - down under [21:53] wow, I actually know 2 songs from these people [21:58] perrito666: how does "mountain man" (axw) feel about that? [21:58] katco: about what of all that? [21:59] perrito666: about renaming the team to "ian's people" [21:59] katco: (also we dont need to ask him, he is still 2 hs away from morning) :p [22:00] perrito666: haha, i always forget "mountain man" axw lives in a different time zone than wallyworld [22:00] it is 6 AM for him still [22:25] the fact that perth is connected to the rest of australia by land is an interesting academic fact that has no effect on reality [22:54] perrito666: like some of ur ideas but not the ones above :D [22:54] katco: mountain man? nani? [22:57] axw: we should have a sprint in perth to make abslutely sure that everyone apprecaites paradise u r in :D [22:58] anastasiamac: I think I have missed something :) [22:58] axw: I'd b siurprised if u have:D [22:59] anastasiamac: according to flock.teleport.org, if tanzanite has a sprint we should all go to sydney [23:00] axw: since everyone is curious/ talking about perth, I think we should sprint there :D [23:02] anastasiamac: are you sure you want to be in the State of Excitement? [23:02] axw: m always in the state of excitment [23:03] Bug #1482226 opened: juju status with 'prefer-ipv6' shows address, not DNS name.

[23:03] anastasiamac: in case that's lost on you... http://theworstofperth.com/2007/11/03/state-of-excitement/ [23:03] axw: but Perth also has great food :D [23:04] * anastasiamac needs to run - ttyl [23:16] perrito666: you back yet?