[00:19] waigani_: menn0 thumper https://github.com/juju/juju/pull/548 [00:19] here is an easy one to warm up with this morning [00:35] anyone know instance distributor provider code? [00:35] just curious how it knows service name [01:28] thumper: got a sec? [01:28] menn0: aye [01:28] thumper: hangout? [01:28] sure [01:29] thumper: calling you now [01:29] thumper: https://plus.google.com/hangouts/_/g4pl2c7bq3jqz2jy3rsjdtvakea?hl=en-GB [01:29] thumper: grrr [01:30] let's use the standup hangout [01:30] ok [01:38] wow, my branch from a month ago merged mostly cleanly with master [01:38] not bad [01:46] \o/ [02:14] can I please get a review on https://github.com/juju/juju/pull/552 to unblock CI? [02:16] wallyworld_: ^^ very small one [02:16] sure [03:15] OOPS: 34 passed, 6 FAILED [03:15] --- FAIL: Test (18.44s) [03:15] FAIL [03:15] exit status 1 [03:15] FAIL github.com/juju/juju/state/apiserver/provisioner 18.541s [03:15] sigh [03:16] well, at least it's only 3 of the apiserver packages [03:16] which is better than before [03:16] but still a lot of tests to fix [03:17] waigani: I'm about to drop maia down at hockey [03:17] waigani: how about we hangout when I get back and talk about the testing ? [03:17] thumper: that would be great, thanks [03:20] ... obtained params.ErrorResults = params.ErrorResults{Results:[]params.ErrorResult{params.ErrorResult{Error:}, params.ErrorResult{Error:}, params.ErrorResult{Error:}, params.ErrorResult{Error:¶ms.Error{"not found", "machine 42 not found"}}, params.ErrorResult{Error:¶ms.Error{"not found", "unit \"foo/0\" not found"}}, params.ErrorResult{Error:¶ms.Error{"not found", "service \"bar\" not found"}}}} [03:20] ... expected params.ErrorResults = params.ErrorResults{Results:[]params.ErrorResult{params.ErrorResult{Error:}, params.ErrorResult{Error:}, params.ErrorResult{Error:}, params.ErrorResult{Error:¶ms.Error{"not found", "machine 42 not found"}}, params.ErrorResult{Error:¶ms.Error{"unauthorized access", "permission denied"}}, params.ErrorResult{Error:¶ms.Error{"unauthorized access", "permission denied"}}}} [03:20] welcome to my day [03:20] looking at long likes of quasi json and spotting the n differences [03:46] waigani: back [03:46] thumper: https://github.com/juju/juju/pull/553 [03:47] waigani: looking now, tests work ok? [03:48] waigani: I added the comments for the public methods on https://github.com/juju/juju/pull/511 [03:49] thumper: all tests passed except state/envuser_test.go which I fixed and tested individually [03:49] thumper: I'll do one more make test to be sure [03:50] wwitzel3: great thanks :) [03:52] wwitzel3, davecheney is my review mentor so you'll have to poke him for an LGTM [03:52] thanks :) [03:54] two secs [03:55] waigani: you are missing the new files... [03:55] waigani: state/envuser.go + test are not there [03:55] wwitzel3: o/ [03:55] thumper: fuk [03:56] thumper: heya [04:00] thumper: state/envuser.go is already in master? [04:00] waigani: is it? [04:00] * thumper looks [04:00] thumper: is for me? [04:01] waigani: umm... no. don't think so [04:01] thumper: okay my local master is stuffed up [04:02] thumper: let me clean this up and try again [04:02] ok [04:20] thumper: that change you helped me with: https://github.com/juju/juju/pull/554/ [04:20] thumper: do you have time to review? [04:20] sure [04:21] thumper: i've already made sure this solves the problem of downgrades in local/manual envs [04:21] so once this is in [04:21] the other change can be proposed straight away [04:23] thumper: cleaned up, I'll address your initial comments before pushing again. [04:23] thumper: user take does not have a Name() method? [04:24] yes it does [04:24] are your deps up to date? [04:24] thumper: I just ran the godeps tool [04:24] but your branch probably isn't up to date with trunk [04:26] menn0: only one real comment [04:29] thumper: I don't think what you've suggested is necessary [04:29] why? [04:29] the test intentionally has no tools in env storage [04:29] so if a download was attempted it would fail [04:30] this work was done test first, and it failed because of this [04:31] thumper: dad duty just started, I'll get it back up later tonight. [04:31] waigani: ack [04:31] thumper: does that make sense? [04:31] menn0: in which case, please add a comment :-) as it wasn't obvious to me [04:31] thumper: will do [04:37] thumper: added comment and rearranged the test a little to make things clearer [04:37] how's this? https://github.com/juju/juju/pull/554/files [04:37] menn0: cheers [04:38] wwitzel3: you've got a LGTM on that change [04:38] there is nothing to be gained from another round of reviews [04:38] do what you think is reasonable then submit that sukka before we get locked down again [04:40] menn0: a slightly premature merge :) [04:40] thumper: sorry. I wasn't sure if you were going to say anything else [04:40] menn0: that's fine :) [04:40] thumper: is there a problem [04:40] ? [04:40] no [04:40] just saw your LGTM :) [04:41] davecheney: thanks [04:43] potentially dumb question: what does this do? go test -p 2 ./... [04:43] and why does the build do it? [04:44] wallyworld_'s last merge got aborted because a test took too long and then the tests were run again as above and passed [04:44] menn0: it runs the tests with reduced parallelism [04:45] because our tests sucks [04:45] oh right [04:45] and often fail spuriously [04:45] I didn't realise we were running tests in parallel at all! [04:45] but -p 2 works more often than not but is slower [04:45] menn0: that's what Go does out of the box [04:45] right [04:45] well I have learned something today [04:45] \o/ [04:46] time to put my feet up [04:46] :) [04:46] enjoy [05:01] menn0: you and andrew gerrand [05:01] he didn't know -p $NUMCPU was the default either [05:01] davecheney: well I don't feel so bad then :) [05:02] possibly he doesn't spend as long as you and I do waiting for tests to ru [05:02] * thumper goes to make dinner [05:09] I'm off, be back in the morning o/ === uru-afk is now known as urulama [06:26] wallyworld_: ping [06:55] davecheney: hey [06:57] wallyworld_: i have a question about the keymanager [06:57] when we pass user: juju-system-key [06:57] to the keymanager [06:57] is that a tag ? [06:57] hmmm [06:57] i didn't add that bit, but let me look at the code [06:57] i've had to put a horrible hack in to make juju accept that as a tag [06:57] ok, ifyou didnd't writ it [06:57] that is ok [06:58] you have TODOs all over it [06:58] i don't think i did - i wrote the key manager itself [06:58] but [06:58] i have exactly one test to fix [06:58] then this bloody branch is done [06:58] i think someone came along and added support for a system-key [06:58] well, they cocked it up [06:58] let me look briefly [06:58] i could have been me, but i can't recall [07:02] davecheney: looks like it was me. a key can be for a user eg fred, or is the juju system key [07:02] right, so they aren't tags [07:02] i guess that was done back before tags [07:02] yeah [07:03] which makes it a bit of a hack to use common.AuthFunc [07:03] anyway [07:03] i've done a gross hack [07:03] it'll hold [07:03] yuk, sorry [07:03] meh [07:03] we'll live [07:03] it can't be fixed now because of BACKWARDS COMPATABILITY !!1! [07:04] yep :-( [07:07] wallyworld_: https://github.com/juju/juju/pull/556 [07:07] DONE [07:07] it's only taken a month [07:07] i'm off to the pub [07:07] looking [07:07] have a drink for me :-) [07:09] perrito666: let me know when you arrive :-) [08:14] wallyworld_: I'm pretty sure you'll be having a drink for yourself, too :) [08:16] morning [08:18] jam: yes i will :-) [08:18] morning TheMue [08:22] dimitern: ping [08:22] TheMue, hey [08:23] dimitern: I changed my approach a bit, but I still hesitate to use the Entity approach. [08:23] dimitern: see https://github.com/TheMue/juju/compare/capability-detection-for-networker [08:23] TheMue, looking [08:24] dimitern: Entity is really generic, for all entities with a tag. But IsManual is a flag for machines. [08:25] dimitern: I now read it only once when creating a local Machine instance, so it is cached and will never bee refreshed, because it won’t change. [08:25] TheMue: AIUI Jobs is also specific to Machines, but the "thing" is Entity which is more generic [08:25] TheMue, no, please let's not make 2 calls for every life request [08:26] jam: Entity doesn’t know about jobs [08:26] TheMue, yes jam's right - there's already a precedent with Jobs, adding another flag is not a big deal I think [08:27] dimitern: themue seems to think I've got the wrong object, I could be wrong there. [08:27] But I thought I remembered seeing other stuff that was machine specific on the generic class [08:28] Aaargh, I see, we’re talking about AgentGetEntitiesResult [08:29] yes! :) [08:29] But I’m still not happy with overloading that struct more and more [08:29] TheMue, that's what versioning is for, no? [08:30] dimitern: I don’t talk about differences, I talk about common and specific fields, separation of concerns [08:30] TheMue, the agents need this data to do their jobs (efficiently), and it's also an internal api [08:30] dimitern: So I would be more happy to let the machine fetch a doc especially for a machine [08:31] dimitern: still not clean and optimal for maintainability, you see how easy one can move into the wrong direction [08:31] TheMue, I don't think this is us moving in the wrong direction [08:32] dimitern: IMHO the Machiner would be responsible for Machine operations and the Machine in the should know what it has to know about machines [08:32] TheMue, fwiw, we probably need to have 2 separate unit and machine agent facades, rather than pretending we can treat both and their entities the same [08:34] TheMue, and if you look at AgentGetEntitiesResults, only Life is common between machines and units, ContainerType and Jobs only apply to machines [08:35] dimitern: yeah, maybe. so to come to a quick solution I will do the AgentGetEntitiesResult change. and I’ll file an issue for refactoring with low priority [08:37] TheMue, that sounds good to me! [08:52] So "juju restore" bootstraps again (which it needs to) [08:52] but if it fails it leaves the instance created - but with no running agent. [08:53] So "juju status" (etc) fail and you have to manually destroy the instance (or accidentally leave it running because you don't realise)... [08:53] jam: your hacked-up-backup script (for local provider) [08:53] jam: it uses $JUJU_ENV [08:53] this isn't set when I'm running the script directly, so I have to set it myself I guess [08:53] or would you expect it to be set? [08:54] voidspace: I believe it is set if you run "juju restore" but I just use "JUJU_ENV=local ./juju-restore" [08:54] jam: right, cool [08:54] voidspace: if you just run "juju-backup" it fails too, right? [08:54] My understanding is that the plugin infrastructure sets that variable [08:54] jam: it fails for publiic-key [08:54] jam: right [08:54] jam: that's what I *thought*, but I as just checking my system wasn't screwed in new and exciting ways [09:01] voidspace: did you do any more hacking on it, or shall I see if I can get it through to completion? [09:01] jam: I was trying (and failing) to get amazon working [09:01] jam: I've now switched to the local script [09:01] backup seems to work fine :-) [09:04] jam, got a minute? [09:04] voidspace: well local backup "works" in that it generates a tarball, but all the paths match exactly the local paths, which means they *don't* match the "official" paths. [09:04] jam, I'd like to pass an idea by you [09:04] well, what *I* would consider official, at least (/var/lib vs /home/$USER/.juju/etc) [09:04] jam: right [09:04] yep [09:05] dimitern: G+ or just in IRC? [09:05] jam, just IRC should be fine [09:05] voidspace: I think the thing to do there would actually be to rewrite them, but I don't expect backup of Amazon to be able to restore into local [09:05] sure! [09:05] just local to local will be a good start [09:06] local to amazon might be useful :-) [09:06] jam, so after experimenting with the net package's Interfaces() and InterfaceAddrs() on precise, trusty and utopic daily image, I realized we can get all the information we need about the network interfaces *without* ever bothering to read /etc/network/interfaces or /interfaces.d/*.cfg [09:06] create your system locally, then "restore" to your production systems [09:06] dimitern: what is it that we wanted but don't have access to? [09:07] jam, like what? [09:07] "we can't get all the information we need" such as? [09:07] looking here: http://golang.org/pkg/net/#Interface [09:07] it looks like we don't have anything about bridging, etc. [09:08] jam, we can discover all interfaces, bridges included, their flags (up, down, broadcast, loopback, multicast), and their index and names, also any addresses assigned [09:09] jam, I'm proposing to just rewrite the interfaces config as needed for ifup/down to work at boot, and as the networker starts it will read all configs and check if there are any changes between what we have in state and what's configured on the machine, and rewrite the configs as needed [09:10] dimitern: ok, I read what you said wrong. I read it as "we cannot get all the information", if we *can* that's great, though I have my doubts. I'm also wondering where "net" gets its information from, is it just the live state, or is it the state that will be started on restart [09:11] jam, the net package gets the info using syscalls and some obscure netlink packets [09:11] dimitern: k, so it would be the "live" state, vs the saved state [09:11] jam, it is more or less equivalent to what we can see using the "ip" command (i.e. real-time) [09:11] dimitern: right, it is a kernel sort of interface [09:11] "ifup" and /etc/network/interfaces are a debian/ubuntu-ism [09:11] jam, yes, and it works just as well in precise as in utopic [09:11] IIRC, Fedora/Redhat use a different saved state [09:12] jam, well, there is support only for linux to discover the interfaces like that, but I've yet to try centos and fedora [09:13] jam, that's true, we'll have to render different stored config for other distros, but let's worry about this as we get there :) [09:15] jam, another up-side of using the net package is we don't need to rely on /etc/network/interfaces being there to decide whether to start the networker or not (more so now, as we have the "safe mode" to disable it selectively) [09:38] dimitern: sorry about the delay, emergency take-the-dog-out action. [09:38] dimitern: so I like the idea a bit (no safe mode would be very nice) [09:38] *but* [09:38] I wonder if we really don't want to save our configuration, which means writing to /etc/network/* [09:39] jam, no, no, I'm not saying that :) [09:39] dimitern: perhaps we could only rewrite things when we've actually decided we need to change things [09:39] jam, we do write the network config in /etc, but we don't read it - we use the net package to discover what nics are there [09:40] dimitern: but we shouldn't write it unless we think there is a change from what's written there, should we? [09:40] in which case, we have to read what is there to write anythnig [09:40] jam, we need to write the config, otherwise without a working juju machine agent + networker, the networking won't be setup correctly after system boot [09:41] jam, yes, we get all NICs, read what's there and render and write "managed" config for each nic that we need to setup, but only if it's pre-existing config on disk is different from what the networker would generate [09:42] jam, am I making more sense? :) [09:43] dimitern: so I can understand that we may not need to parse them, I'm not 100% sure that our method of comparison as byte-strings is quite what we want (what about comments in the files, etc). [09:43] jam, ok, so let's backtrack just a bit [09:44] jam, the user trusts (or we hope they do) juju to do the right thing with the machines juju manages, right? the same should be true wrt the networker taking control over the machine's networking config and managing it, without expecting the user to interfere? [09:45] dimitern: the whole point of "Safe" is because we don't trust us on Manual or Local [09:45] jam, we make this obvious by using the comment header "# Managed by Juju, please do not change." in each config file the networker generates [09:46] jam, right, so for "safe mode", don't write changes to the config or run any ifup/down commands, effectively just sitting there and logging what we discovered [09:50] jam, I'm hoping we can get rid of safe mode for manual machines once we have a way for the user to explicitly tell us how to setup networking on them, or we're able to discover it somehow, smartly [10:45] dimitern: TheMue: voidspace: standup? [10:45] jam: omw [10:50] perrito666: ping [10:52] voidspace: are you still there? [11:34] marcoceppi: poke about charm tools: https://bugs.launchpad.net/charm-tools/+bug/1359170 [11:34] Bug #1359170: juju charm create fails in an unhelpful fashion with juju-1.21 in PATH [11:34] Also, when I look at: https://juju.ubuntu.com/docs/authors-charm-writing.html [11:34] It has the lines: [11:34] juju charm create vanilla [11:34] but in my browser, those are wrapped onto 2 lines [11:34] so it looks like 2 commands [11:35] Ctrl Refresh fixed it for me.... very weird [11:41] morning voidspace [11:41] perrito666: morning [11:41] perrito666: solved my horrendous backup / restore problems [11:42] perrito666: well, more or less [11:42] voidspace: heh, all backup and restore problems are horrendous [11:42] perrito666: backup wasn't working *at all* [11:43] voidspace: odd, since when? [11:43] perrito666: but jam finally sussed it - the juju 1.18 juju-backup is in the path and the dev one isn't [11:43] perrito666: only for me on trunk [11:43] perrito666: so I have to run the backup script directly to try it [11:46] sweet, is there a PR already? [11:46] perrito666: not a PR yet [11:47] perrito666: I'll show you what I have (complete now I think) [11:47] perrito666: the issue is that the 1.18 "juju-backup" shell script didn't know about /usr/lib/juju/bin/mongodump which you fixed for 1.20, but 1.18 is the one in /usr/bin/juju [11:47] perrito666: although I need to test it, hence the problem with backup not working [11:47] perrito666: https://github.com/voidspace/juju/compare/backup-ssh [11:48] and just running "juju backup" searches $PATH for "juju--backup" so even though juju itself is 1.21, "juju backup" was running the 1.18 version. [11:48] jam: so backup and restore from trunk worked fine for me - which is a first [11:48] now to try it with my code... [11:48] ah very true, my usual test uses absolute path [11:50] perrito666: you mean /home/user/path/to/juju/cmd/plugins/juju-backup/juju-backup ? [11:52] jam: yup, since I use the automated test from qa I added my paths to make sure it alwas runs the same [11:52] perrito666: and then presumably you just set JUJU_ENV to test the right environment? [11:53] TheMue: didn't you land a patch to allow "@" syntax for "juju set" ? [11:54] jam: the CI test requires it as a param actually (test_recovery.py) [11:56] perrito666: I don't see a test_recovery.py in lp:juju-ci-tools [11:56] test_assess_recovery.py ? [11:57] jam: it was test_recovery.py until friday [11:57] * perrito666 pulls [11:57] perrito666: perhaps it is a different source code, because test_assess_recovery.py imports "test_recovery" at the top. [11:58] RM test_recovery.py => assess_recovery.py [11:58] perrito666: looks like test_assess_recovery.py didn't get fixe [11:58] fixed [11:59] perrito666: and it looks like CI does, indeed, run "juju-backup" and not "juju backup" which might be something we should think carefully about, since *users* are going to be doing the latter. [11:59] but we are testing the former [11:59] I must have local changes to ensure that, ah I see, those tests ship their own version of backup [12:00] * perrito666 wonders why [12:00] interesting [12:00] yeah, seems odd [12:00] jam: good point Ill nag sinzui about it when he shows [12:00] anyway, about to test my restore [12:00] just killed the state server [12:04] jam: looks like restore does fetch the tools from the correct storage location when used in conjunction with upload-tools (just btw) [12:04] voidspace: good to hear. I expected as much, since we are using the control-bucket as defined in the .jenv [12:05] I almost wonder if backup should be saving the .jenv as well. [12:05] since you really need both (I believe) [12:05] yep [12:08] jam: so my restore failed [12:08] voidspace: did stock juju core succeed? [12:08] jam: it looks like it opened the apiState fine, but then the Client failed to get an address for "machine-1" (my mysql unit - so the call to client.PublicAddress("machine-1") failed [12:08] jam: yes [12:09] jam: heh, although to be fair I didnt try with a unit with trunk as I wanted a quick test [12:09] but this seems like a plausible failure [12:09] I'm going to make coffee and then dig in [12:09] no public address found: unknown unit or machine "machine-1 [12:10] voidspace: the nice thing about backup and restore is that once you have the backup, you don't have to backup again, just try restore [12:10] yep :-) [12:10] voidspace: that sounds like a "tag" vs an "id" issue [12:10] as in, it might be expecting "1" for "machine-1" [12:10] ah right, just "1" maybe [12:10] will try that [12:10] even before coffee :-) [12:12] although if restore fails you have to manually kill the ec2 instance [12:13] as a failed restore leaves the instance it created running [12:15] jam: sorry, just seen your question. have been to lunch. [12:16] ok, restore underway again [12:16] coffee time [12:16] jam: have to see what it has been exactly, but yes, IMHO it has been the @ to lead from files [12:18] jam: https://bugs.launchpad.net/juju-core/+bug/1216967 [12:18] Bug #1216967: Missing @ syntax for reading config setting from file content

