| === asavu_ is now known as asavu | ||
| fwereade_ | morning wrtp, TheMue | 08:09 |
|---|---|---|
| wrtp | fwereade_: goat moanin' | 08:09 |
| TheMue | fwereade_, wrtp: morning | 08:09 |
| wrtp | TheMue: hiya | 08:09 |
| * TheMue just fights with a network equipment change | 08:10 | |
| * 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:11 | |
| fwereade_ | wrtp, cool | 08:12 |
| wrtp | (and i learned a new skill: how to wire an RJ45 jack) | 08:12 |
| fwereade_ | wrtp, handy :) | 08:13 |
| === Leseb_ is now known as Leseb | ||
| === asavu_ is now known as asavu | ||
| fwereade_ | TheMue, in my recent review, did my ramblings about naming make any sense? | 10:19 |
| TheMue | fwereade_: sorry, had only been able to do a first scanning. will discuss it later, currently my network doesn't e'thing right | 10:20 |
| === asavu_ is now known as asavu | ||
| === asavu__ is now known as asavu | ||
| TheMue | fwereade_: around? | 11:58 |
| fwereade_ | TheMue, heyhey | 12:12 |
| fwereade_ | TheMue, having lunch shortly but good to chat for now | 12:12 |
| 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:13 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:55 |
| fwereade_ | TheMue, hm, it seemed to me that NotResolved would be a sensible default value for an unst var | 12:56 |
| fwereade_ | unset | 12:56 |
| 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:57 |
| 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:58 |
| 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 | 12:59 |
| 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:00 |
| 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:01 |
| 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:28 |
| 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:29 |
| TheMue | fwereade_: and in this case the "resolved" flag is set? | 13:30 |
| fwereade_ | TheMue, you do "juju resolved <broken-thing>" and tack on a --retry if you want torun the hook again | 13:31 |
| 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:33 |
| 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:36 |
| === asavu_ is now known as asavu | ||
| 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:37 |
| TheMue | fwereade_: ok, i only wondered about the passive version "resolved" instead of "need error resolution" | 13:38 |
| 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:39 |
| TheMue | niemeyer: ok, this way it sounds reasonable. thx | 13:42 |
| === asavu_ is now known as asavu | ||
| niemeyer | TheMue: So, go-state-continued-machine is the bottom of your queue, right? | 14:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| TheMue | niemeyer: it doesn't depend | 14:50 |
| niemeyer | TheMue: Super, thanks | 14:50 |
| fwereade_ | need to pop out briefly, bbs | 15:11 |
| niemeyer | TheMue: You've got a review | 15:40 |
| niemeyer | fwereade_: Will pick one of yours when I'm back from lunch | 15:40 |
| rogpeppe | niemeyer, fwereade_, TheMue: small review for you: https://codereview.appspot.com/5754086 | 16:01 |
| TheMue | niemeyer: thx | 16:03 |
| 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? | 16:41 |
| niemeyer | TheMue: Isn't that the case we talked about last week? | 17:43 |
| niemeyer | rogpeppe: LGTM, cheers | 17:57 |
| rogpeppe | niemeyer: thanks | 17:57 |
| 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 ;) | 17:59 |
| 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:13 |
| TheMue | niemeyer: ah, fine | 18:14 |
| rogpeppe | niemeyer: http://paste.ubuntu.com/880728/ | 18:14 |
| 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:15 |
| niemeyer | rogpeppe: Please ping me when you have some time.. | 18:17 |
| niemeyer | rogpeppe: And enjoy your ROD | 18:17 |
| niemeyer | fwereade_: and you got a review as well | 18:33 |
| TheMue | niemeyer: last propose before submit is in | 18:35 |
| niemeyer | TheMue: Checking | 18:50 |
| niemeyer | TheMue: The comment for Resolved is still bogus | 18:51 |
| 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:52 |
| TheMue | niemeyer: mom, taking a look | 18:53 |
| niemeyer | TheMue: "mom" isn't a great abbreviation for "moment", btw ;-D | 18:54 |
| TheMue | niemeyer: hmm, knowing it as common abbrev: mom pls for one moment please | 18:55 |
| niemeyer | TheMue: https://www.google.com/search?q=define%3Amom | 18:56 |
| TheMue | niemeyer: found my mistake, only looked to the wrong naming that has been a result of the search'n'replace | 18:57 |
| niemeyer | TheMue: np.. please submit it | 19:01 |
| niemeyer | TheMue: (with the fix) | 19:01 |
| TheMue | niemeyer: ok, will go in now | 19:02 |
| TheMue | niemeyer: so, it's in, time to leave | 19:08 |
| niemeyer | TheMue: Have a good time | 19:14 |
| TheMue | niemeyer: thx, have a good ROD too | 19:15 |
| 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/ | 19: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:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| niemeyer | fwereade_: Having the command that runs another command create symlinks as it calls the other command is a bit novel and unexpected | 20:56 |
| 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:57 |
| 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:58 |
| niemeyer | fwereade_: The commands that are available to a hook are normal Linux executables, and they will be found in the PATH | 20:59 |
| fwereade_ | niemeyer, but if you could guarantee that the environment was bad, what benefit would there be to making it available? | 21:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| niemeyer | fwereade_: It basically means a working system can't change relations after started, unless it breaks | 21:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| fwereade_ | niemeyer, well IMO this is the crux of it, please expand; that'll probably convince me to drop it entirely | 21:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| niemeyer | Anything, really.. there are many more out-of-band use cases than there are for setup/teardown | 21:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| niemeyer | :-) | 21:18 |
| fwereade_ | niemeyer, ok, I think that scotches the idea, which rested entirely on my conception that hook commands would not be generally useful | 21:19 |
| 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:22 |
| 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:27 |
| niemeyer | fwereade_: A lot of /usr/bin/* is context dependent.. | 21:28 |
| 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:29 |
| 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:30 |
| niemeyer | fwereade_: Ok.. let's go the other way around then.. please find me a command that creates symlinks on demand ;-) | 21:31 |
| 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:32 |
| fwereade_ | niemeyer, but still, it remains a derail due to my own missed context | 21:33 |
| fwereade_ | niemeyer, maybe one day I'll find a situation in which it really does make sense | 21:34 |
| 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:41 |
| rogpeppe | fwereade_: i'm interested to see gustavo's point of view on this :-) | 21:42 |
| * rogpeppe stands well back | 21:42 | |
| 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:43 |
| 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:44 |
| * fwereade_ looks resigned | 21:45 | |
| * 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:47 |
| niemeyer | :-) | 21:48 |
| niemeyer | fwereade_: Yes | 21:48 |
| 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:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| fwereade_ | niemeyer, mainly juju.hooks.protocol | 21:58 |
| fwereade_ | niemeyer, which feels to me like a lot of code whose only effect is to obfuscate what's actually happening :/ | 21:59 |
| niemeyer | fwereade_: Ok, I'm fine to see the branch implementing it.. if it's indeed considerably simpler, I'm game | 22:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| fwereade_ | niemeyer, btw, tyvm for the clarification on out-of-band hook commands, was edifying | 22:07 |
| niemeyer | fwereade_: You're very welcome. Glad to have had it too | 22:08 |
| fwereade_ | niemeyer, btw, if a branch is already WIP, I presume I still need to `lbox propose -prep` to prevent it being promoted? | 22:12 |
| niemeyer | fwereade_: Right | 22:13 |
| fwereade_ | niemeyer, cheers, justchecking :) | 22:13 |
| niemeyer | fwereade_: np | 22:13 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:06 |
| niemeyer | fwereade_: Yeah, the surprising revision details isn't so surprising for me ;-) | 23:16 |
| niemeyer | and another review.. | 23:22 |
| fwereade_ | niemeyer, thanks | 23:37 |
| 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:38 |
| fwereade_ | niemeyer, sensible? | 23:39 |
| bigjools | hi folks | 23:41 |
| 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:43 |
| fwereade_ | bigjools, I'm not sure about docs, but I may be able to help? | 23:45 |
| bigjools | fwereade_: ah col | 23:46 |
| bigjools | cool | 23:46 |
| 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:47 |
| fwereade_ | bigjools, hmm; it's definitely not that zk just isn't running *yet*? | 23:48 |
| bigjools | oh how long does it take? | 23:48 |
| 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:49 |
| 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:50 |
| 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 | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!