[00:20] waigani: just user IMO [00:20] waigani: because all users are local [00:20] thumper: ok [00:34] thumper: waigani menn0 https://github.com/juju/juju/pull/653 [00:34] if you have a chance [00:34] this is what we discussed on the call [00:35] davecheney: sorry, I haven't had a chance to look yet [00:38] s'ok [00:38] no that urgent, but not that complex either [00:39] davecheney: done [00:39] thanks [00:39] re gofmt [00:39] that's sort of how it comes [00:39] and i'm moving those packages to the top level so that will change the ordering again [00:46] menn0: you were right about gofmt [00:46] fixed [00:48] thumper: the state/api{,server} -> / change is coming next [00:48] davecheney: kk, awesome [00:55] thanks mongo, http://paste.ubuntu.com/8211128/ [01:01] ugh... [01:01] * thumper is starting to really hate the juju/juju/juju package [01:01] back in the day j/j/juju was supposed to be "the" way of connecting to state [01:01] but now we have [01:01] state/api [01:01] and agent/ [01:01] i guess all good things come in threes [01:01] * thumper nods [01:02] j/j/juju needs to die IMO [01:02] i'm the man for that job [01:02] unfortunately I can't kill the method right now [01:02] as restore plugin has decided to use it [01:02] everywhere else is just tests [01:02] for the method I'm looking at [01:02] juju.NewAPIState(environ, api.DialOpts{}) [01:05] hmm [01:05] there is OpenAPIState in another package [01:05] probably few of them [01:05] and testing/OpenAPIAs [01:05] colour me unsurprised [01:05] I am daves complete lack of surprise [01:06] * thumper needs to find some time to write the LXC talk he is giving in about 4.5 hours [01:06] glwt [01:11] thumper: http://godoc.org/github.com/davecheney/graphpkg [01:11] just updated this a little [01:12] so I can see the lay of the land [01:12] you can also use godoc to get a graph of the packages [01:12] but I don't trust it to be up to date [01:13] and dot went to 100% [01:13] :( [01:13] not a good sign [01:15] wallyworld_: I think we have more new flaky test [01:15] http://paste.ubuntu.com/8211272/ [01:16] davecheney: known issue, already in the doc [01:16] cool [01:16] thanks for confirming [01:16] np [01:16] i haven't seen that one before [01:16] you're lucky [01:16] i'm not sure if that means Ineed to look more, or less [01:16] sadly we have a few of those common ones [01:17] but once it's fixed, a several breakages will go away [01:17] it's an odd one [01:17] it's happening in test tear down [01:17] btw, I love the open source community [01:17] https://github.com/davecheney/gmx/issues/2 [01:17] such people skills [01:17] yup, it also can happen elsewhere i think, but teardown is most common [01:18] lol [01:19] i'm a tool [01:19] davecheney: in Launchpad, the various build recipe APIs were wrong for a while because I couldn't spell [01:19] who can't spell gauge [01:19] i thought it was recipie [01:19] wallyworld_: how many i's are there in recipippie ? [01:19] not enough [01:19] imo [01:19] wallyworld_: you're not alone, i have a hard time remembering that recipe isn't spelled, recepit [01:20] fuck [01:20] recepit [01:20] i just can't spell in general [01:20] damn it [01:20] i really cannot spell that word [01:20] or any other that is slightly like it [01:20] without the red underscore I am worthless [01:20] dyslexic much [01:20] me too [01:21] axw: well, i have done my friday test fix early this week - stupid mega watcher test race bit me trying to land some code [01:22] wallyworld_: okey dokey, [01:22] https://github.com/juju/juju/pull/655 [01:22] truly enormouse, entirely mechanical change [01:23] wallyworld_: I think I'm going to do tools catalogue & storage in one [01:23] probably not much bigger of a PR in the end [01:23] whatever is easiest :-) [01:23] i don't mind big pr's sometimes [01:23] wallyworld_: https://github.com/juju/juju/pull/655/files [01:24] I don't think it'll be all that big, we'll see [01:24] 600 files!! [01:24] 600 files changed, +600 lines, -600 lines :( [01:24] davecheney: so just a package move [01:24] sed baby, sed [01:24] yup [01:24] hopefully uncontentious [01:24] yup [01:25] people i talk to think putting the api at the top level makes sense [01:25] i'm +/- on having both api and apiserver at the top level [01:25] i rememver back in the day there was something like [01:25] api/apiserver [01:25] or apisever/api [01:25] but that sounds no better [01:26] davecheney: IMO we should move api out of this repo altogether at some point [01:26] axw: +1 << 32 [01:26] have language-specific API repos [01:26] yes, that was part of the reason for monving api/params to apiserver/params [01:26] cool. [01:27] i'd be keen to see the api (client) move it it's own repo [01:27] but I don't think it is urgent [01:27] ie, it doesn't justify your time to setup another repo and top level build job [01:27] agreed [01:43] davecheney: FWIW the gofmt comment was waigani's, not mine [01:44] prefixed with "super minor point" gofmt -s -d says it should come after [02:11] menn0: right [02:11] sorry [02:11] anyway, it's fixed now [02:19] (╯°□°)╯︵ ┻━┻ [02:19] that's the ticket [02:46] thumper: waigani the current state of play http://godoc.org/github.com/juju/juju/state?import-graph [02:47] hey that's really cool [02:47] hit hide(all) to hide the std lib pacakges [02:47] davecheney: can you generate that but only look at "github.com/juju/juju" ? [02:47] that will make it a bit simpler [02:48] thumper: do you mean the juju/juju package [02:48] or juju/juju/... [02:50] thumper: https://github.com/davecheney/juju/compare/juju:master...davecheney:188-state-clone-state-serving-info?expand=1 [02:50] not ready for review yet [02:50] I think I can reduce the delta a bit more [02:50] but we're still going to have three copies of params.StateServingInfo after this change [02:53] there are also a lot of things which now depend directly on state [02:53] which is not good either [02:55] thumper: ping [02:56] wwitzel3: hey [02:56] whazzup? [02:57] hey, you have a second for a quick hangout, I have some questions about some juju run stuff I've been working on. [02:59] sure [02:59] thumper: I'll go to the Oynx standup one [02:59] ack [03:04] all: juju/mongo is a helper package for setting up and managing mongo servers, right ? [03:06] fixed it: ┬─┬ ノ( ゜-゜ノ) [03:06] so much awesome.. http://vimeo.com/95066828 [03:06] comedy value and distributed systems [03:51] thumper: looking at state/apiserver/client/run.go .. the client.Run method, it calls ParallelExecute which calls ssh.ExecuteCommandOnMachine [03:51] wwitzel3: yeah, that is how the api server calls out to the machines that it needs to call [03:51] wwitzel3: it calls the 'juju-run' command on the other side [03:52] thumper: ahh, ok [04:17] jam: i have an api version question if you're around [04:40] waigani: hmm... [04:40] * thumper thinks of expedience [04:40] vs learning [04:40] bugge [04:40] r [04:41] waigani: the issue I'm having is that you have done things exactly as they have been done before [04:41] the problem is that they way they were done before is kinda crap [04:41] haha [04:41] well, let's do it right [04:41] sure? [04:41] ugh .. no but your call [04:42] * thumper takes a quick look to determine the amount of work [04:42] hangout? [04:43] sure [04:43] waigani: use the standup one === Ursinha is now known as Ursinha-afk [06:11] hazmat: if you haven't already, you should read his columns too. hilarious and educational === urulama-afk is now known as urulama [07:37] morning all [08:04] back and I have internet.... [08:04] currently provided by a 30metre ethernet cable slung into next door... [08:11] morning [08:12] voidspace: hehe, welcome back. troubles with provider switch at least almost solved? [09:15] well, that's 330mb of updates done [09:25] voidspace, have EE given you a better date than 2 weeks? [09:48] mattyw, since you're the OCR along with myself, would you mind taking a look at this trivial fix? https://github.com/juju/juju/pull/659 [09:49] dimitern, looking [09:52] dimitern, done [09:53] dimitern, and thanks for pointing it out, the branch I'll be landing soon had some loggers I needed to rename [09:55] mattyw, cheers! [10:00] mattyw, mail sent\ [10:10] jam, can you take a look at https://github.com/juju/juju/pull/659 as well please? [10:20] dimitern: heya. want to fill me in on what you and markS talked about? [10:20] wallyworld_: /wave [10:20] jam: hi there, just otp, will ping soon [10:21] dimitern: so on https://github.com/juju/juju/pull/659 I'm wondering if we want to change the logging path, since if anyone was filtering theyd have to change their scripts [10:22] dimitern: review [10:22] reviewd [10:27] jam, you mean the prefixes? [10:27] dimitern: the logging prefixes, yes [10:27] but it seems better in the new place anyway [10:28] jam, yeah, and I've sent a mail to juju-dev, just in case someone complains, we can deal with it [10:28] jam, thanks, I'll merge it then [10:33] axw, those are precious.. thanks "A systems programmer will know what to do when society breaks down, because the systems programmer already lives in a world without law." [10:35] although the nosql bane line in the presentation takes the cake for me. bane voice. "let your reads and writes choose their own destiny." :-) [10:37] jam, did you have a chance to try the rudder charm or look at the readme. [10:38] hazmat: I looked through the readme, but I haven't played with it [10:38] its essentially just creating a tunneling network just like you would get installing openvswitch etc on each node [10:39] hazmat: :) [10:40] jam, in a nutshell, but its all coordinating the subnet split to host map without central point of failure and it works in environments that are gre hostile (azure). [10:41] and you don't really need openvswitch to do the point to point gre tunneling. [10:42] fwereade: the UpgradeInfo work is finally up for review. https://github.com/juju/juju/pull/660 [10:46] dimitern: standup? [10:47] jam, omw, sorry [10:52] morning [11:19] menn0, thanks, there is a small chance I will get to it today... [11:20] fwereade: it probably needs someone else to have a look as well given that we're the authors [11:20] fwereade: but it would be good to get your feedback on the change I made since you last looked at it [11:22] * perrito666 discovers new levels of heartburn [11:29] jam: hi, got time for a question? [11:31] wallyworld_: so I'm on the phone now myself, I'm happy to chat in IRC a bit [11:31] sure [11:45] perrito666, morning [11:45] mattyw: morning [11:45] wallyworld_: so what's your question? [11:45] perrito666, I managed to get that auth fails bug again this morning - but I wasn't looking for it when it happens :| [11:45] dimitern: thanks for fixing my fuckup [11:45] it never occred to me about the logger names [11:45] voidspace: http://paste.ubuntu.com/8214743/ [11:45] please consider my suggestion in reply [11:46] i think we can make the default case of the logger less of a footgun [11:46] davecheney: what is the call stack for top level var inits? [11:46] mgz, am I being hated again? https://github.com/juju/juju/pull/562 [11:46] mattyw: I presume you cannot make it happen willingly right? [11:46] jam it will have the package name in it [11:47] all package level vars are initalised by a faux init() function [11:47] bascically one per file [11:47] that is created by the compiler for you [11:47] hang on [11:47] i'll prove it [11:47] perrito666, well I've tried running just a subset of the tests that should show the error and I've got through hundreds of runs with no error. But I've seen it a couple of times during a make check [11:48] jam: so, i have a client api call that i can add params to. when run against older juju, the new params will be ignored. but i'd rather have the client detect what version of the api is running server side and warn the user. it's the EnsureAvailability() api call on client. can we up that one api call to version 2? or does it have to be done at the facade level? [11:48] mattyw: I have the theory that under a decent load on the testing machine you should be able to triggerit [11:48] jam: http://paste.ubuntu.com/8214777/ [11:49] davecheney, no worries :) [11:49] wallyworld_: api versioning is at the Facade level, and I would like us to bump the version if we change anything, even if it is "technically compatible" [11:49] ok, sad that the client facade is sooooo big [11:49] jam: back on freenode - rejoining hangout [11:50] jam: calling Remove on a replicaset is likely to cause primary renegotiation [11:50] jam: (I would expect) [11:50] davecheney, you heading out early on the sprint to hit go eu? [11:50] jam: which is why it would be slow [11:50] wallyworld_: agreed. would it be easier to move EnsureAvailability to a locally clustered API and version *that* one ? [11:50] hazmat: negative [11:50] jam: is the version gets bumped to V2, how will a caller know what methods may be incompatible or not? they won't. [11:50] hazmat: people couldn't get their shit sorted in time [11:50] so I couldn't change my flights [11:51] wallyworld_: they know only about the ones that they are using. So we will still expose v0 for clients that don't know about v2 [11:51] i'm going to dotGo only [11:51] wallyworld_: but no, we don't have WADL sort of thing so that you can programattically say "oh, v2 is exactly like v0 except for here" [11:51] davecheney, ugh. bummer. i was thinking of coming in for the day from brussels just to check it out. [11:51] hazmat: i wouldn't say no [11:51] jam: i could introduce a new facade. it makes sense that all apis on a facade should be bumped together [11:51] i'm going to be in paris from the 9th til the 12th [11:52] wallyworld_: you've already been part of the great Client breakup [11:52] Keyserver et al [11:52] jam: yes indeed, i was going to use the same technique [11:53] wallyworld_: just to mention, that all new facades should start at V1, as v0 is intended to be the version that was in 1.18 [11:53] jam: is there sample code that shows how to set up a new api version? point me where to look? [11:54] i guess there's a version number registered somewhere [11:54] wallyworld_: so just creating a new one is easy [11:54] the line of Register() [11:54] takes a 1 instead of a 0 [11:54] ok, ta [11:55] wallyworld_: the client side code needs to check what the supported version of the API is, and then fall back to the Client facade if it can't get to the new facade [11:55] how do it do that? in this case it doesn't matter as the new fascade will be there or not, but in general? [11:58] wallyworld_: Facade.BestAPIVersion() [11:58] thanks [11:59] jam: I think I'm back again, lost the hangout though *sigh* - really sorry [11:59] :) [12:01] TheMue: can you help wallyworld_ find the right API docs to figure out how to properly introduce a new Facade version? [12:01] jam: TheMue: in standup, will check back soon [12:01] I feel like we've documented all this, but I'm not finding the docs in our source tere. [12:01] tree. [12:03] wallyworld_: so there is a bit of "must be careful" here, I believe, which maybe we can make better. But for a Facade that didn't exist in 1.18, then "BestAPIVersion()" should return 0, which we "know" didn't exist, so your client code can tell that it should use the other facade. [12:04] It is also possible that the new client layer could do the transition without the cmd/juju stuff caring. [12:04] so we would have api/statemanagement/statemanagement.go [12:04] and that would embed a FacadeCaller for your new StateManagement facade [12:04] and it could have EnsureAvailability() on it [12:04] which internally would check [12:05] if self.BestAPIVersion() == 0 { // switch to old interface: [12:07] wallyworld_: back from lunch, ping me when available too [12:07] jam: I don't have the wireless router connected at all now, and my connection is via a switch [12:07] but you're still only either or? [12:10] mfoord: either IRC or Hangout, but never both... :) [12:12] jam: it still looks like my connection is being broken every minute [12:12] jam: I've emailed you [12:13] jam: I can browse and use email fine but both freenode and hangouts hate me [12:13] jam: I *have* to get IRC working as a very minimum [12:13] voidspace: yeah [12:13] I emailed you [12:13] good luck sorting it out [12:13] I'm close to EOD anyway [12:15] voidspace: it seems to be calling c.stopNow() which is fundamentally calling runtime.Goexit() [12:15] which certainly seems like it should be exiting ungracefully [12:16] voidspace: ah, goexit is just this goroutine [12:16] jam: looking at the traceback [12:16] eg, kill this thread, not kill this process [12:17] jam: so Remove didn't used to be an attemptLoop - but that was unreliable too because Remove *needs* to be an attemptLoop (for the same reason that the other operations do) [12:17] jam: we probably don't want Remove to be in a defer [12:17] voidspace: it doesn't help the traceback that we defer a func() that calls a function that takes a func() [12:17] right... [12:18] jam: we could just not defer those removes and do them at the end, that would simplify [12:19] jam: that function isn't used outside of those two tests I don't think - so it shouldn't matter (?) if a test fails and we don't call remove [12:19] voidspace: I wonder if we want to Remove at all [12:19] we'll clean up the replicaset anyway [12:19] I would think changing the test to just nuke everything would be cleaner [12:19] jam: well, it is "assertAddRemoveSet" [12:19] voidspace: so *those* Remove calls are just "cleanup what I set up" [12:19] because they are in defer [12:19] there is a call on line 241 [12:19] they are, but the test name implies we want to test that Remove works [12:19] that is the actual testing of Remove working [12:20] ah [12:20] TheMue: hi. i can read the code to see how to bump up an api version, or are there docs i can read? [12:20] that may also be the flakiness [12:20] voidspace: if we get an error, and the replicaset is in a bad state [12:20] and then we hammer it with "remove them one by one" [12:20] while I'm destroying some of them [12:20] I imagine it isn't happy with that [12:21] the tests setup a new replicaset every time - so perhaps we don't need those defered removes at all [12:21] as we call Destroy immediately after [12:21] voidspace: The only reason we *might* is if we wanted to not have to set up the Root to be shared between tests or something like that [12:21] but I have the feeling, we're better off *for the replicaset tests* to start and return to scratch each time [12:22] I know we share the DB between tests when we can, just calling Drop Databases in TestTearDown [12:22] but I don't think we need to do that here. [12:23] wallyworld_: do you know jams doc on Google? [12:23] jam: TearDownTest calls root.Destroy() [12:23] jam: and in the IPV6 suite we explicitly call Destroy ourselves [12:23] TheMue: i don't think so. i may have got an email at one point but can't recall now [12:24] TheMue: probably not. as the goal was to get them somewhere in the source tree/on juju.ubuntu.com and I think those never got finished [12:24] jam: so I don't think that's a concern [12:24] voidspace: right, so that is just the root, but yeah, we should just be clearer that we call Instance.Destroy() on everything and not try to Remove them down the stack [12:24] because cleaning up a Mongo Cluster by removing one, killing it, removing one, killing it [12:24] is likely to just cause us more pain that we need to be testing. [12:25] jam, wallyworld_: ah, ok. a part of it is here: https://github.com/TheMue/juju/blob/api-implementation-guide/doc/design/juju-api-implementation-guide.md [12:25] jam: we also defer the Destroy on the members [12:25] TheMue: thanks, will read that [12:25] jam: I only wait to get my current experiences with new facades into it too [12:26] wallyworld_: I'm currently writing some code helping to test the client side when the server side not yet has the newest version [12:26] ok, sounds good [12:26] TheMue: sure, so just share it as we can, and we should get it published soon. better to have something for reference. [12:27] jam: yep [12:27] even if it isn't 100% complete, as long as it isn't *incorrect* [12:38] jam: i need to be able to run ensure-availability with a placement directive to have a specified machine become a state server, not just any old new one. the guys are happy to pass in either a machine number or maas name (like in --to for add-unit). This will require either converting a HostUnits machine to a ManageEnvirons machine, since add-machine creates HostUnits machine, or 2. adding an option to add-machine to create a [12:38] ManageEnvirons machine which does not participate until activated. pros and cons to both. maybe there's a 3rd option. i think 1 may be most flexible. update machine jobs in state; a watcher in machine agent notices, updates agent conf to record the manageenviron job, then restarts machine agent. but i'm not fully across all of the HA mechanics so i'm not sure what else needs to be done. do you have any thoughts or should i ask nate [12:38] or william? [12:39] wallyworld_: what has never been clear from a MaaS guys is why they need to add-machine first [12:39] I realize they want to control locations [12:40] jam: this is landscape guys [12:40] and maybe there is a problem that they need to specify 2 machines [12:40] wallyworld_: sure, but its on MaaS [12:40] yes, >1 will be needed [12:40] --to foo,bar [12:40] wallyworld_: hey regarding https://github.com/juju/juju/pull/630/files#r16968425 [12:40] they want this machine right here to be the state server, not any other one [12:40] voidspace: lost you again ? [12:41] wallyworld_: will the updated config be persisted to environments.yaml making the change permanent? [12:41] wallyworld_: sure, I'm just wonderign why we need to "add-machine" first [12:41] can't we just "juju ensure-availability --??? maas-name:A,maas-name:B" [12:41] katco: it will get written to jenv, becoming permanent [12:41] wallyworld_: ahh ok. ty [12:42] jam: we could i guess, but that will be a bit of work, since we won't have run cloud init to set stuff up [12:42] wallyworld_: ? [12:43] wallyworld_: the point is that we can have ensure-availability still allocating machines, just give them the knob to say what machine [12:44] add-machine boots a machine and runs cloud init to set up the tools, agent config etc. if we don't do that and ensure-availability to an arbitrary machine, that machine still has to then be set up to run juju [12:44] wallyworld_: presumably they had a knob available on "add-machine" so that they could decide what that exact machine was [12:44] and couldn't we supply it on ensure-availability? [12:44] ah, i think the add-machine knob was to specify ssh: [12:45] that would take an existing machine and put juju on it [12:46] so i guess if we did juju ensure-availability --to maas-name:A,maas-name:B then that would have to ssh in and set up juju [12:47] wallyworld_: the idea is that they are manually provisioning with ssh? [12:47] "juju add-machine ssh:foo@bar" / [12:47] I thought they were just doing "juju add-machine" but with maas-name [12:47] to pick an explicit machine to proviison [12:47] provision [12:47] they want to use whatever they use with add-unit [12:47] add-unit --to blah [12:47] wallyworld_: add-unit or add-machine ? [12:47] same syntax as for add-unit [12:48] wallyworld_: AFAIK you can't add-unit to a manually provisioned machine [12:48] so a machine number or mass name, right? [12:48] wallyworld_: right, but that just requests a machine from the Provisioner, which lets us set up everything in cloud-init. [12:48] wallyworld_: now... I *hope* all of the EnsureMongoServer stuff has gotten done correctly so we can create a state server late [12:48] rather than only at cloud-init time. [12:49] So I'd be *happy* if "juju ensure-availability --to 1" worked correctly. But For what they're doing what they need is [12:49] "juju ensure-availability --to maas-name:A" [12:49] how does mass-name placement directive work then? does that assume a virgin maas machine? [12:49] not "juju ensure-availability --to 1" (I think) [12:49] wallyworld_: like tags [12:49] wallyworld_: each machine just has a unique name [12:50] with tags, that assumes that a maas machine is not running, but tagged in maas, and so is then booted with cloud init etc? [12:50] wallyworld_: right, same with maas-name [12:50] maas-name is a Provisioning constraint (placement directive) [12:51] give me a machine that fits this description [12:51] which happens to uniquely address one machine ever [12:51] ok, so "juju ensure-availability --to maas-name:A" would be like add-machine but setting it up to run a state server etc [12:51] wallyworld_: so... I'd like "juju ensure-availability --to 1,2" to work. But I'd really like to understand what Landscape is trying to do, as I feel that them doing "juju add-machine" first is actually bad practice [12:51] rather than host units [12:52] wallyworld_: (I think everything still gets host units, but it would also get JobManageEnviron) [12:52] yep [12:52] i think we can tell them what best practice is [12:52] i think not using add-machine is the right way to go [12:53] wallyworld_: I certainly understand their desire to say "ensure-availability and put it exactly here" [12:53] And we want to definitely support that case. [12:53]