=== asavu_ is now known as asavu [08:09] morning wrtp, TheMue [08:09] fwereade_: goat moanin' [08:09] fwereade_, wrtp: morning [08:09] 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] wrtp, cool [08:12] (and i learned a new skill: how to wire an RJ45 jack) [08:13] wrtp, handy :) === Leseb_ is now known as Leseb === asavu_ is now known as asavu [10:19] TheMue, in my recent review, did my ramblings about naming make any sense? [10:20] fwereade_: sorry, had only been able to do a first scanning. will discuss it later, currently my network doesn't e'thing right === asavu_ is now known as asavu === asavu__ is now known as asavu [11:58] fwereade_: around? [12:12] TheMue, heyhey [12:12] TheMue, having lunch shortly but good to chat for now [12:13] TheMue, ...or maybe not [12:13] fwereade_: ok, can wait [12:13] TheMue, laura's making it complicated;) [12:13] fwereade_: already had lunch ;) [12:48] TheMue, heyhey, all fed and peaceful now :) [12:48] TheMue, what can I do for you? [12:48] fwereade_: ha, know that fealing [12:48] fwereade_: discussing about the retry mode [12:48] TheMue, ah, yes,cool [12:49] TheMue, what do you think of "resolution" as associated noun? [12:49] TheMue, I'm against RetryMode now because, really, only one of the 3 states involves retrying anything [12:50] fwereade_: if that's the semantics behind it i'm fine with "resultution" [12:50] fwereade_: sadly inside the node the content is "retry = ..." [12:51] TheMue, heh, yeah, I'm afraid we're stuck with that [12:51] fwereade_: but i think that's a weakness we can live with [12:55] 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] TheMue, hm, it seemed to me that NotResolved would be a sensible default value for an unst var [12:56] unset [12:57] 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] fwereade_: so with one of -1, 1000 or 1001 it's more clear [12:58] TheMue, ok, makes sense, I'm comfortable with that :) [12:59] fwereade_: what do you say to the change after rogs idea of giving it an own type? [12:59] TheMue, yeah, can't see any harm in that [12:59] fwereade_: i like it, even if it has just three valid values. [12:59] TheMue, you can tack the Validate func onto thattype too [13:00] fwereade_: oh, havn't i, damn [13:00] TheMue, heh maybe you have I didn't check [13:00] fwereade_: the new/old naming is ok, will change it [13:00] TheMue, cool [13:01] TheMue, just makes it a little easier for me to follow [13:01] fwereade_: it has already the type, phew [13:01] TheMue, cool, sorry about that :) [13:01] fwereade_: np [13:28] fwereade_: btw, which kind of errors are handled with the Resolved functions of Unit? [13:28] TheMue, any state transition error [13:28] TheMue, ie hooks [13:28] fwereade_: ic, thx [13:29] TheMue, but also potentially things that might go wrong before a hook starts [13:29] TheMue, failing to download the new version of a charm while upgrading for example [13:29] TheMue, anything that puts us into an error state [13:30] fwereade_: and in this case the "resolved" flag is set? [13:31] TheMue, you do "juju resolved " and tack on a --retry if you want torun the hook again [13:33] fwereade_: does that command set the flag? [13:33] Good morning everybody [13:33] niemeyer: morning [13:33] TheMue, yeah, to whichever value, controlled by --retry [13:33] heya niemeyer [13:36] 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"? === asavu_ is now known as asavu [13:37] TheMue, the agent reads the value, clears it, and tries to do what it was asked [13:37] TheMue, think of the clearing as the unit agent taking over responsibility [13:38] fwereade_: ok, i only wondered about the passive version "resolved" instead of "need error resolution" [13:39] 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] TheMue, not quite sure I follow [13:39] TheMue, what niemeyer said :) [13:39] TheMue: It's a statement saying it's good to go now, rather than "fix it for me" [13:42] niemeyer: ok, this way it sounds reasonable. thx === asavu_ is now known as asavu [14:44] TheMue: So, go-state-continued-machine is the bottom of your queue, right? [14:45] niemeyer: just took a look, yes, it is [14:45] TheMue: Ok, I see it still has comments from fwereade_ unaddressed, though [14:46] TheMue: Are you working on those now? [14:46] niemeyer: after re-propose the go-state-continued-unit a few moments ago i would now continue with that one. [14:46] fwereade_: Btw, you've recommended: "It'd be quite nice to move this out into its own little internalMachineId func [14:46] " [14:47] niemeyer, yep; disagree? [14:47] fwereade_: Ah, sorry, nevermind.. I totally missed what you actually meant [14:47] niemeyer, ah ok,sorry unclear :) [14:47] fwereade_: No.. I misunderstood.. and talking to myself helped :-D [14:47] niemeyer: *lol* [14:47] fwereade_: It was clear, I was on crack [14:48] 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] niemeyer: it doesn't depend [14:50] TheMue: Super, thanks [15:11] need to pop out briefly, bbs [15:40] TheMue: You've got a review [15:40] fwereade_: Will pick one of yours when I'm back from lunch [16:01] niemeyer, fwereade_, TheMue: small review for you: https://codereview.appspot.com/5754086 [16:03] niemeyer: thx [16:41] 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] TheMue: Isn't that the case we talked about last week? [17:57] rogpeppe: LGTM, cheers [17:57] niemeyer: thanks [17:59] 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] fwereade_: You'll have some of them [18:13] :) [18:13] fwereade_: Sorry for not getting to those today [18:13] TheMue: You just got a LGTM, though [18:14] niemeyer: ah, fine [18:14] niemeyer: http://paste.ubuntu.com/880728/ [18:15] niemeyer: but i gotta go 5 minutes ago [18:15] niemeyer: see y'all tomorrow [18:15] 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] rogpeppe: Please ping me when you have some time.. [18:17] rogpeppe: And enjoy your ROD [18:33] fwereade_: and you got a review as well [18:35] niemeyer: last propose before submit is in [18:50] TheMue: Checking [18:51] TheMue: The comment for Resolved is still bogus [18:52] 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] niemeyer: mom, taking a look [18:54] TheMue: "mom" isn't a great abbreviation for "moment", btw ;-D [18:55] niemeyer: hmm, knowing it as common abbrev: mom pls for one moment please [18:56] TheMue: https://www.google.com/search?q=define%3Amom [18:57] niemeyer: found my mistake, only looked to the wrong naming that has been a result of the search'n'replace [19:01] TheMue: np.. please submit it [19:01] TheMue: (with the fix) [19:02] niemeyer: ok, will go in now [19:08] niemeyer: so, it's in, time to leave [19:14] TheMue: Have a good time [19:15] niemeyer: thx, have a good ROD too [19:48] fwereade_: One of your branches seems to be affected by the problem rogpeppe pointed out.. [19:48] fwereade_: https://codereview.appspot.com/5786051/ [20:48] niemeyer, huh, I'll take a look at the testutil weirdness [20:48] fwereade_: I'm fixing a.. hmm.. questionable behavior I implemented in goetveld [20:48] niemeyer, about the go-hook-package branch (if you have a mo?) [20:48] fwereade_: Not sure if for some reason they started to forbid it [20:48] fwereade_: I do [20:50] 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] 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] niemeyer, "this command doesn't exist" seems like the clearest way to denote thatthere's no good reason to call it [20:52] niemeyer, and I like the idea of minimising pollution of command space [20:52] fwereade_: I'm not following (2).. missing more foundational reasoning about why we're using "command" there at all [20:53] niemeyer, same general idea as not importing stuff you don;t use [20:53] fwereade_: It's a function to call a hook.. which "command" is that? [20:53] niemeyer, it's called via jujuc but it's still fundamentally a command line tool [20:54] niemeyer, (thatis, everything called from a hook is) [20:54] fwereade_: Yeah, but why is this relevant at all to the function that calls a hook? [20:54] 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] fwereade_: Precisely.. why is (2) being done at all? [20:55] niemeyer, for the reasons above... what's the benefit of making available a whole bunch of tools that can't be used? [20:56] fwereade_: Having the command that runs another command create symlinks as it calls the other command is a bit novel and unexpected [20:57] niemeyer, do the 3 uses of command there refer to agent, hook, hook-tool respectively? [20:57] fwereade_: It refers to Linux commands in general [20:57] fwereade_: Unset your DISPLAY environment variable and call "xeyes" [20:58] fwereade_: You'll get an error like this: Error: Can't open display: [20:58] fwereade_: The environment wasn't set properly for it to run [20:58] 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] fwereade_: The commands that are available to a hook are normal Linux executables, and they will be found in the PATH [21:00] niemeyer, but if you could guarantee that the environment was bad, what benefit would there be to making it available? [21:01] 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] 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] niemeyer, heh, I had the impression that we explicitly restricted that idea to making other relations available to hooks [21:03] niemeyer, do they ever make sense entirely outside hooks? [21:03] fwereade_: That's always been the idea, at least [21:03] fwereade_: relation-set $RELATION system-on-fire=true [21:04] fwereade_: Think about what happens once the system reaches stability.. [21:04] fwereade_: all hooks were run [21:04] fwereade_: If we don't allow out-of-band changes in relations, we're severely restricting what people can do via relations [21:05] fwereade_: It basically means a working system can't change relations after started, unless it breaks [21:06] niemeyer, so relation-set could be called entirely outside juju's control? [21:06] fwereade_: Let's paint a brighter picture.. relation-set is always under juju's control.. :-) [21:07] 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] 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] fwereade_: Yes, I hope we can make that meaningful in a clean way [21:08] fwereade_: and I don't think it's hard even [21:09] niemeyer, well IMO this is the crux of it, please expand; that'll probably convince me to drop it entirely [21:10] fwereade_: Which statement is "this" referring to? [21:10] niemeyer, sorry, the meaningful relation-set not inside a hook [21:10] niemeyer, I don't see what could cause thattohappen [21:11] fwereade_: Anything that happens on the machine [21:11] fwereade_: Right now the usefulness of relations is severely restricted to being modifiable inside a hook only [21:11] 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] niemeyer, a use case would be a great help to me here [21:12] 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] fwereade_: I just described one above.. [21:12] fwereade_: relation-set $MONITORING_RELATION the-system-is-on-fire [21:12] fwereade_: relation-set $MONITORING_RELATION the-system-is-on-fire=1 [21:13] fwereade_: relation-set $RELATION load-is-too-high=1 [21:13] fwereade_: relation-set $RELATION I-got-a-new-user=1 [21:13] fwereade_: relation-set $RELATION I-need-another-database=customers [21:13] fwereade_: relation-set $RELATION send-an-sms-to-fwereade [21:13] :) [21:14] Anything, really.. there are many more out-of-band use cases than there are for setup/teardown [21:15] 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] niemeyer, can we look at load-is-too-high in a bit more detail? [21:15] fwereade_: Sure.. what's the question, more precisely? [21:16] 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] niemeyer, I'm unclear what that something would be [21:17] fwereade_: We're talking about a software that can execute a command when something happens.. [21:17] fwereade_: This sounds pretty straightforward [21:17] fwereade_: What are you unclear about there? [21:17] niemeyer, sure, not an overwhelmingly original concept when put like that :) [21:18] :-) [21:19] niemeyer, ok, I think that scotches the idea, which rested entirely on my conception that hook commands would not be generally useful [21:22] 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] niemeyer, huh, I just realised how that sounded [21:22] niemeyer, yes, but ASSUMING there was a dragon in your bed it was perfectly reasonable to set of the fire extinguisher [21:22] 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] 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] ah well :) [21:28] fwereade_: A lot of /usr/bin/* is context dependent.. [21:29] fwereade_: Just think about how many of those only work under X, or after you started LXC, etc [21:29] 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] fwereade_: Many other put binaries under /usr/lib/, that are only ever run by themselves [21:30] niemeyer, but starting LXC makes commands meaningful in a range of contextx that the LXC-starting cannot control [21:31] fwereade_: Ok.. let's go the other way around then.. please find me a command that creates symlinks on demand ;-) [21:32] 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] niemeyer, er, `ln` :p [21:32] (sorry) [21:32] fwereade_: Haha [21:33] niemeyer, but still, it remains a derail due to my own missed context [21:34] niemeyer, maybe one day I'll find a situation in which it really does make sense [21:41] 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] fwereade_: i'm interested to see gustavo's point of view on this :-) [21:42] * rogpeppe stands well back [21:43] 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] 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] 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] 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] :-) [21:48] fwereade_: Yes [21:50] 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] 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] fwereade_: You'll need pretty much all of that somewhere [21:53] fwereade_: Reuse is great.. you can reuse in either side [21:54] niemeyer, we get all the same functionality with one method -- "run this command line" -- with one result type -- out, err, code [21:54] niemeyer, and that allows you to write all the commands as Command implementations that interact directly with the context [21:55] 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] 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] fwereade_: Why? [21:57] fwereade_: What's that lot? I think that's the crux there [21:57] niemeyer, whereas doing it in the agent allows us to use Command implementations that already have the relevant context directly accessible [21:58] niemeyer, mainly juju.hooks.protocol [21:59] niemeyer, which feels to me like a lot of code whose only effect is to obfuscate what's actually happening :/ [22:00] fwereade_: Ok, I'm fine to see the branch implementing it.. if it's indeed considerably simpler, I'm game [22:01] 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] fwereade_: That doesn't put me off at all [22:02] fwereade_: I'm all for several small branches [22:02] niemeyer, good-oh [22:03] 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] fwereade_: Well, that's what the description is for :) [22:04] fwereade_: But it has to be a reasonable way to walk towards the achievement [22:05] niemeyer, I might take another look at those, the first one feels rather more what-than-why in hindsight [22:05] 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] fwereade_: That's what happened with today's branches, for instance [22:05] fwereade_: It's quite useless without more stuff [22:05] fwereade_: BUT [22:06] fwereade_: It's easy to see where the feature is going.. the debate was about how that was being done, not why [22:06] niemeyer, yes indeed :) [22:07] niemeyer, btw, tyvm for the clarification on out-of-band hook commands, was edifying [22:08] fwereade_: You're very welcome. Glad to have had it too [22:12] niemeyer, btw, if a branch is already WIP, I presume I still need to `lbox propose -prep` to prevent it being promoted? [22:13] fwereade_: Right [22:13] niemeyer, cheers, justchecking :) [22:13] fwereade_: np [23:00] 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] niemeyer, sure, justa mo [23:01] fwereade_: Superb, thanks a lot [23:01] fwereade_: I've removed a silly hack I had, which might actually be considered a bug [23:01] fwereade_: It used to embed the revision information at the top of the file [23:02] fwereade_: I'm not sure if that's what confused Rietveld somehow after some upgrade they made [23:02] fwereade_: Either way, that means we'll now see which files _actually_ changed across different "propose" commands, which is awesome [23:06] niemeyer, https://codereview.appspot.com/5786051 [23:06] niemeyer, there's a surprising [revision details] in there now [23:06] niemeyer, but OTOH atleast you can see the diffs [23:16] fwereade_: Yeah, the surprising revision details isn't so surprising for me ;-) [23:22] and another review.. [23:37] niemeyer, thanks [23:38] 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] niemeyer, sensible? [23:41] hi folks [23:43] 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] bigjools, I'm not sure about docs, but I may be able to help? [23:46] fwereade_: ah col [23:46] cool [23:47] so for the maas stuff I have bootstrap saying it's worked - I see a node start up on the maas side [23:47] but then trying to use deploy results in it complaining that zookeeper is not running [23:47] I thought I'd better try and understand exactly what needs to happen to be able to debug this [23:48] bigjools, hmm; it's definitely not that zk just isn't running *yet*? [23:48] oh how long does it take? [23:49] and what initiates that? [23:49] bigjools, once you have an instance, just about everything that happens should be covered by the cloud-init stuff [23:50] ah ok, so bootstrap kicks it all off [23:50] I'll ssh in to the node and see if it's starting up [23:50] bigjools, yeah; that's the best place to start [23:51] bigjools, I'm afraid I know nothing about debugging cloud-init though [23:51] you and me both :) [23:51] bigjools, I have a feeling something useful should be logged somewhere, but... yeah, that's not very helpful ;) [23:51] heh