| 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:03 |
| 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:04 |
| 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:05 |
| wallyworld | what is? CI output? | 00:06 |
| rick_h__ | wallyworld: IRC | 00:06 |
| wallyworld | yes | 00:06 |
| wallyworld | i can search | 00:06 |
| wallyworld | davecheney: let's discuss real soon in juju meeting, then we can revert if needed | 00:07 |
| * thumper sighs | 00:08 | |
| thumper | I wish our code wasn't so shit | 00:08 |
| * thumper thinks hard about hooking this up | 00:08 | |
| 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:34 |
| wallyworld | natefinch: what happens if you run "ls -l /usr/lib/go/src/pkg/archive/zip" is there a .hg in there? | 00:45 |
| 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:48 |
| 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:49 |
| 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:50 |
| thumper | coffee time... | 00:53 |
| 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:54 |
| wallyworld | but i'm not sure | 00:55 |
| wallyworld | regardless, there's still one critical bug open | 00:55 |
| wallyworld | one other | 00:56 |
| thumper | what is the other? | 01:00 |
| 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:02 |
| * 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:03 | |
| 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:06 | |
| * thumper marks it high, but not regression | 01:07 | |
| thumper | and works on it | 01:07 |
| thumper | wallyworld: I'm getting the godeps errors now I've pull trunk too | 01:24 |
| wallyworld | \o/ | 01:24 |
| davecheney | wallyworld: thumper see my reply to the mail thread | 01:34 |
| davecheney | you already know my solution ... | 01:34 |
| thumper | seems reasonable to me :-) | 01:35 |
| wallyworld | me too :-) | 01:37 |
| 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:44 |
| 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:45 |
| 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 | 01:51 |
| axw | wallyworld: I'm asking ben howard for access to Azure China for testing - is there anyone else who should have access? | 02:14 |
| wallyworld | axw: we're all in the juju core meeting :-) | 02:15 |
| axw | oops | 02:15 |
| * davecheney insert paddling | 02:15 | |
| davecheney | https://github.com/juju/juju/pull/567 | 02:27 |
| === Ursinha is now known as Ursinha-afk | ||
| axw | wallyworld: Internet is scheduled for connection today, btw | 02:46 |
| axw | could be up to 48h before it's active tho | 02:46 |
| 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:47 |
| 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:52 |
| 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:53 |
| 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 ..." | 02:54 |
| === Ursinha-afk is now known as Ursinha | ||
| thumper | anyone? https://github.com/juju/juju/pull/568 | 03:00 |
| menn0 | wallyworld, thanks | 03:01 |
| wallyworld | np | 03:02 |
| wallyworld | looking | 03:02 |
| thumper | wallyworld: inlining now... | 03:05 |
| 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:06 |
| davecheney | ta | 03:07 |
| menn0 | look at that merge queue... it's a thing of beauty :) | 03:22 |
| thumper | where is the merge queue? | 03:33 |
| thumper | menn0: ? | 03:33 |
| 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:35 |
| 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:47 |
| wallyworld | \o/ | 03:48 |
| wallyworld | yep | 03:48 |
| wallyworld | menn0: 1.20 is a lot different isn't it | 03:49 |
| 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:50 |
| 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:51 |
| menn0 | wallyworld, well I made the problem too so don't thank me too much :) | 03:52 |
| wallyworld | ok, thanks for nothing then :-) | 03:52 |
| 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:53 |
| wallyworld | wallyworld tells wallyworld that all the time | 03:54 |
| menn0 | LOL | 03:54 |
| 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:21 |
| * thumper is done for the day (until meetings tonight) | 04:32 | |
| * thumper afk until 10pm local | 04:32 | |
| === thumper is now known as thumper-afk | ||
| 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:33 |
| davecheney | then push 556 tomorrow | 04:34 |
| axw | davecheney: commented | 05:15 |
| davecheney | axw: thanks, good suggestion | 05:23 |
| davecheney | give me a few minutes | 05:23 |
| axw | sure, ping me and I'll take another look | 05:24 |
| davecheney | axw: PTAL | 05:39 |
| axw | davecheney: LGTM | 05:41 |
| davecheney | axw: thanks, lets see if this asplodes ci overnight | 05:41 |
| dimitern | morning all | 05:45 |
| wallyworld | axw: can you take a peek at this one for me? https://github.com/juju/juju/pull/574 | 06:19 |
| axw | sure | 06:19 |
| wallyworld | thanks axw | 06:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| wallyworld | and hences masks the true private address | 06:38 |
| wallyworld | axw: do you agree with my statement above? | 06:44 |
| axw | wallyworld: sounds sane | 06:45 |
| wallyworld | righto | 06:45 |
| wallyworld | thanks | 06:45 |
| 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:13 |
| 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:14 |
| voidspace | wallyworld: o/ | 07:18 |
| voidspace | axw: morning | 07:18 |
| axw | voidspace: howdy | 07:18 |
| 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:19 |
| axw | voidspace: I have not had an official answer | 07:20 |
| 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:21 |
| 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:22 |
| 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:25 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| TheMue | morning | 07:39 |
| voidspace | TheMue: morning | 07:39 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 | |
| TheMue | jam: when refactoring the code this way I would spend some time in reviewing the help texts | 07:56 |
| TheMue | jam: the quality can’t be tested, but at least it’s a good opportunity to do so | 07:57 |
| 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? | 07:58 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| TheMue | We hide features, not good. :/ | 08:05 |
| 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:06 |
| rogpeppe1 | wallyworld: ping | 08:16 |
| 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:17 |
| 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:46 |
| 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:47 |
| jam | rogpeppe1: $ ./goroot | 08:48 |
| jam | /usr/lib/go | 08:48 |
| rogpeppe1 | jam: and does godeps actually produce a non-zero exit code? | 08:48 |
| 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:49 |
| 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. | 08:50 |
| Beret | wallyworld, around? | 09:01 |
| 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:02 |
| Beret | wallyworld, nevermind | 09:21 |
| voidspace | who is OCR today? | 09:25 |
| 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:27 |
| TheMue | voidspace: it can be changed via mup | 09:28 |
| voidspace | TheMue: ah, ok | 09:28 |
| 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:29 |
| 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:30 |
| TheMue | yeah, simplifies the quick access | 09:31 |
| voidspace | it's slow to calculate | 09:31 |
| voidspace | I have it starred now | 09:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:38 |
| voidspace | TheMue: oh, it does look like that assert is just duplicated | 09:39 |
| voidspace | TheMue: duplicate assert removed, thanks | 09:40 |
| 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:41 |
| voidspace | TheMue: i.e. is the test useful in it's own right? | 09:42 |
| TheMue | voidspace: I would like a test that only those ports we want are open and no others | 09:54 |
| 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:57 |
| TheMue | voidspace: yep, I’ve seen | 09:58 |
| 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 | 09:59 |
| 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 |
| === thumper-afk is now known as thumper | ||
| voidspace | which is a bit sucky | 10:01 |
| 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:02 |
| 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:03 |
| rogpeppe1 | jam: could you "go get -u launchpad.net/godeps" and try it again, please - the issue should be fixed now | 10:05 |
| jam | rogpeppe1: looks good to me | 10:09 |
| rogpeppe1 | jam: cool | 10:09 |
| jam | rogpeppe1: at least, no errors | 10:09 |
| TheMue | voidspace: a live test could at least have a problem with the local provider | 10:12 |
| TheMue | voidspace: it simply is a difficult topic. :D | 10:13 |
| voidspace | TheMue: yeah :-/ | 10:33 |
| 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:41 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:47 |
| jam | voidspace: have you read the IPv6 and charms doc? | 10:50 |
| 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:51 |
| voidspace | charms code I am not very familiar with - so will be fun to work on (maybe "fun") | 10:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 10:59 |
| 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:07 |
| 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:09 |
| 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?) | 11:48 |
| wallyworld | katco: just finishing a meeting | 12:02 |
| katco | wallyworld: ok | 12:02 |
| 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:03 |
| perrito666 | gsamfira: I tried under a certain cirsumstance and failed, Ill do it myself and take a look | 12:11 |
| gsamfira | if not, you can simply enable ssh agent forwarding on your machine | 12:14 |
| gsamfira | and that will allow you to use your local key even if you hop through another machine | 12:15 |
| perrito666 | gsamfira: I need to do something that does this automatically | 12:18 |
| gsamfira | gotcha | 12:18 |
| katco | good morning, team. how is everyone? | 12:30 |
| TheMue | katco: fine, and you? | 12:32 |
| katco | TheMue: getting over a cold, but looking forward to landing some code :) it's the perfect remedy :) | 12:33 |
| TheMue | katco: hehe, is it available on recipe? | 12:34 |
| katco | TheMue: what do you mean by recipe? | 12:35 |
| perrito666 | bbl | 12:36 |
| TheMue | katco: the remedy (it’s listed here in my dict also as medicine) | 12:36 |
| katco | TheMue: oh, sorry... thought maybe that was a technical reference :) haha, it's in the Programmer's book of home remedies ;) | 12:37 |
| TheMue | katco: a good book ;) | 12:39 |
| 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:41 |
| 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:43 |
| katco | TheMue: :) | 12:44 |
| katco | wallyworld: actually, are you still around? | 12:45 |
| 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:46 |
| wallyworld | let me look into it a bit | 12:47 |
| katco | i'm looking at state/apiserver/client/client.go | 12:47 |
| katco | wallyworld: seems like maybe it should be an error if the two settings conflict on a local machine | 12:48 |
| 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:51 |
| wallyworld | hmmm, i just trying to remember the use case | 12:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| katco | juju cmd? | 12:58 |
| wallyworld | the ProvisioningScript api call | 12:58 |
| katco | hmm ok | 12:58 |
| wallyworld | sorry, wrong terminology | 12:58 |
| wallyworld | because if we say DisablePackageCommands is deprecated, we need to prvide the new alternative | 12:59 |
| katco | right | 13:01 |
| wallyworld | i think you can just add the extra bools to the end of the struct | 13:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| katco | wallyworld: yeah, and then we're all set up to provide the finer-grained control | 13:07 |
| wallyworld | yep | 13:07 |
| katco | wallyworld: ok thanks :) | 13:08 |
| 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:09 |
| 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:10 |
| wallyworld | katco: it's only for a very specific api call | 13:11 |
| katco | wallyworld: ah that's right, it's not in the environ config | 13:12 |
| 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:14 |
| wallyworld | i think the bug should stay open | 13:15 |
| wallyworld | but we can do the backport | 13:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| free | sinzui: we can workaround it, but would be nice | 13:20 |
| sinzui | thank you free | 13:20 |
| katco | wallyworld: is this the common boilerplate you were referring to? juju/juju/environs/boilerplate_config.go | 13:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| 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:29 |
| wallyworld | i'll email when we are ready, but i expect it to be tuesday at latest unless something comes up | 13:30 |
| 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:38 |
| 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:41 |
| jam | ah, ffs, this code looks all sorts of buggy and broken :( | 13:42 |
| 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:44 |
| 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:45 |
| sinzui | jam, thank you! | 13:46 |
| mattyw | fwereade, ping? | 14:02 |
| zirpu | in the beginning was the pong. and it moved back and forth. | 14:40 |
| perrito666 | hey natefinch wwitzel3 ericsnow I am here but I am getting the party is over on hangout | 15:01 |
| natefinch | perrito666: works for me. Try restarting your browser | 15:02 |
| === urulama is now known as uru-afk | ||
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1w, 1359170 1354027 | ||
| 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:25 |
| jcw4 | should I just file defects for the tests that seem to fail only on go 1.3? | 16:26 |
| natefinch | jcw4: yes file bugs, or just fix them. We shouldn't ever be relying on map order | 16:34 |
| jcw4 | natefinch: +1 | 16:34 |
| hazmat | anyone know the instance distributor code? | 16:59 |
| natefinch | hazmat: I don't even know what the instance distributor is | 17:14 |
| hazmat | natefinch, its zone spread | 17:16 |
| natefinch | hazmat: ahh, ok | 17:16 |
| hazmat | but it seems to be operating at a instance level, trying to figure out how it ties back to the service level | 17:17 |
| natefinch | hazmat: no idea, that sounds like something that the Australian/New Zealand guys would have written | 17:19 |
| hazmat | natefinch, yeah.. i know who write it.. | 17:20 |
| hazmat | nevermind .. i figured it out.. it populates a distribution group with the extant instances that have common services | 17:27 |
| === BradCrittenden is now known as bac | ||
| 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 | 17:59 |
| 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:00 |
| 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:01 |
| natefinch | marcoceppi: yes | 18:02 |
| marcoceppi | natefinch: then that has my +1 since it's already there in core | 18:02 |
| marcoceppi | natefinch: any idea on my above query? | 18:03 |
| marcoceppi | only thing I can think is somehow relation-get checks CONTEXT_ID and knows it's not a relation | 18:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| jrwren_ | I don't know. I'd love to find out. | 18:09 |
| ericsnow | marcoceppi: see newRelationIdValue in worker/uniter/jujuc/context.go | 18:09 |
| natefinch | man our code is hard to navigate | 18:11 |
| 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:12 |
| katco | is lxc-clone no longer defaulted to true? | 18:56 |
| 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:57 |
| katco | https://github.com/juju/juju/blob/master/environs/config/config.go#L872 | 18:58 |
| sinzui | smoser, wallyworld, Lauren Mayberry sings "I communicate in simple streams" on the Chvrches - Night Sky song | 19:16 |
| 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:34 |
| natefinch | katco: not sure | 19:35 |
| 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:36 |
| 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:37 |
| 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:40 |
| 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:43 |
| katco | natefinch: doh, no that's not right either =| | 19:44 |
| 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:46 |
| natefinch | That looks like English... | 19:47 |
| natefinch | but I have no idea what it means :) | 19:47 |
| katco | natefinch: so i am no expert, but basically when defining the config variable, you can give it a default value | 20:08 |
| katco | natefinch: if you specify schema.Omit, it will not add it to a validated config object's map | 20:09 |
| 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:10 |
| * 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| perrito666 | well the asus was a nifty piece of hardware, but the soldered 4G of ram where a pain | 20:30 |
| === anthonyf` is now known as anthonyf | ||
| perrito666 | I mean, nice screen, nice kb (after replacing), decent battery, decent processor but really, 4G? | 20:30 |
| katco | perrito666: yeah bleck | 20:34 |
| sinzui | perrito666, do You have a few minutes to review https://github.com/juju/juju/pull/582/files | 20:54 |
| perrito666 | sinzui: I do | 20:56 |
| 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:57 |
| sinzui | perrito666, thank you for the explanation.I wasn't sure how new is new. | 20:58 |
| perrito666 | sinzui: las vegas new | 20:58 |
| 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 | 20:59 |
| perrito666 | sinzui: your pr messages dont compile in english | 21:05 |
| === uru-afk is now known as urulama | ||
| alexisb | thumper, ping | 21:32 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| urulama | :D | 21:51 |
| menn0 | davecheney, waigani: email standup today? | 22:22 |
| waigani | menn0: sounds good | 22:31 |
| wallyworld | sinzui: i merged your makefile changes directly | 22:50 |
| davecheney | menn0: sure | 22:56 |
| 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:01 |
| waigani | davecheney: I don't know how I missed that, I have the conflict locally now thanks | 23:18 |
| davecheney | waigani: you are a winner | 23:21 |
| davecheney | http://www.teddideppner.com/wp-content/uploads/2013/08/korben-dallas-winner-500x278.jpg | 23:22 |
| waigani | whoop whoop | 23:27 |
| perrito666 | anyone very expert in api calls? | 23:49 |
| davecheney | perrito666: proably me or jam | 23:50 |
| === xavier is now known as Guest55763 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
