[00:54] <davecheney> anyone here want to help debgging a manual provider issue ?
[00:54] <davecheney> http://paste.ubuntu.com/7144037/
[00:54] <davecheney> wedged here
[00:58] <davecheney> hmm, wedged waiting on mongodb
[00:58] <davecheney> but mongodb isn't running
[00:58] <davecheney> ....
[00:58] <davecheney> juju-db start/running, process 4156
[00:58] <davecheney> 2014-03-24 00:52:01 DEBUG juju.environs.bootstrap state.go:73 loading "provider-state" from "file:///var/lib/juju/storage/provider-state"
[00:58] <davecheney> 2014-03-24 00:52:01 DEBUG juju.agent agent.go:318 read agent config, format "1.18"
[00:59] <davecheney> 2014-03-24 00:52:01 DEBUG juju.agent bootstrap.go:63 initializing address [localhost:37017]
[00:59] <davecheney> 2014-03-24 00:52:01 INFO juju.state open.go:79 opening state; mongo addresses: ["localhost:37017"]; entity ""
[00:59] <davecheney> 2014-03-24 00:52:01 DEBUG juju.state open.go:99 connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused
[00:59] <davecheney> the first line is a lie
[01:03] <davecheney> root@winton-06:/etc/init# status juju-db
[01:03] <davecheney> juju-db stop/waiting
[01:03] <davecheney> what ?
[01:03] <davecheney> why did it stop ?
[01:05] <axw> davecheney: is juju-mongodb installed?
[01:05] <davecheney> yes it is
[01:05] <davecheney> root@winton-06:/etc/init# stat /usr/lib/juju/bin/mongod File: ‘/usr/lib/juju/bin/mongod’
[01:06]  * davecheney goes spelunking for log files
[01:07] <davecheney> 2014-03-24 01:02:01 DEBUG juju.utils.ssh ssh_openssh.go:147 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i "/home/ubuntu/.juju/ssh/juju_id_rsa" "ubuntu@10.245.67.6" 'sudo pkill -6 jujud'
[01:07] <davecheney> ^ why sudo pkill
[01:07] <davecheney> -6 is an odd signal
[01:07] <davecheney> sudo killall jujud ?
[01:14] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1296485
[01:14] <_mup_> Bug #1296485: manual provider fails to remove itself if bootstrapping fails <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1296485>
[01:16] <davecheney> ok, here is theprobme
[01:17] <davecheney> root@winton-06:/etc/init# start juju-db
[01:17] <davecheney> juju-db start/running, process 4660
[01:17] <davecheney> root@winton-06:/etc/init# status juju-db
[01:17] <davecheney> juju-db stop/waiting
[01:17] <davecheney> juju-db is shutting down
[01:18] <axw> davecheney: should probably use killall, but we use a particular signal to tell the machine agent to uninstall itself
[01:18] <davecheney> axw: http://paste.ubuntu.com/7144083/
[01:18] <davecheney> oh crap
[01:18] <davecheney> root@winton-06:/var/log/upstart# getconf PAGESIZE
[01:18] <davecheney> 65536
[01:18] <davecheney> FUCK
[01:19] <axw> :\
[01:19] <axw> is someone working on a patch to mongo?
[01:20]  * davecheney looks
[01:20] <davecheney> ill go an ask in #ibm
[01:21] <axw> seems kinda important
[01:21] <davecheney> no thumper ?
[01:22]  * axw shrugs
[01:25] <wallyworld> tim is away today - public holiday
[01:27] <davecheney> (╯°□°）╯︵ ┻━┻
[01:31] <axw> wallyworld: it'll be a lonely standup - got anything to talk about?
[01:32] <wallyworld> axw: touch base on that upstart logging thing?
[01:32] <axw> wallyworld: sure
[02:09] <axw> wallyworld: I was just thinking we could bind mount /var/log/juju-<namespace> in the containers, and symlink the whole thing as ~/.juju/local/log. What do you think?
[02:09]  * wallyworld thinks
[02:10] <wallyworld> i like that all the files or kept together that way
[02:10] <axw> maybe I should check with thumper before making that change
[02:10] <wallyworld> it's not that big a change to implement
[02:10] <axw> yeah
[02:10] <wallyworld> i'd be inclided to do it
[02:11] <wallyworld> i think it makes sense
[02:11] <axw> I'll have a poke in a bit
[02:11] <wallyworld> i don't like how some files are symlinked and others aren't
[02:15] <axw> wallyworld: reviewed. sorry, you'll have a few files to merge
[02:15] <axw> mine just landed
[02:15] <wallyworld> np at all
[02:15] <wallyworld> thanks for reviewing
[02:57] <wallyworld> davecheney: hi, thanks for reviewing. that SSLHostnameVerification code is copied across from another package so it not new to this mp. it's a pattern people introduced to avoid passing true/false as params which give no indication as to what's happening
[02:57] <davecheney> wallyworld: fair enough
[02:57] <davecheney> right, but that doesn't mean you need a new type
[02:57] <davecheney> just a well named constant
[02:57] <wallyworld> i think it was done to stop people passing in true/false
[02:57] <davecheney> it doens't prevent that
[02:57] <wallyworld> ie force them to use the const
[02:58] <davecheney> won't work
[02:58] <davecheney> doesn't work like that
[02:58] <wallyworld> i'm just guessing, i didn't write the code
[02:58] <wallyworld> maybe it was done for clarity?
[02:58] <davecheney> see previous comment about constant name
[02:58] <davecheney> anyway
[02:58] <davecheney> feel free to ignore that suggestion
[02:58] <davecheney> it was a minor nit
[02:59] <davecheney> that change is a signficant improvement
[02:59] <wallyworld> np, thanks, i'll read the comments and see if i can improve things
[03:00] <wallyworld> the hostnameVerification variable name tries to hide the bool nature of the values and reinforce the use of the constants
[03:00] <davecheney> yes, but it doens't work
[03:01] <wallyworld> it's meant as a visual aide to reading the code
[03:01] <davecheney> feel free to ignore that suggestion
[04:09] <jam1> axw: wallyworld: Is thumper still around?
[04:09] <axw> jam1: public holiday I'm told
[04:09] <jam1> axw: ok, thanks. we had a phone call scheduled, but I'm happy to go have breakfast instead. :)
[04:11] <jam1> I see the holiday on the calendar now.
[04:12] <axw> jam1: how do holidays end up on there?
[04:12] <jam1> axw: people add them
[04:12] <axw> ok
[04:12] <jam1> This is the Juju team calendar, but it looks like you aren't set with edit rights
[04:12] <jam1> I'll fix that now
[04:12] <axw> jam1: thanks
[04:13] <jam1> axw: your @canonical account can add and modify things in the calendar now
[04:13] <axw> cool, ta
[04:15] <axw> jam1: wallyworld says you were able to reproduce #1295501. after breakfast, would you mind running bootstrap with strace so I can try to get to the bottom of it?
[04:15] <_mup_> Bug #1295501: local provider upstart script broken <local-provider> <logging> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1295501>
[04:15] <axw> (assuming you can still repro)
[04:15] <jam1> axw: I saw the file come up pointing at a /var/log that I didn't have.
[04:16] <axw> jam1: yeah, the file should be there - something must've gone wrong early on in bootstrap
[04:16] <jam1> axw: *bootstrap* seemed to work, but restart failed
[04:16] <axw> silently wrong I mean
[04:16] <jam1> ah, but you think it "failed" but didn't actually stop
[04:16] <axw> yup
[04:49] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1235529
[04:49] <_mup_> Bug #1235529: Local provider does not respect tools-url <bootstrap> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1235529>
[04:49] <davecheney> this can be closed, right ?
[04:49] <davecheney> we've changed that logic a bazillion times
[04:49] <davecheney> that bug report can't be accurate anymore
[04:50] <davecheney> ubuntu@winton-02:~/src/launchpad.net/juju-core$ uname -a
[04:50] <davecheney> Linux winton-02 3.13.0-8-generic #28-Ubuntu SMP Mon Feb 17 08:22:39 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux
[04:50] <davecheney> crap, ignore
[04:52] <axw> davecheney: I don't think so, the local provider makes assumptions that it's bootstrapping tools with version.Current with buildnumber++, IIRC
[04:53] <davecheney> fairy nuf
[05:53] <axw> jam: thanks for the email. copy&paste last line of my reply: "Looking at your log dirs, though, I see they both have the files (machine-0.log). So is the restart bug still occurring...?"
[05:54] <jam> I haven't seen that the restart problem is still happening, I got stuck noticing that it didn't clean up after itself, and that strace -f isn't working.
[05:56] <jam> axw: I'll bootstrap and then poke machine-0 real quick
[05:56] <axw> thanks
[06:06] <davecheney> how the FUCK do I godeps
[06:07] <davecheney> fucking every time have to fight with this tool
[06:07] <davecheney> why is the head of launchpad/golxc broken ?!?
[06:08] <axw> davecheney: godeps -u dependencies.tsv
[06:09] <axw> I think it doesn't like it when repos are dirty though
[06:09] <axw> in that case I sometimes just bzr update -r <revno>
[06:09] <jam> axw: manually killing jujud w/ SIGTERM, and using restart juju-agent-jameinel-local all seem to bring the agent back up.
[06:09] <davecheney> why should it care if the repo is dirty
[06:10] <davecheney> the repo I care about isn't the one that is dirty
[06:10] <axw> jam: bugger, no repro then :/
[06:10] <wallyworld_> davecheney: welcome to golangs EXCELLENT dependency management :-(
[06:10] <davecheney> wallyworld_: i walked into that one didn't i
[06:10] <wallyworld_> yep :-)
[06:10] <axw> davecheney: yeah I know, it would be nice if you could specify just one
[06:10] <axw> or cat them in or something
[06:11] <axw> wallyworld_ jam: in any case, this CL should make local provider bootstrap a little simpler and more robust: https://codereview.appspot.com/79310043/
[06:12] <wallyworld_> looking
[06:17] <axw> incidentally, I have a feeling this fixes #1294776
[06:17] <_mup_> Bug #1294776: No debug-log with MAAS, 14.04 and juju-core 1.17.5 <logging> <regression> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1294776>
[06:25] <axw> wallyworld_: I did at a test... was there something in particular you think was worth testing?
[06:26] <wallyworld_> axw: ah sorry, totally missed it.
[06:27] <axw> nps
[06:27] <wallyworld_> i could have sworn i looked at allt he files
[06:28] <axw> wallyworld_: good to land then?
[06:52] <wallyworld_> axw: sorry, went to pick up kid. yeah
[06:53] <wallyworld_> axw: one thing i didn't look at closely - will it handle existing local dirs with root ownership etc? or maybe we just require a destroy-env first?
[07:17] <axw> wallyworld_: there are some cases where it's necessary to destroy-env --force, but there's no change there
[07:18] <axw> can't remove them if you're not root
[07:19] <wallyworld_> ok
[07:19] <wallyworld_> just thining out loud
[07:31] <dimitern> morning jam, 1-1 ?
[07:57] <vladk> good morning
[08:01] <rogpeppe> mornin' all
[08:01] <rogpeppe> vladk, dimitern, wallyworld_, axw, jam: hiya
[08:01] <vladk> rogpeppe: hello
[08:02] <jam1> morning vlad, rogpeppe
[08:02] <axw> rogpeppe: morning
[08:02] <axw> and vladk
[08:12] <dimitern> rogpeppe, hey
[08:13] <dimitern> morning vladk
[08:13] <vladk> dimitern: morning
[08:22] <wallyworld_> rogpeppe: g'day
[08:22] <rogpeppe> wallyworld_: yo!
[08:22] <wallyworld_> how are they hangin'?
[08:22] <rogpeppe> i'm looking for a review of this, if anyone has a little time: https://codereview.appspot.com/78890043/
[08:23]  * wallyworld_ is about to eat dinner sorry
[08:24] <rogpeppe> wallyworld_: pretty good, except i'd worked out a great pair programming workflow with voidspace and now he's gone and got sick :-(
[08:24] <wallyworld_> you'll just have to do it with yourself
[08:24]  * wallyworld_ has never tried pair programming over irc before
[08:25] <rogpeppe> wallyworld_: google hangouts, each person with two screens, each sharing their own screen
[08:25] <rogpeppe> wallyworld_: and each with their own branch; you constantly push to your own branch and merge the other person's
[08:26] <rogpeppe> wallyworld_: makes it very easy to move concurrently on micro-tasks, which seemed to be working very well
[08:27] <rogpeppe> it wouldn't work well on every kind of task though
[08:28] <dimitern> rogpeppe, have you tried termbeamer or tmate for console sharing ?
[08:32] <wallyworld_> sounds like a good workflow for sure
[08:38] <rogpeppe> dimitern: it wouldn't work great for me, as i don't use a terminal emulator
[08:38] <dimitern> rogpeppe, oh, acme, right
[08:39] <rogpeppe> dimitern: or any other editor that's not rooted in the 1970s :-)
[08:39] <dimitern> rogpeppe, yeah :), well emacs is from 1970s too
[08:40] <rogpeppe> dimitern: indeed so
[08:40] <rogpeppe> dimitern: well, written in the '80s i think
[08:42] <rogpeppe> dimitern: no, it seems it really did originate in the '70s
[08:43] <dimitern> rogpeppe, 1976 is the first version
[08:44] <rogpeppe> dimitern: i'd appreciate it if you could review this (some new API additions and client refactoring): https://codereview.appspot.com/78890043/
[08:47] <dimitern> rogpeppe, sure, looking
[08:48] <rogpeppe> dimitern: ta!
[09:00] <rogpeppe> jam1: 1-1 ?
[09:01] <jam> rogpeppe: brt, switching machines, taking the dog outside
[09:01] <rogpeppe> jam: k
[09:03] <dimitern> jam, how's the dog doing? :)
[09:04] <jam1> dimitern: pretty good, but I can't quite leave her by herself downstairs while I'm upstairs on the phone call
[09:05] <dimitern> :)
[09:07] <jam1> she knows to not pee inside, but I can't quite trust that I'll notice she needs to go out in time.
[09:16] <dimitern> rogpeppe, reviewed
[09:43] <rogpeppe> dimitern: "Why using a const only here? I'd pick one - always use a const for a facade name or never."
[09:44] <rogpeppe> dimitern: which places are you looking at that that aren't using a const for the facade name?
[09:44] <dimitern> rogpeppe, deployer i think
[09:45] <rogpeppe> dimitern: actually, there are quite a few. i'd decided that i wasn't going to change all of them, because it makes the CL even bigger.
[09:45] <rogpeppe> dimitern: i think some consolidation in a subsequent CL might be appropriate
[09:55] <dimitern> rogpeppe, i'm fine with that
[09:59] <mgz> morning all
[10:00] <dimitern> morning mgz
[10:00] <wwitzel3> hello
[10:02] <jam1> morning mgz
[10:02] <dimitern> mgz, you have LGTM on your networks-in-state branch
[10:02] <mgz> dimitern: ta
[10:06] <mgz> dimitern: I'll land that and do follow up fast with test and the function params change
[10:06] <dimitern> mgz, cheers!
[10:20] <wwitzel3> axw: nice job figuring out bug 1294776, I was able to reproduce it finally making that change to my environments.yaml
[10:20] <_mup_> Bug #1294776: No debug-log with MAAS, 14.04 and juju-core 1.17.5 <logging> <regression> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1294776>
[10:26] <axw> wwitzel3: cool. sorry for stealing all your bugs - I just stumbled across this one
[10:26] <wwitzel3> axw: no it is great, I couldn't even reproduce it, didn't even think to edit the yaml file.
[10:33] <fwereade> mgz, dimitern: were there more tests on that branch that I didn't see?
[10:37] <dimitern> fwereade, what tests?
[10:37] <fwereade> dimitern, unit tests for services without network docs
[10:38] <dimitern> fwereade, good point - mgz could add these in the follow-up changing AddService perhaps?
[10:38] <dimitern> mgz, you could do this by adding a service document in state directly and then fetch it with the state public methods
[10:39] <fwereade> dimitern, mgz: they're only necessary once there are clients that actually ask for the networks, I guess
[10:39] <fwereade> dimitern, mgz: they're not optional but I guess they don't have to land with that branch
[10:42] <dimitern> fwereade, +1
[10:43] <dimitern> mgz, take a look at state/compat_test.go:TestEnvironAssertAlive for an example how to add something directly bypassing the public state methods
[10:45] <dimitern> mgz, fwereade, jam1, rogpeppe, wallyworld_, standup?
[10:46] <dimitern> vladk, ^^
[10:46] <mgz> fwereade: I am missing the test you said, but I do know how to write it and will include it in the followup
[10:47] <fwereade> mgz, great, tyvm
[10:47] <jam1> fwereade: so landing that bit of code was blocking dimitern getting the next step done, so I said to go ahead and land it, and we can fix in post
[10:47] <jam1> fwereade: standup ?
[10:47] <fwereade> jam1, np, it's safe until that method has a client
[10:47] <jam1> :)
[10:48] <fwereade> jam1, hangouts are being difficult, will join as soon as I can
[10:48] <jam1> fwereade: np, we'll start without you
[12:10] <axw> fwereade: re "Taking DG into account when choosing pre-existing instances" - I wasn't planning on doing that until I get to ec2 AZs, is that okay?
[12:11] <axw> i.e. I'd implement Azure AS support first without it
[12:11] <axw> oh wait
[12:12] <axw> I think we did agree on using it for Azure too... it would just always say create me a new machine
[12:21] <axw> rogpeppe: can you please take a quick look over https://codereview.appspot.com/75250043/patch/100001/110003 ?
[12:21] <rogpeppe> axw: looking
[12:22] <rogpeppe> axw: what's the ManagerMachines call actually used for?
[12:23] <axw> rogpeppe: for grouping manager machines into an availability set
[12:23] <axw> or spreading across availability zones
[12:23] <rogpeppe> axw: manager instances. presumably?
[12:23] <axw> rogpeppe: we need to know where the existing ones
[12:23] <axw> rogpeppe: yep
[12:24] <axw> rogpeppe: this is to avoid AllMachines + IsManager for each, which isn't so scalable
[12:25] <rogpeppe> axw: axw: so... i've recently added an APIHostPorts call, which gets information on the API addresses of the current state servers.
[12:26] <rogpeppe> axw: but i've realised that
[12:26] <rogpeppe> axw: i think i want the instance ids in there too
[12:26] <rogpeppe> axw: so istm that perhaps that info is pretty much what you need
[12:26] <rogpeppe> axw: and it would save you an O(n) scan through the machines
[12:27] <axw> rogpeppe: the code that uses ManagerMachines does different things depending on the input entity - so I really don't want to use another API
[12:27] <axw> rogpeppe: or is it another method on state?
[12:27] <rogpeppe> axw: it's another method on state
[12:27] <axw> ah ok
[12:27] <rogpeppe> axw: but...
[12:28] <rogpeppe> axw: yeah, i think it could work actually
[12:29] <axw> rogpeppe: that sounds fine, I will change over to using that before I land then
[12:29] <axw> rogpeppe: thanks
[12:30] <axw> rogpeppe: will you be adding instance IDs for HA stuff, or will I need to do that?
[12:30] <rogpeppe> axw: how about we have a call that returns []struct {InstanceId instance.Id; APIHostPorts []instance.HostPort; StateHostPorts []instance.HostPort} ?
[12:30] <rogpeppe> axw: hmm, there might be an issue actually
[12:30] <rogpeppe> axw: because the address info isn't set immediately
[12:31] <axw> ah, yeah, that would be a problem
[12:31] <rogpeppe> axw: but presumably you need to know immediately what instance ids correspond to state servers
[12:31] <axw> rogpeppe: yep
[12:34] <rogpeppe> axw: ok. but, i just realised - i think you can use the existing StateServerInfo call as is
[12:34]  * axw looks
[12:36] <axw> rogpeppe: heh yeah, looks like it. thanks :)
[12:36] <axw> bbl, I'll have abetter look later
[12:40] <wwitzel3> natefinch: you around?
[12:40] <jam1> wwitzel3: he just said he had to go deal with kids for a bit
[12:41] <wwitzel3> jam1: thanks
[12:50] <fwereade> axw, that's fine
[12:50] <fwereade> axw, I'm just obsessively reminding you that it's part of the stream of work :)
[12:51] <axw> rogpeppe: it does require additional state.Machine() calls for each... but I suppose that's not so bad, since there can only be 7 state servers max
[12:51] <axw> fwereade: cool
[12:52] <rogpeppe> axw: i wonder if it might be nice to add a State.Machines(ids []string) ([]*Machine, error) call
[13:06] <axw> rogpeppe: maybe, though I'm less inclined to expand state now that I know the upper bound is so small
[13:06] <rogpeppe> axw: yeah
[13:07] <bodie_> morning all
[13:07] <rogpeppe> bodie_: hiya
[13:30] <natefinch> wwitzel3: back now
[13:31] <wwitzel3> natefinch: k
[13:48] <dimitern> rogpeppe, mgz, fwereade, a quick review? machine networks in state https://codereview.appspot.com/79250044
[13:49] <rogpeppe> dimitern: in a little bit
[13:49] <dimitern> rogpeppe, ta
[13:56] <natefinch> dimitern, rogpeppe, fwereade: how do we log into the mongo db for localhost?  Is it special?  I swear just using the SSL key on AWS worked, but I can't get it to work on local
[13:56] <fwereade> dimitern, I'm having some difficulty
[13:56] <mgz> dimitern: looking
[13:56] <fwereade> dimitern, Machine.Networks calls readNetworks
[13:56] <rogpeppe> natefinch: there are two levels of authentication
[13:56] <fwereade> dimitern, which NotFounds if the doc is not there
[13:56] <fwereade> dimitern, right?
[13:57] <fwereade> dimitern, but the tests imply that doesn't happen
[13:57] <rogpeppe> natefinch: i'm not sure what you mean by the ssl key though
[13:57] <fwereade> dimitern, I am 100% for returning {no networks, no error} if the doc is not there
[13:57] <fwereade> dimitern, but I don't see where that's tested
[13:58] <rogpeppe> pwd
[13:58] <dimitern> fwereade, right
[13:58] <dimitern> fwereade, the doc is always created
[13:58] <mgz> dimitern: I'm not sure about the past tense for those variable names
[13:58] <dimitern> fwereade, at machine creation time
[13:58] <fwereade> dimitern, in upgraded environments that didn't happen
[13:58] <dimitern> mgz, we should pick one and use it throughout
[13:58] <fwereade> dimitern, we need tests for that behaviour on machine and service
[13:58] <mgz> fwereade: yeah, that's on my plate
[13:58] <dimitern> fwereade, will add them, ok
[13:59] <natefinch> rogpeppe: I had thought the SSLPEMKeyFile was for authorization, but now that I reread it, I guess it's probably not
[13:59] <fwereade> dimitern, mgz: only one of you needs to do it -- would be ideal for dimitern to since he consolidates the fields
[13:59] <mgz> okay
[13:59] <fwereade> er funcs
[13:59] <fwereade> dimitern, ok?
[14:00] <dimitern> fwereade, will do
[14:00] <fwereade> dimitern, <3
[14:15] <rogpeppe> dimitern: further state/api changes, as suggested by yourself: https://codereview.appspot.com/79470043/
[14:15]  * rogpeppe needs some lunch
[14:29] <rogpeppe> natefinch: how are you getting on? shall i come and join you?
[14:29] <mgz> does he get to share your lunch? :)
[14:30] <rogpeppe> mgz: nae chance
[14:30] <rogpeppe> not that he would like it anyway, i reckon
[14:32] <natefinch> rogpeppe: heh.  I like most things. What are you having?   Also, I think we're doing ok right now... it looks like part of the problem is that for replica sets you're supposed to use --keyfile instead of --auth for authentication (according to mongo's docs)
[14:32] <rogpeppe> natefinch: you have to use both
[14:32] <dimitern> rogpeppe, LGTM
[14:32] <rogpeppe> dimitern: ta
[14:33] <natefinch> rogpeppe: you're welcome to join us.  The docs say --keyfile implies --auth, so I guess it is using both.
[14:33] <natefinch> rogpeppe: https://plus.google.com/hangouts/_/76cpjfeph92ud9qfcn92ant4io?hl=en
[14:34] <rogpeppe> natefinch: thickly sliced wholemeal bread, oliver oil, encona chilli sauce, extra mature cheddar, sliced tomatoes, as a sandwich
[14:34] <natefinch> rogpeppe: that sounds awesome
[15:42] <dimitern> fwereade, mgz, next in line - networks in status (via api server) https://codereview.appspot.com/76400049
[15:43] <dimitern> fwereade, can you please expand on https://codereview.appspot.com/79250044/diff/1/state/networks.go#oldcode17 I'm not sure I follow you
[15:46] <fwereade> dimitern, so, those docs will be stored in mongo with {"networkstoinclude": [blah, blah], "networkstoexclude": [blah, blah]}
[15:46] <fwereade> dimitern, and all those field names will be in every document
[15:46] <dimitern> fwereade, so how about `bson:"included"` and `bson:"excluded"` ?
[15:47] <mgz> dimitern: will look
[15:47] <fwereade> dimitern, and while I wouldn't normally be one to jealously count every byte... -- yeah, that's perfect
[15:47] <dimitern> fwereade, ok, will do
[15:47] <fwereade> dimitern, I don't think we want those machine networks in status
[15:48] <fwereade> dimitern, similarly to how we don't have machine constraints in status
[15:48] <fwereade> dimitern, we'll want the networks the machine is actually on in reality, but we only know that post-provisioning
[15:48] <fwereade> dimitern, we do want included/excluded networks in *service* status though
[15:49] <dimitern> fwereade, well, the card was about machines
[15:49] <fwereade> dimitern, so, we do want to show machine networks
[15:49] <fwereade> dimitern, but not those networks
[15:49] <dimitern> fwereade, and we don't have a similar card for services
[15:50] <dimitern> fwereade, so what then?
[15:50] <fwereade> dimitern, those are the requested networks (like constraints) and we want to show the actual ones (like hardware characteristics)
[15:50] <dimitern> fwereade, a separate couple of fields on machineDoc the provisioner sets?
[15:50] <fwereade> dimitern, I think we decided it'd be the machiner facade
[15:51] <fwereade> dimitern, er *not* the machiner facade
[15:51] <fwereade> dimitern, but somemachine-agent-specific one
[15:51] <fwereade> dimitern, ie the machine agent comes up and asks the state server what networks it should set up
[15:51] <fwereade> dimitern, the state server asks the provider what vlans are there, and caches that info on the machine in state somehow
[15:52] <fwereade> dimitern, (*probably* another little document rather than tacking it onto the machine, usual forces still apply there)
[15:52] <dimitern> fwereade, ok then, so we need to talk about this some more tomorrow
[15:52] <fwereade> dimitern, the impact of that is (1) the machine agent sets up the desired networks
[15:52] <dimitern> fwereade, i'll finish the rest today
[15:52] <fwereade> dimitern, and (2) those networks are stored in state ready to be included in status
[15:53] <fwereade> dimitern, if you would do exactly that CL for the service status, though, I would be happy
[15:53] <fwereade> dimitern, if it needs a card, add one, sorry we missed it before
[15:54] <hatch> in juju-core trunk are there any known bugs with ec2 `juju add-machine --series saucy`?
[15:54] <hatch> it's been sitting as 'pending' in `juju status` for a good 15 minutes now
[15:55] <dimitern> fwereade, adding one now
[15:55] <hatch> which is long even for ec2 to provision a new instance :)
[15:57] <fwereade> hatch, not aware of any -- anything in machine-0.log?
[15:57] <fwereade> hatch, (does the machine have an instance id in status?)
[15:58] <hatch>   "2":
[15:58] <hatch>     instance-id: pending
[15:58] <hatch>     series: saucy
[15:58] <hatch> nope
[15:58] <hatch> just checking the log now
[15:58] <fwereade> hatch, cheers
[15:59] <hatch> fwereade the messages from around when I provisioned the machine https://gist.github.com/hatched/3ef622f05e1a1b1249c4
[16:00] <fwereade> hatch, and messages with "provisioner" in them?
[16:00] <fwereade> hatch, they might only trigger a bit after you added the machine
[16:01] <fwereade> hatch, (I only see 5 lines there)
[16:02] <hatch> updated with a bunch of lines which were just dumped out
[16:03] <hatch> it dumped pages and pages of those errors
[16:04] <hatch> updated again
[16:04] <hatch> this is using fresh trunk
[16:04] <hatch> a fresh
[16:04] <hatch> on precise
[16:08] <jamespage> sinzui, got ack for 1.17.6 for upload - building now
[16:09] <sinzui> jamespage, thank you for warning
[16:15] <rogpeppe> is juju --upload-tools currently working?
[16:15] <rogpeppe> i'm failing to bootstrap under ec2 using --upload-tools
[16:16] <hatch> rogpeppe I just did that using the most recent trunk
[16:16] <hatch> on ec2
[16:16] <rogpeppe> i'm seeing a "error: flag provided but not defined: --instance-id"
[16:16] <rogpeppe> hatch: and it worked?
[16:17] <hatch> yeah - add-machine didn't
[16:17] <hatch> but normal deploying did
[16:22] <dimitern> fwereade, updated https://codereview.appspot.com/79250044/ as suggested
[16:23] <dimitern> fwereade, in order to change https://codereview.appspot.com/76400049 to report service networks I need mgz's follow-up branch that changes AddService with networks
[16:26]  * dimitern is done for today (but can appear again a bit later)
[16:35] <mgz> dimitern: recorded my naming thingies on the review, fwereade may have thoughts on both my concerns
[16:40] <mgz> fwereade: I'm very tempted to have a shared juju struct which bundles the (includeNetworks, excludeNetworks []string) stuff for passing around, is there any reason to not do that? we'll need like.. three (one state, one api, one internal) which is a bit suck, but we actually do have three copies now
[16:41] <fwereade> mgz, I am implacably opposed to having the same struct definitions for internal state documents as we use to express them across packages
[16:41] <mgz> fwereade: indeed. and we need clean ones for the api too.
[16:41] <fwereade> mgz, agreed
[16:41] <mgz> the question is, do we want another one for passing around.
[16:41] <fwereade> mgz, same forces apply
[16:42] <fwereade> mgz, let me reread, I may have misunderstood
[16:42] <fwereade> mgz, for mild entertainment you can read http://thecodelesscode.com/case/97 while I do
[16:42] <mgz> I shall :)
[16:43] <fwereade> mgz, yes, a struct instead of an implied tuple would make for a nicer state package interface
[16:43] <fwereade> mgz, I think I'm +1
[16:43] <mgz> fwereade: where should I place such a beast?
[16:43] <fwereade> mgz, I think that would go in the state package
[16:43] <fwereade> mgz, eg consider Jobs
[16:44] <mgz> with horacio, we stuck one in... environ or somewhere, just because we needed it and could factor it out later
[16:44] <fwereade> mgz, state methods take/return state.Jobs, api bits take/return params.Jobs
[16:44] <fwereade> mgz, I think?
[16:47] <mgz> I think it would need to be outside state, in instance or something, if I want to reuse the same one for the StartInstanceParams member
[16:54] <fwereade> mgz, that may well make more sense
[16:54] <fwereade> mgz, putting the one that's passed around into the package it best fits with
[16:54] <mgz> (case 71 is still my favourite, I always forget one part of it or other)
[17:29] <rogpeppe> fwereade: FWIW i'm not convinced that http://thecodelesscode.com/case/97 is directly relevant in our case. we're not talking about a coincidental similarity, but two things that really are the same. they *can* be different (and that's something that can change at a later date) but i'm not sure it's really helpful to say that they *must* always be different.
[17:32] <rogpeppe> taken to its logical extreme, we wouldn't export *any* types with marshalling methods from any package
[18:07] <sinzui> natefinch, Do you have any insights with this bug? https://bugs.launchpad.net/juju-core/+bug/1296870
[18:07] <_mup_> Bug #1296870: bootstrap exits before deploy is supported on local provider <bootstrap> <deploy> <local-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1296870>
[18:07] <sinzui> I probably need to talk with jam or thumper
[18:10] <natefinch> sinzui: yeah, I don't know about that one
[18:10] <sinzui> thank you for looking natefinch
[18:11] <natefinch> sinzui: sorry I couldn't be more help.  I know there's been some work going on with the local provider, axw might have some idea, too
[19:40] <natefinch> morning thumper
[19:40] <thumper> o/
[19:40] <natefinch> o_
[19:41] <natefinch> (can't lift my arms today.... worked out for the first time in 20-ish months yesterday)
[19:50] <thumper> haha
[19:50] <thumper> I'm covered in small stab wounds
[19:50] <thumper> cut the holly hedge yesterday
[19:54] <natefinch> thumper: ouch.  That's why I want to rip out our holly :)
[19:54] <thumper> I want to rip out ours too
[21:06] <thumper> mramm: you around?
[21:06] <mramm> yep
[21:20] <sinzui> thumper, I would like your opinion of bug 1296870
[21:20] <thumper> sinzui: otp, with you soonish
[21:35] <rogpeppe> thumper: would you be around for a brief chat?
[21:36] <rogpeppe> unless... fwereade, are you around?
[21:37] <wwitzel3> rogpeppe: you still messing with the HA stuff?
[21:37] <rogpeppe> wwitzel3: yeah
[21:38] <rogpeppe> wwitzel3: i'm still in the hangout if you wanna join me https://plus.google.com/hangouts/_/76cpjfeph92ud9qfcn92ant4io?hl=en
[21:38] <thumper> rogpeppe: yeah, I'm here
[21:38] <thumper> whazzup?
[21:38] <rogpeppe> thumper: just realised something unfortunate, not sure what we should do about it
[21:38] <thumper> shall I join the hangout?
[22:16] <rogpeppe> thumper: that seems to work
[22:16] <thumper> awesome
[22:17] <fwereade> rogpeppe, thumper: it's lovely to pop online to discover a serious problem has just been fixed
[22:17]  * fwereade hopes he drew correct inferences from the above
[22:17] <hazmat> thumper, strange one.. juju run returned denied on ssh but juju ssh and normal ssh run fine.. any suggestions.. http://pastebin.ubuntu.com/7148527/
[22:18]  * thumper looks
[22:18] <rogpeppe> fwereade: not fixed, but we've at least worked out a reasonable place to insert the required horrible hack
[22:18] <thumper> hazmat: old environment?
[22:18] <thumper> hazmat: could per perm denied on the fslock file
[22:18] <rogpeppe> fwereade: the problem being that currently no agents aren't added as users to the mongo admin database
[22:18] <fwereade> rogpeppe, it sounds like that still qualified as good news
[22:18] <fwereade> rogpeppe, they're all still added?
[22:18] <rogpeppe> s/aren't/are/
[22:19] <thumper> hazmat: local provier?
[22:19] <fwereade> rogpeppe, oh -- none *are*?
[22:19] <hazmat> thumper, manual with lxc host saucy, trusty containers.. futex(0x17e4318, FUTEX_WAIT, 0, {1, 999996635}Permission denied (publickey). is what i see of out of strace
[22:19] <rogpeppe> fwereade: no, they're not, but they need to be (well, state servers only, of course)
[22:19] <fwereade> rogpeppe, right, ok, understood
[22:19] <rogpeppe> fwereade: because without admin access, you can't access the replica set info
[22:19] <hazmat> thumper, other machines in the env are fine..
[22:20] <fwereade> rogpeppe, yep, indeed
[22:20] <thumper> hazmat: just machine 0?
[22:20] <thumper> probably is a fslock thing...
[22:20] <hazmat> thumper, which fslock ? yes just machine 0..
[22:20] <thumper> permissions on /var/lib/juju/locs?
[22:20] <thumper> permissions on /var/lib/juju/locks
[22:20] <rogpeppe> fwereade: so the horrible hack is to temporarily run mongo in non-auth mode (listening on localhost only) so we can add the required admin access for machine-0
[22:20] <hazmat> thumper, those look fine.. dir owned by ubuntu
[22:20] <thumper> hmm...
[22:21] <rogpeppe> fwereade: there are alternatives, but they all seem worse to me
[22:21] <thumper> hazmat: yes, very weird...
[22:21] <thumper> hazmat: juju run uses the system identity
[22:21] <thumper> hazmat: so not a local ssh
[22:21] <thumper> perhaps something missing there...
[22:22] <fwereade> rogpeppe, yeah, sounds tolerable :)
[22:22] <thumper> hazmat: check the authorized keys for the ubuntu user on machine 0
[22:23] <hazmat> thumper, bingo.. machine log 2014-03-24 22:22:44 ERROR juju runner.go:220 worker: exited "authenticationworker": adding current Juju keys to ssh authorised keys: cannot add ssh key without comment
[22:24] <hazmat> manually added the juju_home/ssh client key.. and removed the key that was causing issue (one with no comment), and it works
[22:31] <thumper> hazmat: is it a bug of ours?
[22:39] <waigani_> InstanceBroker.StopInstances appears to stop instances, not destroy them. InstanceBroker.StartInstances appears to create instances, not start stopped ones. Is this correct?
[22:40] <hazmat> thumper, not sure
[22:41] <thumper> waigani_: not quite
[22:43] <thumper> waigani_: now I remember why we had the methods the same way
[22:43] <thumper> waigani_: the instance broker interface defines talking to cloud instances
[22:43] <thumper> start instance -> create and start
[22:43] <thumper> stop isntance -> stop and destroy
[22:43] <thumper> very much like what the container manager does
[22:43] <waigani_> and now we want to split that up into four methods
[22:44] <thumper> waigani_: not the InstanceBroker no
[22:44] <thumper> just the container manager
[22:44] <thumper> InstanceBroker is unchanged
[22:44] <thumper> just the container manager changes here
[22:44] <waigani_> okay, so how do we make the container manager consitant with the InstanceBroker?
[22:44] <thumper> we don't
[22:44] <waigani_> I think fwereade wants us to
[22:44] <thumper> there is a kvm-broker and lxc-broker in the worker/provisioner code
[22:45] <thumper> it is the mapping
[22:45] <thumper> no he doesn't
[22:45] <thumper> he just might not realize yet
[22:45] <waigani_> lol
[22:45] <thumper> and that is fine
[22:45] <fwereade> thumper, waigani_: I look forward to my education
[22:45] <thumper> fwereade: np
[22:45] <thumper> fwereade: go to sleep
[22:45]  * thumper goes to the gym to hit things
[22:45] <thumper> I always feel better after the gym
[23:23]  * rogpeppe finally finishes
[23:24]  * davecheney applauds