[01:03] wallyworld, are you able to give me permission to tag github.com/juju/juju.git ? [01:03] sure [01:03] my git user is 'jogeo' [01:09] jog: sorry, browser crashed. does it work now? [01:09] wallyworld, yup thanks! [01:10] np [03:22] anything interesting come out of the meeting? [03:25] wwitzel3: u mean team meeting? [03:26] anastasiamac: yeah [03:26] ericsnow: ping, you happen to still be around? [03:27] wwitzel3: well, we just caught up on new terminology (and what are the mplications for code, docs, blogs), restructure of core and spec contentes/processes [03:27] wwitzel3: it was short and quick :D [03:28] wwitzel3: as in brief :P [03:28] is there a listing of the new teminology? [03:28] environment = model [03:28] service = application [03:28] JES = controller [03:28] tools = agents [03:29] workload = payload [03:29] m adding this to meetings minute [03:29] anastasiamac: great, thank you [03:29] better to confirm with rick_h_ too :D [03:31] wwitzel3: i may have heard relation = link (but it could b jetleg too) [04:04] anastasiamac: confirm what? [04:04] anastasiamac: wwitzel3 terminology looks good [04:05] thanks [04:05] relation stays, just talked a lot as forming a link [04:13] anastasiamac: can you explain the environment = model thing? Environment is kind of overloaded, but when I think environment, I think like my production juju environment on AWS or my testing juju environment on MAAS [04:27] natefinch: the thinking is that juju models the working system and a controller of several models seems ok [04:28] natefinch: there's some more, can chat on how the discussions went the last two weeks. [04:29] rick_h_: sure, just wondering how we actually talk about these things... I can say "juju deploy adds a new service to the model".... but I can't really say "a machine just went down in our production model" [04:32] natefinch: interesting use case. I'd skip that by saying models have names in a controller and you'd actually say "a machine died in production-analytics" [04:32] but admit I'm cheating [04:32] heh ok :) [04:33] rick_h_: seems like there's really two things - there's juju's model of the world, stored in mongo, which is the model... and then there's the reality attached to that model. [04:38] natefinch: which do you talk to and interact with via the cli? [04:39] natefinch: I think you are right in that distinction though. [04:39] rick_h_: depends on the command.... things like deploy and add machine really just change the model, which the controller then attempts to modify reality to match [04:39] rick_h_: but then if you're doing juju status - you're showing both the model and reality [04:40] natefinch: yea, but then again it's the model's view of reality. [05:01] wallyworld: you still have a 'juju-charm-demo' instance running. is that intentional? [06:19] jam: no, it is not, i thought i had killed them all. damn [06:19] wallyworld: it started something like 25hrs ago [06:19] so roughly yesterday [06:20] hmmm, i don't recall starting it but i must have [06:22] killed now [06:34] rick_h_: thank you for explanantion - would it be gr8 to have terminology discussion with Nick and Peter present to ensure that docs reflect our world :) [07:10] Bug #1506338 opened: state/leadership: sporadic test timeout [07:35] domas, fwereade: I just filed https://bugs.launchpad.net/juju-core/+bug/1506353 [07:35] Bug #1506353: leadership resolver still too noisy

[07:35] it seems the new dependency engine is waking up every 30s or so and logging that there is essentially "nothing to do" [07:35] which seems ok, until you have 100s of units doing it [07:46] Bug #1506353 opened: leadership resolver still too noisy

[08:02] wallyworld, ping? [08:04] mattyw: hey, just otp with fwereade , can i ping you soon? [08:04] wallyworld, [08:05] frobware, ping [09:01] dooferlad, voidspace, fwereade [10:19] * dooferlad is AFK for ~25 mins [10:19] axw, wallyworld: offhand, non-urgent, but in case yuo see it before sleep: what would be causing the resolver loop to wake up every 30s? [10:20] mgz, ping? [10:44] * dooferlad is back [10:46] morning [10:47] perrito666: 'ning [10:49] perrito666: 'ng [10:49] voidspace: next step only 'g? ;) [10:50] TheMue: :-) [12:03] mgz, there was some code in core in cmd/status that hadn't been moved onto yaml.v2. It was still working because juju/cmd was still on yaml.v1, but when you update the dep it breaks, I'm fixing that one up, there doesn't look there will be more but obv' we'll have to look out for it [12:38] Bug #1506460 opened: On juju-br0 interface creation the inet6 addresses of the original interface are lost

