=== hatch__ is now known as hatch [00:41] 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] thing is, when i try to connect, i get error: Unable to connect to environment "foo": no registered provider for "openstack" [00:42] "for fun" [00:42] ha [00:42] :) [00:42] to scratch an itch, actually [00:42] what do i need to do to initialize those providers [00:42] you need to import from providers so the init() gets run [00:42] ah, ok [00:42] use a _ at the start [00:43] so it doesn't complain about unused imports [00:43] grep for it and you'll see where else it's done [00:43] 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:44] wallyworld_, that did the trick, thanks [00:44] np [00:45] mischief61507: not hard [00:45] mischief61507: can you raise and issue with the syscalls that are missing [00:45] i'm assuming its the usual TCSET/TCGET [00:45] ictls [00:45] nono [00:46] it's mainly use of nonportable signal names [00:47] 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] mischief61507: i'm sure we can do some kind of conditional compilatoin [00:48] yea, having _unix and _plan9.go files would likely work [00:48] mischief61507: https://bugs.launchpad.net/juju-core/+filebug [00:48] if you would be so kind [00:59] wallyworld_, Do you have an experience unfucking gobot. we have a backlog of branches that cannot merge in 1.18. [01:00] sinzui: i have and i will [01:01] sinzui: bot is running [01:01] must be something else [01:01] i'll look [01:01] it says no approved proposals for 1.18 [01:02] wallyworld_, jhobbs and I stopped after a while [01:03] wallyworld_, This is mine https://code.launchpad.net/~sinzui/juju-core/inc-1.18.0/+merge/214053 [01:03] sinzui: gotbot claims that one is not approved [01:03] I will approve it again [01:03] done [01:04] sinzui: and tests running === thumper-gym is now known as thumper [01:21] 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] :-( [01:22] do you need me to check anything? [01:23] hmmm. [01:23] looking at the errors, looks like it fails to upload and/or find tools [01:25] sinzui: i can look into it [01:52] 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] yes probably [01:52] but the real problem is that on trusty, the tests should rely on juju-mongodb [01:53] thumper: okay, as a temp patch, should I add it in? [01:53] add what where? [01:54] thumper: to the makefile - install dependencies [01:54] https://bugs.launchpad.net/juju-core/+bug/1301353 [01:54] <_mup_> Bug #1301353: juju test suite should use juju-mongodb

