[00:10] Bug #1506680 opened: `juju environments` fails due to missing ~/.juju/current-environment [00:15] thumper: final version.Current PR is up for review === wgrant is now known as Guest27601 === thumper is now known as Guest68941 === Guest68941 is now known as thumper [00:58] wallyworld: heading out for a quick dog walk before the rain comes in [00:58] ok [00:58] ping when you are free === Guest27601 is now known as wgrant [01:39] wallyworld: there now [01:39] ok [02:23] ericsnow: how goes? [06:55] mgz: ping [08:59] fwereade: i reverted the change omit series, could you PTAL http://reviews.vapour.ws/r/2888/ [08:59] wallyworld, cheers [09:02] wallyworld, LGTM, thanks [09:02] tyvm [09:03] fwereade, jam: hangout? [09:22] dimitern: looks like they took a different approach in maas - they didn't go with device_type in the end [09:22] dimitern: so that card can be deleted [09:22] dimitern: https://bugs.launchpad.net/maas/+bug/1490637 [09:22] Bug #1490637: Devices with parents should not show on devices tab [09:22] dimitern: they just decided to use the presence of a parent instead [09:22] dimitern: so I can delete my branch.... [09:28] TheMue: so, the lock problem. [09:28] voidspace, it sounds like a mess that they need to fix :) [09:30] dimitern: yeah, weird [09:30] dimitern: I've added a comment to the issue and will ping them about it [09:30] dooferlad: yes, let's unlock it [09:31] * dooferlad groans [09:32] dooferlad: the scope is always only the local node? [09:32] voidspace, cheers [09:32] TheMue: yes [09:32] https://github.com/golang/go/issues/2307 is background on the Windows socket behaviour [09:32] dooferlad: so surely a state based solution is nice, but not needed? [09:33] TheMue: using state would fix the problem, yes [09:33] TheMue: it is our single source of truth [09:34] dooferlad: as we just said, state would help, but not solve it if a process/node dies and the lock stays in state [09:34] TheMue: state would notice that the connection died though, right? That could be an even to unlock. [09:35] TheMue: actually, it looks like the socket code on Windows should only allow one connection now. [09:35] TheMue: [09:35] dooferlad: a, you would check, if a connection between a node and state exists? not the data in state in a collection? [09:36] dooferlad: I thought the whole time of a lock collection with records containing node, handle, and lease time [09:36] TheMue: you would store the lock data in the collection, but you could validate it against if the thing that created the lock still exists [09:37] dooferlad: and processes use their node and handle to check if the lease time is passed off or not [09:38] TheMue: but I don't want to do anything lock related in state because adding more logic to state unless we have a good future use case. [09:38] And we don't have a lease time. There is no need. [09:38] dooferlad: how would you validate if the creator still exists? [09:38] We have connections to state open to update state from machines. [09:39] We just see if the connection that created the lock is still there [09:39] but, it involves a network, so no, don't do that [09:39] dooferlad: many distributed solutions I've looked for use lease times. we could create this lock as a util type, it will find it's usage ;) [09:39] Doing this right over a network turns into a distributed consensus algorithm [09:40] at which point we have implemented etcd to replace a file lock [09:40] so lets not [09:44] On Linux we could use /tmp to ensure our locks don't exist across reboots (yay!) and on Windows we can use the file attributes FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE (see https://en.wikipedia.org/wiki/List_of_RAM_drive_software#Native) to achieve about the same thing [09:44] that solves all my problems. [09:46] apart from delete_on_close doesn't look right [09:46] arg [09:47] https://github.com/natefinch/npipe maybe is the best way to go on Windows [09:49] dooferlad: hmmm, ok, not yet really sure [09:50] TheMue: maybe I just move the file locks to /tmp on Linux and leave the rest. It would be enough to get the MAAS and EC2 tests passing and since we don't do container init on Windows (or run those tests) then problem solved. [09:50] TheMue: the need for the lock then goes away once we are down to 1 juju process and we all celebrate. [09:50] TheMue: (well, when that happens) [09:51] * dooferlad needs a cup of tea. Back in 5 [09:59] mattyw, tasdomas: as people who've used the dependency engine: I have a use case for injecting an engine into itself, and am having naming troubles [09:59] fwereade, ah naming, one of the solved problems [09:59] mattyw, tasdomas: currently exposed as InceptionManifold, which is not really accurate, but is a useful indicator of the presence of weirdness [10:00] mattyw, tasdomas: a more accurate nname would be OurobourosManifold but that's, er, a bit obscure [10:00] mattyw, tasdomas: thoughts appreciated :) [10:01] fwereade, RecursiveManifold ? [10:01] fwereade, -1 to inception [10:01] tasdomas, fwereade, I was just typing exactly that! [10:01] fwereade, I don't really care for names as long as they are not misleading [10:01] fwereade, a rose by any other name.. [10:02] tasdomas, there's quite a lot of subtlety embedded in "so long as they are not misleading" ;) [10:02] fwereade, well, in my case misleading would be calling it SimpleManifold [10:03] tasdomas, it *is* actually pretty simple ;p [10:03] tasdomas, (but point taken all the same) [10:03] fwereade, there's no such thing as a simple manifold [10:03] ;-] [10:03] * fwereade has a sad now [10:03] ;p [10:06] hm, maybe it would be best to just have an `Engine.InstallSelf(name string) error` method? and unexport the manifold itself except for tests? [10:08] ...but then the InstallSelf tests end up yucky and arms-lengthy in a bad way [10:08] SelfManifold? [10:08] mattyw, tasdomas: ^^ [10:09] fwereade, self is fine [10:09] fwereade, but document it [10:11] mattyw, cheers [10:26] mattyw, http://reviews.vapour.ws/r/2916/diff/# -- adequately documented? [10:38] fwereade, a proper review will come later [10:38] fwereade, but for now the documentation seems fine [10:38] fwereade, and given the actualy implementation i really like SelfManifold as a name [10:38] mattyw, cool, thanks :D [10:39] mattyw, don't feel obliged to do a full review, the implementation remains unchanged from when thumper LGTMed it [10:39] fwereade, ok cool, good enough for me [10:39] mattyw, tyvm [10:39] fwereade, I'm having one of those days where I'm chasing shiny things instead of doing the stuff I'm supposed to [10:39] mattyw, haha, sorry to contribute to that [10:39] fwereade, no problem - shiny == awesome [13:17] mgz, are you around? [13:20] mattyw: hey [13:22] mgz, just pushing an update to the yaml branch [13:22] mgz, it looks like we can get rid of that weirdness [13:22] mgz, but I'm not full of confidence as I still don't really understand why it was there [13:26] mattyw: jw4's comment is bug 1436871 [13:26] Bug #1436871: ppc64 gccgo fails to build cmd/juju

