[03:00] <axw> wallyworld: https://codereview.appspot.com/91740043/
[03:00] <axw> tested live with maas
[03:00] <wallyworld> axw: already looking :-)
[03:00] <axw> cheers
[03:00] <axw> going to go do some packing, bbiab
[03:09] <axw> wallyworld: hrm, it is selecting the instance but it doesn't seem to be bootstrapping. I will continue investigating... there may be another change required to bootstrap though
[03:09] <wallyworld> ok
[03:09] <wallyworld> branch looks ok - i did have a suggestion about the error checking in bootstrap
[03:10] <wallyworld> i've +1ed it so you can land once it works :-)
[03:21] <axw> wallyworld: testing again with a fresh maas node, could've been because it was dirty
[03:21] <axw> wallyworld: I didn't want to return other errors because we don't care about whether they're well formed
[03:21] <axw> wallyworld: just that they're unscoped or not
[03:22] <axw> bootstrap doesn't care if you specify an lxc placement with an invalid machine id
[03:22] <axw> because it just doesn't support lxc placement
[03:29] <wallyworld> axw: ok, it makes sense now that i think a bit harder
[03:31] <axw> alrighty, worked fine with a new node
[04:09] <jam> wallyworld: https://code.launchpad.net/~wallyworld/juju-core/bootstrap-supported-series/+merge/216974 LGTM
[04:09] <jam> morning all
[04:09] <wallyworld> jam: great thanks
[04:10] <jam> wallyworld: fwiw I think we actually want to target 1.18 with that patch
[04:10] <wallyworld> jam: we want to get a lot of stuff into 1.18
[04:10] <jam> wallyworld: since 1.18 local is broken in the same way
[04:11] <wallyworld> i'll land in 1.19 first cause that ships tomorrow and then will back port
[04:11] <jam> wallyworld: *I* find it much easier to land to 1.18 and then merge up, but as you wish
[04:11] <wallyworld> i just cherry pick :-)
[04:12] <wallyworld> but i can see that could get messy easier than landing to 1.18 first
[04:12] <jam> wallyworld: 1 case isn't bad, N cases starts to get hairy
[04:12] <jam> wallyworld: can I ask to have you peek at https://code.launchpad.net/~natefinch/juju-core/045-amd64plz/+merge/216612
[04:13] <jam> It looks like FindInstanceSpec doesn't like that we prefer amd64 now
[04:13] <jam> and I think you have some familiarity with that code
[04:13] <wallyworld> sure
[04:13] <wallyworld> that was actually on my list
[04:13] <wallyworld> cause i tried to land it this morning
[04:13] <wallyworld> there's a couple of failures
[04:14] <wallyworld> jam: btw, is the weekly meeting on tonight with everyone away? i can't make it cause it's my son's birthday
[04:14] <jam> wallyworld: you lazy slacker, how dare you have a family life! :)
[04:14] <wallyworld> yeah, bad i am
[04:14] <jam> wallyworld: I think we'll still do it with whoever is around
[04:14] <jam> but don't feel bad
[04:14] <wallyworld> sure, axw was wondering also
[04:15] <wallyworld> probs will just be discussing getting 1.19 out anuway
[04:21] <axw> woot, maas-name is merged
[04:32] <jam> axw: so that is "juju deploy --to maas-name:foobar" ?
[04:47] <axw> jam: sorry was eating lunch. not quite; for one thing deploy/add-unit are not supported yet (I opened a new bug for that)
[04:48] <axw> jam: we can now do "juju add-machine [env-name:]<maas-name>"
[04:48] <axw> jam: also s/add-machine/bootstrap/
[04:48] <jam> axw: [env-name:] why wouldn't it be -e envname ?
[04:49] <axw> jam: it's how fwereade wanted it, not exactly sure when we'd have env-name != implied env
[04:49] <axw> jam: but you can leave it out altogether and it uses the implied env name
[04:49] <jam> wallyworld: lp:~wallyworld/juju-core/bootstrap-supported-series just bounced with test suite failures
[04:49] <axw> jam: I *think* it's for multi-env
[04:49] <wallyworld> ah, ok, just about to propose the i386 branch
[04:50] <wallyworld> will look in a bit
[04:50] <jam> wallyworld: I'm looking at your constraints vocabs patch
[04:50] <wallyworld> great ta
[04:58] <jam> wallyworld: reviewed https://codereview.appspot.com/96730043/
[04:58] <wallyworld> ta, will look rsn
[04:59] <jam> wallyworld: On your SeriesToUpload patch, I was surprised to see Lucid
[04:59] <wallyworld> jam: i didn't add it, it was already there
[04:59] <jam> k
[05:00] <wallyworld> i think the test just set it up as the preferred series in config
[05:00] <wallyworld> just to have something other than precise to use
[05:02] <wallyworld> jam: i tweaked some metadata and a test and fixed a nil pointer issue and it seems to work now https://codereview.appspot.com/90720043/
[05:03] <jam> wallyworld: LGTM
[05:03] <wallyworld> ta
[06:56] <fwereade> axw, jam: it's not really env-name, it's provider-name (or, heh, really more like account-name) but since we don't have those concepts in play at the moment we can't sanely reference them
[06:56] <jam> fwereade: fwiw, Id rather bring that in  when we actually have multi-provider environments
[06:57] <jam> but as long as you can just leave it off, I guess it is fine.
[06:57] <jam> I do wonder if we want to continue the --to syntax
[06:57] <axw> yeah, just as long as we don't prevent future use
[06:57] <jam> since that would match how it would end up on things that aren't bootstrap and add-machine
[06:57] <jam> but I suppose add-machine already uses the ssh: syntax
[06:58] <fwereade> jam, axw: yes, Iwould generally prefer that we not make a big deal of the prefixes; I just wantthem in place for when we do
[06:58] <fwereade> jam, axw: I think a placement directive is meaningful both as a positional arg and as a --to payload
[06:59] <fwereade> jam, axw: and it's to our benefit to make it look nice and easy in both cases, just as it is to our benefit to design it such that we can expandin plausibledirections in future without having to change everything ;)
[06:59] <axw> me too. "I'm bootstrapping $machine" vs. "I'm deploying $service to $machine"
[07:01] <jam> fwereade: axw: any chance that your change allows "juju bootstrap ssh:user@host" at the same time ?
[07:01] <fwereade> axw: although, hmm, I suddenly fret that --to works better on bootstrap...
[07:01] <axw> jam: no, I did think of that, but it's not possible atm
[07:01] <axw> jam: because we use the bootstrap-host when preparing
[07:01] <fwereade> axw, jam: I'm not quite sure what positional arg I would be saving it for
[07:01] <fwereade> axw, ah, that's a shame
[07:02] <axw> jam, fwereade I added a TODO in provider/manual to revisit it tho
[07:02] <jam> axw: AIUI we have a bug open on it
[07:02] <fwereade> axw, it does STM that we don't really even need an environments.yaml for that case,though
[07:02] <axw> ok
[07:02] <fwereade> axw, that's a bigger change, but one we should make soonish
[07:03] <jam> axw: bug #1282217
[07:03] <_mup_> Bug #1282217: Specifying bootstrap-host requires editing environments.yaml <bootstrap> <ci> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282217>
[07:03] <fwereade> axw, I haveto write it upproperly for vegas
[07:03] <jam> and possibly bug #1282642
[07:03] <_mup_> Bug #1282642: Bootstrap prefers .jenv over environments.yaml <bootstrap> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1282642>
[07:03] <axw> ah yes, that's right
[07:03] <jam> fwereade: so AIUI in bug #1282217, we need it in Prepare because we potentially call SyncTools before we bootstrap
[07:03] <_mup_> Bug #1282217: Specifying bootstrap-host requires editing environments.yaml <bootstrap> <ci> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282217>
[07:03] <axw> jam, fwereade: the main issue is that we have multiple ways of preparing an environment, and it currently needs to be usable before bootstrap
[07:03] <axw> yep
[07:04] <jam> however, sync-tools is sort of dying anyway, so I'd rather not tie us to that
[07:04] <fwereade> jam, yeah, but I'm not sure there's any reasonable remaining justification for sync-tools
[07:04] <fwereade> jam, axw: I don't *think* there's anything beyond sync-tools keeping Prepare distinct from Bootstrap, is there?
[07:05] <axw> fwereade: only plugins, but they probably don't need it
[07:05] <jam> fwereade: Prepare is the time when we take the rough template and fill out all the random bits
[07:05] <jam> so I don't mind it as a step
[07:05] <jam> but that step can happen only during bootstrap for all I care
[07:05] <axw> that would be nice
[07:05] <fwereade> jam, yeah, I'm not really against *prepare* so much as I am against environments.yaml
[07:05] <jam> fwereade: I *think* the fact that we gave bootstrap --source means we've replaced the other needs we had
[07:06] <fwereade> cool
[07:07] <jam> fwereade: with some possible caveats
[07:07] <jam> like I think we are missing a way to say "Give me a copy of the tools that are at $URL"
[07:07] <axw> the juju-metadata plugin uses PrepareFromName. does it need it to?
[07:07] <jam> and --metadata-source requires it to be a local path
[07:07] <jam> so you can bootstrap from a public URL either
[07:07] <axw> I think it might, so we can prepare tools and metadata in keystone or whatever
[07:07] <jam> axw: I'm a firm believer that metadata should not be a plugin
[07:08] <jam> axw: and I think it is in the same boat as sync-tools, in that when you are preparing your own image/tool metadata
[07:08] <jam> you can't have an env bootstrapped yet
[07:08] <jam> because you're creating its infrastructure
[07:08] <axw> right... so it just needs to be able to deal with an "unprepared" env config
[07:09] <jam> axw: but I don't think manual actually needs it, since you're not doing image lookup if your target is manual
[07:09] <fwereade> jam, axw: I dunno, I feel like creating metadata and uploading it are very distinct things
[07:09] <jam> you may need it for tools
[07:09] <fwereade> jam, axw: and that separation points towards the pluginness being a good thing
[07:09] <jam> tohugh again, I think --source for bootstrap is a better workflow there
[07:09] <fwereade> jam, axw: it probably shouldn't be about environments at all
[07:10] <fwereade> jam, axw: plugins for metadata generation, for them as needs it
[07:10] <jam> fwereade: actually, I firmly believe it shouldn't involve an env, because I often try to configure stuff, and I don't have a default env, and it just goes "poo" you must set -e
[07:10] <jam> fwereade: afaict it doesn't really do anything with the env, at least for generate
[07:10] <jam> maybe validate will use it for where to find the stream data
[07:10] <fwereade> jam, axw: --source args that let you point at local or remote metadata that gets pushed into your environment
[07:11] <fwereade> jam, axw: would be nicest of all, really, to have validate again just point at a metadata source
[07:11] <fwereade> jam, axw: then if an environment uses that source, yay, you know it's validated
[07:12] <axw> fwereade: how do point at the environment storage?
[07:15] <axw> although hm, the tools don't actually upload to env storage?
[07:15] <jam> axw: the metadata does
[07:15] <jam> or can
[07:16] <axw> jam: sorry I meant the plugin. doesn't look like it does... maybe there's a flag I'm missing
[07:17] <axw> anyway, if we can make it so prepare is only ever called by bootstrap that would be awesome
[07:19] <fwereade> axw, jam: yeah, I don't think we really need to -- although I think I'm backing off the idea that you *can't* validate metadata for an env, it still seems perfectly reasonable to just take the source from the env and check that source
[07:21] <axw> seems sane. I think once it's in the env, it should be reasonable to assume it's valid
[07:48] <jam> fwereade: I feel like you have a better handle on what should be happening while hooks are firing, I think I've gotten the context down small enough in https://bugs.launchpad.net/juju-core/+bug/1311825 but I don't quite understand why it does/doesn't do stuff
[07:48] <_mup_> Bug #1311825: test failure UniterSuite.TestUniterUpgradeConflicts <ci> <intermittent-failure> <test-failure> <juju-core:In Progress by jameinel> <https://launchpad.net/bugs/1311825>
[07:49] <jam> fwereade: do you want to Hangout about it?
[07:50] <fwereade> jam, sure, but you may just be watching me catching up
[07:51] <jam> fwereade: https://plus.google.com/hangouts/_/canonical.com/john-william
[08:42] <mfoord> morning all
[09:03] <fwereade> mfoord, heyhey
[09:06] <mfoord> fwereade: o/
[09:10] <fwereade> jam, https://codereview.appspot.com/92720044
[09:11] <jam> fwereade: LGTM
[09:11] <jam> fwereade: me thinks we might want that patch in 1.18 ?
[09:11] <jam> since it is about making CI happier to make releases
[09:34] <jam> fwereade: provisioner treats no tools as error: https://codereview.appspot.com/93720044
[09:37] <natefinch> morning all
[09:43] <jam> morning natefinch
[09:43] <jam> natefinch: care to start your day with a review ? https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/217011
[09:45] <natefinch> jam: sure
[09:52] <perrito666> morning
[09:52] <natefinch> perrito666: morning
[09:54]  * perrito666 notices his bug resembles a mamushka doll
[09:59] <axw> jam: not going to be able to make the meeting, I have to look after my daughter
[10:00] <jam> axw: np
[10:00] <axw> also I have tomorrow off - national holiday. see you all in vegas
[10:00] <jam> axw: see you next week
[10:01] <jam> fwereade: standup ?
[10:02] <perrito666> axw: you can bring your daughter to the meeting its becoming a thing :)
[10:02] <natefinch> axw: see you in vegas
[10:02] <natefinch> perrito666: you have a point :)
[10:03] <jam> vladk|offline: group standup ?
[10:32]  * perrito666 sees the test running for too long and knows he is about to get an error
[10:45] <mfoord> natefinch: you need to bring your daughter to Vegas. Daily standups without her just won't be the same...
[10:45] <natefinch> mfoord: haha
[11:25] <psivaa> jam: hey, could you help taking a look at http://paste.ubuntu.com/7315688/  for juju bootstrap with trunk version, 1.19.1-trusty-amd64 pls?
[11:27] <jam> psivaa: known bug we won't fix, you have to use --upload-tools to bootstrap trukn
[11:28] <psivaa> jam: ack, i think i tried that too. let me do that again. thanks
[11:28] <jam> psivaa: bug #1308337
[11:28] <_mup_> Bug #1308337: 1.19.1 cannot bootstrap 1.19.0 (no longer installs mongodb-server during bootstrap) <regression> <juju-core:Won't Fix> <https://launchpad.net/bugs/1308337>
[11:30] <psivaa> jam: thanks. with --upload-tools i got http://paste.ubuntu.com/7314791/ in a private cloud. not sure if the cloud being overly restrictive is any reason.
[11:30] <psivaa> i'll try that with hpcloud
[11:30] <jam> psivaa: you're using juju-core with gccgo and not compiling with static linking
[11:30] <jam> psivaa: var/lib/juju/tools/1.19.1.1-precise-amd64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
[11:30] <jam> psivaa: you need to set flags, let me go look them up
[11:31] <jam> psivaa: var/lib/juju/tools/1.19.1.1-precise-amd64/jujud: error while loading shared libraries: libgo.so.5: cannot open shared object file: No such file or directory
[11:31] <jam> sorry
[11:31] <jam> psivaa: INSTALL_FLAGS := -gccgoflags=-static-libgo
[11:31] <jam> psivaa: so you should be doing "go install -gccgoflags=-static-libgo" when building juju from trunk
[11:31] <psivaa> ack, will try that. thanks jam
[12:02] <wwitzel3> anyone else having issues with publickey denied with juju ssh to machine 0? using local provider?
[12:12] <jam> wwitzel3: your local machine isn't accepting your own ssh key, but that isn't that uncommon. ssh 0 is never guaranteed to work ,because most people don't even run openssh on their laptop/etc
[12:12] <jam> wwitzel3: what command are you running?
[12:13] <jam> eg "juju debug-log" never worked with local until recent 1.19.1-ish stuff
[12:13] <jam> thumper turned debug-log into an api call.
[12:43] <wwitzel3> jam: just juju ssh 0
[12:44] <jam> wwitzel3: right, that depends entirely on if "ssh localhost" works
[12:44] <jam> wwitzel3: not something guaranteed for local provider
[12:45] <wwitzel3> jam: well, I can run ssh localhost and it works as expected
[12:45] <jam> wwitzel3: sorry, can you "ssh ubuntu@localhost" ?
[12:45] <wwitzel3> jam: oh right, because that is the user it is expecting
[12:46] <mfoord> canonical wiki not responding
[12:46] <mfoord> and I want some lxc information from it
[12:46] <mfoord> so that seems like a good time to go on lunch
[12:47] <mfoord> back soon(ish)
[12:47] <wwitzel3> miss you already
[12:47] <mfoord> wwitzel3: liar :-)
[12:48] <perrito666> mfoord: also irc server is not letting me connect
[12:48] <jam> mfoord: wiki just came up for me
[12:48] <jam> slow, but it did come up
[13:10] <jam> fuuuuuu!!!
[13:10] <jam> I can't land anything on the 1.18 branch on the bot, the test suite is broken on tip
[13:10] <jam> didn't wallyworld have a patch recently because we had some test isolation issues when releases were made?
[13:11]  * wallyworld has vague recollections but can't recall the details
[13:12] <jam> wallyworld: does https://code.launchpad.net/~jameinel/juju-core/1.18-provisioner-no-tools-is-fatal-1311676/+merge/217011/comments/515862/+download ring any bells ?
[13:13] <jam> wallyworld: I'm just getting lots of "no tools available" failures on the 1.18 branch
[13:13] <jam> even without my patch (if I SSH in manually and try it)
[13:13] <jam> but it passes on my machine on trusty
[13:13] <wallyworld> jam: it's the changed lts thing
[13:13] <jam> ah, ffs, LatestLTSSerise became trusty
[13:13] <wallyworld> yep
[13:13] <jam> so all the tests that were expecting "precise" to just work
[13:13] <jam> ...
[13:14] <wallyworld> jam: i fixed it in trunk with the SeriesToUpload fix
[13:15] <wallyworld> it sorta worked before but then we got the %LTS% placeholder put in
[13:15] <jam> wallyworld: I can land my patch today by just editing /usr/share/distro-info/ubuntu.csv ...
[13:15] <jam> and making Trusty come out next month
[13:15] <wallyworld> yeah
[13:16] <wallyworld> i need to backport a bunch of fixes to 1.18
[13:16] <jam> wallyworld: well, the test which failed now passes on the bot
[13:16] <wallyworld> \o/
[13:16] <jam> I feel a bit dirty, but I feel *very* pragmatic
[13:17] <wallyworld> sometimes that's fine :-)
[13:18] <wallyworld> jam: so it seems we won't have 1.19.1 for ODC unless we shift out some bugs
[13:18] <jam> wallyworld: High bugs don't block releasing 1.19.1
[13:19] <wallyworld> great
[13:19] <jam> wallyworld: they're just the stuff I want next on everyone's queues
[13:19] <jam> they probably block 1.20
[13:19] <wallyworld> yeah
[13:19] <jam> High 1.19.1 bugs do, High 1.20 bugs probably don't...
[13:19] <jam> as we're essentially doing priority by keeping multiple milestones
[13:28] <jam> natefinch:  wwitzel3: can I get a trivial review: https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/217036
[13:28] <jam> we were ignoring an 'err' return that could cause a later pani()
[13:28] <jam> panic()
[13:28] <wwitzel3> + 1 we shouldn't do that
[13:28] <wwitzel3> haha, taking a look
[13:30] <wwitzel3> LGTM
[13:31] <alexisb> dude! you guys are kicking a** on bugs!
[13:33] <jam> alexisb: well, I feel like I'm reporting as many as I'm fixing, but we are doing a lot of them
[13:33] <alexisb> jam :) understood
[13:33] <alexisb> but finding them is important to
[13:33] <wwitzel3> jam: that's interesting, because it was declared as a var and then used in scope at the bottom of the fuction, it wasn't an compile time error when we didn't use the err we get back from the function.
[13:33] <alexisb> either way the progress is impressive
[13:33] <jam> wwitzel3: hypothetically I should be adding a test for that path
[13:34] <alexisb> jam are we seeing a lot of regressions from HA and vlan landing?
[13:35] <jam> alexisb: we are seeing a lot of things that don't work when HA is enabled
[13:35] <jam> not quite the same thing
[13:35] <jam> when you don't *use* HA, then everything still works
[13:35] <wwitzel3> :)
[13:35] <alexisb> jam ack
[13:35] <alexisb> that is better then HA breaking everything :)
[13:38] <fwereade> natefinch, please remind me how arch selection works after your change -- do we pick amd64 by default, regardless of client?
[13:38] <jam> alexisb: right. I think it falls under "not a regression, but fairly important bugs" which is reasonable
[13:38] <jam> given that HA isn't by-default
[13:39] <fwereade> natefinch, if so, am I right in thinking it should also resolve https://bugs.launchpad.net/juju-core/+bug/1274755 and https://bugs.launchpad.net/juju-core/+bug/1262967 ?
[13:40] <alexisb> jam we will need to flush out the HA bugs and get them fixed before 1.20
[13:42] <natefinch> fwereade: I changed it to just select the same arch as the host if possible
[13:42] <natefinch> fwereade: since jam had made a good point that otherwise we'll break --uploađ-tools
[13:43] <alexisb> jam, for the HA sprint discussion...
[13:43] <jam> fwereade: I don't think it fixes https://bugs.launchpad.net/juju-core/+bug/1274755
[13:43] <jam> that is that our canned data doesn't include other ARCH
[13:43] <alexisb> do you think it is a mini topic or needs a full timeslot?
[13:43] <fwereade> natefinch, that seems backwards -- aren't we restricting by available images/tools before going further?
[13:43] <jam> alexisb: I think we're going to be talking a lot about next steps for HA, TBH
[13:43] <jam> fwereade: https://bugs.launchpad.net/juju-core/+bug/1274755 is a test-suite bug
[13:44] <jam> fwereade: so if you just run "juju bootstrap" it will pick something
[13:44] <jam> if you later run "juju upgrade-juju --upload-tools"
[13:44] <jam> We've at least had support requests
[13:44] <jam> where they expected the latter to work, but were on say i386
[13:44] <jam> and you can't upload i386 tools to an amd64 env
[13:45] <jam> I'm not *sure* what clouds would have amd64 and ppc64 and then run from a ppc64 client
[13:45] <natefinch> fwereade: the arch check is the last thing we do, after other considerations (tools and constraints)
[13:45] <jam> alexisb: I'm *mostly* concerned that we have time allocated to doing the work
[13:45] <alexisb> ack
[13:45] <jam> alexisb: We can do the actual discussion in the bar, but I do think it is going to have a longer tail if we really want polish
[13:46] <alexisb> yep we are planning to but time aside for core coding
[13:47] <jam> alexisb: so are you saying I can have time for my team to code, or time to discuss HA ?
[13:48] <alexisb> I am saying we have already planed to have time for coding, and I can schedule time for HA discussion if needed
[13:53] <jam> alexisb: sounds good
[13:53] <jam> I realize I'm adding them late, but when I come across them, I figure it is better to bring it up
[13:53] <jam> we'll probably be adding some during the week as well, I would imagine
[13:54] <alexisb> yes something tells me this will be a dynamic plan
[13:54] <alexisb> I am just trying to ensure we capture everything and make note of it
[13:57] <jam> alexisb: certainly, and I *definitely* appreciate that I can fire off a "we should talk about this" and not have to actually schedule it myself
[13:59] <jam> wwitzel3: I think the code in question wanted to do shared error handling, and then just didn't, or was refactored out of being shared. I can poke at it a bit more
[13:59] <jam> wwitzel3: I can't land it yet on the bot because of the Trusty / Utopic stuff (still needs to land my other branch which fixes 1.18 branch to pass the test suite again)
[13:59] <coreycb> Hi, I'm getting connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused' on bootstrap of local provider on trusty
[14:00] <fwereade> natefinch, jam: dammt, I thought we'd done the SupportedArchitectures work to head that sort of problem off at the pass
[14:00] <jam> wwitzel3: cfg is needed because it gets used later on
[14:01] <fwereade> natefinch, jam: anyway, thanks, I won't close the bugs then :)
[14:01] <jam> wwitzel3: and you can't return 'cfg' without returning 'err' I believe, we could declare 'err' more locally but we can't use := syntax
[14:01] <jam> fwereade: *shrug* I'm not sure. I'm just giving my synopsis of the bug
[14:01] <jam> since we don't have that platform on-hand to test it
[14:01] <jam> maybe it works
[14:01] <jam> wallyworld was doing testing on ppc64, right?
[14:02] <fwereade> jam, indeed, but the evidence does not strongly point that way :)
[14:02] <coreycb> /var/log/upstart/juju-db*.log has:   "/bin/sh: 1: exec: /usr/lib/juju/bin/mongod: not found"
[14:03] <jam> coreycb: do you have "juju-local" installed ? it should bring in "juju-mongodb"
[14:04] <coreycb> jam: nope
[14:04] <jam> coreycb: I believe in trunk we detect if juju-local is available and if not, request that you install it
[14:04] <fwereade> jam, you remember updating the ec2instance types a couple of months ago? do you recall where you got the cpu-power scores?
[14:05] <coreycb> jam, that fixed it.  I don't think it notified me to but I could hvae missed something.  I know it told me to install mongodb-server.
[14:05] <jam> coreycb: 1.18 detected fixed dependencies, which were valid on precise, but not trusty
[14:05] <jam> so instead we now require juju-local
[14:05] <jam> which brings in the right things on both platforms
[14:06] <coreycb> jam, ok I'm on 1.18.1-0ubuntu1
[14:07] <jam> fwereade: I believe they changed their webpages :(
[14:07] <natefinch> jam, wwitzel3:  we should declare err inside the if scope.  Yes, you'll need to do it in two places, but it'll ensure the compiler knows if you don't use it
[14:08] <fwereade> jam, yeah, and now the only provider that understood cpu-power no longer gives us values
[14:08] <jam> fwereade: found it: https://aws.amazon.com/ec2/pricing/
[14:08] <jam> fwereade: it is under pricing, but not under instance types
[14:08] <fwereade> jam, ah-ha! thanks
[14:08] <jam> natefinch: i did
[14:08] <jam> though it feels pretty wasted victory
[14:09] <jam> natefinch: that is going to be something RSN someone is going to say "Why is this code duplicated" and pull it out as they refactor the function and forget to handle the err :)
[14:09] <jam> but I *did* add a test for this case
[14:09] <fwereade> jam, and there's some new ones, might as well add them (since I'm fixing a typo and looking them up anyway ;p)
[14:09] <jam> note that the code still has another bug
[14:09] <jam> which is if envs.Config() doesn't return IsNotFound
[14:09] <jam> but returns some other err
[14:09] <jam> it is going to break again
[14:09] <natefinch> jam: yeah, I was going to mention that
[14:11] <jam> natefinch: so you can pick up my patch if you want, but I'm way past EOD and shaving yaks is not a good start to my weekend
[14:12] <natefinch> jam: no problem
[14:12] <jam> natefinch: its pretty obvious that the author thought err was going to bubble up and be handled
[14:12] <jam> but isn't
[14:12] <jam> like, why handle only IsNotFound here
[14:12] <natefinch> yep
[14:13] <jam> natefinch: so I'd appreciate handoff of https://code.launchpad.net/~jameinel/juju-core/1.18-panic-parsing-jenv-1312136/+merge/217036. If you like it well enough, Approve it, if you want to tweak it, feel free
[14:15] <natefinch> jam: sure, I'd like to handle the non-not found error
[14:15] <natefinch> jam: seems like we don't need to handle notfound special there, just return whatever error we get
[14:17] <jam> natefinch: sgtm, I'm not sure what errors we could handle
[14:17] <jam> which means we probably want to move the Warningf that I have
[14:17] <jam> up
[14:17] <jam> and share the err
[14:18] <jam> natefinch: the Warningf is because otherwise we don't inform the user that there data is bad, because we are trying to connect on the other Try
[14:20] <natefinch> jam: so always warn if we return a non-nil error?
[14:20] <jam> natefinch: I think we could not warn on NotFound
[14:21] <natefinch> jam: yeah, that seems valid
[14:21] <natefinch> jam:  someone higher up is probably checking for isnotfound anyway
[14:25] <jam> happy birthday to Vladk
[14:25] <vladk> jam: thanks
[14:26] <perrito666> vladk: hey hb
[14:26] <perrito666> why is calendar not telling me that its your bd?
[14:27] <wwitzel3> vladk: nice job, do it again next year ;)
[14:31] <fwereade> jam, another question about the m3 instance types -- they seem to accept both paravirtual and hvm images. do you know any particular reason to choose one over the other?
[14:35] <coreycb> are individual juju command options documented somewhere?
[14:36] <natefinch> coreycb: juju help <commandname>
[14:36] <coreycb> natefinch, duh, thanks :)
[14:36] <natefinch> coreycb: np :)
[14:38] <fwereade> alexisb, I've just realised I've been listening to the hold music on the cross-team call for 10 mins -- do you know if it's happening?
[14:39] <coreycb> hmm 'juju debug' gets - ERROR control-bucket: expected string, got nothing
[14:39] <alexisb> fwereade, I think mark sent a cancellation notice
[14:39] <coreycb> sorry, juju debug-log
[14:39] <alexisb> but you are not the first to ask so maybe not
[14:40] <bloodearnest> fwereade: it just got all electro-funk on me
[14:40] <fwereade> bloodearnest, yeah, it was a bit more soothing when I started listening
[14:41] <fwereade> alexisb, well, I'll drop off for now, I'm around if I'mwanted
[14:42] <rick_h_> fwereade: same here. I just gave up.
[14:42] <rick_h_> fwereade: looking through my mail for any missed notice
[14:42] <fwereade> rick_h_, couldn't find one, but iirc he is at gophercon
[14:42] <rick_h_> yep, conference has swallowed our teams
[14:43] <alexisb> :)
[14:43] <alexisb> yep sorry guys
[14:43] <alexisb> I would run it but I dont have the leader code
[14:43] <alexisb> and I am on a plane
[14:43] <rick_h_> all good, see everyone in 4 days
[14:45] <natefinch> alexisb: I thought you were going to be there yesterday?
[14:46] <alexisb> natefinch, I was
[14:46] <alexisb> I ended up in the ER
[14:46] <alexisb> it is a long story
[14:46] <natefinch> alexisb: whoa, hope everything's ok
[14:46] <alexisb> but I am headed that way now
[14:47] <alexisb> yes just complications from the cold I had 3 weeks ago
[14:47] <alexisb> but I promise everyone I am not contagious I wont get you sick
[14:48] <natefinch> alexisb: heh... I thought I was getting over my three (now almost four) week cold a couple days ago, and it just got worse.
[14:49] <coreycb> has anyone seen this?  http://paste.ubuntu.com/7322857/
[14:49] <coreycb> (sorry for so many questions this morning)
[14:53] <natefinch> coreycb: hmm you don't really need to do debug-log locally, since you can just view the log yourself.  But I do wonder if that's a bug in local
[14:54] <perrito666> alexisb: plane with internet sweet, here I was once asked to shut down my ipod (as in old, no internet ipod) for takeoff :p I certainly would not be allowed to use internet on flight
[14:55] <natefinch> fwereade: any known issues with debug-log on local?  Seems like it would try to ssh to localhost's port 22, and I'm not sure we can guarantee it'll be open?
[14:55] <coreycb> natefinch, yeah I can just log into the machine for now
[14:56] <natefinch> coreycb: it's the local provider, right?  So the logs should be under ~/.juju/local
[14:57] <coreycb> natefinch, yes it is.  ok thanks
[15:00] <fwereade> natefinch, not sure it ever worked properly until thumper's debug-log-via-api, thought it'd work now
[15:00] <fwereade> natefinch, although, yeah, you can always just look at the logs ;)
[15:00] <natefinch> fwereade: is that post 1.18.1?
[15:00] <fwereade> natefinch, I *thought* .0, but I'd have to go hunting
[15:01] <natefinch> fwereade: it's ok. I can try it out and see what's going on
[15:01] <fwereade> natefinch, cheers
[15:08] <natefinch> anyone else having bzr issues?   I presume it's a launchpad connection problem.
[15:45] <wwitzel3> natefinch: everything was giving me issues earlier, but apparently there were some networking issues. Seems fine for me now.
[15:45] <wwitzel3> natefinch: though still a bit slower than normal
[16:15] <natefinch> wwitzel3: that's good
[16:15] <natefinch> rogpeppe: hey, how's gophercon?
[16:15] <rogpeppe> natefinch: great so far!
[16:15] <rogpeppe> natefinch: (apart from the hangover)
[16:15] <natefinch> rogpeppe: haha, well, only one person to blame for that. ;)   I hear the lower air pressure makes alcohol more effective up there
[16:17] <rogpeppe> natefinch: yeah
[16:30] <natefinch> wwitzel3: can you review my update to john's branch?  I think it's a lot easier to read, and also handles an error path that his change was missing: https://codereview.appspot.com/90740044
[16:37] <mfoord> I was wrong about rsyslog v5 docs not being online
[16:37] <mfoord> thankfully they are
[16:38] <fwereade> natefinch, LGTM, much nicer
[16:38] <mgz> rogpeppe: how do you have a hangover already...
[16:39] <perrito666> mgz: clearly drinklag
[16:40] <mfoord> rogpeppe: hey, hi
[16:40] <mfoord> rogpeppe: obviously the right fix for the hangover is to start drinking again
[16:46] <sinzui> natefinch, rogpeppe : CI still fails trunk because of precise unit tests: https://bugs.launchpad.net/juju-core/+bug/1312261
[16:46] <_mup_> Bug #1312261: 3 unit tests  fail the entire precise suite <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1312261>
[16:49] <sinzui> natefinch, or wwitzel3 , or anyone. ^ any ideas what can be done to the tests or to the test setup to make them pass on precise?
[17:08] <wwitzel3> natefinch: LGTM, nice job
[17:20] <mfoord> so according to rsyslogd my config file is valid
[17:21] <mfoord> need HA up and running to try it
[17:21] <mfoord> that'll be a task for tomorrow I think
[17:21] <mfoord> time to go jogging
[17:25] <mgz> sinzui: one thing to check on those tests if if the precise has up to date distro-info-data
[17:26] <sinzui> mgz, you mean the archives we pull from whe we do an update could be stale?
[17:28] <sinzui> mgz, distro-info-data was installed/upgraded to 0.8ubuntu0.6
[17:28] <sinzui> oh, mgz, but trusty got  0.18ubuntu0.1
[17:30] <sinzui> mgz, distro-info-data_0.8ubuntu0.6_all.deb on precise does know about utopic
[17:31]  * sinzui quickly updates publishing script to use that name instead of unctuous.
[18:09] <perrito666> has anyone ever encountered a loop of "INFO juju.state open.go:133 dialled mongo successfully" when calling state.Open() ?
[18:11] <natefinch> perrito666: doesn't sound familiar.  Are you running with --debug?  Hopefully you'd get more info about what's actyually going on.  The other option is to go look at the system logs, rsyslog, etc.  Sometimes mongo's logs will output something useful.
[18:11]  * natefinch has to go run a quick errand, back in half hour ish.
[18:54] <natefinch> directions for restarting Ubuntu:  click power button, restart, hit the restart button in the popup window. Wait a minute, nothing happens.  Close all applications and try again.  Wait a minute, nothing happens.  Open terminal run sudo reboot, window manager closes immediately, wait 2 minutes while ubuntu .... image spins, hold power button for 5 seconds until hard power off.  Push power button again.
[18:57] <sinzui> hands up who moved loggo from the loggo organisation to the juju organisation
[18:57] <perrito666> natefinch: wow, instead, iirc: open terminal, sync, unplug power cord
[18:58] <natefinch> perrito666: heh, well, it's a laptop, so I'd have to remove the battery too, which requires unscrewing stuff.  Probably just pushing the power button for 5 seconds to start is the best bet,.
[18:59] <perrito666> natefinch: seems your machine hates the new ubuntu kernel
[19:00] <sinzui> 1.18 cannot build because loggo has moved. I need to create a shim.
[19:00] <natefinch> perrito666: something.  There was a sweet spot in there somewhere where it was rebooting correctly for a month or two.  Not so much, now.  Oh well, I don't reboot often enough for it to be a big deal.  Had to today because LXC was being a bitch and screwing my juju local
[19:00] <natefinch> sinzui: does loggo not exist in the old place?
[19:01] <sinzui> Will go/godeps allow my to symlink, or do it need to manually get it
[19:01] <sinzui> natefinch, yes it does exist in the old place
[19:01] <sinzui> well regardless, of the solution I will know soon
[19:02] <natefinch> sinzui: go build only cares about paths on disk.  it looks for "launchpad.net/loggo" under $GOPATH/src/launchpad.net/loggo  .. it has no idea and doesn't care how the code got to that directory
[19:03] <natefinch> sinzui: not sure about godeps.... it expects to be able to use VCS to sync a branch to a commit number, will probably fail if it can't do that in the correct directory
[19:03] <sinzui> thank you natefinch . I will hope for a symlink, but plan to pull from the old repo
[19:04] <sinzui> hmm, but why didn't godeps complain that the lib wasn't missing. go build certainly noticed
[19:04] <natefinch> sinzui: not sure.  Not hugely familiar with the internals of godeps.  I'd assume that if that directory didn't exist, it would barf
[19:05] <sinzui> maybe the tarball script is calling godeps too early
[19:05]  * sinzui looks
[19:25] <sinzui> natefinch, a new clue, Looks like logo has to be in the old and new location for go to build. I tested with just old and just new and go failures.
[19:25] <natefinch> sinzui: sounds like some of the code is referencing the old path and some is referencing the new path
[19:25] <jam1> natefinch: my patch was intended for lp:juju-core/1.18 though you're proposing it against trunk
[19:25] <natefinch> jam1: doh
[19:26] <natefinch> jam1: that would be why it has 1.18 in the name, too :/
[19:26] <sinzui> natefinch, if this is the case I think I or jam will update the code to just use the old location to meet Ubuntu's criteria for micro releases
[19:26] <natefinch> sinzui: yeah, we definitely should not be using both, that could easily cause bad behavior
[19:27] <jam1> sinzui: so the awful truth is that LTS switching to trusty broke some of our tests, I believe
[19:27] <natefinch> jam1: luckily one of the tests failed ;)
[19:27] <jam1> sinzui: bug #1312176
[19:27] <_mup_> Bug #1312176: test suite fails on Precise now that Trusty is released <test-failure> <testing> <juju-core:Triaged> <https://launchpad.net/bugs/1312176>
[19:27] <natefinch>  jam1: it's like one of those "are you sure you want to merge this?" popups.  You have to really mean it
[19:28] <sinzui> jam1, you can feel good that trusty tests usually pass the first time. trusty is ver stable
[19:28] <natefinch> jam1: well, shit.  I guess I should cherrypick my change and move it to a new branch
[19:30] <jam1> natefinch: can you just propose it against 1.18 or did you merge trunk in the meantime?
[19:30] <natefinch> jam1: I merged trunk :/  there were conflicts (not surprising since it was for 1.18)
[19:31] <sinzui> natefinch, jam1. 1.18 does indeed want both loggos and the juju/loggo is unpinned because the goreps don't know about it.
[19:31] <natefinch> jam1: I can just re-branch your branch and copy over the changes, they were pretty trivial
[19:31] <natefinch> sinzui: that's a pretty important bug.  Importing both could easily cause serious issues.  We need to only use one or the other.
[19:31] <jam1> sinzui: yeah, I think hazmat noted that we have a bogus import
[19:43] <sinzui> natefinch, jam1: https://bugs.launchpad.net/juju-core/+bug/1311909 proposal for a fix sane? I can do all the packaging changes. The upgrade suggestion might to too tricky to do
[19:43] <_mup_> Bug #1311909: juju 1.18 (local provider) depends on lxc 1.0.0 but nothing forces it to install on precise <packaging> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1311909>
[19:46] <natefinch> sinzui: sounds good to me
[19:52] <natefinch> weird, lbox totally screwed up the link to the code review
[19:53] <natefinch> no.... it looks like reitveld just reused an old number including old comments, but with the correct code
[19:54]  * natefinch doesn't know WTF is going on with reitveld
[19:58] <jam1> sinzui: if we just put lxc 1.0.0 into ppa:juju/stable would it make it work?
[20:08] <natefinch> dammit, somehow bzr or lbox completely mangled my commit
[20:08]  * natefinch does it over again
[20:10] <sinzui> jam1, I think it might have avoided the issue where juju-local wasn't installed
[20:13] <natefinch> ahh FFS
[20:15] <natefinch> jam1, wwitzel3: not sure if either of you are still here, but I had to manually propose my new branch because lbox is somehow totally borked for this branch for whatever reason
[20:16] <natefinch> jam1, wwitzel3: https://code.launchpad.net/~natefinch/juju-core/panic-parsing-jenv-1312136/+merge/217130
[20:18] <fwereade> natefinch, that still LGTM
[20:18] <natefinch> fwereade: thanks
[20:28] <sinzui> natefinch, wwitzel3 will either of you be landing a branch in the next 2 hours?
[20:29] <natefinch> sinzui: in theory I have one landing right now
[20:29] <sinzui> fab, I will wait for your branch instead os replaying an old revision to test utopic building
[20:35] <natefinch> fwereade: trivial code review if you have a sec: https://codereview.appspot.com/94760043
[20:36] <fwereade> natefinch, shouldn't there be an error returned and checked there?
[20:37] <natefinch> fwereade: oops, wow, yeah.  Thanks for catching that
[20:40] <natefinch> fwereade: fixed
[20:43] <sinzui> natefinch, 	lp:juju-core/1.18 r2275 just fail again.
[20:43] <sinzui> go build -v launchpad.net/juju-core/...
[20:43] <sinzui> tmp.t3vUjGZmJ6/RELEASE/src/launchpad.net/juju-core/state/apiserver/usermanager/usermanager.go:9:2: cannot find package "github.com/loggo/loggo" in any of:
[20:43] <sinzui> 	/usr/lib/go/src/pkg/github.com/loggo/loggo (from $GOROOT)
[20:43] <sinzui> 	/mnt/jenkinshome/jobs/build-revision/workspace/tmp.t3vUjGZmJ6/RELEASE/src/github.com/loggo/loggo (from $GOPATH
[20:44] <fwereade> natefinch, LGTM
[20:45] <natefinch> fwereade: thanks
[20:45] <natefinch> sinzui: do you need me to fix that?
[20:46] <sinzui> natefinch, I am about to prose a fix for the one bad import
[20:46] <natefinch> sinzui: ok
[20:46] <natefinch> sinzui: that looks to be the only place it's imported in 1.18 AFAICS
[20:52] <sinzui> natefinch, Do you have a moment to review https://codereview.appspot.com/96780043
[20:53] <natefinch> sinzui: LGTM
[20:54] <sinzui> thank you natefinch , I will offer to the gobot god
[20:54] <natefinch> sinzui: good luck :)
[20:56] <natefinch> ok, EOD for me
[21:13] <perrito666> hey, is this on syslog something I should worry about? replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)
[22:26] <fwereade> if anyone's around, I'd appreciate a review of https://codereview.appspot.com/96790043 that included checking a random sample of it against objective reality
[22:26]  * fwereade bed