[08:09] <fwereade_> morning wrtp, TheMue
[08:09] <wrtp> fwereade_: goat moanin'
[08:09] <TheMue> fwereade_, wrtp: morning
[08:09] <wrtp> TheMue: hiya
[08:10]  * TheMue just fights with a network equipment change
[08:11]  * wrtp managed to wire up the ethernet properly over the weekend. file server in the loft, GB ethernet throughout and no need to rely on dodgy wireless device drivers...
[08:12] <fwereade_> wrtp, cool
[08:12] <wrtp> (and i learned a new skill: how to wire an RJ45 jack)
[08:13] <fwereade_> wrtp, handy :)
[10:19] <fwereade_> TheMue, in my recent review, did my ramblings about naming make any sense?
[10:20] <TheMue> fwereade_: sorry, had only been able to do a first scanning. will discuss it later, currently my network doesn't e'thing right
[11:58] <TheMue> fwereade_: around?
[12:12] <fwereade_> TheMue, heyhey
[12:12] <fwereade_> TheMue, having lunch shortly but good to chat for now
[12:13] <fwereade_> TheMue, ...or maybe not
[12:13] <TheMue> fwereade_: ok, can wait
[12:13] <fwereade_> TheMue, laura's making it complicated;)
[12:13] <TheMue> fwereade_: already had lunch ;)
[12:48] <fwereade_> TheMue, heyhey, all fed and peaceful now :)
[12:48] <fwereade_> TheMue, what can I do for you?
[12:48] <TheMue> fwereade_: ha, know that fealing
[12:48] <TheMue> fwereade_: discussing about the retry mode
[12:48] <fwereade_> TheMue, ah, yes,cool
[12:49] <fwereade_> TheMue, what do you think of "resolution" as associated noun?
[12:49] <fwereade_> TheMue, I'm against RetryMode now because, really, only one of the 3 states involves retrying anything
[12:50] <TheMue> fwereade_: if that's the semantics behind it i'm fine with "resultution"
[12:50] <TheMue> fwereade_: sadly inside the node the content is "retry = ..."
[12:51] <fwereade_> TheMue, heh, yeah, I'm afraid we're stuck with that
[12:51] <TheMue> fwereade_: but i think that's a weakness we can live with
[12:55] <TheMue> fwereade_: i selected -1 for NotResolved because 0 is the default for an unset int. and i don't wan't this value by accident. -1 is more expressive here.
[12:56] <fwereade_> TheMue, hm, it seemed to me that NotResolved would be a sensible default value for an unst var
[12:56] <fwereade_> unset
[12:57] <TheMue> fwereade_: NotResolved is ok for an unset reply, yes, but returning an uninitialized int by accident with this value may lead to a wrong handling later.
[12:58] <TheMue> fwereade_: so with one of -1, 1000 or 1001 it's more clear
[12:58] <fwereade_> TheMue, ok, makes sense, I'm comfortable with that :)
[12:59] <TheMue> fwereade_: what do you say to the change after rogs idea of giving it an own type?
[12:59] <fwereade_> TheMue, yeah, can't see any harm in that
[12:59] <TheMue> fwereade_: i like it, even if it has just three valid values.
[12:59] <fwereade_> TheMue, you can tack the Validate func onto thattype too
[13:00] <TheMue> fwereade_: oh, havn't i, damn
[13:00] <fwereade_> TheMue, heh maybe you have I didn't check
[13:00] <TheMue> fwereade_: the new/old naming is ok, will change it
[13:00] <fwereade_> TheMue, cool
[13:01] <fwereade_> TheMue, just makes it a little easier for me to follow
[13:01] <TheMue> fwereade_: it has already the type, phew
[13:01] <fwereade_> TheMue, cool, sorry about that :)
[13:01] <TheMue> fwereade_: np
[13:28] <TheMue> fwereade_: btw, which kind of errors are handled with the Resolved functions of Unit?
[13:28] <fwereade_> TheMue, any state transition error
[13:28] <fwereade_> TheMue, ie hooks
[13:28] <TheMue> fwereade_: ic, thx
[13:29] <fwereade_> TheMue, but also potentially things that might go wrong before a hook starts
[13:29] <fwereade_> TheMue, failing to download the new version of a charm while upgrading for example
[13:29] <fwereade_> TheMue, anything that puts us into an error state
[13:30] <TheMue> fwereade_: and in this case the "resolved" flag is set?
[13:31] <fwereade_> TheMue, you do "juju resolved <broken-thing>" and tack on a --retry if you want torun the hook again
[13:33] <TheMue> fwereade_: does that command set the flag?
[13:33] <niemeyer> Good morning everybody
[13:33] <TheMue> niemeyer: morning
[13:33] <fwereade_> TheMue, yeah, to whichever value, controlled by --retry
[13:33] <fwereade_> heya niemeyer
[13:36] <TheMue> fwereade_: and then? i still don't have the worklow behind it. something fails and that needs to be resolved. after it's done (manually?) who clears that "resolved"?
[13:37] <fwereade_> TheMue, the agent reads the value, clears it, and tries to do what it was asked
[13:37] <fwereade_> TheMue, think of the clearing as the unit agent taking over responsibility
[13:38] <TheMue> fwereade_: ok, i only wondered about the passive version "resolved" instead of "need error resolution"
[13:39] <niemeyer> TheMue: That's intentional.. if you type "juju resolved" you're saying "the problem has been resolved and it's fine to continue"
[13:39] <fwereade_> TheMue, not quite sure I follow
[13:39] <fwereade_> TheMue, what niemeyer said :)
[13:39] <niemeyer> TheMue: It's a statement saying it's good to go now, rather than "fix it for me"
[13:42] <TheMue> niemeyer: ok, this way it sounds reasonable. thx
[14:44] <niemeyer> TheMue: So, go-state-continued-machine is the bottom of your queue, right?
[14:45] <TheMue> niemeyer: just took a look, yes, it is
[14:45] <niemeyer> TheMue: Ok, I see it still has comments from fwereade_ unaddressed, though
[14:46] <niemeyer> TheMue: Are you working on those now?
[14:46] <TheMue> niemeyer: after re-propose the go-state-continued-unit a few moments ago i would now continue with that one.
[14:46] <niemeyer> fwereade_: Btw, you've recommended: "It'd be quite nice to move this out into its own little internalMachineId func
[14:46] <niemeyer> "
[14:47] <fwereade_> niemeyer, yep; disagree?
[14:47] <niemeyer> fwereade_: Ah, sorry, nevermind.. I totally missed what you actually meant
[14:47] <fwereade_> niemeyer, ah ok,sorry unclear :)
[14:47] <niemeyer> fwereade_: No.. I misunderstood.. and talking to myself helped :-D
[14:47] <TheMue> niemeyer: *lol*
[14:47] <niemeyer> fwereade_: It was clear, I was on crack
[14:48] <niemeyer> TheMue: Is go-state-continued-unit dependent on the go-state-continued-machine, or is it an independent branch that I can review on its own?
[14:50] <TheMue> niemeyer: it doesn't depend
[14:50] <niemeyer> TheMue: Super, thanks
[15:11] <fwereade_> need to pop out briefly, bbs
[15:40] <niemeyer> TheMue: You've got a review
[15:40] <niemeyer> fwereade_: Will pick one of yours when I'm back from lunch
[16:01] <rogpeppe> niemeyer, fwereade_, TheMue: small review for you: https://codereview.appspot.com/5754086
[16:03] <TheMue> niemeyer: thx
[16:41] <TheMue> niemeyer: do you know the reason why remove_machine_state returns a boolean which only has the one use that the only caller raises an exception when it's false?
[17:43] <niemeyer> TheMue: Isn't that the case we talked about last week?
[17:57] <niemeyer> rogpeppe: LGTM, cheers
[17:57] <rogpeppe> niemeyer: thanks
[17:59] <fwereade_> whoops, eod, I think cath could use some help; nn all, and I'd love it if I came back to some reviews tomorrow ;)
[18:13] <niemeyer> fwereade_: You'll have some of them
[18:13] <niemeyer> :)
[18:13] <niemeyer> fwereade_: Sorry for not getting to those today
[18:13] <niemeyer> TheMue: You just got a LGTM, though
[18:14] <TheMue> niemeyer: ah, fine
[18:14] <rogpeppe> niemeyer: http://paste.ubuntu.com/880728/
[18:15] <rogpeppe> niemeyer: but i gotta go 5 minutes ago
[18:15] <rogpeppe> niemeyer: see y'all tomorrow
[18:15] <TheMue> niemeyer: the topic above is the case of last week. before i change it i just wonna get sure that there's no needed idea behind it.
[18:17] <niemeyer> rogpeppe: Please ping me when you have some time..
[18:17] <niemeyer> rogpeppe: And enjoy your ROD
[18:33] <niemeyer> fwereade_: and you got a review as well
[18:35] <TheMue> niemeyer: last propose before submit is in
[18:50] <niemeyer> TheMue: Checking
[18:51] <niemeyer> TheMue: The comment for Resolved is still bogus
[18:52] <niemeyer> TheMue: Arguably, the improvement is small, but since you said "Done", I'm not sure if you didn't appreciate the suggested comment or just overlooked it
[18:53] <TheMue> niemeyer: mom, taking a look
[18:54] <niemeyer> TheMue: "mom" isn't a great abbreviation for "moment", btw ;-D
[18:55] <TheMue> niemeyer: hmm, knowing it as common abbrev: mom pls for one moment please
[18:56] <niemeyer> TheMue: https://www.google.com/search?q=define%3Amom
[18:57] <TheMue> niemeyer: found my mistake, only looked to the wrong naming that has been a result of the search'n'replace
[19:01] <niemeyer> TheMue: np.. please submit it
[19:01] <niemeyer> TheMue: (with the fix)
[19:02] <TheMue> niemeyer: ok, will go in now
[19:08] <TheMue> niemeyer: so, it's in, time to leave
[19:14] <niemeyer> TheMue: Have a good time
[19:15] <TheMue> niemeyer: thx, have a good ROD too
[19:48] <niemeyer> fwereade_: One of your branches seems to be affected by the problem rogpeppe pointed out..
[19:48] <niemeyer> fwereade_: https://codereview.appspot.com/5786051/
[20:48] <fwereade_> niemeyer, huh, I'll take a look at the testutil weirdness
[20:48] <niemeyer> fwereade_: I'm fixing a.. hmm.. questionable behavior I implemented in goetveld
[20:48] <fwereade_> niemeyer, about the go-hook-package branch (if you have a mo?)
[20:48] <niemeyer> fwereade_: Not sure if for some reason they started to forbid it
[20:48] <niemeyer> fwereade_: I do
[20:50] <fwereade_> niemeyer, (1) I suspect Env probably actually shouldn't be separate from context, it seemed separate at the time; in practice I think it'll make sense to tack it onto context
[20:51] <fwereade_> niemeyer, (2) the temporary path addition is because it seems better to just make meaningless commands entirely unavailable, rather than available-but-guaranteed-to-error
[20:51] <fwereade_> niemeyer, "this command doesn't exist" seems like the clearest way to denote thatthere's no good reason to call it
[20:52] <fwereade_> niemeyer, and I like the idea of minimising pollution of command space
[20:52] <niemeyer> fwereade_: I'm not following (2).. missing more foundational reasoning about why we're using "command" there at all
[20:53] <fwereade_> niemeyer, same general idea as not importing stuff you don;t use
[20:53] <niemeyer> fwereade_: It's a function to call a hook.. which "command" is that?
[20:53] <fwereade_> niemeyer, it's called via jujuc but it's still fundamentally a command line tool
[20:54] <fwereade_> niemeyer, (thatis, everything called from a hook is)
[20:54] <niemeyer> fwereade_: Yeah, but why is this relevant at all to the function that calls a hook?
[20:54] <fwereade_> niemeyer, the function that calls the hook makes (1) the env vars and (2) the relevant "executables" available for use by the hook
[20:55] <niemeyer> fwereade_: Precisely.. why is (2) being done at all?
[20:55] <fwereade_> niemeyer, for the reasons above... what's the benefit of making available a whole bunch of tools that can't be used?
[20:56] <niemeyer> fwereade_: Having the command that runs another command create symlinks as it calls the other command is a bit novel and unexpected
[20:57] <fwereade_> niemeyer, do the 3 uses of command there refer to agent, hook, hook-tool respectively?
[20:57] <niemeyer> fwereade_: It refers to Linux commands in general
[20:57] <niemeyer> fwereade_: Unset your DISPLAY environment variable and call "xeyes"
[20:58] <niemeyer> fwereade_: You'll get an error like this: Error: Can't open display:
[20:58] <niemeyer> fwereade_: The environment wasn't set properly for it to run
[20:58] <niemeyer> fwereade_: We don't hide xeyes away just because we can't run it if there's no good environment for it to run
[20:59] <niemeyer> fwereade_: The commands that are available to a hook are normal Linux executables, and they will be found in the PATH
[21:00] <fwereade_> niemeyer, but if you could guarantee that the environment was bad, what benefit would there be to making it available?
[21:01] <fwereade_> niemeyer, is there a situation in which it would be a good idea to let people hack up a JUJU_CLIENT_ID and call these tools out-of-band?
[21:02] <niemeyer> fwereade_: a) Because that's how everything in Linux works; b) Because that won't write and remove several inodes in the disk on every access; c) Because we'll eventually run these commands out of band as we discussed previously
[21:03] <fwereade_> niemeyer, heh, I had the impression that we explicitly restricted that idea to making other relations available to hooks
[21:03] <fwereade_> niemeyer, do they ever make sense entirely outside hooks?
[21:03] <niemeyer> fwereade_: That's always been the idea, at least
[21:03] <niemeyer> fwereade_: relation-set $RELATION system-on-fire=true
[21:04] <niemeyer> fwereade_: Think about what happens once the system reaches stability..
[21:04] <niemeyer> fwereade_: all hooks were run
[21:04] <niemeyer> fwereade_: If we don't allow out-of-band changes in relations, we're severely restricting what people can do via relations
[21:05] <niemeyer> fwereade_: It basically means a working system can't change relations after started, unless it breaks
[21:06] <fwereade_> niemeyer, so relation-set could be called entirely outside juju's control?
[21:06] <niemeyer> fwereade_: Let's paint a brighter picture.. relation-set is always under juju's control.. :-)
[21:07] <fwereade_> niemeyer, haha, ok, let me restate: relation-set can be *called* as part of an unrelated script on a system, and that should be meaningful?
[21:07] <niemeyer> fwereade_: Even then, that's not very relevant to this discussion, to be honest.. even if that wasn't the case, it'd still not make sense to be creating and removing several symlinks *every time a hook is run*
[21:08] <niemeyer> fwereade_: Yes, I hope we can make that meaningful in a clean way
[21:08] <niemeyer> fwereade_: and I don't think it's hard even
[21:09] <fwereade_> niemeyer, well IMO this is the crux of it, please expand; that'll probably convince me to drop it entirely
[21:10] <niemeyer> fwereade_: Which statement is "this" referring to?
[21:10] <fwereade_> niemeyer, sorry, the meaningful relation-set not inside a hook
[21:10] <fwereade_> niemeyer, I don't see what could cause thattohappen
[21:11] <niemeyer> fwereade_: Anything that happens on the machine
[21:11] <niemeyer> fwereade_: Right now the usefulness of relations is severely restricted to being modifiable inside a hook only
[21:11] <niemeyer> fwereade_: Which means all events in a relation happen as a side-effect of the relation going up, or the relation going down
[21:12] <fwereade_> niemeyer, a use case would be a great help to me here
[21:12] <niemeyer> fwereade_: Everything else in between, which is where the application will hopefully spend most of its time, can't make use of relations because there's no out-of-band changing of relations
[21:12] <niemeyer> fwereade_: I just described one above..
[21:12] <niemeyer> fwereade_: relation-set $MONITORING_RELATION the-system-is-on-fire
[21:12] <niemeyer> fwereade_: relation-set $MONITORING_RELATION the-system-is-on-fire=1
[21:13] <niemeyer> fwereade_: relation-set $RELATION load-is-too-high=1
[21:13] <niemeyer> fwereade_: relation-set $RELATION I-got-a-new-user=1
[21:13] <niemeyer> fwereade_: relation-set $RELATION I-need-another-database=customers
[21:13] <niemeyer> fwereade_: relation-set $RELATION send-an-sms-to-fwereade
[21:13] <niemeyer> :)
[21:14] <niemeyer> Anything, really.. there are many more out-of-band use cases than there are for setup/teardown
[21:15] <fwereade_> niemeyer, ok, this involves a somewhat different conception of a charm to what I'd had before... I'm still a bit unclear about the mechanism in play
[21:15] <fwereade_> niemeyer, can we look at load-is-too-high in a bit more detail?
[21:15] <niemeyer> fwereade_: Sure.. what's the question, more precisely?
[21:16] <fwereade_> niemeyer, it seems we're talking about a charm that includes some sort of monitoring of the service, and which can call a shell script in response to ...something happening
[21:16] <fwereade_> niemeyer, I'm unclear what that something would be
[21:17] <niemeyer> fwereade_: We're talking about a software that can execute a command when something happens..
[21:17] <niemeyer> fwereade_: This sounds pretty straightforward
[21:17] <niemeyer> fwereade_: What are you unclear about there?
[21:17] <fwereade_> niemeyer, sure, not an overwhelmingly original concept when put like that :)
[21:18] <niemeyer> :-)
[21:19] <fwereade_> niemeyer, ok, I think that scotches the idea, which rested entirely on my conception that hook commands would not be generally useful
[21:22] <fwereade_> niemeyer, I maintain that, assuming the above, PATH manipulation is a perfectly normal thing and the cost of writing a few symlinks is not significant in the context of a hook execution, but that's neither here nor there
[21:22] <fwereade_> niemeyer, huh, I just realised how that sounded
[21:22] <fwereade_> niemeyer, yes, but ASSUMING there was a dragon in your bed it was perfectly reasonable to set of the fire extinguisher
[21:22] <niemeyer> fwereade_: PATH manipulation is.. writing a handful of symlinks every single time one of the hooks is run sits at the questionable side for me
[21:27] <fwereade_> niemeyer, it rested entirely on the assumption that the set of meaningful commands was context-dependent and potentially subject to change, which was what I took away from the recent discussions
[21:27] <fwereade_> ah well :)
[21:28] <niemeyer> fwereade_: A lot of /usr/bin/* is context dependent..
[21:29] <niemeyer> fwereade_: Just think about how many of those only work under X, or after you started LXC, etc
[21:29] <fwereade_> niemeyer, seems different somehow... similar to how you wouldn't even bother to install a gui tool for managing your database on a headless server
[21:30] <niemeyer> fwereade_: Many other put binaries under /usr/lib/, that are only ever run by themselves
[21:30] <fwereade_> niemeyer, but starting LXC makes commands meaningful in a range of contextx that the LXC-starting cannot control
[21:31] <niemeyer> fwereade_: Ok.. let's go the other way around then.. please find me a command that creates symlinks on demand ;-)
[21:32] <fwereade_> niemeyer, I'm not sure I buy the idea that if a tool is sometimes relevant it should *always* be available -- just thata tool should always be available in any context in which it *might* make sense
[21:32] <fwereade_> niemeyer, er, `ln` :p
[21:32] <fwereade_> (sorry)
[21:32] <niemeyer> fwereade_: Haha
[21:33] <fwereade_> niemeyer, but still, it remains a derail due to my own missed context
[21:34] <fwereade_> niemeyer, maybe one day I'll find a situation in which it really does make sense
[21:41] <fwereade_> niemeyer, btw, I'm now worrying that you'll disapprove of the general idea of the parallel pipeline -- which makes jujuc *purely* a proxy which sends command lines back tothe agent for interpretation, and gets back output+return code
[21:42] <rogpeppe> fwereade_: i'm interested to see gustavo's point of view on this :-)
[21:42]  * rogpeppe stands well back
[21:43] <fwereade_> niemeyer, the tradeoff is in *slightly* more complexity in cmd, in exchange for removal of (what feels to me like) unnecessarily complex plumbing in the python, and surprisingly neat reuse of supercommand
[21:44] <niemeyer> fwereade_: That sounds unrelated, even though if I have to be honest I'd say it's a bit suspect to have the juju server parsing command lines for its clients
[21:44] <fwereade_> niemeyer, it's something I did recently that you haven't reviewed yet ;)
[21:45]  * fwereade_ looks resigned
[21:47]  * fwereade_ steps up gamely anyway
[21:47] <fwereade_> niemeyer, well, can we agree to begin with that all the meaningful work in a hook command is actually performed by the agent?
[21:48] <niemeyer> :-)
[21:48] <niemeyer> fwereade_: Yes
[21:50] <fwereade_> niemeyer, and the total work is: (1) figure out what the hook's asking for; (2) do it by interacting with the hook context in some way; (3) give the result back
[21:52] <fwereade_> niemeyer, in python we have a whole lot of plumbing -- server with 8 methods, client with 8 methods, declaration of params and return types for all those methods, and individual executables that turn a command line into params and results back into output/exit codes
[21:53] <niemeyer> fwereade_: You'll need pretty much all of that somewhere
[21:53] <niemeyer> fwereade_: Reuse is great.. you can reuse in either side
[21:54] <fwereade_> niemeyer, we get all the same functionality with one method -- "run this command line" -- with one result type -- out, err, code
[21:54] <fwereade_> niemeyer, and that allows you to write all the commands as Command implementations that interact directly with the context
[21:55] <niemeyer> fwereade_: You can write all commands as command implementations interacting with the context either way, and you have to do line parsing either way
[21:56] <fwereade_> niemeyer, where the line parsing happens only matters in that *if* we do it in jujuc we need a lot more plumbing to interact with the context
[21:57] <niemeyer> fwereade_: Why?
[21:57] <niemeyer> fwereade_: What's that lot?  I think that's the crux there
[21:57] <fwereade_> niemeyer, whereas doing it in the agent allows us to use Command implementations that already have the relevant context directly accessible
[21:58] <fwereade_> niemeyer, mainly juju.hooks.protocol
[21:59] <fwereade_> niemeyer, which feels to me like a lot of code whose only effect is to obfuscate what's actually happening :/
[22:00] <niemeyer> fwereade_: Ok, I'm fine to see the branch implementing it.. if it's indeed considerably simpler, I'm game
[22:01] <fwereade_> niemeyer, I fear I'm going to put you off irretrievably when I say it's 4 branches... but I really did try to make each as focused and independent as possible
[22:02] <niemeyer> fwereade_: That doesn't put me off at all
[22:02] <niemeyer> fwereade_: I'm all for several small branches
[22:02] <fwereade_> niemeyer, good-oh
[22:03] <fwereade_> niemeyer, the only trouble with that approach is that it opens the early branches up to a lot of "but why?" questions that are best answered "because $followup", and that ratherdetracts from the benefits of the several-small-branches approach
[22:04] <niemeyer> fwereade_: Well, that's what the description is for :)
[22:04] <niemeyer> fwereade_: But it has to be a reasonable way to walk towards the achievement
[22:05] <fwereade_> niemeyer, I might take another look at those, the first one feels rather more what-than-why in hindsight
[22:05] <niemeyer> fwereade_: What causes discussions is that when rallying to implement a larger portion, it's easy to forget about some of the details
[22:05] <niemeyer> fwereade_: That's what happened with today's branches, for instance
[22:05] <niemeyer> fwereade_: It's quite useless without more stuff
[22:05] <niemeyer> fwereade_: BUT
[22:06] <niemeyer> fwereade_: It's easy to see where the feature is going.. the debate was about how that was being done, not why
[22:06] <fwereade_> niemeyer, yes indeed :)
[22:07] <fwereade_> niemeyer, btw, tyvm for the clarification on out-of-band hook commands, was edifying
[22:08] <niemeyer> fwereade_: You're very welcome. Glad to have had it too
[22:12] <fwereade_> niemeyer, btw, if a branch is already WIP, I presume I still need to `lbox propose -prep` to prevent it being promoted?
[22:13] <niemeyer> fwereade_: Right
[22:13] <fwereade_> niemeyer, cheers, justchecking :)
[22:13] <niemeyer> fwereade_: np
[23:00] <niemeyer> fwereade_: Just in case you're still around, would you mind to run "apt-get update; apt-get install lbox" and "lbox propose" in that bogus branch again?
[23:01] <fwereade_> niemeyer, sure, justa mo
[23:01] <niemeyer> fwereade_: Superb, thanks a lot
[23:01] <niemeyer> fwereade_: I've removed a silly hack I had, which might actually be considered a bug
[23:01] <niemeyer> fwereade_: It used to embed the revision information at the top of the file
[23:02] <niemeyer> fwereade_: I'm not sure if that's what confused Rietveld somehow after some upgrade they made
[23:02] <niemeyer> fwereade_: Either way, that means we'll now see which files _actually_ changed across different "propose" commands, which is awesome
[23:06] <fwereade_> niemeyer, https://codereview.appspot.com/5786051
[23:06] <fwereade_> niemeyer, there's a surprising [revision details] in there now
[23:06] <fwereade_> niemeyer, but OTOH atleast you can see the diffs
[23:16] <niemeyer> fwereade_: Yeah, the surprising revision details isn't so surprising for me ;-)
[23:22] <niemeyer> and another review..
[23:37] <fwereade_> niemeyer, thanks
[23:38] <fwereade_> niemeyer, I'm not strongly inclined to put all the `var _ = Suite(...`s into init()s in *this* branch -- that feels like a separate trivial to me
[23:39] <fwereade_> niemeyer, sensible?
[23:41] <bigjools> hi folks
[23:43] <bigjools> can anyone point me at some docs help me out, I am trying to work out the sequence of events that happens during bootstrap and deployment
[23:45] <fwereade_> bigjools, I'm not sure about docs, but I may be able to help?
[23:46] <bigjools> fwereade_: ah col
[23:46] <bigjools> cool
[23:47] <bigjools> so for the maas stuff I have bootstrap saying it's worked - I see a node start up on the maas side
[23:47] <bigjools> but then trying to use deploy results in it complaining that zookeeper is not running
[23:47] <bigjools> I thought I'd better try and understand exactly what needs to happen to be able to debug this
[23:48] <fwereade_> bigjools, hmm; it's definitely not that zk just isn't running *yet*?
[23:48] <bigjools> oh how long does it take?
[23:49] <bigjools> and what initiates that?
[23:49] <fwereade_> bigjools, once you have an instance, just about everything that happens should be covered by the cloud-init stuff
[23:50] <bigjools> ah ok, so bootstrap kicks it all off
[23:50] <bigjools> I'll ssh in to the node and see if it's starting up
[23:50] <fwereade_> bigjools, yeah; that's the best place to start
[23:51] <fwereade_> bigjools, I'm afraid I know nothing about debugging cloud-init though
[23:51] <bigjools> you and me both :)
[23:51] <fwereade_> bigjools, I have a feeling something useful should be logged somewhere, but... yeah, that's not very helpful ;)
[23:51] <bigjools> heh