[00:03] <davecheney> wallyworld: i don't see the value of pr 495
[00:03] <davecheney> i would not have approved it
[00:03] <davecheney> CI already tests godeps works
[00:03] <wallyworld> me either
[00:03] <davecheney> we don't need to run it locally
[00:04] <davecheney> +1 for reverting it for more review
[00:04] <wallyworld> well, i'll talk to nate first
[00:04] <rick_h__> davecheney: wallyworld I think that was casuing CI some issues. They had issues with it today
[00:04] <davecheney> wallyworld: that's +2 for revcerting it
[00:04] <davecheney> that is a carrying margin
[00:05] <davecheney> nate can always repropose it
[00:05] <davecheney> nothing is lost
[00:05] <wallyworld> rick_h__: what issues do you know?
[00:05] <rick_h__> wallyworld: it was down and not functional for a bit. I know sinzui and he were chasing down things and trying to get something with deps right
[00:05] <rick_h__> wallyworld: sorry, only idly watched irc as I wasn't directly effected
[00:05] <wallyworld> np
[00:05] <rick_h__> wallyworld: I can check my logs for more info
[00:05] <rick_h__> wallyworld: but then this is logged right?
[00:06] <wallyworld> what is? CI output?
[00:06] <rick_h__> wallyworld: IRC
[00:06] <wallyworld> yes
[00:06] <wallyworld> i can search
[00:07] <wallyworld> davecheney: let's discuss real soon in juju meeting, then we can revert if needed
[00:08]  * thumper sighs
[00:08] <thumper> I wish our code wasn't so shit
[00:08]  * thumper thinks hard about hooking this up
[00:34] <menn0> thumper, I think I see a race in PR 555 (the downgrade one). Fixing it now. This also makes the code clearer around the bit that confused you.
[00:34] <thumper> ok, cool
[00:45] <wallyworld> natefinch: what happens if you run "ls -l /usr/lib/go/src/pkg/archive/zip"   is there a .hg in there?
[00:48] <wallyworld> menn0: are you going to fix bug 1359435 ?
[00:48] <mup> Bug #1359435: Next version selection for upgrades is no longer correct <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1359435>
[00:49] <menn0> wallyworld, I just noticed that today incidentally while reviewing a PR from thumper
[00:49] <menn0> wallyworld, I had no intention of looking at it today
[00:49] <wallyworld> ok, ta
[00:49] <menn0> wallyworld, I'm unlikely to get to it this week and I'm off next week.
[00:50] <menn0> happy to look at it when I get back though
[00:50] <menn0> (if it's not fixed by then)
[00:50] <wallyworld> np, we'll get it sorted, i want to be able to release 1.20.6 early next week
[00:53] <thumper> coffee time...
[00:54] <thumper> wallyworld: how will we know if ci is happy with the windows build?
[00:54] <thumper> wallyworld: and when can we land the pending stuff?
[00:54] <wallyworld> thumper: i *think* it detects that the bug is fix committed
[00:54] <wallyworld> hence i marked it as such
[00:55] <wallyworld> but i'm not sure
[00:55] <wallyworld> regardless, there's still one critical bug open
[00:56] <wallyworld> one other
[01:00] <thumper> what is the other?
[01:02] <wallyworld> https://bugs.launchpad.net/bugs/1359170
[01:02] <mup> Bug #1359170: arguments no longer passed to plugins if you don't have an environment set <regression> <Juju Charm Tools:Invalid> <juju-core:Triaged by jameinel> <juju-core 1.20:Triaged by jameinel> <https://launchpad.net/bugs/1359170>
[01:03]  * thumper digs
[01:03] <thumper> I had a look at john's fix for that
[01:03] <thumper> but disagreed with it
[01:03]  * thumper looks again
[01:06] <thumper> wallyworld: this isn't a critical regression though
[01:06] <thumper> wallyworld: this has been this way for quite some time
[01:06] <thumper> at least since someone change the env command to be the wrapper as it is now
[01:06] <wallyworld> thumper: i didn't mark it as a regression. i guess we can unmark it
[01:06]  * thumper removes the tag
[01:07]  * thumper marks it high, but not regression
[01:07] <thumper> and works on it
[01:24] <thumper> wallyworld: I'm getting the godeps errors now I've pull trunk too
[01:24] <wallyworld> \o/
[01:34] <davecheney> wallyworld: thumper see my reply to the mail thread
[01:34] <davecheney> you already know my solution ...
[01:35] <thumper> seems reasonable to me :-)
[01:37] <wallyworld> me too :-)
[01:44] <axw> wallyworld: thanks for the review. will make those doc updates and test again after rebasing
[01:44] <axw> lots of changes from the windows PR...
[01:44] <wallyworld> sure, np
[01:44] <wallyworld> axw: i reverted it
[01:44] <axw> wallyworld: oh?
[01:44] <wallyworld> one of the windows ones
[01:44] <axw> the userdata one?
[01:44] <wallyworld> yep
[01:45] <wallyworld> it caused a regression
[01:45] <axw> bugger :(
[01:45] <axw> gabriel will be sad
[01:45] <wallyworld> my comment is in the revert
[01:45] <axw> I'll take a look, thanks
[01:45] <wallyworld> axw: well, he MUST learn to test his stuff
[01:45] <wallyworld> i mean, you develop for windows, you test your stuff on windows before landuing surely?
[01:51] <davecheney> minutes for handout in 10 mins are https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit
[01:51] <davecheney> please add items to discuss
[02:14] <axw> wallyworld: I'm asking ben howard for access to Azure China for testing - is there anyone else who should have access?
[02:15] <wallyworld> axw: we're all in the juju core meeting :-)
[02:15] <axw> oops
[02:15]  * davecheney insert paddling
[02:27] <davecheney> https://github.com/juju/juju/pull/567
[02:46] <axw> wallyworld: Internet is scheduled for connection today, btw
[02:46] <axw> could be up to 48h before it's active tho
[02:47] <wallyworld> axw: let's hope they do it on time  :-)
[02:47] <perrito666> does anyone know if its possible to ssh from a state server to an agent? (meaning, do we have a private key in place that is allowed on the agents?)
[02:52] <menn0> axw or wallyworld : any chance you can have a look at this? https://github.com/juju/juju/pull/566
[02:52] <wallyworld> sure
[02:53] <wallyworld> perrito666: yes, i believe so, that's how juju run works, right thumper ?
[02:53]  * thumper looks up
[02:53] <thumper> wat?
[02:53] <menn0> perrito666, yep, there's an identity file that you can use
[02:54] <thumper> right
[02:54] <thumper> yes
[02:54] <thumper> I think it is in /var/lib/juju/identity
[02:54] <thumper> use with "ssh -i ..."
[03:00] <thumper> anyone? https://github.com/juju/juju/pull/568
[03:01] <menn0> wallyworld, thanks
[03:02] <wallyworld> np
[03:02] <wallyworld> looking
[03:05] <thumper> wallyworld: inlining now...
[03:06] <wallyworld> ta
[03:06] <davecheney> wallyworld: can you kill http://juju-ci.vapour.ws:8080/job/github-merge-juju/364/console
[03:06] <davecheney> it's not going to pass
[03:06] <wallyworld> sure
[03:07] <davecheney> ta
[03:22] <menn0> look at that merge queue... it's a thing of beauty :)
[03:33] <thumper> where is the merge queue?
[03:33] <thumper> menn0: ?
[03:35] <menn0> thumper, I mean all the jobs queued up here: http://juju-ci.vapour.ws:8080/job/github-merge-juju/
[03:35] <menn0> it was longer before
[03:47] <menn0> wallyworld, the 1.20 backport of what you just reviewed for me: https://github.com/juju/juju/pull/569
[03:47] <menn0> can you pls have a look?
[03:48] <wallyworld> \o/
[03:48] <wallyworld> yep
[03:49] <wallyworld> menn0: 1.20 is a lot different isn't it
[03:50] <menn0> wallyworld, yeah the upgrade code has changed a lot so the backports are non-trivial
[03:50] <menn0> wallyworld, I don't see much more upgrade stuff being backported to 1.20 now though
[03:50] <menn0> this PR might be the last one (wishful thinking anyway)
[03:50] <wallyworld> menn0: my only concern is that maybe there is a test or two missing that may be needed in the backport?
[03:51] <menn0> wallyworld, the other tests that were in trunk don't make sense in 1.20
[03:51] <menn0> b/c upgradeWorkerContext doesn't exist in 1.20
[03:51] <wallyworld> rightio
[03:51] <wallyworld> done, thanks for fixing \o/
[03:51] <menn0> the higher level test that I did include does cover the change though
[03:52] <menn0> wallyworld, well I made the problem too so don't thank me too much :)
[03:52] <wallyworld> ok, thanks for nothing then :-)
[03:53] <menn0> menn0, that's more like it :)
[03:53] <menn0> wallyworld, even.... tiiiirrred
[03:53] <wallyworld> lol
[03:53] <wallyworld> menn0: the first sign of insanity is talking to yourself
[03:54] <wallyworld> wallyworld tells wallyworld that all the time
[03:54] <menn0> LOL
[04:21] <davecheney> menn0: i thought the definition of insanity was trying to submit a pull request over and over again and expecting differnt results
[04:21] <menn0> davecheney, if that' the case then we're all a little bit insane
[04:32]  * thumper is done for the day (until meetings tonight)
[04:32]  * thumper afk until 10pm local
[04:33] <davecheney> wallyworld: thumper-afk axw https://github.com/juju/juju/pull/571
[04:33] <davecheney> ^ this PR tries to peal off the most dangerous parts of 556
[04:33] <davecheney> i'd like to submit tihs today and see if CI burps overnight
[04:34] <davecheney> then push 556 tomorrow
[05:15] <axw> davecheney: commented
[05:23] <davecheney> axw: thanks, good suggestion
[05:23] <davecheney> give me a few minutes
[05:24] <axw> sure, ping me and I'll take another look
[05:39] <davecheney> axw: PTAL
[05:41] <axw> davecheney: LGTM
[05:41] <davecheney> axw: thanks, lets see if this asplodes ci overnight
[05:45] <dimitern> morning all
[06:19] <wallyworld> axw: can you take a peek at this one for me? https://github.com/juju/juju/pull/574
[06:19] <axw> sure
[06:29] <wallyworld> thanks axw
[06:30] <axw> wallyworld: hmm, should we be throwing away non-public addresses if they have the same IP address component?
[06:30] <axw> wallyworld: I think we may only want to throw away if it's public...
[06:30] <axw> otherwise that changes the internal address selection
[06:30] <wallyworld> hmmmm
[06:31] <wallyworld> when could there be two addresses, same IP, but one marked public, one marked private?
[06:31] <axw> wallyworld: if the floating IP returns the same as a private address range?
[06:31] <axw> un moment
[06:32] <axw> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1348287/comments/4
[06:32] <wallyworld> it won't do that - floating ip addresses are public
[06:32] <mup> Bug #1348287: Juju status returns private IP in 'public-ip' field. <cloud-installer> <landscape> <openstack-provider> <juju-core:In Progress by wallyworld> <juju-core 1.20:In Progress by wallyworld> <https://launchpad.net/bugs/1348287>
[06:33] <wallyworld> the problem was that their public and private ip address ranges were both 10.x.x.x
[06:33] <wallyworld> so juju couldn't guess which one was public
[06:33] <wallyworld> but there will never be 2 addresses with the same IP, that doesn't make sense
[06:34] <axw> well the auto-detection logic will classify it as private
[06:34] <axw> because it's in the 10. range
[06:34] <axw> but...
[06:34] <axw> I think the floating IPs will always come from a separate pool
[06:34] <wallyworld> yes, which is why we mark it as public
[06:34] <axw> so that's ok
[06:35] <wallyworld> ie the provider knows that a 10.a.b.c address is public if it is the floating ip address which was assigned
[06:35] <axw> wallyworld: the point I'm trying to make is that we shouldn't disqualify that address from use in internal communications
[06:35] <wallyworld> sure, but juju will guess that it is private when it is not
[06:36] <wallyworld> i do think that if it is known to be a floating ip address, it should be marked as public and nothing else
[06:36] <axw> public/private are relative. they may be the same thing depending on where you are. anyway, it doesn't matter because they'll be separate address ranges still
[06:37] <wallyworld> what worries me is that would could have in juju status both public and private be the same address
[06:37] <wallyworld> because the floating one was guessed as private and so was picked
[06:38] <wallyworld> and hences masks the true private address
[06:44] <wallyworld> axw: do you agree with my statement above?
[06:45] <axw> wallyworld: sounds sane
[06:45] <wallyworld> righto
[06:45] <wallyworld> thanks
[07:13] <wallyworld> axw: i killed your job because it was going to fail
[07:13] <wallyworld> trusty vs precise test failure
[07:13] <axw> wallyworld: yeah, I noticed, but doesn't killing it orphan the ec2 instance?
[07:13] <wallyworld> hmmm, yeah maybe
[07:14] <wallyworld> i'll ping curtis later to clean up
[07:14] <wallyworld> gotta run to soccer, back later for meetings \o/
[07:14] <axw> wallyworld: actually looks like it may have run the terminate script
[07:14] <axw> adios
[07:18] <voidspace> wallyworld: o/
[07:18] <voidspace> axw: morning
[07:18] <axw> voidspace: howdy
[07:19] <voidspace> any news on where the october sprint will be?
[07:19] <voidspace> I'm in India until October 5th
[07:19] <voidspace> sprint starts on the 6th...
[07:20] <axw> voidspace: I have not had an official answer
[07:21] <davecheney> voidspace: i heard brusssles
[07:21] <voidspace> axw: I haven't heard anything either
[07:21] <davecheney> but that was not confirmed
[07:21] <voidspace> davecheney: that would be cool
[07:21] <voidspace> davecheney: I mean, literally cool
[07:21] <voidspace> Brussells in October
[07:21] <voidspace> hmm, neither of us can spell Brussels it seems
[07:21] <voidspace> I'm still not convinced I've got it right
[07:21] <axw> Bruxelles
[07:22] <axw> :p
[07:22] <davecheney> yet we can still communicate our intentions perfectly
[07:22] <voidspace> :-)
[07:22] <voidspace> if only computers worked like that...
[07:22] <davecheney> \o/ evolution
[07:25] <free> hello, could anyone have a look at #1325946 for Landscape? it should be a no-brainer backport to 1.20.x
[07:25] <mup> Bug #1325946: Can't start named MAAS instances if environment is named kvm or lxc <add-machine> <kvm> <landscape> <lxc> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1325946>
[07:32] <voidspace> free: I will have some spare cycles shortly and will see if I can get to it
[07:32] <voidspace> free: unless someone else beats me to it...
[07:32] <free> voidspace: thanks!
[07:32] <free> voidspace: is there already a target date for the next 1.20.x release?
[07:32] <voidspace> free: that I don't know, it would depend on sinzui
[07:33] <voidspace> free: but we seem to do them fairly regularly, he's pretty efficient
[07:33] <free> voidspace: alright, would be great to have this little backport in the next one
[07:33] <voidspace> free: understood
[07:33] <voidspace> free: I can see the motivation from the bug report :-)
[07:33] <free> voidspace: he :)
[07:34] <voidspace> free: for the record, we're actively working on "multi-tenant state servers"
[07:34] <voidspace> free: which means that api calls won't automatically be scoped against a specific environment
[07:34] <free> voidspace: gotcha
[07:35] <free> voidspace: we're fine passing the UUID (as opposed to the name)
[07:35] <voidspace> free: yep, understood - and we need to be aware of that constraint
[07:39] <TheMue> morning
[07:39] <voidspace> TheMue: morning
[07:43] <jam> TheMue: so the issue is that if you back out your fix, the test doesn't fail, does it?
[07:43] <jam> because we are essentially testing that set.Help() == set.Help()
[07:43] <jam> and *not* testing that the contents of setDoc are the contents of set.Help()
[07:44] <jam> So for checking "is set registered" it works fine, but for testing whether the actual content is sane, it doesn't quite cover it.
[07:44] <voidspace> jam: morning o/
[07:44] <voidspace> coffee
[07:44] <voidspace> brb
[07:44] <jam> morning voidspace
[07:44] <TheMue> jam: hmm, than I took to test of the deploy help wrong
[07:45] <jam> TheMue: so there is 2 things that are good to test, (a) that "juju set" exists as a command, and (b) that the content of "juju set --help" contains what we want it to.
[07:45] <jam> Some people like to have tests like: c.Assert(helpText(), gc.Equals, `The content of the help text`) others feel like you shouldn't repeat yourself, as it means you have to update too many tests when something changes.
[07:46] <jam> TheMue: However, the test you added *wouldn't* have caught that changing setDoc doesn't change the output of "juju set --help"
[07:46] <jam> because it is effectively testing that
[07:46] <jam> c.Assert(set.helpText(), gc.Equals, registeredHelpText("set"))
[07:46] <jam> The "deploy" help has the same problem
[07:47] <TheMue> jam: IC
[07:47] <jam> as does sync-tools help
[07:47] <TheMue> jam: you said you added a good test. could you point me to it?
[07:47] <jam> TheMue: I can understand that people feel "the help text is com
[07:47] <jam> combined from 3 different places, and it is clumsy to just report it
[07:47] <jam> "
[07:48] <jam> TheMue: I believe I added the sync-tools one, but it suffers from what I just observed.
[07:48] <jam> I had written that test to check for (a)
[07:48] <jam> but I realize now that (b) would be useful to have
[07:48] <jam> and we don't
[07:49] <jam> TheMue: actually, when I wrote the test, I think I actually did: c.Assert(registeredHelpText("sync-tools"), gc.Equals, syncToolsDocString)
[07:49] <jam> TheMue: but now that we have stuff like EnvironCommandWrapper
[07:49] <jam> the *actual* help text is a bit obscured from just the raw string we have somewhere.
[07:50] <jam> So I'm wondering if we would benefit from splitting the test we have into actual concrete comparisons
[07:50] <TheMue> jam: OK, so a good test would be, for each command, to retrieve the help by executing the command and compare it to a variable where the help text is stored (like setDec)
[07:50] <jam> TheMue: or whether people would complain too much about having to update a test when they tweak the help content. (I happen to like the safety-net of tests)
[07:50] <jam> TheMue: actually, my preferred is to compare it to a local string
[07:51] <jam> TheMue: so in the table, "out: " would contain the actual help text string
[07:51] <TheMue> jam: *iiirks*
[07:51] <voidspace> jam: TheMue: for similar tests in the past I've just done a "contains test"
[07:52] <TheMue> jam: but then we would have to do it for args and purpose too, just to be consistent
[07:52] <voidspace> jam: TheMue: i.e. not duplicating the full text in the test, but asserting that it contains "some relevant part that we require it to contain"
[07:52]  * TheMue is reminded of UI tests in unit tests
[07:52] <voidspace> which is less clumsy to maintain and still tests (somewhat) that the output is being generated correctly
[07:52] <jam> TheMue: voidspace: so some of it is "the output of juju set --help is something that I'd actually like to read"
[07:53] <jam> and having it all in one place rather than just "contains" helps with that.
[07:53] <TheMue> voidspace: that wouldn’t work if we for example add some content
[07:53] <voidspace> TheMue: well, it wouldn't *fail*
[07:53] <jam> TheMue: voidspace: I don't think people today (core developers for example) are actually running "juju help $COMMAND" and reading all of it to actually know if it makes sense.
[07:53] <voidspace> jam: yes but it's still horrible
[07:53] <TheMue> voidspace: if you don’t change the test it won’t fail
[07:53] <voidspace> TheMue: but is "adding some text" something you want to test
[07:54] <voidspace> TheMue: and if it is it's easy to test
[07:54] <voidspace> TheMue: you can have several contains tests if there are several important parts
[07:54] <jam> voidspace: it might be good to know that you *didn't* add "and you're all a bunch of a$$hats" to every command :)
[07:54] <voidspace> jam: and copying and pasting output into a test doesn't actually test readability at all
[07:54] <TheMue> jam: inside the tests we have access to setDoc and co. so I would like the convention that doc never is set directly, but always via a variable and we compare the output to that variable
[07:55] <jam> TheMue: I'm reasonably ok with that as a compromise.
[07:55] <jam> TheMue: I think juju core could benefit from someone actually spending time reading the various help texts and how they reference eachother, etc. and actually make that a nice experience for users.
[07:55] <jam> that doesn't have to be done via the test suite, though.
[07:55] <TheMue> jam: so I could add a TestAllHelps and change the code to fit this convention. it’s good for a table driven test. :)
[07:55]  * voidspace really goes to get coffee
[07:56] <TheMue> jam: when refactoring the code this way I would spend some time in reviewing the help texts
[07:57] <TheMue> jam: the quality can’t be tested, but at least it’s a good opportunity to do so
[07:58] <jam> TheMue: my idea in having the full content there (after all generation steps) is that when auditing a change, you can see what the actual final outputs are. Though I realize that then when "-e" gets slightly different wording, it ends up changing 50 different commands' help content.
[07:58] <jam> though that is, honestly, just a search and replace, right?
[08:01] <TheMue> jam: for later changes I’m with you, it’s no problem. I only have my troubles with the duplication of all output
[08:01] <TheMue> jam: but hey, it’s not double in the binary, it’s only in the test
[08:01] <TheMue> jam: so it’s  ok
[08:01] <jam> TheMue: there is the concept of Dont Repeat Yourself
[08:02] <jam> and I want to be tasteful here
[08:02] <jam> and people certainly have different opinions in this.
[08:02] <jam> I'm just putting forth a thought.
[08:02] <jam> That maybe nobody actually knows what all the help texts say because we hide it in all of our layers and wrappers, etc.
[08:03] <TheMue> Yeah, there’s a lot of indirection.
[08:03] <jam> TheMue: and we have stuff where "global" help settings don't show up in the default "juju set --help"
[08:04] <TheMue> From a quality point of view it definitely would be better to ensure a correct output (but not the quality of the output).
[08:04] <jam> TheMue: "juju help global-options" shows you options that are available but aren't shown in "juju help" or "juju help set"
[08:04] <TheMue> But having all texts repeated in one file would make it easier to look for a consistent help and wording
[08:04] <jam> and "juju help set" doesn't *tell* you about "juju help global-options" you have to find it from "juju help topics"
[08:05] <TheMue> We hide features, not good. :/
[08:06] <jam> TheMue: I'm pretty sure thumper did it intentionally to avoid cluttering the short help, but I *think* we at least want a one-line reference so it can be discovered.
[08:06] <TheMue> So a change like this would have to goals: 1. ensure that the shown help is the correct one but even more important 2. that it has a good quality, is consistent and complete
[08:16] <rogpeppe1> wallyworld: ping
[08:17] <rogpeppe1> or anyone that has installed Go from a PPA - i'd like to try find out why godeps is failing in that case
[08:46] <jam> rogpeppe1: mine is just from the archive, I think, and it is failing
[08:46] <jam> rogpeppe1: https://bugs.launchpad.net/bugs/1359573
[08:46] <mup> Bug #1359573: API inconsistency: machine tag vs id <api> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1359573>
[08:46] <jam> sorry
[08:46] <jam> ii  golang-go           2:1.2.1-2ubunt amd64          Go programming language compiler
[08:46] <jam> ii  golang-go           2:1.2.1-2ubunt amd64          Go programming language compiler
[08:46] <jam> $ godeps -t ./...
[08:46] <jam> godeps: no version control system found for "/usr/lib/go/src/pkg/go/build"
[08:46] <jam> godeps: no version control system found for "/usr/lib/go/src/pkg/bufio"
[08:46] <rogpeppe1> jam: what does this program print for you? http://paste.ubuntu.com/8104597/
[08:47] <rogpeppe1> jam: and what's the exact output you get from "godeps -t ./..." ?
[08:47] <jam> rogpeppe1: http://paste.ubuntu.com/8104605/ for the latter
[08:48] <jam> rogpeppe1: $ ./goroot
[08:48] <jam> /usr/lib/go
[08:48] <rogpeppe1> jam: and does godeps actually produce a non-zero exit code?
[08:49] <jam> rogpeppe1: $ godeps -t ./... 2>/dev/null ; echo $?
[08:49] <jam> 1
[08:49] <jam> yeah
[08:49] <jam> exit 1
[08:49] <rogpeppe1> jam: i think i know what's going on now, thanks. the fix should hopefully not be hard.
[08:50] <jam> rogpeppe1: I'm around if you need me to poke at stuff
[08:50] <rogpeppe1> jam: thanks - i may well ask you to try an updated version.
[09:01] <Beret> wallyworld, around?
[09:02] <Beret> wallyworld, https://code.launchpad.net/~lutostag/gomaasapi/fix_nonce_generation/+merge/231638
[09:02] <Beret> that seems like a hack to me and not a proper fix
[09:02] <Beret> aren't we just changing the odds that we'll hit that bug again rather than properly preventing it?
[09:21] <Beret> wallyworld, nevermind
[09:25] <voidspace> who is OCR today?
[09:27] <voidspace> and the title is incorrect as neither of those two bugs are critical and open
[09:27] <voidspace> doesn't look like I'm allowed to change the title though
[09:28] <TheMue> voidspace: it can be changed via mup
[09:28] <voidspace> TheMue: ah, ok
[09:29] <TheMue> voidspace: but have to remember the syntax myself :)
[09:29] <voidspace> TheMue: do you know the magic incantation?
[09:29] <voidspace> heh
[09:29] <TheMue> voidspace: and btw, even without being ocr I just reviewed your PR
[09:29] <voidspace> TheMue: ah, cool - thanks
[09:30] <TheMue> voidspace: today Nate and Menno are OCRs
[09:30] <voidspace> TheMue: thanks
[09:30] <voidspace> I was just looking for the doc
[09:30] <voidspace> not sure if I have it starred
[09:30] <voidspace> I should do
[09:31] <TheMue> yeah, simplifies the quick access
[09:31] <voidspace> it's slow to calculate
[09:31] <voidspace> I have it starred now
[09:32] <voidspace> TheMue: the one I really need reviewing is this one: https://github.com/juju/juju/pull/561
[09:32] <voidspace> TheMue: the other one was reviewed to death already ;-)
[09:33] <TheMue> voidspace: *lol*
[09:33] <TheMue> voidspace: OK, will take a look
[09:33] <voidspace> TheMue: I don't understand your comment "why two asserts?"
[09:34] <voidspace> TheMue: I don't see two
[09:34] <voidspace> TheMue: maybe I'm being dense
[09:34] <voidspace> TheMue: and I have a philosophical objection to testing that we don't do things
[09:34] <voidspace> even where it is something we used to do
[09:34] <voidspace> because such tests build up and don't really test anything useful anymore
[09:36] <TheMue> voidspace: provider/openstack/live_test.go lines 183 and 184
[09:36] <voidspace> TheMue: ah, 184 isn't shown in the snippet
[09:36] <voidspace> I'll look
[09:37] <voidspace> TheMue: the answer maybe, "you'll have to ask the person who originally wrote the test" - but I'll look :-D
[09:37] <TheMue> voidspace: yeah, I won’t test it too, but in this case you do a change. something that has been open before is now closed. the test would document it.
[09:37] <voidspace> TheMue: the test would document something that doesn't happen
[09:37] <voidspace> TheMue: there are an infinity of things that don't happen we could document
[09:37] <TheMue> voidspace: I know it hasn’t been done by you, I only seen it
[09:37] <voidspace> it just becomes a historical note
[09:37] <voidspace> TheMue: sure I'll look
[09:38] <voidspace> TheMue: the test makes sense at the time you write it, but not after that
[09:38] <TheMue> voidspace: yes, a documentation of the change, not of what doesn’t happen
[09:38] <voidspace> TheMue: as I said, I object...
[09:38] <voidspace> I don't think our tests should be a historical archive
[09:38] <voidspace> they should document what we do, not what we used to do
[09:39] <voidspace> TheMue: oh, it does look like that assert is just duplicated
[09:40] <voidspace> TheMue: duplicate assert removed, thanks
[09:41] <voidspace> TheMue: the question I would ask is "if we had never opened the state port would we have a test that it is not opened"?
[09:42] <voidspace> TheMue: i.e. is the test useful in it's own right?
[09:54] <TheMue> voidspace: I would like a test that only those ports we want are open and no others
[09:57] <voidspace> TheMue: pretty sure we have that actually
[09:57] <voidspace> TheMue: some of those changes are me *removing* StatePort from the list of expected ports
[09:58] <TheMue> voidspace: yep, I’ve seen
[09:59] <voidspace> TheMue: I'm pretty sure if you run the modified tests against unmodified trunk you'll see failures because StatePort is open when the tests don't expect it to be
[10:01] <dimitern> jam, meeting?
[10:01] <voidspace> TheMue: I do agree that that is a useful thing to test
[10:01] <voidspace> TheMue: I'm pretty sure it's covered though
[10:01] <TheMue> voidspace: I’m not talking directly about your changes, more about a general way. e.g. having one test doing it for each provider the same way
[10:01] <voidspace> TheMue: yeah, unfortunately that code is provider specific
[10:01] <voidspace> TheMue: we choose which ports to open inside each provider
[10:01] <voidspace> which is a bit sucky
[10:02] <voidspace> so we could still screw it up for a provider and not have a test fail
[10:02] <TheMue> that’s what I meant, yes
[10:02] <jam> dimitern: made it
[10:03] <voidspace> TheMue: I would think that only a live test could usefully do that
[10:03] <voidspace> TheMue: or we move the code that chooses ports to open out of the providers, which would be a better fix
[10:05] <rogpeppe1> jam: could you "go get -u launchpad.net/godeps" and try it again, please - the issue should be fixed now
[10:09] <jam> rogpeppe1: looks good to me
[10:09] <rogpeppe1> jam: cool
[10:09] <jam> rogpeppe1: at least, no errors
[10:12] <TheMue> voidspace: a live test could at least have a problem with the local provider
[10:13] <TheMue> voidspace: it simply is a difficult topic. :D
[10:33] <voidspace> TheMue: yeah :-/
[10:41] <voidspace> TheMue: are we switching existing code to errors.Annotate as we see them?
[10:41] <voidspace> TheMue: I know I have to Errorf in my branch - one existing and one new
[10:41] <voidspace> I can switch both, no problem
[10:41] <voidspace> but just asking as a principle
[10:43] <TheMue> voidspace: as I understood jam we’re doing
[10:43] <jam> TheMue: voidspace: sorry we're not available for the standup today, we have a call with Mark S
[10:44] <jam> dimitern and I
[10:44] <voidspace> jam: :-(
[10:44] <voidspace> ok
[10:44] <voidspace> jam: dimitern: enjoy, don't promise too many things...]
[10:44] <jam> voidspace: you can probably chat with dimitern after we're done, but then I have the Team Lead call
[10:44] <voidspace> jam: ok
[10:45] <voidspace> my next immediate task (after fixing things from TheMue review) is backporting a bugfix to 1.20
[10:45] <voidspace> then I need a day long task
[10:47] <jam> voidspace: so the db access stuff is sorted out?
[10:47] <voidspace> jam: yep, basically
[10:47] <voidspace> jam: two PRs and two reviews
[10:50] <jam> voidspace: have you read the IPv6 and charms doc?
[10:51] <jam> voidspace: https://docs.google.com/a/canonical.com/document/d/1PZ0RipScWNmhpRuyVCZfpSLbH0UGekyApIzZU2_ca_Q/edit
[10:51] <voidspace> jam: I've read dimiter's networking model - the recent revision
[10:51] <voidspace> jam: not sure about the charms one
[10:51] <voidspace> jam: will make sure I digest it
[10:51] <voidspace> thanks, starring
[10:52] <voidspace> charms code I am not very familiar with - so will be fun to work on (maybe "fun")
[10:53] <jam> voidspace: so I think we may want to start with "container addressibility" https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.h1grzzgqa6st (sorry for the giant doc)
[10:53] <voidspace> ah, the vegas doc
[10:53] <jam> the shorter (older) doc was https://docs.google.com/a/canonical.com/document/d/1Gu422BMAJDohIXqm6Vq4WTrtBV8hoFTTdXvXDQCs0Gs/edit, it isn't very complete
[10:53] <voidspace> jam: container addressability is what TheMue was working on, right
[10:53] <voidspace> experimenting with
[10:54] <jam> dammit, why is "clear the screen" in Pidgin the same ^L as "go to the address bar" in Firefox
[10:54] <jam> https://docs.google.com/a/canonical.com/document/d/1UzJosV7M3hjRaro3ot7iPXFF9jGe2Rym4lJkeO90-Uo/edit#heading=h.a92u8jdqcrto is another one to look at
[10:54] <voidspace> "Networking for containers" is terse
[10:55] <TheMue> voidspace: stopped it to do other tasks. would like to see you setting up a test environment too, maybe it’s simply an error by me
[10:55] <voidspace> it doesn't explain why we want containers - we have the future use case of "more dense deployments"
[10:55] <voidspace> TheMue: yep
[10:55] <voidspace> TheMue: I followed your progress
[10:55] <jam> voidspace: TheMue was working IPv6 and containers which isn't quite the same
[10:55] <voidspace> TheMue: I started to get nested containers setup
[10:55] <voidspace> TheMue: but didn't get much further than that
[10:55] <voidspace> jam: right - ipv6 addressability
[10:55] <jam> this is more about asking EC2 to give us another address, and then getting that address routed into one of our containers
[10:56] <voidspace> jam: do we have a more immediate use case for container addressability
[10:56] <jam> so that LXC-1 on machine-1 is visible to LXC-N on machine-2
[10:56] <voidspace> right
[10:56] <TheMue> jam: oh, that sounds nice too
[10:56] <jam> voidspace: right now the only environment that can deploy into LXC and get the service out is MaaS because it assigns addresses from DHCP
[10:56] <voidspace> jam: but why do we need that?
[10:57] <voidspace> jam: I mean, I know why it would be nice. But why is it a priority?
[10:57] <jam> voidspace: "juju deploy mysql --to lxc:0"
[10:57] <jam> voidspace: density
[10:57] <voidspace> that's why it would be nice
[10:57] <voidspace> jam: ok, so that's shifted up the priority stack
[10:57] <voidspace> cool, cool
[10:57] <jam> voidspace: its part of the general "networking model"
[10:58] <voidspace> after a while my vm saturates both cores on this laptop and the machine becomes unseable until I restart parallels
[10:58] <voidspace> "a while" is a couple of days
[10:58] <jam> voidspace: ouch
[10:58] <voidspace> but still
[10:59] <jam> voidspace: also, we need to change how we do container addresses in MaaS starting with MaaS 1.6
[10:59] <jam> as they want us to do the same thing ther
[10:59] <jam> ask MaaS for another address, and then we can use it for the container
[10:59] <voidspace> jam: right
[10:59] <jam> rather than going via DHCP
[10:59] <voidspace> so if we need to do it right for MaaS we might as well solve the general problem
[11:07] <dimitern> voidspace, TheMue, guys, you're still standuping ? :)
[11:07] <dimitern> doesn't look so
[11:07] <dimitern> ok, I need a short ciggie break
[11:09] <mattyw> thumper, thanks for pointing out this problems in metrics. I'll put a card on the board to remind me to do them
[11:09] <thumper> mattyw: np
[11:48] <perrito666> ill ask this again in case there is someone new
[11:48] <perrito666> does anyone know if its possible to ssh from a state server to an agent? (meaning, do we have a private key in place that is allowed on the agents?)
[12:02] <wallyworld> katco: just finishing a meeting
[12:02] <katco> wallyworld: ok
[12:03] <gsamfira> perrito666: the code suggests that it is possible. I can bootstrap an environment in 5 minutes on MaaS and let you know if you'd like.
[12:11] <perrito666> gsamfira: I tried under a certain cirsumstance and failed, Ill do it myself and take a look
[12:14] <gsamfira> if not, you can simply enable ssh agent forwarding on your machine
[12:15] <gsamfira> and that will allow you to use your local key even if you hop through another machine
[12:18] <perrito666> gsamfira: I need to do something that does this automatically
[12:18] <gsamfira> gotcha
[12:30] <katco> good morning, team. how is everyone?
[12:32] <TheMue> katco: fine, and you?
[12:33] <katco> TheMue: getting over a cold, but looking forward to landing some code :) it's the perfect remedy :)
[12:34] <TheMue> katco: hehe, is it available on recipe?
[12:35] <katco> TheMue: what do you mean by recipe?
[12:36] <perrito666> bbl
[12:36] <TheMue> katco: the remedy (it’s listed here in my dict also as medicine)
[12:37] <katco> TheMue: oh, sorry... thought maybe that was a technical reference :) haha, it's in the Programmer's book of home remedies ;)
[12:39] <TheMue> katco: a good book ;)
[12:41] <katco> TheMue: it only has 3 pages: one on caffeine, one on the asymptotic time it takes to get better, and then the third page just says, "Code."
[12:43] <katco> TheMue: apparently i applied a O(1) remedy ;)
[12:43] <TheMue> katco: so will follow chapter 3 now, currently adding a new version of an API call
[12:44] <katco> TheMue: :)
[12:45] <katco> wallyworld: actually, are you still around?
[12:46] <wallyworld> yup
[12:46] <katco> wallyworld: just looking at how i'm going to set this DisablePackageCommands... and i'm a little fuzzy on the precedent. what happens if the config settings conflict with this?
[12:47] <wallyworld> let me look into it a bit
[12:47] <katco> i'm looking at state/apiserver/client/client.go
[12:48] <katco> wallyworld: seems like maybe it should be an error if the two settings conflict on a local machine
[12:51] <wallyworld> katco: there's nowhere in the Go codebase that sets that bool; it must be used via a python client. but if the user has specified it, that's what they want so it should override any config settings
[12:51] <katco> wallyworld: but if they also set the new config values, shouldn't we alert them to the fact that their preferences are conflicting?
[12:53] <wallyworld> hmmm, i just trying to remember the use case
[12:54] <wallyworld> it's used in manual prvisioning to set up a host5
[12:54] <wallyworld> that's within juju, not sure about external usage
[12:55] <katco> wallyworld: host5?
[12:55] <wallyworld> bah, typo
[12:55] <wallyworld> i think a warning printed on the console is sufficient
[12:55] <katco> wallyworld: and then prefer the disablepackagecommands?
[12:56] <wallyworld> yep. but the check doesn't happen client side, unless the enc config is fetched
[12:56] <wallyworld> env
[12:56] <katco> wallyworld: i also put in a comment that that setting was deprecated as of 1.20.6... is that safe?
[12:57] <wallyworld> a code comment?
[12:57] <katco> wallyworld: yes
[12:57] <wallyworld> that's fine
[12:57] <wallyworld> it will remain deprecated until juju 2.0
[12:57] <katco> wallyworld: gotcha
[12:57] <wallyworld> actually, i think you need to add support for the new bools in the command
[12:58] <katco> juju cmd?
[12:58] <wallyworld> the ProvisioningScript api call
[12:58] <katco> hmm ok
[12:58] <wallyworld> sorry, wrong terminology
[12:59] <wallyworld> because if we say DisablePackageCommands is deprecated, we need to prvide the new alternative
[13:01] <katco> right
[13:01] <wallyworld> i think you can just add the extra bools to the end of the struct
[13:02] <katco> gosh, also... if the defaults for these 2 new settings are true, basically anytime someone uses the DisablePackageCommands setting, they're going to get these warnings.
[13:02] <wallyworld> but hmmm
[13:02] <katco> they wouldn't be able to set these 2 new settings in a < 1.20.6 client
[13:02] <wallyworld> that's not such a good idea, because we won't know which variation they'e using
[13:02] <katco> or w/e this is going in
[13:03] <wallyworld> let's leave it for now
[13:03] <wallyworld> we may just need to wait till the old bool is removed and replace it with the 2 new ones
[13:04] <katco> wallyworld: sorry, so what now? "leave it"?
[13:04] <wallyworld> support the original DisablePackageCommands bool but not worry about the new ones yet
[13:05] <katco> wallyworld: ah, so maybe use the original to drive the new ones? that way the finer-grained control is all in place, but the clients just can't use it that way yet?
[13:05] <wallyworld> yup
[13:05] <wallyworld> as the DisablePackageCommands is pulled off the wire, map it to the 2 new ones
[13:06] <katco> wallyworld: ok. i _think_ that should still provide performance benefits when DisablePackageCommands = true.
[13:06] <wallyworld> yes it will
[13:06] <wallyworld> cause neither upgrade nor update wil be run
[13:07] <katco> wallyworld: yeah, and then we're all set up to provide the finer-grained control
[13:07] <wallyworld> yep
[13:08] <katco> wallyworld: ok thanks :)
[13:09] <wallyworld> np, i think it's a decent solution. we can always add the finer grained stuff to the command if really needed
[13:09] <wallyworld> s/command/api
[13:09] <katco> wallyworld: yeah, people might not even need it
[13:09] <wallyworld> exactly
[13:10] <sinzui> hi jam, wallyworld, natefinch, There is a request to backport a change to 1.20. The proposed change is certainly backportable, but I need your agreement that it will solve the problem, see bug 1325946
[13:10] <mup> Bug #1325946: Can't start named MAAS instances if environment is named kvm or lxc <add-machine> <kvm> <landscape> <lxc> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1325946>
[13:10] <katco> wallyworld: kind of begs the question, why wasn't this doing what we wanted earlier?
[13:11] <wallyworld> katco: it's only for a very specific api call
[13:12] <katco> wallyworld: ah that's right, it's not in the environ config
[13:14] <wallyworld> sinzui: it may do, that bug looks kinda ugly
[13:14] <voidspace> sinzui: wallyworld: the backport is a workaround for the bug, right?
[13:14] <wallyworld> that's what i was thinking too
[13:14] <voidspace> sinzui: wallyworld: and does solve the problem (as far as I can tell anyway)
[13:15] <wallyworld> i think the bug should stay open
[13:15] <wallyworld> but we can do the backport
[13:16] <sinzui> wallyworld, thank you. voidspace , thank you
[13:16] <wallyworld> sinzui: i am hoping we can do a 1.20.6 release early next week, say tuesday?
[13:16] <voidspace> free: ^^^
[13:17] <free> voidspace: awesome
[13:17] <wallyworld> i have 2 or 3 small fixes to do for bugs, plus a backport or 2
[13:17] <free> voidspace: would the fix we spoke about be in?
[13:17] <voidspace> free: yep
[13:17] <free> voidspace: great
[13:17] <wallyworld> which one?
[13:17] <voidspace> wallyworld: that's the one we just discussed :-)
[13:17] <sinzui> wallyworld, possibly...I expect to be hiding from the beach. If I have network I can guarantee it. The QA team can follow the template/script, but I think they might have some anxiety
[13:17] <wallyworld> ah
[13:17] <voidspace> bug 1325946
[13:17] <mup> Bug #1325946: Can't start named MAAS instances if environment is named kvm or lxc <add-machine> <kvm> <landscape> <lxc> <maas-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1325946>
[13:18] <wallyworld> sinzui: when you back?
[13:18] <sinzui> wallyworld, 1.20.5 is in utopic today
[13:18] <sinzui> wallyworld, the following week
[13:18] <free> voidspace: if it's not too big of a deal the last thing we'd need for Landscape is #1359714. But that we could workaround because we can sniff the machine ID by looking at the current directory name in the hook
[13:18] <mup> Bug #1359714: Add JUJU_MACHINE_ID to the hooks environment <charms> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1359714>
[13:18] <wallyworld> sinzui: i think they should do the release, can't rely on one person, if we do that, something is wrong with the process
[13:18] <sinzui> wallyworld, I really am hiding from the beach. I intend to hack on something
[13:19] <wallyworld> ok :-)
[13:19] <wallyworld> sinzui: the reason for wanting to release is there's some fixes in there many people are interested in
[13:19] <voidspace> free: I'm not sure how suitable for backporting it would be once we fix it (new feature and all that)
[13:19] <sinzui> free, do you need that behaviour in 1.20.x?
[13:19] <voidspace> free: but we can look at it
[13:20] <free> sinzui: we can workaround it, but would be nice
[13:20] <sinzui> thank you free
[13:21] <katco> wallyworld: is this the common boilerplate you were referring to? juju/juju/environs/boilerplate_config.go
[13:22] <sinzui> I am going to lower all the criticals affecting 1.21-alpha1 that have a  1.20.x to High because we do not need to take further action with them
[13:23] <wallyworld> katco: yes, but i see that it is not really suitable to add the config stuff to - it may need to be done individually for all providers
[13:23]  * sinzui wants the bug listing to clearly show what we want to fix now
[13:23] <katco> wallyworld: i thought it most applicable to point out in lxc and manual. it is still available in the others, but maybe not as important to call out. thoughts?
[13:23] <wallyworld> sinzui: there are no open criticals for 1.21 though, right?
[13:24] <wallyworld> katco: sounds reasonable, but i think people were asking about it for ec2 etc as well
[13:24] <katco> wallyworld: ah ok. in it goes!
[13:24] <sinzui> wallyworld, the topic says so, but you cannot easily check the bug listing to see if they were fixed while you slept :(
[13:24] <wallyworld> katco: that's what he said
[13:25] <katco> wallyworld: LOL
[13:25] <katco> wallyworld: in a time when the world is crazy, it's good to see some humor is multi-national :)
[13:25] <wallyworld> :-D
[13:26] <sinzui> wallyworld, actually, all claim to be fixed. CI lost an ec2 instance 9 hours ago and stalled. I have restarted the building and publication of the last revision added to 1.20
[13:26] <wallyworld> sinzui: actually, you reminded me - i killed a couple of jenkins landing jobs that were going to fail - that may have left orphaned instances?
[13:28] <sinzui> wallyworld, ah. Indeed. I see them from time to time I assume any machine 12 hours old is safe to remove
[13:28] <wallyworld> remove away
[13:29] <wallyworld> sinzui: so have a think about 1.20.6 release - would be nice for early next week, and you can see how well you can rely on your team :-)
[13:29] <sinzui> +1
[13:30] <wallyworld> i'll email when we are ready, but i expect it to be tuesday at latest unless something comes up
[13:38] <jam> sinzui: so https://github.com/juju/juju/commit/ee7cfef912eea184822cb3a536aff04b56bf14e4 looks like it would promote compatibility, which seems ok to me
[13:38] <jam> though the error message there means the patch isn't quite complete
[13:38] <jam> return nil, fmt.Errorf("invalid environment name %q", p.Placement.Scope)
[13:38] <jam> doesn't quite make sense when the Scope is a UUID
[13:41] <jam> sinzui: their actual issue is several lines earlier which is:
[13:41] <jam> containerType, err := instance.ParseContainerType(p.Placement.Scope)
[13:41] <jam> though why we are passing a plain "scope"
[13:41] <jam> that isn't properly tagged is beyond me
[13:42] <jam> ah, ffs, this code looks all sorts of buggy and broken :(
[13:44] <sinzui> hey everyone. I got successful runs of unit tests in lxc yesterday. I am going to propose some changes the devel and stable makefile that will make unittests more reliable in the many envs we try them in
[13:45] <jam> sinzui: so the thing they are asking for is a bad fix to their original bug, but we're possibly ok backporting it. The main problem is that I really don't think we should be changing the CLI unless we know the API server is updated.
[13:45] <jam> so maybe 1.21 is already broken against 1.20 and we just don't know it
[13:46] <sinzui> jam, thank you!
[14:02] <mattyw> fwereade, ping?
[14:40] <zirpu> in the beginning was the pong. and it moved back and forth.
[15:01] <perrito666> hey natefinch wwitzel3 ericsnow I am here but I am getting the party is over on hangout
[15:02] <natefinch> perrito666: works for me.  Try restarting your browser
[16:25] <jcw4> I've noticed that go 1.3* uncovers a few testing defects for me; I assume because of the forced random iteration of maps
[16:25] <jcw4> are we running tests using latest go in CI anywhere?
[16:26] <jcw4> should I just file defects for the tests that seem to fail only on go 1.3?
[16:34] <natefinch> jcw4: yes file bugs, or just fix them.  We shouldn't ever be relying on map order
[16:34] <jcw4> natefinch: +1
[16:59] <hazmat> anyone know the instance distributor code?
[17:14] <natefinch> hazmat: I don't even know what the instance distributor is
[17:16] <hazmat> natefinch, its zone spread
[17:16] <natefinch> hazmat: ahh, ok
[17:17] <hazmat> but it seems to be operating at a instance level, trying to figure out how it ties back to the service level
[17:19] <natefinch> hazmat: no idea, that sounds like something that the Australian/New Zealand guys would have written
[17:20] <hazmat> natefinch, yeah.. i know who write it..
[17:27] <hazmat> nevermind .. i  figured it out.. it populates a distribution group with the extant instances that have common services
[17:59] <marcoceppi> Why doesn't this work?
[17:59] <marcoceppi> JUJU_RELATION_ID=mongos:3 JUJU_REMOTE_UNIT=shard1/0 relation-get
[17:59] <marcoceppi> I get an error that no relation id is specified
[18:00] <rick_h__> mongos?
[18:00] <marcoceppi> I'm running this on mongodb charm
[18:00] <rick_h__> aside from that no idea how that stuff owrks
[18:00] <marcoceppi> if i set those as -r  and give it a remote unit int he command line it work
[18:00] <marcoceppi> sbut setting the environment variable before the command does not
[18:01] <marcoceppi> is there an additional environment variable in hook that's telling it it's not a realtion?
[18:01] <marcoceppi> natefinch: also, it looks like there's already a JUJU_HOOK_NAME in the environment, could we just use that instead of argv[1] ?
[18:02] <natefinch> marcoceppi: yes
[18:02] <marcoceppi> natefinch: then that has my +1 since it's already there in core
[18:03] <marcoceppi> natefinch: any idea on my above query?
[18:04] <marcoceppi> only thing I can think is somehow relation-get checks CONTEXT_ID and knows it's not a relation
[18:05] <natefinch> marcoceppi: I don't really know that area of the code, so I can't really help.
[18:05] <marcoceppi> natefinch: who can I bother :)
[18:05] <jrwren_> marcoceppi: relation-get requires a parameter
[18:06] <marcoceppi> jrwren_: I'm not even getting that far
[18:06] <marcoceppi> error: no relation id specified
[18:06] <marcoceppi> even with key, still same error. I've added it to environment via export and by setting it preceeding the command
[18:07] <jrwren_> marcoceppi: requires the -r if you are outside a relation hook. Is that what you are trying to fake by setting those env var?
[18:07] <marcoceppi> jrwren_: yes, how does it know? context_id ?
[18:07] <marcoceppi> I figured it would check env, then check -r
[18:07] <marcoceppi> but it's not even looking for the envs
[18:09] <jrwren_> I don't know. I'd love to find out.
[18:09] <ericsnow> marcoceppi: see newRelationIdValue in worker/uniter/jujuc/context.go
[18:11] <natefinch> man our code is hard to navigate
[18:12] <marcoceppi> haha
[18:12] <marcoceppi> so, ctx.HookRelation looks promising, I see it's checking for relation context
[18:12] <marcoceppi> that's probably being pulled in from JUJU_CONTEXT_ID
[18:12] <marcoceppi> really wish I could fake that
[18:56] <katco> is lxc-clone no longer defaulted to true?
[18:57] <katco> in the code, it's specified with schema.Omit, but i'm looking at Ian's comment on 7/31 here (https://bugs.launchpad.net/juju-core/+bug/1350493), and it says Juju 1.20 ships with it set to true
[18:57] <mup> Bug #1350493: 1.20.x local provider not running apt-get update <charms> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1350493>
[18:58] <katco> https://github.com/juju/juju/blob/master/environs/config/config.go#L872
[19:16] <sinzui> smoser, wallyworld, Lauren Mayberry sings "I communicate in simple streams" on  the  Chvrches - Night Sky song
[19:34] <katco> i thought i understood this, but i'm missing something. in environments.yaml, how do you set a default config value, and then detect if it's using the default or a user-specified value?
[19:35] <natefinch> katco: not sure
[19:36] <katco> natefinch: doh :(
[19:36] <katco> i mean i can think of a way to do it, but i'm not sure if that's the canonical way
[19:37] <natefinch> katco: likely the only way to know for sure is if we have some explicit code in there for detecting an unset value and using a default instead... like a nil *string or whatever
[19:40] <katco> natefinch: well, there's schema.Omit, and if i specify that, i can return a value in the setting's wrapper-method if it's not found
[19:43] <katco> natefinch: ahh... it looks like the magic-combo might be to specify the setting in alwaysOptional as schema.Omit, but then give it a default in allDefaults
[19:44] <katco> natefinch: doh, no that's not right either =|
[19:46] <natefinch> If a field is not present in the map and defaults to Omit, the missing field will be ommitted from the coerced map as well.
[19:47] <natefinch> That looks like English...
[19:47] <natefinch> but I have no idea what it means :)
[20:08] <katco> natefinch: so i am no expert, but basically when defining the config variable, you can give it a default value
[20:09] <katco> natefinch: if you specify schema.Omit, it will not add it to a validated config object's map
[20:10] <katco> natefinch: which is exactly what i want, but i also want a default value if it's not specified. and apparently that's the tricky bit (or at least the part i haven't figured out). i'm going with a work-around and someone can correct me lol
[20:25]  * perrito666 bashes a bit his head on the keyboard
[20:25] <katco> perrito666: may i join you, sir?
[20:25] <perrito666> katco: certainly, you will have to provide your own keyboard though
[20:26] <katco> alas, i have already broken mine.
[20:26]  * perrito666 thinks katco might remember the effect he has on keyboards
[20:26] <katco> rofl
[20:26] <katco> yeah you can just replace yours!
[20:27] <perrito666> katco: well I have bulky thinkpad now so it is even easier and there is not violence involved
[20:27] <katco> just need to finish this test, rebase, test again and then finall submit this stupid PR
[20:27] <katco> perrito666: oh did you get a new laptop already?
[20:27] <perrito666> katco: I swapped my mac with my wifes thinkpad
[20:28] <katco> perrito666: ah nice. how do you like it?
[20:28] <perrito666> katco: I always like thinkpads, this is a t420, the only downside of it is to carry it
[20:28] <perrito666> and I have plenty of ram, which allows me to do a lot
[20:29] <katco> perrito666: i know what you mean. i went from a... 11"? macbook air to a 15" s57
[20:29] <katco> perrito666: i thought about a smaller one, but at sprints i want a screen i can work off of
[20:30] <perrito666> well the asus was a nifty piece of hardware, but the soldered 4G of ram where a pain
[20:30] <perrito666> I mean, nice screen, nice kb (after replacing), decent battery, decent processor but really, 4G?
[20:34] <katco> perrito666: yeah bleck
[20:54] <sinzui> perrito666, do You have a few minutes to review https://github.com/juju/juju/pull/582/files
[20:56] <perrito666> sinzui: I do
[20:57] <perrito666> sinzui: you should know that as per the new review mentor plan my reviews lack power unless upgraded with a reviewer combo :p (holds true for all newcommers)
[20:58] <sinzui> perrito666, thank you for the explanation.I wasn't sure how new is new.
[20:58] <perrito666> sinzui: las vegas new
[20:59] <sinzui> perrito666, you started before Las Vegas :)
[20:59] <perrito666> sinzui: mm, lets put it this way,anyone who's first sprint was vegas or after :p
[21:05] <perrito666> sinzui: your pr messages dont compile in english
[21:32] <alexisb> thumper, ping
[21:46] <menn0> alexisb, I believe thumper has the day off today
[21:46] <urulama> thumper: you owe us a beer next time ;)
[21:46] <alexisb> menn0, ug
[21:46] <alexisb> he accepted the invite and forced urulama to stay up until midnight :)
[21:47] <menn0> alexisb, ok, then maybe he will be around?
[21:47] <alexisb> I always forget that you guys are a day ahead
[21:47] <menn0> alexisb, do you want me to SMS him?
[21:47] <alexisb> I think he just didnt think about the timing giving it is a reoccurring meeting
[21:47] <alexisb> menn0, nah
[21:47] <alexisb> were good
[21:48] <alexisb> he just owes urulama a beer ;)
[21:48] <urulama> alexisb: tbh, i'm always up at this time, but, still a belgium beer it is :D
[21:48] <menn0> urulama, alexisb: I think you should ask for more than one :)
[21:49] <perrito666> so, how is this mechanism to extort beers from thumper?
[21:49] <urulama> alexisb: or maybe i can get by for not reviewing his errgo/errors branch :S
[21:49] <alexisb> perrito666, you have to invite thumper to a meeting he cannot attend and trick him into accepting the invite...
[21:50] <alexisb> then make sure it is at midnight your time and ensure everyone feels bad for you staying up
[21:50] <perrito666> alexisb: ah that should be easy, people tend to accept invites without looking
[21:50] <alexisb> then make the request on IRC
[21:50] <alexisb> we should write this process in a google doc and send it out to juju-dev ;)
[21:51] <urulama> :D
[22:22] <menn0> davecheney, waigani: email standup today?
[22:31] <waigani> menn0: sounds good
[22:50] <wallyworld> sinzui: i merged your makefile changes directly
[22:56] <davecheney> menn0: sure
[23:01] <davecheney> sinzui: how are the builds looking at the momnet
[23:01] <davecheney> i see there are no blockers
[23:01] <davecheney> i'm going to try to land my large api refactor branch today
[23:01] <davecheney> and I'd like to not land it on top of other breakage
[23:18] <waigani> davecheney: I don't know how I missed that, I have the conflict locally now thanks
[23:21] <davecheney> waigani: you are a winner
[23:22] <davecheney> http://www.teddideppner.com/wp-content/uploads/2013/08/korben-dallas-winner-500x278.jpg
[23:27] <waigani> whoop whoop
[23:49] <perrito666> anyone very expert in api calls?
[23:50] <davecheney> perrito666: proably me or jam