[12:46] voidspace, hey [12:47] voidspace, I managed to confirm your fix on 1.25 works with a few different net configs for nodes in maas 1.9 [12:47] voidspace, I'm trying a few more confs now (so far tested lxc and kvm connectivity) [12:53] dimitern: cool [12:53] dimitern: I have containers working with 1.25 and the fix for master [12:54] dimitern: I set the master branch to land but tests failed [12:54] looking at it now [12:55] cmd_juju_subnet_test panicked [12:55] voidspace, so I'm having issues with my local maas network setup I suspect, as it *always* takes ~5m to deploy a node (w/ or w/o juju) due to cloud-init waiting for 10 then 120s for the network to come up (even though it's statically configured) [12:55] bah [12:55] voidspace, hmm - what was the issue? [12:55] ah, no reachable servers [12:55] that happens from time to time - can happen to any test [12:55] will retry [12:56] Bug #1503740 changed: Storage should be behind a feature flag in 1.24

[12:56] right [12:56] it's not good, but it's not my immediate problem... [12:56] I'm going on lunch [12:56] bbiab [12:56] also there's the bug above, just filed - when we have inet6 config in /e/n/i we should be handling it properly [13:02] Bug #1503740 opened: Storage should be behind a feature flag in 1.24

[13:08] Bug #1226307 changed: juju-core lazily get tools if from public bucket

[13:08] Bug #1503740 changed: Storage should be behind a feature flag in 1.24

[13:11] dimitern, I see the same slow deployment time. This is what I thought you reported yesterday. [13:12] frobware, I suspect the issue might be due to having 1 NIC with 2 aliases all on the same subnet [13:13] dimitern, agreed. I haven't been scientific enough in recording which does/does not work... [13:17] frobware, voidspace, also, I just did a test with one of the NUCs having 2 NICs bonded in bond0 [13:17] script needs to handle this case better - connectivity was lostit doesn't work [13:18] dimitern, can you please raise a bug for this explicit case [13:20] Bug #1226307 opened: juju-core lazily get tools if from public bucket

[13:20] frobware, sure [13:23] Bug #1226307 changed: juju-core lazily get tools if from public bucket

[13:37] frobware, what was that ip link command to add the bridge? [13:37] frobware, ip link add link juju-br0 type bridge doesn't seem to work [13:38] fwereade: I fixed a bunch of the issues you had with the unit assigner worker.. some of the comments I responded to without fixing, as a couple of them would have been quite large refactors. Would appreciate if you could take a look http://reviews.vapour.ws/r/2814/ [13:38] dimitern, sudo ip link add name juju-br0 type bridge [13:39] frobware, right, thanks! [13:45] frobware, I might have found a workaround the bond issue [13:46] frobware, using that ip link add + ip link set up seems to do the trick without loss of connectivity [13:46] double checking now.. [13:46] dimitern, would be worth verifying the UP status of the link [13:47] frobware, I've added dumping of all routes, links, and addresses at the end of the script [13:50] dimitern, using `ip addr' ? [13:50] dimitern, or ifconfig? [13:54] frobware, all three with iprotue2 [13:54] iproute2 even [13:56] ericsnow: ping [13:57] katco: I might be a couple minutes late to standup [13:57] wwitzel3: np we can wait [14:05] anastasiamac: yeahback [14:05] oops [14:05] back [14:35] Bug #1506498 opened: juju-br0 not configured properly with maas 1.9 on machines with 2 bonded NICs [14:37] frobware, so the in addition to adding and upping the bridge, we need to wait for both the bond and the bridge to become ready, pining the default GW [14:37] frobware, filed bug 1506498 [14:37] Bug #1506498: juju-br0 not configured properly with maas 1.9 on machines with 2 bonded NICs [14:38] Bug #1506498 changed: juju-br0 not configured properly with maas 1.9 on machines with 2 bonded NICs [14:39] * dimitern needs to step out, will continue a bit later with the tests [14:44] Bug #1506498 opened: juju-br0 not configured properly with maas 1.9 on machines with 2 bonded NICs [14:45] nice bikeshed opportunity anyone! i want to factor writeServerFile out of cmd/juju/user so that it can be used by cmd/juju/system too. but... where should the new location be? [14:46] possibilities considered so far: cmd/juju/system, cmd/juju/common, environs/configstore [14:46] fwereade, dimitern, jam: suggestions? [14:56] surely *someone* must have an opinon! dimitern, cmars, natefinch, mgz... ? [14:57] rogpeppe: I really don't :) [14:57] mgz: bah! [14:57] well, I think "common" sucks as a concept, but we have it [14:57] mgz: FWIW i don't like any of the above suggestions [14:57] mgz: i agree totally. i don't want to make it worse [14:58] mgz: currently i'm thinking of a new package, maybe github.com/juju/juju/serverfile [14:58] or perhaps cmd/juju/serverfile [14:58] mattyw: nice bikeshed opportunity anyone! i want to factor writeServerFile out of cmd/juju/user so that it can be used by cmd/juju/system too. but... where should the new location be? [14:59] mattyw: [15:46:25] possibilities considered so far: cmd/juju/system, cmd/juju/common, environs/configstore [14:59] rogpeppe: nope, no real opinion. If it's just for cmd/juju, keep it under there somewhere [14:59] natefinch: well, it's potentially something that someone external to juju might want to use [15:00] rogpeppe, I take offence at the assumption that I always enjoy a bikeshed [15:00] rogpeppe, so the punishment is, whatever I say you have to agree with 100% [15:00] rogpeppe, i probably wouldn't import something out of juju/juju though, because it's such a huge checkout from github [15:01] mattyw: not a chance. the way of bikesheds is: noone gives a toss until a decision is made, then everyone disagrees with it [15:01] cmars: i don't understand [15:01] rogpeppe, wait, are we talking juju/juju/cmd/juju or cmd/juju ? [15:01] cmars: the former [15:02] er, juju/cmd. ok [15:02] rogpeppe, I'd put it in environs/server_file.go for now [15:02] mattyw: i'm not sure. isn't environs a bit overburdened already? [15:02] * rogpeppe checks again [15:03] it is, it's the best of the three options presented [15:03] I could also go with environs/serverfile/write.go or something [15:04] mattyw: yeah, that might be reasonable [15:04] mattyw: although it's not really much to do with environs [15:04] rogpeppe, also you shouldn't miss this chance to rename it writeControllerFile [15:04] mattyw: ha [15:04] mattyw: if there's gonna be some renaming, let's do it consistently all at once across the code base please [15:05] rogpeppe, since when has that been a think? [15:05] thing [15:05] the thing takes a *cmd.Context does moving it out of cmd make sense? [15:05] mattyw: it seems like the only sane approach to me [15:06] I have not internalised our import graph, but pretty sure environs generally gets imported by cmd not the other way around [15:06] * mattyw looks again [15:06] mgz: i don't think it should take a cmd.Context [15:06] mgz: or an EndpointProvider come to that [15:07] fair enough, if refactored to be a different interface have wider options [15:08] those are good points, it should basically be given the structure and where to put it, and it writes it there I'd imagine [15:09] mattyw, mgz: i'm thinking of something like: http://paste.ubuntu.com/12790951/ [15:11] mattyw: and given that it refers to environs/configstore, perhaps environs/serverfile would work best [15:11] rogpeppe, I'd be +1 all of that except for the incomprehensible lack of godocs in the paste ;) [15:12] that does seem pretty reasonable. with filename being an abspath. [15:12] mgz: yup [15:13] mgz, while you're here: juju/juju/cmd/status had mention of GetYAML and was still using yaml.v1 from github.com/juju/cmd [15:13] mgz, I started the work to move it over - does that conflict with anything you're doing? [15:13] mattyw: nope, just missed it in the grep [15:14] problem with packages that have go get as their gating mechanism [15:14] mgz, ok - was sort of hoping I'd get a yeah and I've fixed all the problems [15:14] mgz, but ok [15:15] mgz, mattyw: actually, another possibility is juju/jujuj/envcmd which is where ServerFile (the serialisation format) is defined [15:15] mattyw: did you find out what was calling GetYAML ? [15:16] rogpeppe, it was using github.com/juju/cmd which was still on yaml.v1 [15:16] mattyw: ha! [15:16] rogpeppe, that could make sense - I suppose it is quite cmd related [15:16] mattyw: if in doubt, use showdeps -a | grep yaml.v1 [15:16] mattyw: i suppose :-\ [15:16] mattyw: hm, did my subnet yaml branhc not land? I'm not confused by the state of master [15:17] rogpeppe, well it's the cmd's that use it right? [15:17] mgz, subnet? [15:17] mattyw: currently, yes [15:17] mgz, cmd/subnet? [15:17] ah, I am confused [15:17] mattyw: although it's a format that others might want to parse [15:17] rogpeppe, so it sort of makes sense [15:17] I removed redundant junk in spaces [15:17] missed the same in subnets [15:17] mattyw: e.g. if you were implementing a juju client in python [15:18] mattyw: unless you've started already on status, I'll do it [15:18] mgz, I've started - but am stuck [15:19] mgz, I'll push what I have so far so you can take a look if you like [15:19] mattyw: I'll have a lok, touched this code before so I should remember what's going on [15:19] mgz, but a couple of tests are failing - "service-status" isn't appearing in the right places [15:19] mgz, one moment [15:24] mattyw: meanwhile, http://reviews.vapour.ws/r/2911/ [15:26] mgz, I migrated those, sure they're not needed? [15:27] mattyw: yup [15:27] I should have seen them when I killed the other ones [15:28] it's noop copy code === akhavr1 is now known as akhavr [15:29] mgz, cool, I suspect it might be the same in the other stuff I'm doing [15:29] mgz, but I haven't got it worked out in my minds yet [15:29] status is the one place we really do fancy stuff [15:29] (still waiting to push) [15:29] but people have looked at it for yaml examples and been confused as to what's actually needed [15:30] mattyw: I evilly turned off my hook a while back and have yet to reenable it [15:30] mgz, St Peter doesn't take kindly to that kind of thing [15:33] mgz, here it is http://reviews.vapour.ws/r/2912/ [15:35] mattyw: ta! [15:39] mattyw: is the famous and much copied rog comment actually still true? [15:39] or can you inline declare types in the methods? [15:39] mgz, I don't know - I was hoping to get tests passing then see if I can remove and at have still pass tests [15:39] :D [15:40] mattyw: I'll poke this after standup [15:40] mgz, rog was kind enough to explain it to me this morning - but it didn't help my understanding, I was hoping to talk to him after ods to go over it in a bit more deetail [15:48] ericsnow, natefinch: aaand again [15:48] wwitzel3: ouch [15:51] it is odd, it is a clean shutdown , but like it is happening in the background .. syslog shows systemd shutting things down before it dies [15:53] bogdanteleaga: if you have a mo, can you look at http://reviews.vapour.ws/r/2860 for the centos changes [16:11] katco: and you got a feature test for your last minute feature right? :P [16:15] mgz: (whistles)... we had one at some point [16:15] mgz: i think it got lost in the shuffle [16:16] mgz: we're happy to write one for next friday [16:25] mgz: looks sane to me, did you test it on centos? [16:27] fwereade: reviewed your uniter logging PR - http://reviews.vapour.ws/r/2913/ [16:38] bogdanteleaga: I do not know how at present, jog is working on centos on our maas, was wondering if you had a working public cloud setup anywhere [16:44] mgz: we didn't try it out in public clouds yet, only maas [16:44] mgz: have you tried http://wiki.cloudbase.it/juju-centos ? [16:46] bogdanteleaga: I assume that's basically what jog followed, he had fun with nic and maas 1.9 though [16:47] anyway, we should have that as part of our revision testing soon enough, then I can rerun the branch with centos [16:51] mgz, 1.9 has support for importing centOS images (i.e. it automatically picks them up from the daily image streams), so I did not have to generate my own images or manually add them. [16:51] https://maas.ubuntu.com/docs/changelog.html#alpha2 [16:56] jog: did you file any bugs for your troubles? [16:56] There is a bug for the LVM issue already [16:58] the second issue was related to having multiple NICs and the MAAS DHCP listening on the second NIC. However, CentOS only configured the first... I've not filed a bug about that yet. [17:01] the bug for LVM is 1499558 and also discussed in the release notes I liked to above [17:37] ericsnow: pushed up my status-set changes [17:37] wwitzel3: cool [18:20] ericsnow, wwitzel3: back, sorry, the furnace guy was here [18:35] ericsnow: pushed an update [18:35] wwitzel3: thanks! [18:36] wwitzel3, ericsnow: what can I do to help? Just review? [18:38] natefinch: that's what i'm doing [18:38] ericsnow: pushed update to unregister as well, added a todo and the checkempty [18:39] wwitzel3: gah... push file renames in separate PR [18:40] just look at it on Github , since it handles it just fine [18:40] :P [18:40] wwitzel3: doing that actually... doesn't do diff b/t 2 files though [18:41] odd it should, I used git rename [18:42] wwitzel3: lemme know what i'm doing wrong, but don't see it here: https://github.com/juju/juju/pull/3517/files?diff=split [18:42] yeah, that is weird, since the commit history is file renamed without change .. then my changes [18:42] man, git sucks, bzr and launchpad handle this just fine [18:43] katco: yeah, that is odd, it is confused about something .. you can just look at the commit here https://github.com/wwitzel3/juju/commit/06ef4664272c5110fe1198ac778a28fba7e73ee4?diff=split [18:43] katco: i broke it up in to a rename commit and a change commit [18:43] * natefinch shakes off the possession by wallyworld [18:43] so that this wouldn't happen .. lol [18:43] and it happened anyway [18:44] wwitzel3: much better [18:44] wwitzel3: +1 to change [18:48] ericsnow: sorry, should have claimed that mattyw yaml review, he put it up incomplete so I could resolve a conundrum for him [18:48] mgz: np :) [18:48] I just found a mo though and have the fix [18:53] ericsnow, thanks anyway, sorry I should have said something in the review [18:53] mattyw: my question about the bugs vs. yaml.v2 still stand though :) [18:57] mattyw: see my review for answer [18:58] ericsnow: we think we can remove most of the weird workaround stuff, only part I'm not sure on is the gccgo behaviour [18:59] mgz: gccgo just keeps on giving [18:59] it's just the fun of working on multiple platforms in general [19:00] you get twice the number of platform bugs === Mmike is now known as Nitko [19:03] wwitzel3: a few very minor review comments: http://reviews.vapour.ws/r/2901/ === Nitko is now known as Mmike [19:07] ericsnow, mgz thanks guys, I'm not actually reading any of the comments, I'm saving it as a suprise [19:07] mattyw: lol [19:07] mattyw: a breakfast excitement [19:09] ericsnow: that status list formatter thing takes a compatVersion, but doesn't use it..... is that correct? and if so, why does it need that value? [19:10] natefinch: I followed the lead of status on that one [19:10] ericsnow: of taking in the value and not using it? :/ :) [19:11] natefinch: haha [20:03] woohoo, new keyboard is here [20:03] my wrists are free again! [20:05] wwitzel3: i expect 50.02% more productivity [20:08] lol, sure ;) [20:23] wwitzel3: sweet... my code keyboard is coming tomorrow. Can't wait. [20:24] natefinch: I looked at those but I didn't see an adjustable version [20:24] wwitzel3: adjustable how? [20:26] natefinch: width and height and tilt [20:27] wwitzel3: yeah, it's not super adjustable... I think it can be tilted, but at the end of the day, it's not rally any more adjustable than the rectangular keyboard that you can get for $10, it's true. [20:28] natefinch: yeah, I don't know how to type on a regular keyboard anymore [20:28] wwitzel3: haha [20:28] wwitzel3: I have a friend who es the kinesis... I imagine that must be even worse [20:29] natefinch: these last two days on the laptop keyboard have been awful .. anytime we have sprints and people watch me type, I can only imagine what people think [20:31] the one I just got is the Goldtouch V2, which is adjustable 0-30 degrees on the horiz and vert [20:31] it doesn't have a num pad, but I have an extrenal one floating around somewhere [20:31] haha.. yeah, for me, it's the touchpad that is horrible. I can type on the laptop ok, but man.... the touchpad makes me feel like I'm 110 years old [21:11] ericsnow: wwitzel3: we have a testable branch yet? [21:12] katco: status-set is landing right now, not sure where list is at [21:12] katco: the only thing I have left is to address a few more comments from natefinch [21:12] wwitzel3: ericsnow: awesome! [21:33] Who's familiar with jes? I'm trying to use it for a spike, but the devel docs aren't helping me. `juju system create-environment test` throws 'error: no system specified' [22:06] Bug #1506649 opened: On juju upgrade the security group lost ports for the exposed services [22:36] Bug #1284982 changed: juju destroy-environment exits with strange error [23:06] aisrael, I should be asleep, but thumper or menn0 should be able to help [23:06] Bug #1506666 opened: juju bootstrap fails in virtualbox [23:08] aisrael: howdy [23:08] aisrael: let me remind myself who this hangs together [23:08] aisrael: which juju version are you using? [23:09] menn0: 1.25-beta1. I'm chatting with thumper about it now, though, but thanks! [23:10] aisrael: ok, you're in good hands then [23:11] probably broken lxc package [23:12] see if update gets you a new one. === sinzui_ is now known as sinzui [23:38] mgz: hey hey [23:39] mgz: do you know if there's likely to be another 1.24 release?