[00:05] davecheney, false [00:05] tags are project specific [00:05] albeit guess work [00:06] hazmat: hmm, i found a way I can search across projects via tag [00:07] go to the main page of lp [00:07] search for your tag there [00:07] sort of works [00:07] projects can have official tags defined to remove the guesswork. you get auto completion and stuff like that then [00:10] i'm trying to build a report for PM who need to know how much work is left on a project [00:10] whenever I see them maintaing their own list in a google doc [00:10] I cry inside [00:14] wonder why they do that [00:16] launchpad is hard, let's go shopping [00:18] davecheney: launchpad is not that hard when a) you know how to use it b) you use it for which it was intended [00:18] sorry, i missed the tag [00:18] ah :-) [00:19] there's also a Canonical developed project tracking tool they could have used [00:19] can't recall the url right now [00:20] thumper: do you know why it's proposed to change managerConfig from a struct to a map? [00:20] yes [00:20] I'll review that one [00:20] it is part of the policy stuff [00:21] a pre-req refactoring to make it easier [00:21] ok [00:21] will also be using it for the fast-lxc clone mechanism [00:21] thumper: also, here's a fix for local provider upgrader bounce https://codereview.appspot.com/69690043 [00:21] also, side note [00:21] I have a physio appt at 2pm [00:21] may not be back for the standup [00:21] ok, we can delay it [00:22] either that or do it without me :-) [00:22] * thumper doesn't feel that special [00:22] we can see though [00:22] could do, we did it last week [00:22] just didn't want you to miss out :-) [00:23] :) [00:23] the description on that branch doesn't indiate that it fixes the local provider upgrade stuff [00:25] thumper: cause it describes the root cause issue [00:25] kk [00:25] which is DesiredTools() failed [00:25] may have had more impact that just local provider [00:26] i tested local provider by hand and it fixed the issue [00:27] i want to run a 1.16 to 1.18 upgrade test also to check the lock dir and system key stuff gets sorted out properly [00:28] kk [00:32] thumper: do you think we can finally re-purpose --verbose for 1.18? or wait till 1.20? it's been deprecated for ages now. needs to happen before 2.0 though. [00:33] a problem we have is that we don't get verbose feedback from the api... [00:33] general output would be "calling api foo" [00:33] some result [00:33] not sure how good verbose will be there... [00:33] however, I think we should change it RSN [00:33] we can use to log request response and stuff like that perhaps [00:34] we can think of something to use it for [00:34] but yeah, the change needs to happen [00:34] we can always improve the verbose output [00:34] over time === _mup__ is now known as _mup_ === _mup__ is now known as _mup_ [00:55] sigh, bot hung again. stabby, stabby [00:58] wow, bot is soooo slooooow today [01:03] wallyworld_: is there any reason not to include *state.State in the upgrade Context for state servers? [01:03] (it would be nil for non-state servers) [01:03] um [01:03] guess not [01:03] i was thinking it best to go via api [01:04] the reason I ask is if there's not one, I have to add an API that will only ever be used for upgrades [01:04] (updating syslog port) [01:04] i see [01:05] there's pros and cons both ways i guess [01:06] I [01:06] i think it could work out ok to do it [01:06] I will propose adding it for now, we can reassess later if it's a bad idea [01:07] wallyworld_: technically you can get it already through the agent.Config... but it'd probably be better to not open again [01:08] yeah, prefer not to open a 2nd one [01:25] axw: tim will be late for standup - physio. he said we could do it without him but i don't mind waiting till he gets back [01:25] wallyworld_: no worries, let's wait === jcsackett_ is now known as jcsackett [01:34] _thumper_, axw, wallyworld_ standup? [01:34] waigani_: waiting for thumper to return [01:34] ah sorry just saw above [01:38] * _thumper_ is back === _thumper_ is now known as thumper [01:40] wallyworld_, waigani_ let's do it [02:22] davecheney: I managed to run gocheck tests with gccgo... what is the problem you are seeing? [02:22] * thumper wanders into the kitchen to make that coffee now that the machine is hot [02:53] thumper: last time I tried they don't pass on any arch [02:53] * davecheney goes to find the bug report [02:53] https://bugs.launchpad.net/gocheck/+bug/1250253 [02:53] <_mup_> Bug #1250253: many tests fail with gccgo

[02:54] thumper: gocheck tests don't appear to pass with golang-go either [02:54] ah... [02:54] * thumper sadface [02:55] it fails really badly under gccgo [02:55] because gccgo has a different format for stack traces [02:56] * thumper is looking at bug 1276909 [02:56] <_mup_> Bug #1276909: error detecting hardware characteristics: unrecognised architecture: aarch64