[13:27] if it builds with both go and the version of yaml we're using, and gccgo, there's nothing left to worry about [13:27] mgz, can I test that somehow? [13:28] yeh,or I can. install gccgo on trusty and build with -compiler gccgo [13:30] mgz, it's here if you want to try it [13:30] mgz, I'll see if I'm setup to do it as well [13:34] seems to build [13:34] of course, looking at the bug it did for me last time too, but I *think* this was a short-lvied bug in the packages [13:34] we'll find out for certain when it gets merged anyway [13:34] mgz, maybe I could channel rogpeppe [13:35] * rogpeppe 's ghost appears [13:36] mattyw: that bug resulted in some quite weird things happening [13:36] mattyw: best to definitively check that it works properly before renaming those types [13:36] spooky! [13:38] rogpeppe, how would I check that? [13:38] rogpeppe, are you the ghost of bugs yet to come? [13:38] mattyw: you'd write a little piece of test code [13:39] rogpeppe, test code - that's an odd concept [13:39] mattyw: more like the ghost of your fetid past [13:39] mattyw: i'm not thinking of an actual test [13:40] mattyw: just a standalone program to check current behaviour [13:40] mattyw: tell you what, i'll do one if you want [13:42] rogpeppe, make sure you send me the code, and show me how to run it [13:42] rogpeppe, it's the only way I'll learn [13:54] mattyw: ironically it appears that the yaml bug was actually fixed 2 hours before i committed that juju comment [13:54] Bug #1506865 opened: Failed to retry tools download after EOF

[13:54] Bug #1506869 opened: TestNewServerDoesNotAccessState api connection failure

[13:54] mattyw: here's my test code [13:54] mattyw: http://paste.ubuntu.com/12798941/ [13:54] rogpeppe, thanks very much [13:54] mattyw: the yaml commit that fixed the bug was 4d6bb54d8acc91e147763cea066cff0b89437e90 [13:55] rogpeppe, you're welcoe to review the pr if you want [13:55] rogpeppe, http://reviews.vapour.ws/r/2912/ [13:56] mattyw: this was the important piece of the diff: http://paste.ubuntu.com/12798949/ [13:57] mattyw: have you run the status tests on that branch? [13:57] rogpeppe, I have [13:57] mattyw: hmm, weird, i wonder why you don't get an infinite loop [13:57] rogpeppe, I've not run cmd/juju/... yet - in hangouts [13:58] mattyw: try running the status tests in cmd/juju/status [13:58] rogpeppe, I've run all of those [14:02] mattyw: interesting. I think that exposes a bug in goyaml actually [14:02] mattyw: what would you expect this to print? http://paste.ubuntu.com/12799013/ [14:03] rogpeppe, shall I read it and guess or you want me to run it? [14:04] rogpeppe, (in our planning meeting now so sort of distracted I'm afraid, many apologies) [14:04] mattyw: first guess, then run [14:09] rogpeppe, I guessed and ran [14:10] rogpeppe, and now I'm confused [14:10] mattyw: the answer it gave is the reason your change doesn't cause infinite recursion [14:16] mattyw: https://github.com/go-yaml/yaml/issues/134 [14:19] mattyw: reviewed http://reviews.vapour.ws/r/2912/ [14:20] rogpeppe, thanks, see martins previous comment regarding omitempty [14:24] mattyw: ah, ok i see about the omitempty. i guess it's best not to mess with the output. [14:30] Bug #1506881 opened: 1.22 client cannot talk to chicago-cubs server

