| === hatch__ is now known as hatch | ||
| cmars | wallyworld_, i'm trying to write a standalone juju plugin (for fun & to learn) with the cmd.Command framework, connect to the state server, etc. | 00:41 |
|---|---|---|
| cmars | thing is, when i try to connect, i get error: Unable to connect to environment "foo": no registered provider for "openstack" | 00:41 |
| wallyworld_ | "for fun" | 00:42 |
| wallyworld_ | ha | 00:42 |
| cmars | :) | 00:42 |
| cmars | to scratch an itch, actually | 00:42 |
| cmars | what do i need to do to initialize those providers | 00:42 |
| wallyworld_ | you need to import from providers so the init() gets run | 00:42 |
| cmars | ah, ok | 00:42 |
| wallyworld_ | use a _ at the start | 00:42 |
| wallyworld_ | so it doesn't complain about unused imports | 00:43 |
| wallyworld_ | grep for it and you'll see where else it's done | 00:43 |
| mischief61507 | davechen1y: how hard do you think it would be to remove all use of non-portable syscall imports from juju-core/cmd/juju and its deps? :) | 00:43 |
| cmars | wallyworld_, that did the trick, thanks | 00:44 |
| wallyworld_ | np | 00:44 |
| davechen1y | mischief61507: not hard | 00:45 |
| davechen1y | mischief61507: can you raise and issue with the syscalls that are missing | 00:45 |
| davechen1y | i'm assuming its the usual TCSET/TCGET | 00:45 |
| davechen1y | ictls | 00:45 |
| mischief61507 | nono | 00:45 |
| mischief61507 | it's mainly use of nonportable signal names | 00:46 |
| mischief61507 | i would like to run juju-core/cmd/juju on plan 9 you see, and once i hacked out the references to nonportable signal names from syscall, it seemed to run ok | 00:47 |
| davechen1y | mischief61507: i'm sure we can do some kind of conditional compilatoin | 00:47 |
| mischief61507 | yea, having _unix and _plan9.go files would likely work | 00:48 |
| davechen1y | mischief61507: https://bugs.launchpad.net/juju-core/+filebug | 00:48 |
| davechen1y | if you would be so kind | 00:48 |
| sinzui | wallyworld_, Do you have an experience unfucking gobot. we have a backlog of branches that cannot merge in 1.18. | 00:59 |
| wallyworld_ | sinzui: i have and i will | 01:00 |
| wallyworld_ | sinzui: bot is running | 01:01 |
| wallyworld_ | must be something else | 01:01 |
| wallyworld_ | i'll look | 01:01 |
| wallyworld_ | it says no approved proposals for 1.18 | 01:01 |
| sinzui | wallyworld_, jhobbs and I stopped after a while | 01:02 |
| sinzui | wallyworld_, This is mine https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053 | 01:03 |
| wallyworld_ | sinzui: gotbot claims that one is not approved | 01:03 |
| sinzui | I will approve it again | 01:03 |
| sinzui | done | 01:03 |
| wallyworld_ | sinzui: and tests running | 01:04 |
| === thumper-gym is now known as thumper | ||
| sinzui | wallyworld_, gobot failed the version change to 1.18.0 again https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053 | 01:21 |
| wallyworld_ | :-( | 01:21 |
| wallyworld_ | do you need me to check anything? | 01:22 |
| wallyworld_ | hmmm. | 01:23 |
| wallyworld_ | looking at the errors, looks like it fails to upload and/or find tools | 01:23 |
| wallyworld_ | sinzui: i can look into it | 01:25 |
| waigani | thumper: juju-mongodb was installed but mongodb was not. If tests rely on mongodb, should it be added to the makefile as a dependency? | 01:52 |
| thumper | yes probably | 01:52 |
| thumper | but the real problem is that on trusty, the tests should rely on juju-mongodb | 01:52 |
| waigani | thumper: okay, as a temp patch, should I add it in? | 01:53 |
| thumper | add what where? | 01:53 |
| waigani | thumper: to the makefile - install dependencies | 01:54 |
| thumper | https://bugs.launchpad.net/juju-core/+bug/1301353 | 01:54 |
| _mup_ | Bug #1301353: juju test suite should use juju-mongodb <tech-debt> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1301353> | 01:54 |
| thumper | waigani: no | 01:54 |
| thumper | waigani: perhaps fix that bug | 01:54 |
| waigani | ah | 01:55 |
| thumper | waigani: also, there is the test to make sure that juju-mongodb is installed for the local provider prechecker | 01:55 |
| thumper | waigani: that would be a good thing to fix too | 01:55 |
| davechen1y | thumper: isn't juju-mongodb a dep of juju-local now ? | 01:56 |
| thumper | davechen1y: I believe so | 01:56 |
| thumper | davechen1y: but many people don't have juju-local installed when trying to use the local provider | 01:56 |
| thumper | we should tell them | 01:56 |
| sinzui | davechen1y, thumper. It appears NO juju users install the juju-local package | 01:57 |
| sinzui | I have had 5 complaints from canonical staff in 2 weeks alone. Juju local is broken they say. They have not installed juju-local to get the correct deps | 01:58 |
| davechen1y | sinzui: shitballs | 01:58 |
| sinzui | I amended the release note to make it clear juju-local is required https://docs.google.com/a/canonical.com/document/d/1h13ZT7dB-Ajl2MHUJA2Qt0BKGPTZq2pFXqAVKGYSinQ/edit?disco=AAAAAJTTWP8 | 01:58 |
| davechen1y | and there isn't a file path that we can hang the usual check off | 01:58 |
| davechen1y | dumb suggestion: juju-1.18 depends on juju local | 01:59 |
| davechen1y | i think that is a less worse solution that making it optional | 01:59 |
| davechen1y | actually | 01:59 |
| davechen1y | scrap that | 01:59 |
| davechen1y | i can see the complains about mongodb already | 01:59 |
| davechen1y | shit, sam left something at home | 01:59 |
| davechen1y | back in 10 mins, gotta go drop it off | 01:59 |
| sinzui | davechen1y, I think jamespage mulled that suggestion in the past. We don't want lxc on the servers in many cases, but for many people, local provider is the first env they test before sending a stack to a cloud that costs moneyh | 02:00 |
| sinzui | waigani, thumper, maybe juju shouldn't check for mongodb-server or cpu-checker or rsyslog-gnutls. Just check for juju-local. No package, then stop and demand it | 02:02 |
| * thumper nods | 02:03 | |
| waigani | okay | 02:03 |
| davechen1y | sinzui: agreed | 02:26 |
| * thumper does a little dance | 02:48 | |
| === vladk|offline is now known as vladk | ||
| davechen1y | thumper: pics or it never happened | 02:50 |
| === vladk is now known as vladk|offline | ||
| thumper | wow... I think I am finally happy with the apiserver tests for this... | 02:59 |
| * thumper just needs a pile of number eight wire | 03:06 | |
| thumper | and we can move this thing forwards | 03:06 |
| waigani | provider/local has checks for rsyslog-gnutls. Should this be replaced with a check for juju-local? | 03:19 |
| thumper | waigani: yes | 03:45 |
| thumper | axw: do you know if juju-local depends on rsyslog-gnutls? | 03:45 |
| axw | thumper: I raised a but about it a while ago, I think sinzui or jamespage did it | 03:46 |
| axw | thumper: apt-cache says yes | 03:47 |
| sinzui | thumper, It does | 03:47 |
| thumper | cool | 03:47 |
| thumper | waigani: so, yes, that is your answer | 03:47 |
| waigani | ah, this is what I've done: lp:~waigani/juju-core/1301353-mongodb-dep | 03:48 |
| waigani | just pushing it up to pull down and test on ppc vm | 03:48 |
| thumper | simple review for someone: https://codereview.appspot.com/84290045/ | 03:49 |
| === vladk|offline is now known as vladk | ||
| axw | thumper: looking | 04:04 |
| axw | thumper: how do you intend to use StartedTailing? | 04:08 |
| thumper | axw: I have it in a test where I need to wait until the back looking seeking is done | 04:08 |
| thumper | so I wait on a channel | 04:09 |
| thumper | that the StartedTailing closes | 04:09 |
| thumper | then I write more | 04:09 |
| thumper | I wish we had some form of signals and slots built into the language | 04:09 |
| thumper | that'd work too | 04:09 |
| thumper | but no | 04:09 |
| axw | you provide a ReadSeeker - why not just do it there? | 04:09 |
| axw | in the Seek() | 04:10 |
| thumper | because I don't seek | 04:10 |
| thumper | and I'm just providing it a real file | 04:10 |
| thumper | Although I think I see what you are getting at | 04:11 |
| axw | if there's no seek, fine, but otherwise you can override | 04:11 |
| axw | I don't like exposing things like this for testing | 04:11 |
| thumper | hmm... | 04:11 |
| thumper | ok | 04:11 |
| thumper | I think I just got another form of 'no reachable servers' | 04:12 |
| thumper | panic: interface conversion: interface is nil, not *websocket.Conn, home/tim/go/src/launchpad.net/juju-core/state/api/apiclient.go:140 | 04:12 |
| thumper | I'll look to see if I can rewrite the test | 04:13 |
| axw | thanks | 04:13 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| thumper | axw: ok, I got it working, but only because that test doesn't seek backwards from the end | 04:24 |
| thumper | but I guess it is sufficient | 04:24 |
| axw | thumper: cool. see my comment on the CL, let me know what you think | 04:25 |
| thumper | hmm... I really want to avoid messing around with tailer too much | 04:27 |
| thumper | ok, that's it | 04:53 |
| thumper | I'm done | 04:53 |
| thumper | night all | 04:53 |
| waigani | eod wip(am I on the right track?): https://codereview.appspot.com/84360043 | 05:01 |
| === tasdomas` is now known as tasdomas | ||
| dimitern | morning all | 06:37 |
| axw | morning dimitern | 07:13 |
| dimitern | hey axw | 07:13 |
| davechen1y | EOW => til next week gentlemen | 07:22 |
| wallyworld | fwereade: instance type constraint https://codereview.appspot.com/84310044 | 07:34 |
| wallyworld | fwereade: also, tests fixes for 1.18 https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 | 07:34 |
| fwereade | wallyworld, I'm just reviewing it, but I have to pop out for an hour shortly | 07:34 |
| fwereade | wallyworld, I'll send what I have in a mo, there's one significant thing | 07:35 |
| wallyworld | fwereade: i'm off to soccer so no hurry | 07:35 |
| wallyworld | jst wanted to let you know they were there | 07:35 |
| fwereade | wallyworld, in particular, what instance-type implies varies by provider | 07:35 |
| wallyworld | especially the 1.18 fix | 07:35 |
| wallyworld | fwereade: sure, it varies, so for ec2 you say instace-type=m1.small, for openstack something else | 07:35 |
| fwereade | wallyworld, eg in ec2 having a root-disk constraint override an inherited instance-type constraint is definitely wrong -- they're independent -- but in ec2 root-disk is part of the instance type | 07:36 |
| fwereade | wallyworld, different vocabularies== np at all, we have varying arches across clouds today | 07:36 |
| wallyworld | oh i see | 07:36 |
| fwereade | wallyworld, we have to delegate fallback handling to the providers I think | 07:36 |
| wallyworld | right, i didn't get that subtlety | 07:36 |
| fwereade | wallyworld, it might be easiest to do this by storing everythying as stacks of constraints and handing over both of those at startinstance time | 07:37 |
| fwereade | wallyworld, but that implies schema changes | 07:37 |
| wallyworld | yeah, was thinking our current approach won't work now | 07:37 |
| wallyworld | well | 07:37 |
| wallyworld | we could defer the fallback behaviour | 07:37 |
| fwereade | wallyworld, so axw/waigani's policy stuff might be the way to make those calculations at the time we do currently | 07:37 |
| wallyworld | sure, the provides can always read the env constraints as needed | 07:38 |
| fwereade | wallyworld, we could defer, but we have to capture the inputs at the same time we currently do the fallbacks | 07:38 |
| wallyworld | np, i'll take a look | 07:39 |
| wallyworld | do we have the rules documented for how to fall back? | 07:39 |
| wallyworld | for each rpovider? | 07:39 |
| fwereade | wallyworld, it's pretty much "what does an instance type imply" in this particular context | 07:39 |
| wallyworld | that's what i'm no sure of. i can read the ec2 docs | 07:40 |
| wallyworld | anyways, gotta run to soccer | 07:40 |
| fwereade | wallyworld, ec2 is potentially misleading | 07:40 |
| fwereade | wallyworld, indeed, we can chat later | 07:40 |
| wallyworld | fwereade: if you want to put a few thoughts down, drop me a line or we can chat | 07:41 |
| wallyworld | but apprt from the fallbac, i think the approavh works | 07:41 |
| wallyworld | or seems to work fine | 07:41 |
| wallyworld | code change to use the constraint itself was quite small | 07:42 |
| fwereade | wallyworld, yeah, I don't think it's devastatingly complex | 07:42 |
| fwereade | wallyworld, tyvm for this :) | 07:42 |
| wallyworld | np, we really need it | 07:42 |
| wallyworld | like last year | 07:42 |
| * fwereade winces gently | 07:43 | |
| wallyworld | fwereade: highest priority now though is the 1.18 test fix | 07:43 |
| wallyworld | to unblock the release | 07:43 |
| rogpeppe | well, at least i've got my second monitor working again now, kinda | 08:05 |
| * rogpeppe doesn't trust trusty any more | 08:05 | |
| * rogpeppe tries to work out how to use lubuntu | 08:09 | |
| rogpeppe | here's an interesting mongod failure: http://paste.ubuntu.com/7202291/ | 08:18 |
| rogpeppe | i thought that most of the replicaset test failures were due to socket address clashes, but the above makes it look like mongod crashes might also be a contributor | 08:18 |
| axw | that doesn't look great | 08:25 |
| fwereade | wallyworld, when you're back, can we talk a bit about upload-tools? as, indeed, a higher priority than the instance-type stuff | 08:26 |
| axw | rogpeppe: I managed to bootstrap local provider with natefinch's branch, with a few modifications - I added some comments to the CL | 08:27 |
| axw | EnsureMongoServer that is | 08:27 |
| rogpeppe | axw: great, thanks | 08:28 |
| voidspace | morning all | 08:42 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| rogpeppe | voidspace: morning! | 09:09 |
| === psivaa_ is now known as psivaa | ||
| dimitern | fwereade, hey, just updated https://codereview.appspot.com/83070047/ with your suggestions and I think it should be ready to land if you can take a look | 09:15 |
| fwereade | dimitern, will do | 09:15 |
| fwereade | dimitern, rogpeppe, I would appreciate thoughts on https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 -- I am concerned that disallowing upload-tools will screw customers in isolated environments -- I guess I'm behind on something here? | 09:16 |
| rogpeppe | fwereade: looking | 09:17 |
| dimitern | fwereade, so --upload-tools will be allowed only for dev versions? | 09:17 |
| ev | jcastro: you were going to add me to the regular charmers call, but either I lost the invite or never got one. When is it? | 09:28 |
| fwereade | dimitern, it looks like that's already happened but it scares me -- clients use the ehh-just-use-the-local-jujud-it's-probably-good-enough functionality in upload-tools | 09:42 |
| fwereade | dimitern, rogpeppe: do you recall when that changed? I know it's something we're working towards but I'm not sure all the other pieces to support it nicely are in place yet | 09:43 |
| fwereade | I'll ask wallyworld when he comes back :) | 09:43 |
| rogpeppe | fwereade, dimitern, voidspace, mgz, axw: i'd appreciate a review of this fairly involved test that tries to sanity-check our singular worker approach: https://codereview.appspot.com/84470043 | 09:43 |
| dimitern | rogpeppe, looking | 09:44 |
| dimitern | fwereade, oww.. | 09:44 |
| rogpeppe | fwereade: sorry, i got distracted finishing up this proposal. will really look now :-) | 09:44 |
| === vladk|offline is now known as vladk | ||
| fwereade | rogpeppe, I know the feeling | 09:44 |
| * fwereade is trying to do about three things at once | 09:45 | |
| rogpeppe | fwereade: it seems weird that upload-tools is disabled for release versions. i hadn't noticed it. | 09:45 |
| rogpeppe | fwereade: and i certainly managed to upgrade-juju with --upload-tools recently, although that was from a 1.16 environment (tho using 1.18 juju) so might not count | 09:46 |
| rogpeppe | fwereade: my thoughts are that it scares me too | 09:55 |
| fwereade | rogpeppe, I think it'll have to be a standup topic | 09:56 |
| rogpeppe | fwereade: yeah | 09:56 |
| fwereade | rogpeppe, please remind me if I forget :) | 09:56 |
| rogpeppe | fwereade: have you got a moment to discuss Ping? | 09:57 |
| fwereade | dimitern, LGTM with a couple of tweaks, ping me if anything's surprising | 09:57 |
| fwereade | rogpeppe, I expect so, which one? | 09:57 |
| fwereade | rogpeppe, the keepalive thingy? | 09:57 |
| rogpeppe | fwereade: well, as part of the singular worker stuff, we need to be able to ping the state session to make sure that mongo hasn't changed masters | 09:58 |
| perrito666 | morning everyone | 09:58 |
| rogpeppe | fwereade: for the StateWorker, that's easy because we've got access to the *state.State and thence its mgo.Session | 09:58 |
| jam | fwereade: if we disabled upload-tools, but enable the ability to use the local jujud as a simplestreams source (juju bootstrap --source=/usr/lib/juju/local-tools) ?) | 09:59 |
| jam | I don't think we can just disable it, either. | 09:59 |
| rogpeppe | fwereade: but for the APIWorker, there's no easy way, because the api Ping doesn't actually check that the underlying mgo.Session is still alive | 09:59 |
| rogpeppe | fwereade: i'm considering making api.State.Ping do a ping of the underlying mgo.Session if the connected agent is an environ manager | 09:59 |
| jam | rogpeppe: I thought you didn't need to ping mongo as we expected the connection to break and bounce the API servers | 09:59 |
| rogpeppe | jam: we have to know when the connection breaks | 10:00 |
| fwereade | rogpeppe, yeah, I thought we were relying on operations failing? | 10:00 |
| jam | fwereade: I guess the issue is that since environ-provisioner is on the other side of the API, then every API facade call should technically check IsMaster | 10:01 |
| jam | otherwise between API calls master could change... ? | 10:01 |
| rogpeppe | fwereade: we can rely on that for the master, but the secondaries need some way of knowing too | 10:01 |
| jam | though I thought we also bounce the API server which bounces the provisioner | 10:01 |
| rogpeppe | jam: we don't need to check on every call, because if isMaster changes, then the API call will fail | 10:06 |
| fwereade | rogpeppe, sorry, I'm having difficulty swapping context | 10:09 |
| rogpeppe | the problem i'm considering is: when an agent is *not* master, it doesn't run any of the singular workers, but it needs to know when the master has changed, so it can't do exactly nothing | 10:10 |
| jam | rogpeppe: don't all connections get bounced when the master changes? | 10:10 |
| rogpeppe | so i make it ping the connection periodically to make sure that the status is as before. when the ping fails, it knows the master might have changed, so it reconnects | 10:10 |
| jam | certainly replsetReconfig bounces all connections. | 10:11 |
| jam | rogpeppe: and I thought everything actually just connects to the master to do any Write operation, so it will also bounce | 10:11 |
| jam | it just needs to know if the connection is "local" | 10:11 |
| rogpeppe | jam: only if the API server is actually doing something | 10:11 |
| rogpeppe | jam: the only way we know if the master has changed is if some operation fails | 10:11 |
| rogpeppe | jam: but there might not be any operations happening. | 10:12 |
| jam | rogpeppe: so we don't notice a disconnect by itself? | 10:12 |
| rogpeppe | jam: how would we? | 10:12 |
| jam | rogpeppe: Presence pingers are very likely to be triggering all the time | 10:12 |
| jam | that writes to the Presence DB | 10:12 |
| jam | \ | 10:12 |
| jam | but if an API server didn't have any clients | 10:12 |
| jam | it would still have its own pinger? | 10:12 |
| fwereade | rogpeppe, jam: can we force state servers to connect to their own api server? would that resolve it? | 10:13 |
| rogpeppe | jam: hmm, it's possible that an agent, by virtue of being connected, has a presence pinger that will kill the connection if it dies | 10:13 |
| rogpeppe | fwereade: not really | 10:13 |
| jam | fwereade: I'm pretty sure we already do by writing "localhost" into agent.conf | 10:14 |
| fwereade | rogpeppe, jam: that'd guarantee at least one connection with a presence pinger for each state server? | 10:14 |
| rogpeppe | fwereade: hmm, i see what you're getting at. | 10:15 |
| * rogpeppe thinks | 10:15 | |
| dimitern | fwereade, cheers! | 10:17 |
| voidspace | natefinch: morning nate | 10:18 |
| natefinch | howdy-ho neighbors | 10:18 |
| rogpeppe | natefinch: hiya | 10:20 |
| wwitzel3 | hey natefinch | 10:20 |
| rogpeppe | fwereade, jam: i haven't yet found anything that would imply that a presence-pinger failure would cause an api connection teardown | 10:20 |
| rogpeppe | and we might actually have a problem, because i'm not sure that *anything* will cause the API server to fail when the state connection fails. | 10:23 |
| * rogpeppe wonders about a decent way to do that | 10:24 | |
| fwereade | rogpeppe, hmm -- yeah, looks like the pinger's just left lying around -- but it doesn't seem like it would be too bad to have a goroutine waiting for pinger failure, and using that condition to tear down the connection | 10:26 |
| natefinch | axw: thanks for all the comments on the EnsureMongoServer branch. It was tested and working last week with the local provider, but we've done some significant refactoring since then, so it's entirely possible we messed some stuff up. I'll be doing live testing today. I'll apply your suggestions as we go. | 10:26 |
| rogpeppe | fwereade: i wonder about a single goroutine started in apiserver.Server.run which periodically pings the underlying state, and if that fails, kills the Server. | 10:33 |
| fwereade | rogpeppe, that's probably cleaner | 10:33 |
| fwereade | rogpeppe, shorter chain of dependencies to get amusingly broken at surprising times | 10:33 |
| rogpeppe | fwereade: yeah | 10:34 |
| rogpeppe | fwereade: right, i'll make a ticket for it | 10:34 |
| rogpeppe | jam: does that sound reasonable to you? | 10:35 |
| dimitern | rogpeppe, reviewed | 10:43 |
| dimitern | perrito666, standup? | 10:47 |
| * perrito666 having computer problems, ill be right there | 10:47 | |
| jam | rogpeppe: sgtm | 10:51 |
| rogpeppe | jam: cool | 10:52 |
| rogpeppe | jam: standup? | 10:52 |
| jam | rogpeppe: not working today :) | 10:52 |
| jam | "not" working | 10:52 |
| rogpeppe | jam: ah, of course. what are you doing here then? :-) | 10:52 |
| jam | rogpeppe: "not" working, certainly | 10:52 |
| natefinch | he just misses us | 10:53 |
| wwitzel3 | jam: lol | 10:53 |
| perrito666 | question, how many lgtms I need on this to merge it? https://codereview.appspot.com/82280045 | 11:07 |
| rogpeppe | perrito666: just one, assuming you're happy with the reviewer's knowledge of the code | 11:09 |
| perrito666 | rogpeppe: I think you wrote the code originally :) so yours woud be appreciated, you will find it really really short | 11:11 |
| rogpeppe | perrito666: i don't understand the change | 11:13 |
| rogpeppe | perrito666: why is 2 seconds too short? | 11:13 |
| perrito666 | rogpeppe: when there is lag, the wait time is 2 sec + whatever it takes for the server to answer | 11:14 |
| perrito666 | when you are next to the machine however, that time is almost inexistent | 11:14 |
| perrito666 | so the time waited is not enough and the operation times out | 11:15 |
| rogpeppe | perrito666: isn't this script always running on the machine itself? | 11:15 |
| rogpeppe | perrito666: also, this sleep is inside a loop anyway, so i don't see why it makes a big difference | 11:15 |
| perrito666 | rogpeppe: it is a seq loop, it will basically wait up to 120 secs, which is not enough in some cases (you make a point on that running remotely, strange) | 11:16 |
| rogpeppe | perrito666: if you want to increase the overall timeout, then it would be better to increase the seq, to say (seq 1 300) | 11:17 |
| perrito666 | rogpeppe: I see, why? (I changed the time bc It made more sense to me to wait a bit between retries intead of hitting a lot more times) | 11:19 |
| dimitern | fwereade, updated https://codereview.appspot.com/83070047/ | 11:22 |
| rogpeppe | perrito666: it depends how long it usually takes | 11:24 |
| rogpeppe | perrito666: how about a 5 second delay and 100 reps? | 11:24 |
| perrito666 | sounds like a good compromise :) | 11:25 |
| wwitzel3 | brb | 11:44 |
| perrito666 | rogpeppe: thanks for your input man :) I added the change | 11:44 |
| perrito666 | s | 11:44 |
| rogpeppe | perrito666: np | 11:44 |
| === lazyPower-travel is now known as lazypower-conf | ||
| * perrito666 wonders if he can teach his vi to do bash coloring for bash inside go | 11:45 | |
| rogpeppe | perrito666: ha ha, that would be a nice trick | 11:54 |
| voidspace | rogpeppe: so this is my basic approach https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 | 11:56 |
| voidspace | rogpeppe: I know you'd *rather* we were calling agentState.Ping() - but that won't work *yet*, right? | 11:56 |
| rogpeppe | voidspace: it will soon. i'd prefer it if this just used that, please. | 11:57 |
| voidspace | rogpeppe: ok | 11:57 |
| voidspace | rogpeppe: in which case, does the agent.State fulfill the singular.Conn interface | 11:57 |
| voidspace | let me find out | 11:58 |
| rogpeppe | voidspace: hmm, not quite | 11:58 |
| rogpeppe | voidspace: as it doesn't have Ping | 11:58 |
| rogpeppe | voidspace: we could just add Ping to agent.State though | 11:58 |
| rogpeppe | voidspace: alternatively (and perhaps better) just make your type be: type myConn struct {*agent.State; *api.State} | 11:59 |
| rogpeppe | voidspace: and i think *that* should fulfil the interface | 11:59 |
| voidspace | rogpeppe: duplicate field State | 12:02 |
| voidspace | oh | 12:02 |
| rogpeppe | voidspace: ha | 12:02 |
| voidspace | anyway, that aside | 12:02 |
| voidspace | I have a lunch date apparently | 12:02 |
| voidspace | so I have to go | 12:02 |
| rogpeppe | voidspace: there's a cunning way around it though | 12:02 |
| voidspace | back in a bit | 12:02 |
| rogpeppe | voidspace: enjoy! | 12:02 |
| voidspace | rogpeppe: I will hear your cunning plan on my return | 12:02 |
| BjornT_ | could someone please help me debug why juju can't connect to the bootstrap node when bootstrapping? i'm trying to bootstrap a maas environment (using vms). the bootstrap node comes up, but juju can't seem to be able to connect to it. | 12:16 |
| BjornT_ | the debug log is showing that juju is trying to do this: http://pastebin.ubuntu.com/7202991/ | 12:17 |
| BjornT_ | if i run that ssh command manually, i'm able to connect to the machine, but juju can't for some reason, and i'm not sure how to figure out why | 12:17 |
| rogpeppe | dimitern: i responded to your review, BTW: https://codereview.appspot.com/84470043/ | 12:18 |
| dimitern | rogpeppe, http://play.golang.org/p/IVDHjlYPXf | 12:18 |
| dimitern | rogpeppe, that's re your answer to my question about simplifying that line of code | 12:19 |
| perrito666 | BjornT_: ist it giving more details on the connetion failure? | 12:19 |
| rogpeppe | dimitern: ah yes, i see | 12:19 |
| dimitern | :) | 12:19 |
| rogpeppe | dimitern: now i come to think of it, i remember deliberately leaving the +1-1 in there | 12:20 |
| BjornT_ | perrito666: the juju log doesn't say it fails, it just keeps retrying all the time, it seems | 12:20 |
| rogpeppe | dimitern: otherwise i think the logic is more obscure | 12:20 |
| rogpeppe | dimitern: logically, we're adding one to get the next in sequence, subtracting one to make it into a zero-based index, then modulo, then add one again | 12:21 |
| rogpeppe | dimitern: so i *think* i'd rather leave that logic explicit | 12:21 |
| dimitern | rogpeppe, ok, but please add a comment | 12:21 |
| rogpeppe | dimitern: ok | 12:21 |
| rogpeppe | dimitern: (although i'd *definitely* need a comment if i went with your suggestion - it's not that obvious what it's doing :-) | 12:22 |
| rogpeppe | ) | 12:22 |
| rogpeppe | dimitern: done | 12:23 |
| dimitern | rogpeppe, ta! | 12:24 |
| BjornT_ | perrito666: now it finished, and shows this error: http://pastebin.ubuntu.com/7203035/ | 12:25 |
| dimitern | rogpeppe, LGTM | 12:25 |
| perrito666 | BjornT_: have you tried removing the key from the keyfile? | 12:25 |
| rogpeppe | dimitern: ta! | 12:25 |
| BjornT_ | perrito666: yes, didn't help | 12:29 |
| * perrito666 scratches head | 12:29 | |
| BjornT_ | perrito666: me to :-/ the maas environment i have with real machines seems to work fine, but i can't figure out what's different with this setup | 12:30 |
| wwitzel3 | 12:42 | |
| perrito666 | wwitzel3: how eloquent | 12:42 |
| wwitzel3 | ignore me! | 12:42 |
| hazmat | davecheney, pong | 12:46 |
| wwitzel3 | ok, there we go, all better :) was having some weird window manager issues | 12:46 |
| perrito666 | wwitzel3: ah happens | 12:47 |
| perrito666 | BjornT_: well if it is a whole virtual setup, some weirdness might occur in the network config (I am purely guessing here) | 12:48 |
| BjornT_ | perrito666: well, i think i've found the culprit. it seems the curtin installer is failing for some reason, so probably not a juju issue | 12:54 |
| bits3rpent | Hey, I was just running through the code yesterday, and I didn't understand a part of server.go 100%. | 13:10 |
| bits3rpent | I was wondering in the context of say, a client running the set command, how would bindRequest find out which method to run? | 13:11 |
| === tvan-afk is now known as tvansteenburgh | ||
| fwereade | bits3rpent, hmm, the MethodCaller stuff rings a bell, but rogpeppe will remember the details better than I will | 13:21 |
| fwereade | bits3rpent, I would suggest that digging into the infrastructure is relatively unlikely to directly help you accomplish anything app-level -- what are you working on at the moment? | 13:21 |
| natefinch | rogpeppe: have you had a chance to look at that commented out code in Machineagent's APIWorker? It needs the StateServingInfo, but it has an api.State not a state.State, and thus doesn't have a StateServingInfo() method on it. | 13:52 |
| voidspace | rogpeppe: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 | 13:54 |
| rogpeppe | natefinch: will do | 13:55 |
| rogpeppe | natefinch: would you be able to have a glance through https://codereview.appspot.com/84470043/ before i approve it, please? | 13:58 |
| natefinch | rogpeppe: sure thing | 14:00 |
| rogpeppe | natefinch: there's a StateServingInfo method on State.Agent() | 14:03 |
| mattyw | fwereade, would you be able to take another look at this: https://codereview.appspot.com/83060049/ | 14:04 |
| natefinch | rogpeppe: oh yeah, right, MachineAgent has a state in it. Sorry, got confused by the local variable in that method | 14:07 |
| rogpeppe | natefinch: i've made the change in my branch (and a couple more, rationalising the use of configChanged). i will push up shortly, when i've run tests | 14:09 |
| rogpeppe | pwd | 14:09 |
| rogpeppe | natefinch: we'll want a test that a machine agent started with no state serving info in its config will get it from state, start the api server, and stash the info in its config | 14:11 |
| natefinch | rogpeppe: great, thanks. Yeah, that test sounds like a pain, but definitely needed. | 14:13 |
| voidspace | rogpeppe: NewEnvironProvisioner is called twice | 14:13 |
| voidspace | rogpeppe: once in cmd/jujud/machine.go | 14:13 |
| voidspace | ah no | 14:13 |
| voidspace | rogpeppe: the second one is container_initialisation_*test* | 14:13 |
| voidspace | my brain parsed out the "_test" bit on first read | 14:14 |
| voidspace | never mind | 14:14 |
| voidspace | sorry | 14:14 |
| rogpeppe | natefinch: tests seem to pass. here's the branch for you to merge: lp:~rogpeppe/juju-core/natefinch-030-MA-HA | 14:15 |
| natefinch | rogpeppe: awesome, doing so now | 14:16 |
| natefinch | rogpeppe: is st.Agent().StateServingInfo() better than using MachineAgent's st.StateServingInfo? | 14:17 |
| rogpeppe | natefinch: i don't understand | 14:18 |
| natefinch | a.st.StateServingInfo() in that place | 14:18 |
| rogpeppe | natefinch: oh yeah | 14:18 |
| rogpeppe | natefinch: MachineAgent.st is horribly bogus | 14:18 |
| natefinch | rofl | 14:18 |
| rogpeppe | natefinch: it should not be there | 14:18 |
| natefinch | wow ok | 14:18 |
| rogpeppe | natefinch: and it's not available at that point anyway | 14:19 |
| rogpeppe | natefinch: MachineAgent.st is a really nasty hack to try and get the *state.State from a StateWorker to the APIWorker | 14:19 |
| rogpeppe | natefinch: for the upgrade code | 14:20 |
| natefinch | that's unfortunate | 14:20 |
| rogpeppe | natefinch: it would be considerably better if the upgrade code made its own connection to the state | 14:20 |
| voidspace | rogpeppe: https://pastebin.canonical.com/107793/ | 14:22 |
| voidspace | rogpeppe: now I have to change my monitor orientation! | 14:28 |
| rogpeppe | voidspace: sorry 'bout that | 14:29 |
| natefinch | lol | 14:30 |
| wwitzel3 | natefinch: hangout? | 14:34 |
| wallyworld | fwereade: sinzui : tested live on ec2 with version 1.18 and bootstrap --upload-tools https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 | 14:36 |
| wallyworld | the branch name is now misleading | 14:37 |
| natefinch | wwitzel3: sure | 14:38 |
| wallyworld | fwereade: sinzui : i gotta get some sleep so if it's +1 could one of you please approve so it can land | 14:39 |
| fwereade | wallyworld, many thanks indeed | 14:39 |
| === Ursinha-afk is now known as Ursinha | ||
| sinzui | wallyworld, thank you very much. I will manage its landing when the time comes | 14:42 |
| wallyworld | fwereade: i took a while cause i went down so many dead alleys trying to get all the tests to pass, and i had to find exactly the right tweaks | 14:43 |
| fwereade | wallyworld, you have gone even further above and beyond than usual | 14:43 |
| wallyworld | np. i really hope it works, i'll check email with anticipation later :-) | 14:44 |
| rogpeppe | natefinch: did you manage to have a look through https://codereview.appspot.com/84470043/ ? | 14:46 |
| rogpeppe | natefinch: don't worry if not. i'll approve it anyway. | 14:46 |
| wwitzel3 | lol | 14:46 |
| natefinch | haha... | 14:47 |
| natefinch | rogpeppe: sorry, got halfway through and got distracted. was hoping we could put the unreliable tests somewhere central so other places can use it | 14:48 |
| rogpeppe | natefinch: the flag, you mean? | 14:48 |
| natefinch | rogpeppe: yes, sorry | 14:48 |
| rogpeppe | natefinch: yes, that's not a bad idea | 14:48 |
| natefinch | juju-core/testing maybe | 14:49 |
| rogpeppe | natefinch: i'll consider it for the future, but if that's the only issue, i'll go ahead with it anyway. | 14:50 |
| rogpeppe | natefinch: when some other test requires it, it can move it into testbase | 14:50 |
| natefinch | rogpeppe: fair enough. | 14:54 |
| natefinch | rogpeppe: not sure I can review the whole thing right now, there's quite a lot of code. | 14:55 |
| rogpeppe | natefinch: np | 14:55 |
| voidspace | rogpeppe: added the singularRunner to StateWorker and removed the now extraneous New functions | 14:55 |
| voidspace | https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 | 14:55 |
| rogpeppe | natefinch: it's mainly there to convince myself that the strategy works | 14:55 |
| * rogpeppe finds it difficult to read diffs without full context... | 14:58 | |
| natefinch | rogpeppe: me too | 14:58 |
| voidspace | I have the same problem with reitveld - I consider the rest of the diff to *be* context... | 14:58 |
| voidspace | rogpeppe: either your microphone is right by your keyboard - or you're typing with a sledgehammer | 15:00 |
| dimitern | fwereade, rogpeppe, mgz, Provisioner API for networks and interfaces https://codereview.appspot.com/84570043 PTAL | 15:00 |
| rogpeppe | voidspace: the problem is the i see the changes, and often the start of the function is missing, so i have to try to infer which function the changes are in | 15:00 |
| mgz | dimitern: looking | 15:00 |
| rogpeppe | voidspace: that all looks great, BTW. i think i'd put the singular conn types at the end of the file though. | 15:00 |
| voidspace | yeah, good call | 15:01 |
| rogpeppe | voidspace: i'm not sure which extraneous New functions you meant, but i guess it doesn't matter now they're gone :-) | 15:01 |
| voidspace | I had New functions to instantiate the singular*Conn structs | 15:01 |
| voidspace | but not needed, can just use singularStateCon{state, machine} (etc) | 15:01 |
| voidspace | I've muted the hangout by the way | 15:02 |
| rogpeppe | voidspace: also, i have a vague convention that if i'm mocking something, i'll make the name the same as the usual name, but without the dot. so i'd use singularNew to mock singular.New, even though the name reads slightly more awkwardly. | 15:02 |
| voidspace | tempted to say I have a convention to use the best name for the thing being mocked | 15:02 |
| voidspace | but I will resist | 15:02 |
| rogpeppe | voidspace: well, i've never actually stated that convention; it's just something that i've been doing and seems to work ok | 15:03 |
| voidspace | rogpeppe: that would mean the test would need to be an explicitly whitebox test | 15:03 |
| voidspace | rogpeppe: but I guess it avoids making the alias a publicly exported part of the package under test | 15:03 |
| rogpeppe | voidspace: it *is* an explicitly whitebox test, if you're mocking out function definitions | 15:03 |
| voidspace | right | 15:04 |
| rogpeppe | voidspace: FWIW the point is moot in cmd/jujud anyway, because all the tests are in the package itself | 15:04 |
| voidspace | ok | 15:04 |
| rogpeppe | voidspace: and i feel that avoiding polluting the public docs is an important thing | 15:05 |
| voidspace | yep, fair point | 15:05 |
| rogpeppe | voidspace: (not that that's an issue in cmd/jujud though) | 15:05 |
| fwereade | sinzui, I think I'm happy with wallyworld's patch -- if I mark it approved can I leave it in your hands from then on? | 15:05 |
| sinzui | Thank you fwereade | 15:05 |
| voidspace | I still think in terms of Python, where NewSingularRunner(thing) looks like a constructor function call and singularRunner(thing) doesn't | 15:05 |
| === Ursinha is now known as Ursinha-afk | ||
| rogpeppe | voidspace: yeah, so singularNew doesn't look like either. but it's sufficiently unusual that hopefully people will either a) understand the convention and know it's intended to be an alias for singular.New or b) go and look at the def'n | 15:07 |
| voidspace | coffee | 15:10 |
| perrito666 | voidspace: marvelous idea, Ill have one too, no sugar please | 15:12 |
| perrito666 | :p | 15:12 |
| === Ursinha-afk is now known as Ursinha | ||
| === hatch__ is now known as hatch | ||
| wwitzel3 | when I set my scrollback buffer to 5000 I didn't know at the time I'd be having to read juju test failures | 15:31 |
| wwitzel3 | or I would of set it much larger :P | 15:31 |
| natefinch | wwitzel3: go get github.com/natefinch/nolog && nolog ./... | 15:35 |
| natefinch | optionally pass it -f to write out the full log to tests.out in the current directory | 15:36 |
| dimitern | mgz, does it make sense? | 15:37 |
| dimitern | mgz, the CL I mean :) | 15:37 |
| mgz | typing m in now | 15:38 |
| mgz | dimitern: done | 15:40 |
| dimitern | mgz, ta! | 15:42 |
| mgz | dimitern: anything unclear? my normal kind of not-super constructive review. | 15:53 |
| dimitern | mgz, :) it's fine, I'll split some of the larger tests when possible | 15:53 |
| dimitern | fwereade, mgz, next in line - StartInstance() returns network information (but in this CL just the interface is changed, so it's trivial) https://codereview.appspot.com/84470044 | 16:04 |
| mgz | nil, nil, nil, err | 16:10 |
| rogpeppe | nil, nil, nil, nil, nil, err | 16:18 |
| arosales | sinzui: fyi dannf submitted https://bugs.launchpad.net/juju-core/+bug/1302205 this is a critical one for arm | 16:19 |
| _mup_ | Bug #1302205: manual provisioned systems stuck in pending <add-machine> <hs-arm64> <manual-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1302205> | 16:19 |
| arosales | sinzui: I see you just traiged it | 16:19 |
| sinzui | arosales, making changes now | 16:20 |
| hazmat | arosales, that log output is normal | 16:21 |
| rogpeppe | wwitzel3: my scroll buffer is infinite... | 16:21 |
| wwitzel3 | rogpeppe: well that's just not true | 16:21 |
| rogpeppe | wwitzel3: well, it might start struggling at >10GB :-) | 16:22 |
| wwitzel3 | haha | 16:22 |
| rogpeppe | wwitzel3: although it's disk-backed, so it won't use more RAM | 16:22 |
| wwitzel3 | rogpeppe: yeah, I can enable disk based buffer, I've just been lazy | 16:22 |
| wwitzel3 | rogpeppe: and I bumped mine up to 10k, which is good enough | 16:23 |
| rogpeppe | wwitzel3: ha ha! you haven't been running uniter tests recently :) | 16:23 |
| wwitzel3 | rogpeppe: I'm looking forward to that then | 16:23 |
| arosales | hazmat: stuck in pending, could that be firewalls? | 16:25 |
| hazmat | arosales, not for manuala | 16:26 |
| natefinch | dammit ubuntu, stop losing my damn windows | 16:26 |
| hazmat | arosales, its strange the machine logs there say there connecting back to the state server | 16:26 |
| wwitzel3 | natefinch: I can no longer lose a window, even if I want to ... | 16:26 |
| natefinch | somewhere, invisible to the desktop, I have a google hangout window | 16:26 |
| arosales | hazmat: ok, re firewall | 16:27 |
| hazmat | arosales, it might be an issue on the state server | 16:27 |
| hazmat | arosales, there's a couple of panics / process restarts there | 16:27 |
| dimitern | mgz, it will eventually get nil, err, but not today :) | 16:29 |
| arosales | hazmat: thanks for taking a look. | 16:29 |
| hazmat | that's odd too.. 2014-04-03 18:09:57 ERROR juju.worker environ.go:56 loaded invalid environment configuration: storage-port: expected int, got float64(8040) | 16:30 |
| * hazmat wonders if this is related to new instance updater code lands | 16:30 | |
| hazmat | oh this is arm64 | 16:31 |
| rogpeppe | dimitern, voidspace, fwereade, wwitzel3, natefinch, mgz: here's the code that kills the api server when the mongo connection goes down: https://codereview.appspot.com/84540044 | 16:34 |
| dimitern | rogpeppe, looking | 16:34 |
| rogpeppe | dimitern: thanks | 16:34 |
| voidspace | rogpeppe: cool | 16:42 |
| dimitern | rogpeppe, reviewed | 16:42 |
| rogpeppe | dimitern: ta! | 16:42 |
| === vladk is now known as vladk|offline | ||
| * dimitern gives up on trying to land all vlan stuff today :/ it's still couple of branches away | 16:44 | |
| dimitern | mgz, but I can at least land the StartInstance CL ;) | 16:45 |
| mgz | dimitern: okay, I'll stamp that one | 16:46 |
| dimitern | mgz, tyvm | 16:46 |
| mgz | dimitern: lgtm | 16:47 |
| dimitern | mgz, ta | 16:59 |
| natefinch | rogpeppe: I've forgotten, what did we do to fix "cannot get replset config: not authorized for query on local.system.replset" when we try to initiate? | 17:06 |
| natefinch | 'cause it's back | 17:06 |
| rogpeppe | natefinch: when are you getting it? | 17:06 |
| natefinch | rogpeppe: in bootstrap, just before we initiate state, we're calling ensuremongoserver and then maybeinitiatereplset | 17:07 |
| natefinch | er MaybeInitiateMongoServer... it fails in there | 17:08 |
| rogpeppe | natefinch: live or in tests? | 17:08 |
| natefinch | rogpeppe: live | 17:08 |
| rogpeppe | natefinch: local provider? | 17:08 |
| natefinch | rogpeppe: nope, amazon | 17:08 |
| wwitzel3 | rogpeppe: and for me on maas | 17:08 |
| rogpeppe | natefinch: are you in a hangout? | 17:09 |
| natefinch | https://plus.google.com/hangouts/_/7ecpi12cuupgkah473lbirvs1k | 17:09 |
| tvansteenburgh | hey guys, i'm deploying a trusty workload to lxc, and all unit agent-states get stuck in "pending" and never come up. machine-0 log -> http://paste.ubuntu.com/7203724/ | 17:16 |
| tvansteenburgh | looking for help on how to proceed if anyone has time | 17:16 |
| tvansteenburgh | precise workload deploys fine | 17:17 |
| tvansteenburgh | $ juju --version | 17:18 |
| tvansteenburgh | 1.17.7-trusty-amd64 | 17:18 |
| tvansteenburgh | the trusty cloud image isn't even being downloaded: | 17:19 |
| tvansteenburgh | root@trusty-vm:/home/tvansteenburgh# ll /var/cache/lxc/ | 17:19 |
| tvansteenburgh | total 12 | 17:19 |
| tvansteenburgh | drwx------ 3 root root 4096 Apr 4 11:08 ./ | 17:19 |
| tvansteenburgh | drwxr-xr-x 18 root root 4096 Mar 25 12:06 ../ | 17:19 |
| tvansteenburgh | drwxr-xr-x 2 root root 4096 Mar 26 14:51 cloud-precise/ | 17:19 |
| tvansteenburgh | root@trusty-vm:/home/tvansteenburgh# lxc-ls --fancy | 17:19 |
| tvansteenburgh | NAME STATE IPV4 IPV6 AUTOSTART | 17:19 |
| tvansteenburgh | ----------------------------------------------------- | 17:19 |
| tvansteenburgh | juju-precise-template STOPPED - - NO | 17:19 |
| rogpeppe | wwitzel3: ~rogpeppe/juju-core/natefinch-030-MA-HA/ | 17:59 |
| wwitzel3 | rogpeppe: thanks | 18:01 |
| rogpeppe | tvansteenburgh: interesting | 18:07 |
| rogpeppe | tvansteenburgh: could you paste all-machines.log? | 18:07 |
| tvansteenburgh | rogpeppe: http://paste.ubuntu.com/7204338/ | 18:09 |
| rogpeppe | voidspace: did you have the code done for your singular worker wrapping changes? | 18:27 |
| rogpeppe | voidspace: (i don't care about the tests, but i'd like the try it out to see if i can get HA actually working live) | 18:28 |
| rogpeppe | s/the/to/ | 18:28 |
| voidspace | rogpeppe: incomplete | 18:30 |
| voidspace | rogpeppe: and I'm EOW now | 18:30 |
| rogpeppe | voidspace: ok | 18:30 |
| rogpeppe | voidspace: could you push what you've got so far? | 18:30 |
| voidspace | rogpeppe: ok | 18:31 |
| rogpeppe | voidspace: thanks | 18:31 |
| voidspace | rogpeppe: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 | 18:32 |
| voidspace | rogpeppe: so, I believe this does | 18:33 |
| voidspace | EnvironProvisioner, Firewaller, MinUnitsWorker, CharmRevisionUpdater and Cleaner | 18:33 |
| voidspace | rogpeppe: assuming they're all done in cmd/jujud/machine.go | 18:33 |
| === BradCrittenden is now known as bac | ||
| voidspace | rogpeppe: Provider Provisioner still needs to be done | 18:34 |
| voidspace | and maybe some other provisioners | 18:34 |
| rogpeppe | voidspace: lovely stuff | 18:34 |
| rogpeppe | voidspace: i was just about to actually try it for real, then realised that the second instance needs to write its passwords for jujud | 18:34 |
| rogpeppe | voidspace: i think we're *that* close | 18:35 |
| rogpeppe | voidspace: to having it (theoretically) working | 18:35 |
| rogpeppe | voidspace: but eow for me too now | 18:35 |
| voidspace | cool! | 18:35 |
| voidspace | g'night everyone | 18:35 |
| rogpeppe | voidspace, wwitzel3: thanks for all your work | 18:35 |
| rogpeppe | happy weekends all | 18:35 |
| wwitzel3 | rogpeppe: see ya, have a good weekend | 18:40 |
| tvansteenburgh | rogpeppe: should i file a bug for my problem you think? | 18:42 |
| jcastro | Charm school at the top of the hour, The topic is Juju Plugins: http://ubuntuonair.com, we'll be taking questions in #juju | 18:53 |
| bcsaller | looks like upgrade-charm on current devel release with trusty is spinning on a git failure, looks to be retrying endlessly | 19:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!