[01:54] waigani: no [01:54] waigani: perhaps fix that bug [01:55] ah [01:55] waigani: also, there is the test to make sure that juju-mongodb is installed for the local provider prechecker [01:55] waigani: that would be a good thing to fix too [01:56] thumper: isn't juju-mongodb a dep of juju-local now ? [01:56] davechen1y: I believe so [01:56] davechen1y: but many people don't have juju-local installed when trying to use the local provider [01:56] we should tell them [01:57] davechen1y, thumper. It appears NO juju users install the juju-local package [01:58] 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] sinzui: shitballs [01:58] 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] and there isn't a file path that we can hang the usual check off [01:59] dumb suggestion: juju-1.18 depends on juju local [01:59] i think that is a less worse solution that making it optional [01:59] actually [01:59] scrap that [01:59] i can see the complains about mongodb already [01:59] shit, sam left something at home [01:59] back in 10 mins, gotta go drop it off [02:00] 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:02] 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:03] * thumper nods [02:03] okay [02:26] sinzui: agreed [02:48] * thumper does a little dance === vladk|offline is now known as vladk [02:50] thumper: pics or it never happened === vladk is now known as vladk|offline [02:59] wow... I think I am finally happy with the apiserver tests for this... [03:06] * thumper just needs a pile of number eight wire [03:06] and we can move this thing forwards [03:19] provider/local has checks for rsyslog-gnutls. Should this be replaced with a check for juju-local? [03:45] waigani: yes [03:45] axw: do you know if juju-local depends on rsyslog-gnutls? [03:46] thumper: I raised a but about it a while ago, I think sinzui or jamespage did it [03:47] thumper: apt-cache says yes [03:47] thumper, It does [03:47] cool [03:47] waigani: so, yes, that is your answer [03:48] ah, this is what I've done: lp:~waigani/juju-core/1301353-mongodb-dep [03:48] just pushing it up to pull down and test on ppc vm [03:49] simple review for someone: https://codereview.appspot.com/84290045/ === vladk|offline is now known as vladk [04:04] thumper: looking [04:08] thumper: how do you intend to use StartedTailing? [04:08] axw: I have it in a test where I need to wait until the back looking seeking is done [04:09] so I wait on a channel [04:09] that the StartedTailing closes [04:09] then I write more [04:09] I wish we had some form of signals and slots built into the language [04:09] that'd work too [04:09] but no [04:09] you provide a ReadSeeker - why not just do it there? [04:10] in the Seek() [04:10] because I don't seek [04:10] and I'm just providing it a real file [04:11] Although I think I see what you are getting at [04:11] if there's no seek, fine, but otherwise you can override [04:11] I don't like exposing things like this for testing [04:11] hmm... [04:11] ok [04:12] I think I just got another form of 'no reachable servers' [04:12] panic: interface conversion: interface is nil, not *websocket.Conn, home/tim/go/src/launchpad.net/juju-core/state/api/apiclient.go:140 [04:13] I'll look to see if I can rewrite the test [04:13] thanks === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [04:24] axw: ok, I got it working, but only because that test doesn't seek backwards from the end [04:24] but I guess it is sufficient [04:25] thumper: cool. see my comment on the CL, let me know what you think [04:27] hmm... I really want to avoid messing around with tailer too much [04:53] ok, that's it [04:53] I'm done [04:53] night all [05:01] eod wip(am I on the right track?): https://codereview.appspot.com/84360043 === tasdomas` is now known as tasdomas [06:37] morning all [07:13] morning dimitern [07:13] hey axw [07:22] EOW => til next week gentlemen [07:34] fwereade: instance type constraint https://codereview.appspot.com/84310044 [07:34] fwereade: also, tests fixes for 1.18 https://code.launchpad.net/~wallyworld/juju-core/fix-tools-tests-1.18/+merge/214159 [07:34] wallyworld, I'm just reviewing it, but I have to pop out for an hour shortly [07:35] wallyworld, I'll send what I have in a mo, there's one significant thing [07:35] fwereade: i'm off to soccer so no hurry [07:35] jst wanted to let you know they were there [07:35] wallyworld, in particular, what instance-type implies varies by provider [07:35] especially the 1.18 fix [07:35] fwereade: sure, it varies, so for ec2 you say instace-type=m1.small, for openstack something else [07:36] 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] wallyworld, different vocabularies== np at all, we have varying arches across clouds today [07:36] oh i see [07:36] wallyworld, we have to delegate fallback handling to the providers I think [07:36] right, i didn't get that subtlety [07:37] 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] wallyworld, but that implies schema changes [07:37] yeah, was thinking our current approach won't work now [07:37] well [07:37] we could defer the fallback behaviour [07:37] wallyworld, so axw/waigani's policy stuff might be the way to make those calculations at the time we do currently [07:38] sure, the provides can always read the env constraints as needed [07:38] wallyworld, we could defer, but we have to capture the inputs at the same time we currently do the fallbacks [07:39] np, i'll take a look [07:39] do we have the rules documented for how to fall back? [07:39] for each rpovider? [07:39] wallyworld, it's pretty much "what does an instance type imply" in this particular context [07:40] that's what i'm no sure of. i can read the ec2 docs [07:40] anyways, gotta run to soccer [07:40] wallyworld, ec2 is potentially misleading [07:40] wallyworld, indeed, we can chat later [07:41] fwereade: if you want to put a few thoughts down, drop me a line or we can chat [07:41] but apprt from the fallbac, i think the approavh works [07:41] or seems to work fine [07:42] code change to use the constraint itself was quite small [07:42] wallyworld, yeah, I don't think it's devastatingly complex [07:42] wallyworld, tyvm for this :) [07:42] np, we really need it [07:42] like last year [07:43] * fwereade winces gently [07:43] fwereade: highest priority now though is the 1.18 test fix [07:43] to unblock the release [08:05] well, at least i've got my second monitor working again now, kinda [08:05] * rogpeppe doesn't trust trusty any more [08:09] * rogpeppe tries to work out how to use lubuntu [08:18] here's an interesting mongod failure: http://paste.ubuntu.com/7202291/ [08:18] 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:25] that doesn't look great [08:26] wallyworld, when you're back, can we talk a bit about upload-tools? as, indeed, a higher priority than the instance-type stuff [08:27] rogpeppe: I managed to bootstrap local provider with natefinch's branch, with a few modifications - I added some comments to the CL [08:27] EnsureMongoServer that is [08:28] axw: great, thanks [08:42] morning all === vladk|offline is now known as vladk === vladk is now known as vladk|offline [09:09] voidspace: morning! === psivaa_ is now known as psivaa [09:15] 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] dimitern, will do [09:16] 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:17] fwereade: looking [09:17] fwereade, so --upload-tools will be allowed only for dev versions? [09:28] 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:42] 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:43] 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] I'll ask wallyworld when he comes back :) [09:43] 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:44] rogpeppe, looking [09:44] fwereade, oww.. [09:44] fwereade: sorry, i got distracted finishing up this proposal. will really look now :-) === vladk|offline is now known as vladk [09:44] rogpeppe, I know the feeling [09:45] * fwereade is trying to do about three things at once [09:45] fwereade: it seems weird that upload-tools is disabled for release versions. i hadn't noticed it. [09:46] 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:55] fwereade: my thoughts are that it scares me too [09:56] rogpeppe, I think it'll have to be a standup topic [09:56] fwereade: yeah [09:56] rogpeppe, please remind me if I forget :) [09:57] fwereade: have you got a moment to discuss Ping? [09:57] dimitern, LGTM with a couple of tweaks, ping me if anything's surprising [09:57] rogpeppe, I expect so, which one? [09:57] rogpeppe, the keepalive thingy? [09:58] 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] morning everyone [09:58] fwereade: for the StateWorker, that's easy because we've got access to the *state.State and thence its mgo.Session [09:59] 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] I don't think we can just disable it, either. [09:59] 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] 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] rogpeppe: I thought you didn't need to ping mongo as we expected the connection to break and bounce the API servers [10:00] jam: we have to know when the connection breaks [10:00] rogpeppe, yeah, I thought we were relying on operations failing? [10:01] 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] otherwise between API calls master could change... ? [10:01] fwereade: we can rely on that for the master, but the secondaries need some way of knowing too [10:01] though I thought we also bounce the API server which bounces the provisioner [10:06] jam: we don't need to check on every call, because if isMaster changes, then the API call will fail [10:09] rogpeppe, sorry, I'm having difficulty swapping context [10:10] 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] rogpeppe: don't all connections get bounced when the master changes? [10:10] 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:11] certainly replsetReconfig bounces all connections. [10:11] rogpeppe: and I thought everything actually just connects to the master to do any Write operation, so it will also bounce [10:11] it just needs to know if the connection is "local" [10:11] jam: only if the API server is actually doing something [10:11] jam: the only way we know if the master has changed is if some operation fails [10:12] jam: but there might not be any operations happening. [10:12] rogpeppe: so we don't notice a disconnect by itself? [10:12] jam: how would we? [10:12] rogpeppe: Presence pingers are very likely to be triggering all the time [10:12] that writes to the Presence DB [10:12] \ [10:12] but if an API server didn't have any clients [10:12] it would still have its own pinger? [10:13] rogpeppe, jam: can we force state servers to connect to their own api server? would that resolve it? [10:13] 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] fwereade: not really [10:14] fwereade: I'm pretty sure we already do by writing "localhost" into agent.conf [10:14] rogpeppe, jam: that'd guarantee at least one connection with a presence pinger for each state server? [10:15] fwereade: hmm, i see what you're getting at. [10:15] * rogpeppe thinks [10:17] fwereade, cheers! [10:18] natefinch: morning nate [10:18] howdy-ho neighbors [10:20] natefinch: hiya [10:20] hey natefinch [10:20] fwereade, jam: i haven't yet found anything that would imply that a presence-pinger failure would cause an api connection teardown [10:23] 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:24] * rogpeppe wonders about a decent way to do that [10:26] 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] 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:33] 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] rogpeppe, that's probably cleaner [10:33] rogpeppe, shorter chain of dependencies to get amusingly broken at surprising times [10:34] fwereade: yeah [10:34] fwereade: right, i'll make a ticket for it [10:35] jam: does that sound reasonable to you? [10:43] rogpeppe, reviewed [10:47] perrito666, standup? [10:47] * perrito666 having computer problems, ill be right there [10:51] rogpeppe: sgtm [10:52] jam: cool [10:52] jam: standup? [10:52] rogpeppe: not working today :) [10:52] "not" working [10:52] jam: ah, of course. what are you doing here then? :-) [10:52] rogpeppe: "not" working, certainly [10:53] he just misses us [10:53] jam: lol [11:07] question, how many lgtms I need on this to merge it? https://codereview.appspot.com/82280045 [11:09] perrito666: just one, assuming you're happy with the reviewer's knowledge of the code [11:11] rogpeppe: I think you wrote the code originally :) so yours woud be appreciated, you will find it really really short [11:13] perrito666: i don't understand the change [11:13] perrito666: why is 2 seconds too short? [11:14] rogpeppe: when there is lag, the wait time is 2 sec + whatever it takes for the server to answer [11:14] when you are next to the machine however, that time is almost inexistent [11:15] so the time waited is not enough and the operation times out [11:15] perrito666: isn't this script always running on the machine itself? [11:15] perrito666: also, this sleep is inside a loop anyway, so i don't see why it makes a big difference [11:16] 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:17] perrito666: if you want to increase the overall timeout, then it would be better to increase the seq, to say (seq 1 300) [11:19] 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:22] fwereade, updated https://codereview.appspot.com/83070047/ [11:24] perrito666: it depends how long it usually takes [11:24] perrito666: how about a 5 second delay and 100 reps? [11:25] sounds like a good compromise :) [11:44] brb [11:44] rogpeppe: thanks for your input man :) I added the change [11:44] s [11:44] perrito666: np === lazyPower-travel is now known as lazypower-conf [11:45] * perrito666 wonders if he can teach his vi to do bash coloring for bash inside go [11:54] perrito666: ha ha, that would be a nice trick [11:56] rogpeppe: so this is my basic approach https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 [11:56] rogpeppe: I know you'd *rather* we were calling agentState.Ping() - but that won't work *yet*, right? [11:57] voidspace: it will soon. i'd prefer it if this just used that, please. [11:57] rogpeppe: ok [11:57] rogpeppe: in which case, does the agent.State fulfill the singular.Conn interface [11:58] let me find out [11:58] voidspace: hmm, not quite [11:58] voidspace: as it doesn't have Ping [11:58] voidspace: we could just add Ping to agent.State though [11:59] voidspace: alternatively (and perhaps better) just make your type be: type myConn struct {*agent.State; *api.State} [11:59] voidspace: and i think *that* should fulfil the interface [12:02] rogpeppe: duplicate field State [12:02] oh [12:02] voidspace: ha [12:02] anyway, that aside [12:02] I have a lunch date apparently [12:02] so I have to go [12:02] voidspace: there's a cunning way around it though [12:02] back in a bit [12:02] voidspace: enjoy! [12:02] rogpeppe: I will hear your cunning plan on my return [12:16] 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:17] the debug log is showing that juju is trying to do this: http://pastebin.ubuntu.com/7202991/ [12:17] 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:18] dimitern: i responded to your review, BTW: https://codereview.appspot.com/84470043/ [12:18] rogpeppe, http://play.golang.org/p/IVDHjlYPXf [12:19] rogpeppe, that's re your answer to my question about simplifying that line of code [12:19] BjornT_: ist it giving more details on the connetion failure? [12:19] dimitern: ah yes, i see [12:19] :) [12:20] dimitern: now i come to think of it, i remember deliberately leaving the +1-1 in there [12:20] perrito666: the juju log doesn't say it fails, it just keeps retrying all the time, it seems [12:20] dimitern: otherwise i think the logic is more obscure [12:21] 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] dimitern: so i *think* i'd rather leave that logic explicit [12:21] rogpeppe, ok, but please add a comment [12:21] dimitern: ok [12:22] 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] ) [12:23] dimitern: done [12:24] rogpeppe, ta! [12:25] perrito666: now it finished, and shows this error: http://pastebin.ubuntu.com/7203035/ [12:25] rogpeppe, LGTM [12:25] BjornT_: have you tried removing the key from the keyfile? [12:25] dimitern: ta! [12:29] perrito666: yes, didn't help [12:29] * perrito666 scratches head [12:30] 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:42] [12:42] wwitzel3: how eloquent [12:42] ignore me! [12:46] davecheney, pong [12:46] ok, there we go, all better :) was having some weird window manager issues [12:47] wwitzel3: ah happens [12:48] BjornT_: well if it is a whole virtual setup, some weirdness might occur in the network config (I am purely guessing here) [12:54] 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 [13:10] Hey, I was just running through the code yesterday, and I didn't understand a part of server.go 100%. [13:11] I was wondering in the context of say, a client running the set command, how would bindRequest find out which method to run? === tvan-afk is now known as tvansteenburgh [13:21] bits3rpent, hmm, the MethodCaller stuff rings a bell, but rogpeppe will remember the details better than I will [13:21] 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:52] 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:54] rogpeppe: https://code.launchpad.net/~mfoord/juju-core/wrapsingletonworkers/+merge/214208 [13:55] natefinch: will do [13:58] natefinch: would you be able to have a glance through https://codereview.appspot.com/84470043/ before i approve it, please? [14:00] rogpeppe: sure thing [14:03] natefinch: there's a StateServingInfo method on State.Agent() [14:04] fwereade, would you be able to take another look at this: https://codereview.appspot.com/83060049/ [14:07] rogpeppe: oh yeah, right, MachineAgent has a state in it. Sorry, got confused by the local variable in that method [14:09] 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] pwd [14:11] 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:13] rogpeppe: great, thanks. Yeah, that test sounds like a pain, but definitely needed. [14:13] rogpeppe: NewEnvironProvisioner is called twice [14:13] rogpeppe: once in cmd/jujud/machine.go [14:13] ah no [14:13] rogpeppe: the second one is container_initialisation_*test* [14:14] my brain parsed out the "_test" bit on first read [14:14] never mind [14:14] sorry [14:15] natefinch: tests seem to pass. here's the branch for you to merge: lp:~rogpeppe/juju-core/natefinch-030-MA-HA [14:16] rogpeppe: awesome, doing so now [14:17] rogpeppe: is st.Agent().StateServingInfo() better than using MachineAgent's st.StateServingInfo? [14:18] natefinch: i don't understand [14:18] a.st.StateServingInfo() in that place [14:18] natefinch: oh yeah [14:18] natefinch: MachineAgent.st is horribly bogus [14:18] rofl [14:18] natefinch: it should not be there [14:18] wow ok [14:19] natefinch: and it's not available at that point anyway [14:19] natefinch: MachineAgent.st is a really nasty hack to try and get the *state.State from a StateWorker to the APIWorker [14:20] natefinch: for the upgrade code [14:20] that's unfortunate [14:20] natefinch: it would be considerably better if the upgrade code made its own connection to the state [14:22] rogpeppe: https://pastebin.canonical.com/107793/ [14:28] rogpeppe: now I have to change my monitor orientation! [14:29] voidspace: sorry 'bout that [14:30] lol [14:34] natefinch: hangout? [14:36] 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:37] the branch name is now misleading [14:38] wwitzel3: sure [14:39] fwereade: sinzui : i gotta get some sleep so if it's +1 could one of you please approve so it can land [14:39] wallyworld, many thanks indeed === Ursinha-afk is now known as Ursinha [14:42] wallyworld, thank you very much. I will manage its landing when the time comes [14:43] 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] wallyworld, you have gone even further above and beyond than usual [14:44] np. i really hope it works, i'll check email with anticipation later :-) [14:46] natefinch: did you manage to have a look through https://codereview.appspot.com/84470043/ ? [14:46] natefinch: don't worry if not. i'll approve it anyway. [14:46] lol [14:47] haha... [14:48] 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]