[15:11] rogpeppe, mgz and again http://reviews.vapour.ws/r/2912 [15:12] rogpeppe, I'll be back in 10 though [15:24] voidspace, ping [15:32] voidspace, if you're still around, you might be interested in what I came up with for the juju-br0 script === tych0- is now known as tych0 [15:33] voidspace, it turned out not quite as simple as I imagined (~200 lines of bash), but handles properly the IPv4/IPv6/both cases as well as aliases, and it's more resilient towards failures (reverts changes back so you can ssh later and diagnose) [15:34] voidspace, anyway - here it is: http://paste.ubuntu.com/12799841/ (still testing a few cases though) [15:34] * dimitern really wants at this point to do all these steps in Go and inject a simple binary that does all and can be easily tested in isolation [15:37] dimitern: I am amazed we don't insist on Python being installed for these things :-| [15:39] dooferlad, it's about time :) [15:40] dooferlad, the issue in this specific case is the script is run very early, before packages are installed (well, we could change the cloud images to include python always - it might be so already in fact) [15:40] dimitern: indeed. I would check that. [15:42] dooferlad, yeah - good idea - check a pristine trust amd64 image deployed from maas as well as "lxc-create -t ubuntu-cloud" - as lxc images might be different (same applies to KVM I guess, but I suspect the use the same images as maas) [15:45] * dimitern pats himself on the back :D in all those ~200 lines of bash (in a go string) - so far only 2 syntax issues (apart from a panic from unmatched "}" in the template) [15:53] mattyw: you still seem to comflict with my (landed) change that scrubs subnets [15:53] mgz, let me wave my rebase wand [15:54] mattyw: you can get a wand for that? Ohh. [15:56] mgz, should be better now [15:57] dooferlad, wand didn't work, had to use keyboard [15:57] mattyw: boo [15:57] tough crowd [15:58] mattyw: shipit [15:59] if it blows up on ppc we'll find out and can add back the hack [15:59] yak sack [16:36] Bug # changed: 1335885, 1373516, 1435283, 1465844, 1478156, 1489477, 1492066, 1493123, 1494070, 1494542, 1495338, 1496639, 1496750, 1497094, 1498746, 1500613 [17:20] dimitern: pong [17:20] dimitern: wow [17:59] sweet, just got my new code keyboard. Gonna take a little getting used to, but the difference from my old keyboard is crazy. [18:00] natefinch: i expect 50.02% more productivity from you. [18:01] katco`: of course ;) [18:03] katco`: which part of the .el for emacs is the one that makes the editor remind me that exported functions should have docs? [18:05] perrito666: lol dunno if golint does that or not [18:05] golint does [18:06] katco`: something is doing it in the conf you passed to me :p I am just trying to understand lol [18:07] perrito666: flycheck does things on the fly, so it's probably just running golint every time the buffer changes or something [18:07] perrito666: i'm sure it has some kind of smarter algo, but that's the just of it [18:39] katco`: is there anything to do to get the payloads stuff in? ericsnow says it merges just fine... do we do a PR, or what? There's no process written down in the wiki. [18:42] natefinch: the CI test to bless it is currently 50% complete [18:42] katco`: sweet [18:42] natefinch: then i think we just propose a merge against 1.25 and do the merge [19:11] wow, glad I got the "quiet" mechanical keyboard. Geez. [19:12] natefinch: lol, I thought you had one of those before [19:13] perrito666: nope. My last keyboard was expensive only because it was wireless and solar powered, not due to the quality of the typing experience. [19:13] solar powered, really? what a strange feature for a kb [19:14] perrito666: never need to charge or change batteries [19:14] natefinch: I have a Code! [19:15] natefinch: my kb never sees the light of day [19:15] the window is behind two monitors [19:15] jcastro: yeah, just got mine, love it. the lights are so perty [19:16] natefinch: pic [19:24] perrito666: http://imgur.com/c7H33c0 [19:24] * natefinch carefully crops out his messy desk [19:26] sure, all of us that have very neat desks will be incredibly offended by it :p [19:26] that is one sexy keyboard [19:26] I want it [19:27] it is wicked sexy... didn't even realize it had media keys until I saw them in that picture ;) [19:28] Bug #1506994 opened: deploy unit can fail after creating a machine but before assigning unit to it [19:28] keyboard backlight has adjustable brightness, too, which is nice - it goes pretty bright. [19:31] Bug #1506994 changed: deploy unit can fail after creating a machine but before assigning unit to it [19:34] Bug #1506994 opened: deploy unit can fail after creating a machine but before assigning unit to it [19:58] Bug # changed: 1463053, 1463922, 1469844, 1471657, 1471936, 1487191, 1499573