[12:18] TheMue: k, I thought it would show up in "juju help set" but I didn't see it there [12:19] jam: interesting, afair it should [12:21] jam: the set doc has a hint. three paragraphs, the second one. which version do you use? [12:23] TheMue: http://paste.ubuntu.com/8097539/ [12:23] is all I see for "juju help set [12:25] jam: see line 28 in juju/cmd/set.go, it’s more. but it’s not yet released [12:25] jam: so if you don’t use your own build you won’t see it. [12:26] TheMue: $ ~ [12:26] ~/dev/go/bin/juju set -h [12:26] I'm using trunk [12:26] ~/dev/go/bin/juju --version [12:26] 1.21-alpha1-trusty-amd64 [12:26] TheMue: you have "setDoc" set to the correct thing [12:26] but line 48 [12:27] has "Doc: "set one or more ..." [12:27] not Doc: setDoc [12:27] TheMue: care to submit a bug and a patch for it? [12:27] jam: aaargh, I found setDoc before and expanded it. never seen that it isn’t used. [12:27] jam: yep, will quickly do it. [12:46] jam: perrito666: looks to me like restore worked fine! [12:46] voidspace: sweet [12:46] jam: perrito666: will double check the code and create PR [12:47] and then *re-PR* the database shutoff [12:47] voidspace: greate. why didn't it work the first time? (did you fix something?) was it just the "machine-1" vs "1" issue? [12:47] jam: yep [12:48] jam: switching to id instead of tag fixed it [12:48] voidspace: I wish our code was more consistent here, but that is what API versioning could get us to :) [12:48] voidspace: can you file a bug tagged "API" about the inconsistency? [12:48] and tech-debt [12:49] jam: yep, and I'm adding a note to the PublicAddress docstring that "target" is an id not a tag. [12:51] aghh the convoluted settings of networkmanager/dnsmasq in 14.04 drive me crazy [12:52] perrito666: it looks like we broke plugins in 1.21 as well, which would have been caught if we were doing "juju restore" instead of "juju-restore", not that we should have used that to actually catch the bug [12:53] jam: thats huge, dont we have a test to make sure plugins actually works? [12:53] perrito666: apparently not https://bugs.launchpad.net/juju-core/+bug/1359170 [12:53] Bug #1359170: juju charm create fails in an unhelpful fashion with juju-1.21 in PATH

[12:53] I tried to run the charm-tools plugin [12:54] and apparently we stopped passing arguments to plugins in 1.21 [12:54] I'm testing 1.20 now [12:54] it seems broken there, too [12:54] bugger [12:54] curtis won't be happy [12:56] wallyworld_: can I point you to bug #1359170 when you're around? [12:56] Bug #1359170: arguments no longer passed to plugins

[12:56] I'll try to pick it up since I discovered it [12:58]