[02:56] davecheney: yeah I noticed that too [02:57] wallyworld_: any idea why hpcloud metadata simplestream search is just "amd64" and "arm" while ec2 is "amd64", "i386" and "arm" ? [02:57] thumper: i'd guess that hp cloud doesn't have i386 images? [02:57] any idea if it has arm64 images? [02:57] no idea [02:57] wallyworld_: if we searched for them and they aren [02:58] * thumper sighs [02:58] and they aren't there, should be fine though right? [02:58] yeah, will be fine [02:58] wallyworld_: can you do something like nova list-images [sic] against HP cloud ? [02:58] i think so yes [02:58] let me check [02:59] i only see 64 bit [03:07] wallyworld_: I'm just applying patches from the bug mentioned above [03:07] and I hit my repetition threshold [03:07] was wondering if we could refactor and combine known architectures [03:07] sure, whatever works :-) [03:08] not all providers support all arches [03:08] sure [03:08] but we can ask for what we know about though right? [03:08] i would think so [03:12] ok launchpad.net/juju-core/cmd/jujud 578.049s [03:12] mmm, speedy [03:13] 12 more seconds and test watchdog would have nixed it [03:20] axw__: i think i might need a state reference in the upgrade context also - well, it will make it easier anyway [03:21] wallyworld_: I started doing it, but it's a pain in the arse to to get the state.State object where the upgrader is created... [03:21] I can go back to it if you need it though [03:21] hmmmm === axw__ is now known as axw [03:21] what i need to do is delete some obsolete config entries [03:22] and EnvironmentSet() is only on clients [03:22] wallyworld_: ok, I will just do it [03:22] but only when on a state server, right? [03:22] I figured I'd leave it till it was needed by someone else, so there we go :) [03:22] yep [03:23] i wonder if it really is the right thing to do [03:23] wallyworld_: bot still fubared? [03:23] or if we should just do it via an api endpoint [03:23] yep :-( [03:23] * thumper sighs [03:23] it just keeps restarting my mp [03:23] wallyworld_: seems to me that the state server shouldn't need to go through the API. [03:24] cause it can't get enough cpu cycles to run the tests in time [03:24] thumper: did errgo move to juju/errgo ? [03:24] axw: yeah, i can see that argument, although there are worker on the state server that do go via the api [03:24] or am i smoking cheap crack ? [03:25] davecheney: no, juju/errgo is rog's one [03:25] davecheney: errgo/errgo will die [03:25] i think all workers should, but for one off upgrade tasks... [03:25] thumper: i noticed that some packages in juju-core still pull the latter [03:25] aye, they should change [03:26] m'kay [03:26] just fiddling with my spreadsheet [03:39] davecheney: yes it does give me hives [03:41] well, i'm going to double down and s/arm64/ppc64/ [03:45] davecheney: thought you might, but shouldn't it be ppc64le? [03:45] el? (to match dpkg arch?) [03:45] yeah [03:47] thumper: it's ppc64 for the same reason that it's arm64, not aarch64 [03:47] i really hope there is no requirement to handle the aliasing [03:50] thumper: oh man, I think this is going to be harder [03:50] actually no [03:50] ignore [03:54] oh, who was saying that they couldn't bootstrap 386 images on hp cloud [03:54] https://codereview.appspot.com/69850043/diff/1/provider/openstack/provider.go?column_width=80 [03:54] ^ there is your answer [04:22] wallyworld_: sorry, took me a little while to figure out a cleanish way to do it, CL incoming now [04:22] axw_: awesome, thanks. i've got my branch ready to go as soon as your lands [04:27] is anything landing? [04:29] thumper: i've upped the timeout to 45 minutes to see if that is enough [04:29] kk [04:29] axw_: you you have the shiteveld link? [04:30] wallyworld_: still uploading, will let you know [04:30] ok [04:34] wallyworld_: https://codereview.appspot.com/69890043/ [04:34] looking [04:38] surely this one is fixed https://bugs.launchpad.net/juju-core/+bug/1240260 [04:38] <_mup_> Bug #1240260: juju bootstrap does not honor https_proxy in environment when fetching tools

[04:44] davecheney: i'm pretty sure that's now fixed with tim's recent proxy changes [04:45] axw_: reviewed, but there are missing tests [04:46] okey dokey [04:46] i'm doing the same get config, set config dance in my branch also [04:46] wallyworld_: wanna close it and we'll pretend it never happened [04:46] ok [04:47] (to ian) [04:47] davecheney: i think it can be closed yeah [04:48] wallyworld_: I need to have lunch, so won't have it done for a little while yet [04:48] no proble, i can still merge your branch [04:48] problem [04:49] wallyworld_: what do you mean "machine agent upgrade in cmd/jujud/upgrade_test.go" ? [04:49] you mean something that tests whether state.State is available? [04:50] axw_: in cmd.jujud, there's tests which set up an env, start machine agent, and check that the upgrades are done [04:50] you just need to add somes lines to (wallyworld checks method name) [04:50] assertStateServerUpgrades [04:51] ah I see [04:51] thanks [04:51] np. also a unit test for the rsyslog upgrade method itself [04:51] in rsyslogupgrade_test.go [04:51] yep got it [05:00] wallyworld_: I didn't actually record a.st, so ... bear that in mind when you merge :) [05:00] I just live tested and it blew up [05:00] i'm just running the test now :-) [05:02] so, these upgrade tests are going to install rsyslog-gnutls on the test machine aren't they... I'd better fix that [05:03] um yeah :-) [05:03] i think we have stubs for apt for testing [05:03] somehwere in utils [05:03] yep [06:08] * axw_ crosses fingers and restarts [06:17] oh joy, compiz is crashing [06:18] \o/ [08:31] mornin' all [08:42] rogpeppe, heyhey [08:42] fwereade: hiya [08:42] rogpeppe, guess what I forgot to do in the zip package? [08:43] fwereade: what was that then? [08:43] rogpeppe, close the files I write to :/ [08:43] fwereade: doh! [08:43] * rogpeppe feels stupid for missing that [08:43] rogpeppe, I was totally baffled by ETXTBSY for a disturbingly long time [08:43] fwereade: good thing you got that really [08:44] fwereade: otherwise we'd just have had a leak [08:44] rogpeppe, yeah, absolutely [10:45] fwereade, rogpeppe, wallyworld_ , standup? [11:27] hi guys. Anyone know who's responsible for uploading the partner os images to HP Cloud's glance? [11:28] they're still using Ubuntu 12.04.2 on region-a.geo-1 [11:32] ev_, I think you'll want to talk to utlemming about that [11:34] thanks [11:58] fwereade, i've added a few bits, but all in all the document lgtm [12:04] dimitern, great, tyvm [12:14] rogpeppe: any updates on the api watcher issue at all? [12:15] cjohnston: i'm sorry, i've been trying to make progress on HA, so haven't been spending much time on bugs recently. [12:15] ack [12:16] is that node 0 HA? [12:16] cjohnston: yes [12:17] very cool [12:17] cjohnston: hopefully :-) === BradCrittenden is now known as bac [14:20] is anyone available to help me work out what's going wrong with one of my cmd/juju tests? [14:22] lunch [14:23] mattyw: will have a look later if you haven't solved the issue [14:24] rogpeppe, if you could spare 10 minutes I'd appreciate it - I'm sure I'm being an idiot somewhere - but I'd love to know where :) [14:24] rogpeppe, I have a meeting in 30 mins so there's no hurry - enjoy your lunch [15:10] mgz, rogpeppe Do either of you have a few minutes to review https://codereview.appspot.com/70100043 [15:11] TheMue: could you please have a look here: https://codereview.appspot.com/68000045 ? [15:11] adeuring: yep *click* [15:11] sinzui: sure thing [15:12] sinzui: lgtm [15:12] oh bugger. mgz, I see this MP that makes me think I should wait an hour for CI to bless. Is lander stuck? https://code.launchpad.net/~wallyworld/juju-core/unitupgrader-desired-tools/+merge/208710 [15:12] sinzui: yeah, the bot is kinda screwed [15:13] I can, if needed, manually land things [15:13] it's had load of >3 all day, for no obvious reason [15:14] mgz, I don't want to rush things. I am assuming that CI will bless the revision if it merges. [15:18] pretty sure nothing will land unless I bash something hard [15:19] the current one has been going... very slowly... since 9:30 this morning [15:19] wow [15:19] mgz, this is canonistack? [15:20] yep. [15:20] lcy02 [15:20] It is dying. [15:20] Do we have docs for writing your own provider? [15:20] We just moved juju-ci off of it [15:20] I've not seen any "this is totally screwed" annoncement yet, but it does seem that way [15:21] mgz ^ I recommend setting up the lander in another cloud. [15:21] jcastro: we have a branch from fwereade with docs and a template provider [15:21] it's somewhat out of date with trunk, but is a good start for a capable coder [15:21] jcastro, mgz: sorry, I never actually landed that, roger had some good comments that I never addressed [15:21] mgz We saw performance degradation and nova lost two machines, and was shuting other down [15:21] jcastro, mgz: it's what the joyent provider started out as [15:22] ok so for the docs I'll just say "contact us" for now [15:22] sinzui: that's more than an end-of-fraiday task, and jam wants to move us to a jenkins thing anyway [15:22] jcastro: I can forward you a mail I sent with the details [15:22] I am renaming the null->manual in the docs, and I wanted to say something like "obviouslly adding machines by hand is not ideal, if you're a provider and want to natively support juju go here." [15:22] ...actually, you were probably cced on it [15:22] mgz, understood. We have stood up enough CIs that it is a could of hours for us to move [15:23] ok, I just wanted something for 1.18, this is Good Enough [15:23] we should at some point have a proper page though [15:23] jcastro: yeah, see the "Juju on Digital Ocean" mail from 2014-02-04 [15:23] * jcastro nods [15:24] links william's branch [15:36] adeuring: done [15:37] Thethanks! [15:37] TheMue: Thanks [16:21] * rogpeppe is back after a rather extended lunchtime think'n'stomp. [16:29] Damn, I bought an external battery for my laptop for the flight, and none of the adapters fits my plug :/ [16:36] natefinch: something that would have been worth verifying in advance, i guess :-) [16:36] mattyw: what's the problem, then? [16:37] rogpeppe: heh yeah. I guess I'll have to run to radioshack and see if they have an adapter from the "big" dell plug to the mini one my laptop has [16:37] rogpeppe, quick hangout? [16:37] mattyw: sure [16:51] man, I wish there was a way to expose functionality in *other* packages during test. Can't tell you how much easier that would make so many tests, and how many "this is only public for testing, please don't change" we could remove. [16:53] rogpeppe: is there a trick we're missing to do this? Sort of a way for a package to say "hey, here's some stuff you might want to mock out during tests" that other packages could then twiddle with, but only during testing? [16:56] natefinch: nope [16:56] fwereade: ping [16:58] rogpeppe: dang. I thought that was the case, but was hoping I was wrong [17:08] rogpeppe, pong [17:14] fwereade: i was just in a call with mattyw, and thought i should run an idea past you [17:14] fwereade: matty's problem was that in his Cmd implementation, he was doing a store.ReadInfo(c.EnvName) [17:14] fwereade: but c.EnvName can be blank [17:15] fwereade: because it can be specified as a default in environments.yaml, which isn't read by then [17:15] fwereade: so my suggestion was that we can make EnvCommandBase read environments.yaml in that case, so c.EnvName will always be non-empty when possible [17:16] fwereade: which means we could lose the "" special case in a fair few places [17:17] fwereade: and it means it's easier for people to write plugins too (and easier to move away from environments.yaml when the time comes) [17:18] rogpeppe, don't we have a standard set of fallbacks? ie the JUJU_ENV, wherever juju switch stores, etc [17:19] rogpeppe, but yeah, it certainly seems like a good idea to do all that logic OAOO and expose it nicely for these situations [17:19] fwereade: yeah, most of them are already dealt with by EnvCommandBase [17:19] rogpeppe, and start requiring actual env names at all lower levels [17:19] fwereade: except the default-from-environments.yaml case [17:19] rogpeppe, cool, if it's just a matter of extracting a method from there then all the better [17:19] rogpeppe, bah [17:20] rogpeppe, probably still worth the ickiness of reading envs.yaml twice to put that logic in one place and drop the ""->default stuff inside environs [17:20] fwereade: that was my thought too [17:20] rogpeppe, done and done, then :) [17:21] fwereade: i think the best thing is just to put the logic inside getDefaultEnvironment, and possibly make it ignore any error if it fails to read the environments.yaml file. [17:22] fwereade: although the latter is more arguable [17:23] fwereade: but AFAICS the worst that can happen is that we get an empty default [17:26] rogpeppe, yeah, "no environment specified" doesn't seem unreasonable [17:27] rogpeppe, I guess we ultimately want to fall back to "the only jenv that exists" if *nothing* else is specified (and there is only one) [17:27] fwereade: i'm not sure about that [17:28] fwereade: i think juju switch works pretty well in general [17:28] fwereade: (much as i wasn't keen on the idea to start with :-]) [17:28] rogpeppe, eh, it's arguable I guess [17:28] rogpeppe, putting the existing logic in one place is enough of a win for me :) [17:29] fwereade: if i've just deleted an environment, i don't really want it to suddenly switch to another environment just because it's the only one left [17:29] fwereade: yeah [17:30] rogpeppe, yeah, fair point -- you'd probably have that earlier env switched in, but I agree you might not, and the impact of a surprising change could be significant [17:30] fwereade: actually, a possibly better idea is to change EnvName to be a method that returns (string, error) [17:30] rogpeppe, +1 [17:30] fwereade: it's more invasive, unfortunatly [17:30] fwereade: but probably worth it [17:31] mattyw: could you do that, please? [17:33] fwereade: actually, another, possibly slightly less invasive option is to add an Init method to EnvCommandBase [17:33] fwereade: and leave the EnvName field as it is [17:33] fwereade: that actually feels more in keeping with the other command stuff [17:35] mattyw: pending fwereade's reply, i think that's a nicer option [17:38] fwereade: one other thing: there's an import cycle if EnvCommandBase calls environs, because environs indirectly uses juju-core/cmd [17:38] fwereade: cmd has always seemed to me to be a somewhat dubious place to have EnvCommandBase, tbh [17:40] fwereade: i think maybe it could live in its own package, along with other environment-related cmd stuff [17:40] rogpeppe, +1 to that as well, thanks [17:40] fwereade: like... wtf is IsMachineOrNewContainer doing in cmd ? [17:41] rogpeppe, sounds like "loitering with intent" to me [17:41] fwereade: i gave it a sharp word [17:41] rogpeppe, IIRC is is subtly misnamed as well [17:41] rogpeppe, ah no maybe it's accurately named but insane [17:42] rogpeppe, we ought to be either detecting an explicit machine name or dispatching a placement directive to a (pseudo-)provider [17:42] I suspect that the bug fix that wallyworld_ has for machine agents is broader that local-provider. my 1.17.4 release from trusty cannot bootstrap precise [17:43] fwereade: anyway, it's only used in two places, and should probably be in cmd/juju until more widespread [17:44] fwereade: how about juju-core/cmd/juju/envcmd as a package name for EnvCommandBase? [17:44] fwereade: cmd/envcmd is also a possibility, i guess [17:44] i'd appreciate if someone takes a look at my agent conf 1.18 CL https://codereview.appspot.com/70010045 [17:45] it was truly painful to merge all trunk changes [17:45] fwereade: except that would pollute the cmd/* name space [17:45] dimitern: you've still got some .THIS files in there [17:46] rogpeppe, man! seriously.. :/ I'll repropose [17:47] it's good they're only 2 and both are now gone [17:52] rogpeppe, updated [17:52] dimitern: thanks [18:20] rogpeppe, mgz, fwereade: anyone know why gocheck would suddenly not be able to create temporary directories? Panic: Couldn't create temporary directory /tmp/gocheck-5577006791947779410/1: mkdir /tmp/gocheck-5577006791947779410/1: no such file or directory (PC=0x413FC6) [18:21] natefinch: how many directories have you got in /tmp? [18:21] rogpeppe: one [18:21] natefinch: does this happen every time? [18:22] mystery [18:23] rogpeppe: currently, yes. Let me try removing this mkdir and see if another one elsewhere succeeds, maybe I'm hitting some weird race condition somehow [18:24] rogpeppe: it seems to not fail in other packages I test [18:27] rogpeppe: nevermind, I see what I did... misunderstanding of what os.TempDir returns.... looks like I was actually deleting /tmp in one of my tests [18:27] natefinch: oops :- [18:27] ) [18:27] natefinch: good thing it wasn't $HOME, eh? [18:28] rogpeppe: ahh yeah. I've done that before too, though not in code, just by being in the wrong place when I did rm -rf * [18:29] ....and this is why man invented offsite backups. [18:33] natefinch, when I see this [18:33] Starting MongoDB server (juju-db) [18:34] is this mongodb-server and juju-mongodb? [18:35] sinzui: that's the mongod upstart service that juju creates when it installs itself. [18:37] natefinch, and since mongodb-server is the only thing juju knows how to install, we know it is mongodb-server [18:53] natefinch, fwereade, jam1, This bug aborted the 1.17.4 release. https://bugs.launchpad.net/juju-core/+bug/1286279 [18:53] <_mup_> Bug #1286279: juju 1.17.4 trusty client cannot bootstrap 1.17.x precise

[18:53] * sinzui needs to think about how to not let 1.17.4 get into the hands of ubuntu trusty users [18:54] * rogpeppe is done for the week [18:55] g'night all [18:56] night rog [18:56] see you next week! [19:01] mgz: yeah! [19:03] rogpeppe: see you next week :) [21:37] natefinch, Do you have any insights into this bug. https://bugs.launchpad.net/juju-core/+bug/1286279 [21:37] <_mup_> Bug #1286279: juju-mongodb breaks 1.17.4 trusty client bootstrap in CPC