[00:05] <hazmat> davecheney, false
[00:05] <hazmat> tags are project specific
[00:05] <hazmat> albeit guess work
[00:06] <davecheney> hazmat: hmm, i found a way I can search across projects via tag
[00:07] <davecheney> go to the main page of lp
[00:07] <davecheney> search for your tag there
[00:07] <davecheney> sort of works
[00:07] <wallyworld_> projects can have official tags defined to remove the guesswork. you get auto completion and stuff like that then
[00:10] <davecheney> i'm trying to build a report for PM who need to know how much work is left on a project
[00:10] <davecheney> whenever I see them maintaing their own list in a google doc
[00:10] <davecheney> I cry inside
[00:14] <wallyworld_> wonder why they do that
[00:16] <davecheney> launchpad is hard, let's go shopping
[00:18] <wallyworld_> 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] <davecheney> sorry, i missed the <sarcasm /> tag
[00:18] <wallyworld_> ah :-)
[00:19] <wallyworld_> there's also a Canonical developed project tracking tool they could have used
[00:19] <wallyworld_> can't recall the url right now
[00:20] <wallyworld_> thumper: do you know why it's proposed to change managerConfig from a struct to a map?
[00:20] <thumper> yes
[00:20] <thumper> I'll review that one
[00:20] <thumper> it is part of the policy stuff
[00:21] <thumper> a pre-req refactoring to make it easier
[00:21] <wallyworld_> ok
[00:21] <thumper> will also be using it for the fast-lxc clone mechanism
[00:21] <wallyworld_> thumper: also, here's a fix for local provider upgrader bounce https://codereview.appspot.com/69690043
[00:21] <thumper> also, side note
[00:21] <thumper> I have a physio appt at 2pm
[00:21] <thumper> may not be back for the standup
[00:21] <wallyworld_> ok, we can delay it
[00:22] <thumper> either that or do it without me :-)
[00:22]  * thumper doesn't feel that special
[00:22] <thumper> we can see though
[00:22] <wallyworld_> could do, we did it last week
[00:22] <wallyworld_> just didn't want you to miss out :-)
[00:23] <thumper> :)
[00:23] <thumper> the description on that branch doesn't indiate that it fixes the local provider upgrade stuff
[00:25] <wallyworld_> thumper: cause it describes the root cause issue
[00:25] <thumper> kk
[00:25] <wallyworld_> which is DesiredTools() failed
[00:25] <wallyworld_> may have had more impact that just local provider
[00:26] <wallyworld_> i tested local provider by hand and it fixed the issue
[00:27] <wallyworld_> 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] <thumper> kk
[00:32] <wallyworld_> 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] <thumper> a problem we have is that we don't get verbose feedback from the api...
[00:33] <thumper> general output would be "calling api foo"
[00:33] <thumper> some result
[00:33] <thumper> not sure how good verbose will be there...
[00:33] <thumper> however, I think we should change it RSN
[00:33] <wallyworld_> we can use to log request response and stuff like that perhaps
[00:34] <wallyworld_> we can think of something to use it for
[00:34] <wallyworld_> but yeah, the change needs to happen
[00:34] <wallyworld_> we can always improve the verbose output
[00:34] <wallyworld_> over time
[00:55] <wallyworld_> sigh, bot hung again. stabby, stabby
[00:58] <wallyworld_> wow, bot is soooo slooooow today
[01:03] <axw> wallyworld_: is there any reason not to include *state.State in the upgrade Context for state servers?
[01:03] <axw> (it would be nil for non-state servers)
[01:03] <wallyworld_> um
[01:03] <wallyworld_> guess not
[01:03] <wallyworld_> i was thinking it best to go via api
[01:04] <axw> 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] <axw> (updating syslog port)
[01:04] <wallyworld_> i see
[01:05] <wallyworld_> there's pros and cons both ways i guess
[01:06] <axw> I
[01:06] <wallyworld_> i think it could work out ok to do it
[01:06] <axw> I will propose adding it for now, we can reassess later if it's a bad idea
[01:07] <axw> wallyworld_: technically you can get it already through the agent.Config... but it'd probably be better to not open again
[01:08] <wallyworld_> yeah, prefer not to open a 2nd one
[01:25] <wallyworld_> 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] <axw> wallyworld_: no worries, let's wait
[01:34] <waigani_> _thumper_, axw, wallyworld_ standup?
[01:34] <axw> waigani_: waiting for thumper to return
[01:34] <waigani_> ah sorry just saw above
[01:38]  * _thumper_ is back
[01:40] <axw> wallyworld_, waigani_ let's do it
[02:22] <thumper> 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] <davecheney> thumper: last time I tried they don't pass on any arch
[02:53]  * davecheney goes to find the bug report
[02:53] <davecheney> https://bugs.launchpad.net/gocheck/+bug/1250253
[02:53] <_mup_> Bug #1250253: many tests fail with gccgo <gccgo> <ppc64el> <Gocheck:New> <juju-core:Triaged by dave-cheney> <https://launchpad.net/bugs/1250253>
[02:54] <davecheney> thumper: gocheck tests don't appear to pass with golang-go either
[02:54] <thumper> ah...
[02:54]  * thumper sadface
[02:55] <davecheney> it fails really badly under gccgo
[02:55] <davecheney> 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 <arm64> <hs-arm64> <patch> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1276909>
[02:56] <thumper> davecheney: yeah I noticed that too
[02:57] <thumper> wallyworld_: any idea why hpcloud metadata simplestream search is just "amd64" and "arm" while ec2 is "amd64", "i386" and "arm" ?
[02:57] <wallyworld_> thumper: i'd guess that hp cloud doesn't have i386 images?
[02:57] <thumper> any idea if it has arm64 images?
[02:57] <wallyworld_> no idea
[02:57] <thumper> wallyworld_: if we searched for them and they aren
[02:58]  * thumper sighs
[02:58] <thumper> and they aren't there, should be fine though right?
[02:58] <wallyworld_> yeah, will be fine
[02:58] <davecheney> wallyworld_: can you do something like nova list-images [sic] against HP cloud ?
[02:58] <wallyworld_> i think so yes
[02:58] <wallyworld_> let me check
[02:59] <wallyworld_> i only see 64 bit
[03:07] <thumper> wallyworld_: I'm just applying patches from the bug mentioned above
[03:07] <thumper> and I hit my repetition threshold
[03:07] <thumper> was wondering if we could refactor and combine known architectures
[03:07] <wallyworld_> sure, whatever works :-)
[03:08] <wallyworld_> not all providers support all arches
[03:08] <thumper> sure
[03:08] <thumper> but we can ask for what we know about though right?
[03:08] <wallyworld_> i would think so
[03:12] <davecheney> ok      launchpad.net/juju-core/cmd/jujud       578.049s
[03:12] <davecheney> mmm, speedy
[03:13] <davecheney> 12 more seconds and test watchdog would have nixed it
[03:20] <wallyworld_> axw__: i think i might need a state reference in the upgrade context also - well, it will make it easier anyway
[03:21] <axw__> 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] <axw__> I can go back to it if you need it though
[03:21] <wallyworld_> hmmmm
[03:21] <wallyworld_> what i need to do is delete some obsolete config entries
[03:22] <wallyworld_> and EnvironmentSet() is only on clients
[03:22] <axw> wallyworld_: ok, I will just do it
[03:22] <wallyworld_> but only when on a state server, right?
[03:22] <axw> I figured I'd leave it till it was needed by someone else, so there we go :)
[03:22] <axw> yep
[03:23] <wallyworld_> i wonder if it really is the right thing to do
[03:23] <thumper> wallyworld_: bot still fubared?
[03:23] <wallyworld_> or if we should just do it via an api endpoint
[03:23] <wallyworld_> yep :-(
[03:23]  * thumper sighs
[03:23] <wallyworld_> it just keeps restarting my mp
[03:23] <axw> wallyworld_: seems to me that the state server shouldn't need to go through the API.
[03:24] <wallyworld_> cause it can't get enough cpu cycles to run the tests in time
[03:24] <davecheney> thumper: did errgo move to juju/errgo ?
[03:24] <wallyworld_> axw: yeah, i can see that argument, although there are worker on the state server that do go via the api
[03:24] <davecheney> or am i smoking cheap crack ?
[03:25] <thumper> davecheney: no, juju/errgo is rog's one
[03:25] <thumper> davecheney: errgo/errgo will die
[03:25] <wallyworld_> i think all workers should, but for one off upgrade tasks...
[03:25] <davecheney> thumper: i noticed that some packages in juju-core still pull the latter
[03:25] <thumper> aye, they should change
[03:26] <davecheney> m'kay
[03:26] <davecheney> just fiddling with my spreadsheet
[03:39] <thumper> davecheney: yes it does give me hives
[03:41] <davecheney> well, i'm going to double down and s/arm64/ppc64/
[03:45] <thumper> davecheney: thought you might, but shouldn't it be ppc64le?
[03:45] <axw> el? (to match dpkg arch?)
[03:45] <thumper> yeah
[03:47] <davecheney> thumper: it's ppc64 for the same reason that it's arm64, not aarch64
[03:47] <davecheney> i really hope there is no requirement to handle the aliasing
[03:50] <davecheney> thumper: oh man, I think this is going to be harder
[03:50] <davecheney> actually no
[03:50] <davecheney> ignore
[03:54] <davecheney> oh, who was saying that they couldn't bootstrap 386 images on hp cloud
[03:54] <davecheney> https://codereview.appspot.com/69850043/diff/1/provider/openstack/provider.go?column_width=80
[03:54] <davecheney> ^ there is your answer
[04:22] <axw_> wallyworld_: sorry, took me a little while to figure out a cleanish way to do it, CL incoming now
[04:22] <wallyworld_> axw_: awesome, thanks. i've got my branch ready to go as soon as your lands
[04:27] <thumper> is anything landing?
[04:29] <wallyworld_> thumper: i've upped the timeout to 45 minutes to see if that is enough
[04:29] <thumper> kk
[04:29] <wallyworld_> axw_: you you have the shiteveld link?
[04:30] <axw_> wallyworld_: still uploading, will let you know
[04:30] <wallyworld_> ok
[04:34] <axw_> wallyworld_: https://codereview.appspot.com/69890043/
[04:34] <wallyworld_> looking
[04:38] <davecheney> 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 <amd64> <apport-bug> <cts-cloud-review> <saucy> <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <https://launchpad.net/bugs/1240260>
[04:44] <wallyworld_> davecheney: i'm pretty sure that's now fixed with tim's recent proxy changes
[04:45] <wallyworld_> axw_: reviewed, but there are missing tests
[04:46] <axw_> okey dokey
[04:46] <wallyworld_> i'm doing the same get config, set config dance in my branch also
[04:46] <davecheney> wallyworld_: wanna close it and we'll pretend it never happened
[04:46] <axw_> ok
[04:47] <axw_> (to ian)
[04:47] <wallyworld_> davecheney: i think it can be closed yeah
[04:48] <axw_> wallyworld_: I need to have lunch, so won't have it done for a little while yet
[04:48] <wallyworld_> no proble, i can still merge your branch
[04:48] <wallyworld_> problem
[04:49] <axw_> wallyworld_: what do you mean "machine agent upgrade in cmd/jujud/upgrade_test.go" ?
[04:49] <axw_> you mean something that tests whether state.State is available?
[04:50] <wallyworld_> axw_: in cmd.jujud, there's tests which set up an env, start machine agent, and check that the upgrades are done
[04:50] <wallyworld_> you just need to add somes lines to (wallyworld checks method name)
[04:50] <wallyworld_> assertStateServerUpgrades
[04:51] <axw_> ah I see
[04:51] <axw_> thanks
[04:51] <wallyworld_> np. also a unit test for the rsyslog upgrade method itself
[04:51] <wallyworld_> in rsyslogupgrade_test.go
[04:51] <axw_> yep got it
[05:00] <axw_> wallyworld_: I didn't actually record a.st, so ... bear that in mind when you merge :)
[05:00] <axw_> I just live tested and it blew up
[05:00] <wallyworld_> i'm just running the test now :-)
[05:02] <axw_> so, these upgrade tests are going to install rsyslog-gnutls on the test machine aren't they... I'd better fix that
[05:03] <wallyworld_> um yeah :-)
[05:03] <wallyworld_> i think we have stubs for apt for testing
[05:03] <wallyworld_> somehwere in utils
[05:03] <axw_> yep
[06:08]  * axw_ crosses fingers and restarts
[06:17] <axw> oh joy, compiz is crashing
[06:18] <wallyworld_> \o/
[08:31] <rogpeppe> mornin' all
[08:42] <fwereade> rogpeppe, heyhey
[08:42] <rogpeppe> fwereade: hiya
[08:42] <fwereade> rogpeppe, guess what I forgot to do in the zip package?
[08:43] <rogpeppe> fwereade: what was that then?
[08:43] <fwereade> rogpeppe, close the files I write to :/
[08:43] <rogpeppe> fwereade: doh!
[08:43]  * rogpeppe feels stupid for missing that
[08:43] <fwereade> rogpeppe, I was totally baffled by ETXTBSY for a disturbingly long time
[08:43] <rogpeppe> fwereade: good thing you got that really
[08:44] <rogpeppe> fwereade: otherwise we'd just have had a leak
[08:44] <fwereade> rogpeppe, yeah, absolutely
[10:45] <dimitern> fwereade, rogpeppe, wallyworld_ , standup?
[11:27] <ev_> hi guys. Anyone know who's responsible for uploading the partner os images to HP Cloud's glance?
[11:28] <ev_> they're still using Ubuntu 12.04.2 on region-a.geo-1
[11:32] <fwereade> ev_, I think you'll want to talk to utlemming about that
[11:34] <ev_> thanks
[11:58] <dimitern> fwereade, i've added a few bits, but all in all the document lgtm
[12:04] <fwereade> dimitern, great, tyvm
[12:14] <cjohnston> rogpeppe: any updates on the api watcher issue at all?
[12:15] <rogpeppe> 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] <cjohnston> ack
[12:16] <cjohnston> is that node 0 HA?
[12:16] <rogpeppe> cjohnston: yes
[12:17] <cjohnston> very cool
[12:17] <rogpeppe> cjohnston: hopefully :-)
[14:20] <mattyw> is anyone available to help me work out what's going wrong with one of my cmd/juju tests?
[14:22] <rogpeppe> lunch
[14:23] <rogpeppe> mattyw: will have a look later if you haven't solved the issue
[14:24] <mattyw> 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] <mattyw> rogpeppe, I have a meeting in 30 mins so there's no hurry - enjoy your lunch
[15:10] <sinzui> mgz, rogpeppe Do either of you have a few minutes to review https://codereview.appspot.com/70100043
[15:11] <adeuring> TheMue: could you please have a look here: https://codereview.appspot.com/68000045 ?
[15:11] <TheMue> adeuring: yep *click*
[15:11] <mgz> sinzui: sure thing
[15:12] <mgz> sinzui: lgtm
[15:12] <sinzui> 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] <mgz> sinzui: yeah, the bot is kinda screwed
[15:13] <mgz> I can, if needed, manually land things
[15:13] <mgz> it's had load of >3 all day, for no obvious reason
[15:14] <sinzui> mgz, I don't want to rush things. I am assuming that CI will bless the revision if it merges.
[15:18] <mgz> pretty sure nothing will land unless I bash something hard
[15:19] <mgz> the current one has been going... very slowly... since 9:30 this morning
[15:19] <sinzui> wow
[15:19] <sinzui> mgz, this is canonistack?
[15:20] <mgz> yep.
[15:20] <mgz> lcy02
[15:20] <sinzui> It is dying.
[15:20] <jcastro> Do we have docs for writing your own provider?
[15:20] <sinzui> We just moved juju-ci off of it
[15:20] <mgz> I've not seen any "this is totally screwed" annoncement yet, but it does seem that way
[15:21] <sinzui> mgz ^ I recommend setting up the lander in another cloud.
[15:21] <mgz> jcastro: we have a branch from fwereade with docs and a template provider
[15:21] <mgz> it's somewhat out of date with trunk, but is a good start for a capable coder
[15:21] <fwereade> jcastro, mgz: sorry, I never actually landed that, roger had some good comments that I never addressed
[15:21] <sinzui> mgz We saw performance degradation and nova lost two machines, and was shuting other down
[15:21] <fwereade> jcastro, mgz: it's what the joyent provider started out as
[15:22] <jcastro> ok so for the docs I'll just say "contact us" for now
[15:22] <mgz> sinzui: that's more than an end-of-fraiday task, and jam wants to move us to a jenkins thing anyway
[15:22] <mgz> jcastro: I can forward you a mail I sent with the details
[15:22] <jcastro> 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] <mgz> ...actually, you were probably cced on it
[15:22] <sinzui> mgz, understood. We have stood up enough CIs that it is a could of hours for us to move
[15:23] <jcastro> ok, I just wanted something for 1.18, this is Good Enough
[15:23] <jcastro> we should at some point have a proper page though
[15:23] <mgz> jcastro: yeah, see the "Juju on Digital Ocean" mail from 2014-02-04
[15:23]  * jcastro nods
[15:24] <mgz> links william's branch
[15:36] <TheMue> adeuring: done
[15:37] <adeuring> Thethanks!
[15:37] <adeuring> TheMue: Thanks
[16:21]  * rogpeppe is back after a rather extended lunchtime think'n'stomp.
[16:29] <natefinch> Damn, I bought an external battery for my laptop for the flight, and none of the adapters fits my plug :/
[16:36] <rogpeppe> natefinch: something that would have been worth verifying in advance, i guess :-)
[16:36] <rogpeppe> mattyw: what's the problem, then?
[16:37] <natefinch> 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] <mattyw> rogpeppe, quick hangout?
[16:37] <rogpeppe> mattyw: sure
[16:51] <natefinch> 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] <natefinch> 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] <rogpeppe> natefinch: nope
[16:56] <rogpeppe> fwereade: ping
[16:58] <natefinch> rogpeppe: dang.  I thought that was the case, but was hoping I was wrong
[17:08] <fwereade> rogpeppe, pong
[17:14] <rogpeppe> fwereade: i was just in a call with mattyw, and thought i should run an idea past you
[17:14] <rogpeppe> fwereade: matty's problem was that in his Cmd implementation, he was doing a store.ReadInfo(c.EnvName)
[17:14] <rogpeppe> fwereade: but c.EnvName can be blank
[17:15] <rogpeppe> fwereade: because it can be specified as a default in environments.yaml, which isn't read by then
[17:15] <rogpeppe> 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] <rogpeppe> fwereade: which means we could lose the "" special case in a fair few places
[17:17] <rogpeppe> 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] <fwereade> rogpeppe, don't we have a standard set of fallbacks? ie the JUJU_ENV, wherever juju switch stores, etc
[17:19] <fwereade> 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] <rogpeppe> fwereade: yeah, most of them are already dealt with by EnvCommandBase
[17:19] <fwereade> rogpeppe, and start requiring actual env names at all lower levels
[17:19] <rogpeppe> fwereade: except the default-from-environments.yaml case
[17:19] <fwereade> rogpeppe, cool, if it's just a matter of extracting a method from there then all the better
[17:19] <fwereade> rogpeppe, bah
[17:20] <fwereade> 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] <rogpeppe> fwereade: that was my thought too
[17:20] <fwereade> rogpeppe, done and done, then :)
[17:21] <rogpeppe> 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] <rogpeppe> fwereade: although the latter is more arguable
[17:23] <rogpeppe> fwereade: but AFAICS the worst that can happen is that we get an empty default
[17:26] <fwereade> rogpeppe, yeah, "no environment specified" doesn't seem unreasonable
[17:27] <fwereade> 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] <rogpeppe> fwereade: i'm not sure about that
[17:28] <rogpeppe> fwereade: i think juju switch works pretty well in general
[17:28] <rogpeppe> fwereade: (much as i wasn't keen on the idea to start with :-])
[17:28] <fwereade> rogpeppe, eh, it's arguable I guess
[17:28] <fwereade> rogpeppe, putting the existing logic in one place is enough of a win for me :)
[17:29] <rogpeppe> 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] <rogpeppe> fwereade: yeah
[17:30] <fwereade> 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] <rogpeppe> fwereade: actually, a possibly better idea is to change EnvName to be a method that returns (string, error)
[17:30] <fwereade> rogpeppe, +1
[17:30] <rogpeppe> fwereade: it's more invasive, unfortunatly
[17:30] <rogpeppe> fwereade: but probably worth it
[17:31] <rogpeppe> mattyw: could you do that, please?
[17:33] <rogpeppe> fwereade: actually, another, possibly slightly less invasive option is to add an Init method to EnvCommandBase
[17:33] <rogpeppe> fwereade: and leave the EnvName field as it is
[17:33] <rogpeppe> fwereade: that actually feels more in keeping with the other command stuff
[17:35] <rogpeppe> mattyw: pending fwereade's reply, i think that's a nicer option
[17:38] <rogpeppe> fwereade: one other thing: there's an import cycle if EnvCommandBase calls environs, because environs indirectly uses juju-core/cmd
[17:38] <rogpeppe> fwereade: cmd has always seemed to me to be a somewhat dubious place to have EnvCommandBase, tbh
[17:40] <rogpeppe> fwereade: i think maybe it could live in its own package, along with other environment-related cmd stuff
[17:40] <fwereade> rogpeppe, +1 to that as well, thanks
[17:40] <rogpeppe> fwereade: like... wtf is IsMachineOrNewContainer doing in cmd ?
[17:41] <fwereade> rogpeppe, sounds like "loitering with intent" to me
[17:41] <rogpeppe> fwereade: i gave it a sharp word
[17:41] <fwereade> rogpeppe, IIRC is is subtly misnamed as well
[17:41] <fwereade> rogpeppe, ah no maybe it's accurately named but insane
[17:42] <fwereade> rogpeppe, we ought to be either detecting an explicit machine name or dispatching a placement directive to a (pseudo-)provider
[17:42] <sinzui> 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] <rogpeppe> fwereade: anyway, it's only used in two places, and should probably be in cmd/juju until more widespread
[17:44] <rogpeppe> fwereade: how about juju-core/cmd/juju/envcmd as a package name for EnvCommandBase?
[17:44] <rogpeppe> fwereade: cmd/envcmd is also a possibility, i guess
[17:44] <dimitern> i'd appreciate if someone takes a look at my agent conf 1.18 CL https://codereview.appspot.com/70010045
[17:45] <dimitern> it was truly painful to merge all trunk changes
[17:45] <rogpeppe> fwereade: except that would pollute the cmd/* name space
[17:45] <rogpeppe> dimitern: you've still got some .THIS files in there
[17:46] <dimitern> rogpeppe, man! seriously.. :/ I'll repropose
[17:47] <dimitern> it's good they're only 2 and both are now gone
[17:52] <dimitern> rogpeppe, updated
[17:52] <rogpeppe> dimitern: thanks
[18:20] <natefinch> 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] <rogpeppe> natefinch: how many directories have you got in /tmp?
[18:21] <natefinch> rogpeppe: one
[18:21] <rogpeppe> natefinch: does this happen every time?
[18:22] <mgz> mystery
[18:23] <natefinch> 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] <natefinch> rogpeppe: it seems to not fail in other packages I test
[18:27] <natefinch> 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] <rogpeppe> natefinch: oops :-
[18:27] <rogpeppe> )
[18:27] <rogpeppe> natefinch: good thing it wasn't $HOME, eh?
[18:28] <natefinch> 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] <natefinch> ....and this is why man invented offsite backups.
[18:33] <sinzui> natefinch, when I see this
[18:33] <sinzui> Starting MongoDB server (juju-db)
[18:34] <sinzui> is this mongodb-server and juju-mongodb?
[18:35] <natefinch> sinzui: that's the mongod upstart service that juju creates when it installs itself.
[18:37] <sinzui> natefinch, and since mongodb-server is the only thing juju knows how to install, we know it is mongodb-server
[18:53] <sinzui> 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 <precise> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279>
[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] <rogpeppe> g'night all
[18:56] <mgz> night rog
[18:56] <mgz> see you next week!
[19:01] <rogpeppe> mgz: yeah!
[19:03] <natefinch> rogpeppe: see you next week :)
[21:37] <sinzui> 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 <bootstrap> <mongodb> <precise> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1286279>