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:54 |
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:58 |
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 | 00:59 |
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:03 |
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:05 |
* davecheney goes spelunking for log files | 01:06 | |
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:07 |
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:14 |
davecheney | ok, here is theprobme | 01:16 |
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:17 |
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:18 |
axw | :\ | 01:19 |
axw | is someone working on a patch to mongo? | 01:19 |
* davecheney looks | 01:20 | |
davecheney | ill go an ask in #ibm | 01:20 |
axw | seems kinda important | 01:21 |
davecheney | no thumper ? | 01:21 |
* axw shrugs | 01:22 | |
=== Guest84660 is now known as bodie_ | ||
wallyworld | tim is away today - public holiday | 01:25 |
davecheney | (╯°□°)╯︵ ┻━┻ | 01:27 |
axw | wallyworld: it'll be a lonely standup - got anything to talk about? | 01:31 |
wallyworld | axw: touch base on that upstart logging thing? | 01:32 |
axw | wallyworld: sure | 01:32 |
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:09 | |
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:10 |
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:11 |
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:15 |
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:57 |
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:58 |
davecheney | that change is a signficant improvement | 02:59 |
wallyworld | np, thanks, i'll read the comments and see if i can improve things | 02:59 |
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:00 |
wallyworld | it's meant as a visual aide to reading the code | 03:01 |
davecheney | feel free to ignore that suggestion | 03:01 |
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:09 |
jam1 | I see the holiday on the calendar now. | 04:11 |
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:12 |
jam1 | axw: your @canonical account can add and modify things in the calendar now | 04:13 |
axw | cool, ta | 04:13 |
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:15 |
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:16 |
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:49 |
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:50 |
axw | davecheney: I don't think so, the local provider makes assumptions that it's bootstrapping tools with version.Current with buildnumber++, IIRC | 04:52 |
davecheney | fairy nuf | 04: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:53 |
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:54 |
jam | axw: I'll bootstrap and then poke machine-0 real quick | 05:56 |
axw | thanks | 05:56 |
davecheney | how the FUCK do I godeps | 06:06 |
davecheney | fucking every time have to fight with this tool | 06:07 |
davecheney | why is the head of launchpad/golxc broken ?!? | 06:07 |
axw | davecheney: godeps -u dependencies.tsv | 06:08 |
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:09 |
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:10 |
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:11 |
wallyworld_ | looking | 06:12 |
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:17 |
axw | wallyworld_: I did at a test... was there something in particular you think was worth testing? | 06:25 |
=== vladk|offline is now known as vladk | ||
wallyworld_ | axw: ah sorry, totally missed it. | 06:26 |
axw | nps | 06:27 |
wallyworld_ | i could have sworn i looked at allt he files | 06:27 |
axw | wallyworld_: good to land then? | 06:28 |
wallyworld_ | axw: sorry, went to pick up kid. yeah | 06:52 |
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? | 06:53 |
=== vladk is now known as vladk|offline | ||
=== vladk|offline is now known as vladk | ||
=== vladk is now known as vladk|offline | ||
axw | wallyworld_: there are some cases where it's necessary to destroy-env --force, but there's no change there | 07:17 |
axw | can't remove them if you're not root | 07:18 |
wallyworld_ | ok | 07:19 |
wallyworld_ | just thining out loud | 07:19 |
dimitern | morning jam, 1-1 ? | 07:31 |
=== vladk|offline is now known as vladk | ||
vladk | good morning | 07:57 |
rogpeppe | mornin' all | 08:01 |
rogpeppe | vladk, dimitern, wallyworld_, axw, jam: hiya | 08:01 |
vladk | rogpeppe: hello | 08:01 |
jam1 | morning vlad, rogpeppe | 08:02 |
axw | rogpeppe: morning | 08:02 |
axw | and vladk | 08:02 |
dimitern | rogpeppe, hey | 08:12 |
dimitern | morning vladk | 08:13 |
vladk | dimitern: morning | 08:13 |
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:22 |
* wallyworld_ is about to eat dinner sorry | 08:23 | |
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:24 | |
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:25 |
rogpeppe | wallyworld_: makes it very easy to move concurrently on micro-tasks, which seemed to be working very well | 08:26 |
rogpeppe | it wouldn't work well on every kind of task though | 08:27 |
dimitern | rogpeppe, have you tried termbeamer or tmate for console sharing ? | 08:28 |
wallyworld_ | sounds like a good workflow for sure | 08:32 |
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:38 |
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:39 |
rogpeppe | dimitern: indeed so | 08:40 |
rogpeppe | dimitern: well, written in the '80s i think | 08:40 |
rogpeppe | dimitern: no, it seems it really did originate in the '70s | 08:42 |
dimitern | rogpeppe, 1976 is the first version | 08:43 |
rogpeppe | dimitern: i'd appreciate it if you could review this (some new API additions and client refactoring): https://codereview.appspot.com/78890043/ | 08:44 |
dimitern | rogpeppe, sure, looking | 08:47 |
rogpeppe | dimitern: ta! | 08:48 |
rogpeppe | jam1: 1-1 ? | 09:00 |
jam | rogpeppe: brt, switching machines, taking the dog outside | 09:01 |
rogpeppe | jam: k | 09:01 |
dimitern | jam, how's the dog doing? :) | 09:03 |
jam1 | dimitern: pretty good, but I can't quite leave her by herself downstairs while I'm upstairs on the phone call | 09:04 |
dimitern | :) | 09:05 |
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:07 |
dimitern | rogpeppe, reviewed | 09:16 |
rogpeppe | dimitern: "Why using a const only here? I'd pick one - always use a const for a facade name or never." | 09:43 |
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:44 |
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:45 |
dimitern | rogpeppe, i'm fine with that | 09:55 |
mgz | morning all | 09:59 |
dimitern | morning mgz | 10:00 |
wwitzel3 | hello | 10:00 |
jam1 | morning mgz | 10:02 |
dimitern | mgz, you have LGTM on your networks-in-state branch | 10:02 |
mgz | dimitern: ta | 10:02 |
mgz | dimitern: I'll land that and do follow up fast with test and the function params change | 10:06 |
dimitern | mgz, cheers! | 10:06 |
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:20 |
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:26 |
fwereade | mgz, dimitern: were there more tests on that branch that I didn't see? | 10:33 |
dimitern | fwereade, what tests? | 10:37 |
fwereade | dimitern, unit tests for services without network docs | 10:37 |
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:38 |
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:39 |
dimitern | fwereade, +1 | 10:42 |
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:43 |
dimitern | mgz, fwereade, jam1, rogpeppe, wallyworld_, standup? | 10:45 |
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:46 |
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:47 |
fwereade | jam1, hangouts are being difficult, will join as soon as I can | 10:48 |
jam1 | fwereade: np, we'll start without you | 10:48 |
=== dimitern is now known as dimitern|lunch | ||
=== vladk is now known as vladk|lunch | ||
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:10 |
axw | i.e. I'd implement Azure AS support first without it | 12:11 |
axw | oh wait | 12:11 |
axw | I think we did agree on using it for Azure too... it would just always say create me a new machine | 12:12 |
=== dimitern|lunch is now known as dimitern | ||
axw | rogpeppe: can you please take a quick look over https://codereview.appspot.com/75250043/patch/100001/110003 ? | 12:21 |
rogpeppe | axw: looking | 12:21 |
rogpeppe | axw: what's the ManagerMachines call actually used for? | 12:22 |
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:23 |
axw | rogpeppe: this is to avoid AllMachines + IsManager for each, which isn't so scalable | 12:24 |
rogpeppe | axw: axw: so... i've recently added an APIHostPorts call, which gets information on the API addresses of the current state servers. | 12:25 |
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:26 |
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:27 |
rogpeppe | axw: yeah, i think it could work actually | 12:28 |
axw | rogpeppe: that sounds fine, I will change over to using that before I land then | 12:29 |
axw | rogpeppe: thanks | 12:29 |
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:30 |
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:31 |
rogpeppe | axw: ok. but, i just realised - i think you can use the existing StateServerInfo call as is | 12:34 |
* axw looks | 12:34 | |
=== vladk|lunch is now known as vladk | ||
axw | rogpeppe: heh yeah, looks like it. thanks :) | 12:36 |
axw | bbl, I'll have abetter look later | 12:36 |
wwitzel3 | natefinch: you around? | 12:40 |
jam1 | wwitzel3: he just said he had to go deal with kids for a bit | 12:40 |
wwitzel3 | jam1: thanks | 12:41 |
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:50 |
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:51 |
rogpeppe | axw: i wonder if it might be nice to add a State.Machines(ids []string) ([]*Machine, error) call | 12:52 |
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:06 |
bodie_ | morning all | 13:07 |
rogpeppe | bodie_: hiya | 13:07 |
natefinch | wwitzel3: back now | 13:30 |
wwitzel3 | natefinch: k | 13:31 |
dimitern | rogpeppe, mgz, fwereade, a quick review? machine networks in state https://codereview.appspot.com/79250044 | 13:48 |
rogpeppe | dimitern: in a little bit | 13:49 |
dimitern | rogpeppe, ta | 13:49 |
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:56 |
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:57 |
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:58 |
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? | 13:59 |
dimitern | fwereade, will do | 14:00 |
fwereade | dimitern, <3 | 14:00 |
rogpeppe | dimitern: further state/api changes, as suggested by yourself: https://codereview.appspot.com/79470043/ | 14:15 |
* rogpeppe needs some lunch | 14:15 | |
rogpeppe | natefinch: how are you getting on? shall i come and join you? | 14:29 |
mgz | does he get to share your lunch? :) | 14:29 |
rogpeppe | mgz: nae chance | 14:30 |
rogpeppe | not that he would like it anyway, i reckon | 14:30 |
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:32 |
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:33 |
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 | 14:34 |
=== hatch__ is now known as hatch | ||
dimitern | fwereade, mgz, next in line - networks in status (via api server) https://codereview.appspot.com/76400049 | 15:42 |
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:43 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
dimitern | fwereade, adding one now | 15:55 |
hatch | which is long even for ec2 to provision a new instance :) | 15:55 |
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:57 |
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:58 |
hatch | fwereade the messages from around when I provisioned the machine https://gist.github.com/hatched/3ef622f05e1a1b1249c4 | 15:59 |
fwereade | hatch, and messages with "provisioner" in them? | 16:00 |
fwereade | hatch, they might only trigger a bit after you added the machine | 16:00 |
fwereade | hatch, (I only see 5 lines there) | 16:01 |
hatch | updated with a bunch of lines which were just dumped out | 16:02 |
hatch | it dumped pages and pages of those errors | 16:03 |
hatch | updated again | 16:04 |
hatch | this is using fresh trunk | 16:04 |
hatch | a fresh | 16:04 |
hatch | on precise | 16:04 |
jamespage | sinzui, got ack for 1.17.6 for upload - building now | 16:08 |
sinzui | jamespage, thank you for warning | 16:09 |
rogpeppe | is juju --upload-tools currently working? | 16:15 |
rogpeppe | i'm failing to bootstrap under ec2 using --upload-tools | 16:15 |
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:16 |
hatch | yeah - add-machine didn't | 16:17 |
hatch | but normal deploying did | 16:17 |
dimitern | fwereade, updated https://codereview.appspot.com/79250044/ as suggested | 16:22 |
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:23 |
* dimitern is done for today (but can appear again a bit later) | 16:26 | |
=== teknico__ is now known as teknico | ||
mgz | dimitern: recorded my naming thingies on the review, fwereade may have thoughts on both my concerns | 16:35 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:47 |
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) | 16:54 |
=== vladk is now known as vladk|offline | ||
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:29 |
rogpeppe | taken to its logical extreme, we wouldn't export *any* types with marshalling methods from any package | 17:32 |
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:07 |
natefinch | sinzui: yeah, I don't know about that one | 18:10 |
sinzui | thank you for looking natefinch | 18:10 |
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 | 18:11 |
=== hatch__ is now known as hatch | ||
natefinch | morning thumper | 19:40 |
thumper | o/ | 19:40 |
natefinch | o_ | 19:40 |
natefinch | (can't lift my arms today.... worked out for the first time in 20-ish months yesterday) | 19:41 |
=== Ursinha is now known as Ursinha-afk | ||
thumper | haha | 19:50 |
=== Ursinha-afk is now known as Ursinha | ||
thumper | I'm covered in small stab wounds | 19:50 |
thumper | cut the holly hedge yesterday | 19:50 |
natefinch | thumper: ouch. That's why I want to rip out our holly :) | 19:54 |
thumper | I want to rip out ours too | 19:54 |
=== hatch__ is now known as hatch | ||
thumper | mramm: you around? | 21:06 |
mramm | yep | 21:06 |
sinzui | thumper, I would like your opinion of bug 1296870 | 21:20 |
thumper | sinzui: otp, with you soonish | 21:20 |
rogpeppe | thumper: would you be around for a brief chat? | 21:35 |
rogpeppe | unless... fwereade, are you around? | 21:36 |
wwitzel3 | rogpeppe: you still messing with the HA stuff? | 21:37 |
rogpeppe | wwitzel3: yeah | 21:37 |
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? | 21:38 |
rogpeppe | thumper: that seems to work | 22:16 |
thumper | awesome | 22:16 |
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:17 |
* 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:18 |
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:19 |
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:20 |
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:21 |
fwereade | rogpeppe, yeah, sounds tolerable :) | 22:22 |
thumper | hazmat: check the authorized keys for the ubuntu user on machine 0 | 22:22 |
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:23 |
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:24 |
thumper | hazmat: is it a bug of ours? | 22:31 |
waigani_ | InstanceBroker.StopInstances appears to stop instances, not destroy them. InstanceBroker.StartInstances appears to create instances, not start stopped ones. Is this correct? | 22:39 |
hazmat | thumper, not sure | 22:40 |
thumper | waigani_: not quite | 22:41 |
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:43 |
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:44 |
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 | 22:45 |
* rogpeppe finally finishes | 23:23 | |
* davecheney applauds | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!