[00:36] WHAT [00:36] % juju status [00:36] error: Get https://s3.amazonaws.com/juju-4218c46225cb7856d9d5ca3c1a685cd87b647996/provider-state: lookup s3.amazonaws.com: no such host [00:36] internets is whack! [00:43] amazon is sooooo slow today [01:12] niemeyer: % error: cannot assign unit "tomcat7/0" to machine: cannot assign unit "tomcat7/0" to unused machine: duplicate key insert for unique index of capped collection [01:12] happens a lot [01:12] is this related to the version of mongo i'm running [01:35] davecheney: shouldn't you be hitting ap-southeast-1 ? [01:36] SpamapS: doesn't make any difference [01:36] s3 is still slow as shit [02:40] davecheney: Yeah, new mgo solves that [02:54] niemeyer: hmm, maybe i didn't go get [02:54] will double chekc [02:55] no, i must have had too, otherwise it wouldn't compile [02:56] davecheney: It wouldn't? [02:57] didn't you introduce a new symbol in the latest mgo ? [02:57] and we use that in juju [02:58] davecheney: I introduced a symbol before the fix to the problem above was released [02:59] ok [02:59] niemeyer: i've recompiled [02:59] thanks [02:59] davecheney: and mgo will still compile file even if juju lacks the fix to the problem above [02:59] niemeyer: welcome to the unspoken dependency problem in go [02:59] davecheney: Yeah, it's kind of a general problem [03:00] davecheney: Also one of the reasons why I don't do interim announcements/releases [03:00] niemeyer: yeah, there is no good way for people to _know_ they have the right release [03:01] i've worked around it in juju by adding tests which break when we've added something to a dep, like the --format= stuff in gnuargs [03:01] but that isn't really a solution [03:03] davecheney: Yeah, not a general one at least.. we can easily add a test against a specific version, though [03:03] Assert(mgo.Version, Equals, Version) [03:04] davecheney: Assuming mgo.Version exists, which it doesn't at the moment [03:04] Anyway, I'm in serious need of some sleep [03:04] niemeyer: later [03:05] It was a long day, both with great stuff and with unusually awkward stuff [03:05] davecheney: Have a good day there [03:06] niemeyer: will have the charm audit done by this arvo [03:06] am down to s [03:06] with a larger sample size, the numbers are looking better [03:06] fewer charms broken as a % of the total [05:15] so, some intersting problems with subordinate charms [05:16] they tend to clobber each other's apt-get requests [05:16] and fail [05:22] and this is what happens when you start too many instances [05:22] 20: [05:22] instance-id: pending [05:22] 21: [05:22] instance-id: pending [05:22] 22: [05:22] instance-id: pending [06:15] lucky(~) % grep -c -- '- failed' ~/charm-audit.txt [06:15] 24 [06:15] lucky(~) % grep -c -- '- started' ~/charm-audit.txt [06:15] 54 [06:15] lucky(~) % grep -c -- '- unknown' ~/charm-audit.txt [06:15] 5 [06:15] will post full report tonight. [08:12] davecheney: I would not expect subordinates to install in parallel [08:16] davecheney, how are you installing subordinates in the first place? :) [08:20] fwereade: juju deply [08:20] there are a few charms that don't do anyting [08:21] the juju charm for example [08:21] but others happily cohabitate [08:22] davecheney, still don't see how that'd work -- what's deploying them? [08:23] fwereade: try it yourself [08:23] happy uniter is happy [08:24] davecheney, that is pleasing, but... the uniter can't deploy new units yet, afaik, and the MA shoudln't be deploying subordinate units... should it? [08:25] fwereade: maybe it can't tell [08:26] davecheney, but juju deploy exits early, before adding units, with subordinate charms [08:27] fwereade: ahh [08:28] i was mistaken [08:28] juju is a subordinate [08:28] davecheney, and Service.AddUnit refuses to add them anyway :) [08:28] but charms like hadoop-master and hadoop-slave are cohabitatin [08:28] davecheney, fwereade: morning [08:29] davecheney, ah, cool... so you have hacked placements or something? [08:29] wrtp, heyhey [08:29] fwereade: nope [08:29] that is just what happens [08:29] davecheney, I has a suspicious [08:29] davecheney, but well, hey, at least we're running them, even if it's not clear tome how ;p [08:30] sounds like the placement policy of "unused" machines isn't being respected [08:30] SpamapS, yeah... [08:30] which would actually make quite a few people very happy ;) [08:30] SpamapS, but then lots of things *do* end up on their own machines (right, davecheney?) [08:30] (even if it is dangerous and error prone) [08:30] SpamapS, haha, yeah [08:30] SpamapS: fwereade it could be related to the charm names [08:30] it only happens to charms that have the same prefix [08:31] davecheney, whoa, wtf? [08:31] fwereade: try it [08:31] davecheney, so cs:precise/hadoop-master and cs:precise/hadoop-slave end up cohabiting? [08:32] yup [08:32] two unit agents [08:32] running at the same time [08:32] fighting over the apt lock [08:32] http://blog.ancientlasers.com/wp-content/uploads/2012/03/Mind-Blown.jpg [08:33] davecheney, hmm, this feels rather like a bug with a capital B, and probably capital U and G as well [08:33] davecheney: the apt thing is a problem when python unit agents co-habitate as well.. charms tend to be written assuming they're "masters of their own domain" [08:34] SpamapS: intersting [08:34] isn't their a flag to apt to say 'please wait, forever if that is what it takes' [08:36] not that I know of [08:36] but I believe you can use aptd for that [08:36] maybe i'm thinking of yum [08:36] * davecheney slaps himself [08:38] davecheney: either way, its not just apt-get ... there may be other ordering issues [08:38] davecheney: if two things want to rearrange the services running right now.. the stops/starts may happen in a very wrong order.. for instance [08:39] if you're going to have more than 1 unit per "container", you have to serialize all hook execution [08:40] * SpamapS really should go try to sleep again [08:41] SpamapS: more investigation is called for [08:42] davecheney: I'm still quite surprised that charms with similar names are being chosen to live on one machine [08:43] SpamapS: it is possibly user error [09:01] wrtp, I think I have a fix for lp:1065576 (the git problem you found yesterday)... can you remind me what the standard I-fixed-a-bug summary line should look like? [09:02] fwereade: pkgname: fix git so it doesn't do X [09:02] fwereade: Fixes bug NNN [09:02] wrtp, ah, I thought there was meant to be a bug ref in the summary [09:02] wrtp, cheers [09:03] fwereade: i don't think so [09:03] fwereade: but you can use --bug with lbox [09:03] fwereade: (and you probably should) [09:03] wrtp, last time I tried that it overwrote the description so I steered well clear [09:03] fwereade: fairy nuff [09:05] wrtp, https://codereview.appspot.com/6636056 should be a trivial, I think [09:06] bbs [09:08] fwereade: it looks plausible, but i don't really know what's going on here. what does "a hook has run and is being committed by git" mean? how are hooks committed by git? [09:22] moin. [09:24] wrtp, b [09:24] Aram, morning [09:24] wrtp, we snapshot dir state at the end of each hook [09:25] fwereade: which dir? [09:25] wrtp, so git can be already running something in the uniter when we try to do status [09:25] wrtp, the charm dir [09:25] fwereade: wow. isn't that a bit... heavyweight? [09:26] wrtp, on discussion a good while ago, it seemed to generally be considered to be a good thing [09:27] fwereade: doesn't that mean that if you've got a large charm, it's read in its entirety on each hook? [09:27] fwereade: i'm sure i'm missing something. what's this in aid of? [09:27] wrtp, git has always seemed to me to be pretty efficient [09:27] wrtp, what is it you're worried about? [09:28] fwereade: i suppose if we trust mtimes, it won't be too bad. [09:28] fwereade: i thought the charm directory was usually immutable actually [09:29] wrtp, huh? the charm dir is anything but [09:29] wrtp, IMO this is a serious drawback [09:29] fwereade: you mean the directory containing the charm hooks &c ? [09:29] wrtp, yeah, the deployemtn dir [09:31] fwereade: interesting. so what does this enable? [09:32] fwereade: i hope we don't have charms that put large database files in the charm directory. [09:33] fwereade: because that could make things seriously slow (and we could use lots of disk space too) [09:34] wrtp, mainly it's intended to help us figure out wtf has been going on when things go wrong [09:34] wrtp, AIUI it's charm state that tends to get put in there [09:35] wrtp, I don't think people are going to be installing postgres inside the charm dir, for example [09:35] fwereade: if they do, we'll be in for a nasty surprise :-) [09:35] s/we/they/ [09:35] wrtp, if they do they're fucked whatever we do [09:36] wrtp, because charm upgrades will do the snapshots anyway [09:36] wrtp, this way, if people are messing with the charm dir other than in hooks, at least we find out fast [09:36] fwereade: there's a difference between snapshotting once on upgrade, and snapshotting on every hook [09:37] fwereade: what's wrong with messing with the charm dir other than in hooks? [09:37] wrtp, how do you tell a hok isn't messing with the charm dir itself? [09:37] fwereade: when i wrote a charm before, the charm dir seemed to be the only piece of space that was the charm's own. so it seemed logical to put mutable data files there. [09:38] fwereade: i think you're saying that's frowned on [09:38] wrtp, depends how they're mutated [09:38] fwereade: it didn't depend on anything before AFAIK [09:38] wrtp, if you've got, say, a cron job messing with the charm dir then, yeah, that's not sensible [09:38] fwereade: why not? [09:38] fwereade: do we document that? [09:39] wrtp, I have no idea [09:39] wrtp, (why we don't document it) [09:39] fwereade: it makes me a little anxious [09:39] wrtp, (*whether* we document it) [09:40] fwereade: because we're saying "of course you shouldn't do *that*", but there's nothing that ever told anyone that it might be a bad idea (and it certainly seemed like a reasonable idea to me back when) [09:40] wrtp, I don't see how it could ever be considered sane to mutate the charm dir from outside a hook at the same time a hook is running [09:41] wrtp, not knowing when a hook is running, which you don't, would STM to preclude the sanity of touching the charm dir other than through juju [09:41] fwereade: why not? say you're implementing a subordinate. you run a database of some kind; where do you put the data files for it? putting them in the charm dir seems kinda reasonable to me. [09:41] wrtp, woudl you consider it sensible to change DB files youself, from outside the DB, while the DB was running? [09:41] fwereade: no, but the DB will change its files while the hooks are running and while they're not, right? [09:41] wrtp, how is that situation any different? [09:42] fwereade: there are files that matter to us in the charm dir, and files that don't [09:42] wrtp, I would personally put the data files somewhere in var [09:42] wrtp, oh really? how do we tell what isn't important? [09:43] wrtp, you seem to be assuming perfect knowledge of all current and future possible charm upgrades... [09:44] wrtp, if you want to keep some charm-related state in the charm dir, and manipulate it in the hooks, great [09:45] wrtp, if you want to install everything from the service in a non-standard place, on your own head be it ;) [09:45] fwereade: if the user creates a "data" dir in their charm dir and uses it for some running database (that's similar to what i did), i don't see that should have untoward effects [09:45] fwereade: but we're going to break that [09:45] wrtp, I don't see how that's possible [09:46] wrtp, you can't do that at all ever anyway, can you? [09:46] fwereade: huh? [09:46] wrtp, (without it being risky/broken, anyway) [09:46] fwereade: why's that? [09:46] wrtp, how do you handle concurrent writes to the charm dir? [09:46] wrtp, or writes/reads, whatever [09:47] fwereade: how does who handle it? [09:47] fwereade: the running database? [09:47] fwereade: or juju? [09:48] wrtp, how do you propose to implement this scheme whereby juju, and something-else, are both writing concurrently to the same dir without errors? [09:49] fwereade: two things can happily write to two independent files without errors. i'm not sure i see the problem. [09:49] wrtp, and how do you propose to ensure this? [09:49] fwereade: i must be missing something here. we all share the same filesystem. [09:50] fwereade: are you thinking about upgrades in particular here? [09:50] wrtp, I'm thinking about charm upgrades, and every hook [09:50] wrtp, all these things can write arbitrary things into the charm dir [09:51] wrtp, you're apparently saying that we should be able to guarantee that *anything* else can *also* write arbitrarily to the charm dir, at any time, without anything ever goind wrong [09:51] fwereade: the things written by hooks are under the control of the charm author. as are things written by programs running in the bg, started by the hooks. [09:52] fwereade: not really. i'm saying that the charm dir is just a dir. we can have two independent things writing to files in it with no problem, just the same way that many programs can write to independent files under the global root. [09:53] fwereade: the difficulty here is that we're assuming that juju has entire control of the charm dir, but i'm not sure that's necessarily the case. [09:53] wrtp, I think you're saying that you can guarantee that the written files will be independent [09:53] wrtp, which STM to be an unsupportable assertion [09:54] fwereade: if i start a database and give it a file to write to, or a directory that i've created for it to put its data files in, i know that it's not going to write outside that file or dir. [09:54] fwereade: how is the charm dir different from, say, /tmp ? [09:55] wrtp, the charm dir is owned by juju, and juju expects to have control over it? [09:55] fwereade: (FWIW, i'm not saying that what we're doing now with git snapshots is *wrong*, but i think it's worth exploring the implications) [09:55] wrtp, would you install mysql inside postgres' data dir? [09:56] fwereade: the problem is that the charm author might feel *they* have control over the charm dir [09:56] wrtp, they have control over it, strictly mediated by juju [09:56] fwereade: after all, they've created the files and populated the directories [09:56] fwereade: it's not strictly mediated... [09:57] fwereade: and i wouldn't be surprised if lots of charms used it for general scratch space [09:59] wrtp, this STM like a documentation issue, fundamentally [09:59] fwereade: and if they do, i we may have a problem [09:59] fwereade: sure [09:59] fwereade: it's also a potential backward-compatibility issue [10:00] wrtp, IMO it's a latent-charm-bug issue [10:00] fwereade: out of interest, is a charm allowed to change its hooks (e.g. to add a new relation-joined hook) on the fly? [10:00] wrtp, I don;t think we ever claimed remotely that it was safe to modify juju's dirs while juju is running [10:01] fwereade: it's only a bug because we've made it a bug [10:01] wrtp, nothing stopping it from doing so [10:01] fwereade: so it doesn't cache the current hooks then? [10:01] wrtp, assuming that it's fine to mess with something's runtime state, just because nobody told you not to, doesn't seem very sensible to me [10:02] wrtp, no, it just executes whatever's there [10:02] fwereade: we never claimed remotely that it *wasn't* safe to modify juju's dirs while juju is running AFAIK :-) [10:02] wrtp, what makes you think that is a reasonable assumption? [10:03] fwereade: it's not *something's* runtime state. it's a *charm's* runtime state. so it seems not unreasonable for a charm to assume that it can change it whenever it likes. [10:03] fwereade: why not? [10:04] wrtp, 5 seconds of thinking would surely reveal that juju has the power to make arbitrary changes to that dir, and lead one to look for mechanisms by which that operation can be made safe, and to conclude from the lack of such mechanisms that it is in fact not safe [10:04] wrtp, details like "no, you cannot run juju tools outside hooks" seem to support this [10:05] fwereade: is there not a hook that's run before an upgrade? [10:06] wrtp, nope [10:06] wrtp, that might also be considered a hint [10:06] fwereade: that seems wrong actually [10:07] wrtp, hmm, how would it help? [10:07] fwereade: ISTM that a charm ought to be able to have the opportunity to shut things down cleanly before an upgrade if it wants to [10:07] wrtp, whoa, why would upgrading the charm remotely justify screwing up the service? [10:08] fwereade: depends on the service. [10:08] wrtp, if, say, a config change causes us to want to change *service* version, then we can deal with that [10:09] wrtp, conflating service version and charm version seems to be a fundamental error [10:10] fwereade: there is a *post*-upgrade hook, right? [10:11] wrtp, yes [10:12] wrtp, AIUI this is essentially to give you the opportunity to rearrange the files inside the charm dir if required [10:12] fwereade: well, you might also need to restart services, etc [10:13] wrtp, what does a charm change matter to the service? [10:13] fwereade: i'm talking about daemons, not juju services, sorry [10:14] wrtp, yeah: why would a charm change justify such an action? [10:14] wrtp, a config change might [10:14] fwereade: what if the charm change is to make a daemon start with different command-line arguments? [10:15] fwereade: or to use an alternative daemon for something [10:15] fwereade: there are many possible reasons a charm might be upgraded [10:15] wrtp, ok, fair enough -- then you can do that just fine in the post-upgrade hook with a minimum of downtime [10:15] wrtp, what good would a pre-upgrade hook do? === TheMue_ is now known as TheMue [10:16] wrtp, although, more likely, you'll just do that in the subsequent config-changed anyway [10:16] fwereade: ISTM that people may have daemons that look at files in the charm dir. if the charm dir can change without warning, that's not a good idea. [10:16] wrtp, I agree that that is not a good idea [10:17] fwereade: it's probably not a good idea anyway, but i bet lots of people do it [10:17] wrtp, that is why people should not do it [10:17] wrtp, the charm dir is for the charm [10:17] wrtp, the service already has a standard place for everything, surely? [10:18] fwereade: i see that. but what *you* think of as the charm is not what others might think of as the charm [10:18] fwereade: what place is that? [10:18] one mo, gotta do the bins [10:18] wrtp, service-dependent, surely? [10:19] wrtp, but the general philosophy is that we should be able to completely nuke juju, and leave the service running unhindered [10:19] wrtp, if the service knows about juju, the charm is being bad [10:21] wrtp, brb ciggie [10:27] fwereade: is there a way for a charm to find out its service name? [10:30] fwereade: because you might easily have two of the same charm deployed in the same container. then each one needs some space for itself. the charm dir might seem like a good place for that, but i see why you think it's not. [10:30] fwereade: i wonder if we should provide each charm with its own temporary directory that it can do whatever it likes to. [10:31] fwereade: then deprecate the whole idea of writing to the charm dir, whether inside or outside a hook. [10:32] wrtp, +1 on that, but I think it's independent of the don't-let-the-service-know-about-the-charm issue [10:33] fwereade: i was responding to your "the service already has a standard place for everything, surely?" - that's not necessarily true [10:34] fwereade: but i agree with your sentiment in general [10:34] wrtp, by convention, if nothing else [10:35] wrtp, if you're installing X, you tend not to put X's data files inside Y's data dir [10:35] fwereade: what if you're installing two Xs? [10:35] fwereade: we really really really need to write some decent docs [10:36] wrtp, agreed there :) [10:36] fwereade: that was a genuine question above BTW; is there a way for a charm to find out its service name? [10:37] wrtp, not directly, but it knows its unit name [10:37] fwereade: ah, that's good enough then. [10:37] fwereade: how does it find its own unit name? [10:37] wrtp, JUJU_UNIT_NAME I think [10:38] wrtp, yep [10:38] wrtp, what would you expect to need it for? [10:38] wrtp, (the service name, I mean) [10:39] fwereade: it's a useful disambiguator. if you're a subordinate service, you want to choose a place to store your charm-external state that doesn't clash with other subordinates that are potentially using the same charm. [10:40] wrtp, I'd expect the relation id to be the disambiguator, but maybe that's not right [10:41] fwereade: there may be no relation [10:41] wrtp, how do you deploy a subordinate without a relation? [10:41] fwereade: i suppose for subordinates, there's always a relation [10:42] fwereade: but do you know that relation id when you're executing the install hook? [10:42] wrtp, shouldn't the install hook just, er, install? [10:43] fwereade: it might need to install to some charm-external directory. same applies to the start hook. [10:43] wrtp, I'm not sure that we're trying to solve the run-multiple-versions-of-the-same-software problem here are we? [10:44] fwereade: it's not hard to run multiple versions of the same software; all we need is a directory that each instance can call its own. [10:44] fwereade: we allow several subordinate services in a given container that might use the same charm. i can imagine cases where that might be very useful. [10:45] fwereade: (i'm imagining a subordinate service that provides some fairly general functionality, determined by the config settings) [10:45] wrtp, then, in that case, surely the unit name is a reasonable disambiguator there [10:46] fwereade: indeed [10:46] wrtp, and the relation id is good for handling multiple relations run by the same charm [10:46] fwereade: yeah [11:50] * fwereade once again fails to successfully use wrtp's fly-killing techniques [11:50] but it was *close* that time [11:50] fwereade: you'll get there :-) [11:50] fwereade: did it escape through the top or the bottom? [11:50] wrtp, bottom [11:51] fwereade: keep trying... [11:51] wrtp, really impressively sharp turn away actually, it probably deserved to live [11:51] fwereade: you're selecting for canny flies [11:51] fwereade: a few more generations and you'll never get 'em [11:51] wrtp, I'm not saying I won't try again next time it comes in range ;) [12:11] crack crack crackity crack [12:12] * wrtp has just found out why his tests were passing when they couldn't possibly be passing [12:42] niemeyer: morning [12:42] ! [12:42] Good morning! [12:44] niemeyer: my use-passwords branch last night was a bit crackful i'm afraid. i forgot to pass the --auth flag to the mongod started by environs/cloudinit. [12:45] niemeyer, heyhey [12:45] niemeyer: i thought of something this morning and could not for the life of me think how the tests were passing [12:45] niemeyer: and that's the reason... [12:46] wrtp: Hah [12:46] fwereade: yo [12:46] niemeyer: i thought it all went a bit too smoothly! [12:54] Aram: ping [12:54] yo [12:54] hello [12:55] niemeyer: ^ ^ [12:55] Aram: Heya! [12:55] Aram: Good point regarding the check [12:56] Aram: I suspect we'll need to verify if it's already in the pending list or not in those removal detection branches then [12:56] niemeyer: perhaps it's still a good idea to check if pending is required at the begining of the logic. [12:56] so we do it only once [12:57] and then depending on that boolean and the rest of the logic determine what to actual returnm [12:57] does that make sense? [12:57] alteratively, we could do it once at the end. [12:57] but I think logic is simpler if we do it at the begining. [12:58] Aram: I think having this logic in a small method would be as nice, and perhaps more clear [12:58] good idea. [13:00] Aram: hasString and hasInt can probably be shared by all watchers [13:00] yes [13:07] hmm, maybe I should eat something, bbiab [13:07] fwereade: Sounds wise [13:15] niemeyer: fairly trivial: https://codereview.appspot.com/6641053 [13:16] oops, the branch is misnamed [13:17] niemeyer: renamed and reproposed [13:17] https://codereview.appspot.com/6635062 [13:23] wrtp: On a call with flacoste.. back in a bit [13:23] niemeyer: np === andrewsmedina is now known as fssparademimipor [14:01] wrtp: Very ncie [14:01] nice [14:06] niemeyer: thanks [14:12] niemeyer: another fairly small one: https://codereview.appspot.com/6604061 [14:14] wrtp: LGTM [14:14] niemeyer: lovely, thanks === fssparademimipor is now known as andrewsmedina [14:49] Connection Timeout: disconnecting client after 300.0 seconds [14:49] bzr: broken pipe [14:49] Am I the only one facing those issues? [14:50] niemeyer, I think so -- I did notice slightly greater than usual flakiness earlier this week but that's it [14:52] fwereade: Weird.. I can't really guess what could be causing it [14:52] Everything else seems to work normally [15:07] Aram: i just saw this test failure. looks like something's not sorting the unit names as expected: http://paste.ubuntu.com/1271309/ [15:08] wrtp: sorry, my fault. [15:08] will fix right away [15:08] Aram: thanks! [15:13] * wrtp only discovered this morning that you can do tail -f * and it works how you'd want. [15:15] niemeyer: next step: https://codereview.appspot.com/6615071 [15:17] wrtp: quick trivial so I fix the build: https://codereview.appspot.com/6625075/ [15:17] Aram: LGTM [15:18] wrtp: sorry for the breakage, in my defense I always run the state tests 20 times before submitting, and it worked here.\ [15:19] niemeyer, can you think of any reason for me not to move uniter.HookContext to hook.Context? I've come to the conclusion that RelationContext is actually fine as it is -- it's Relationer that really needs the big changes, and it shouldn't be affected by this [15:21] wrtp: done [15:21] fwereade: RelationContext or ContextRelation? [15:22] niemeyer, ha, ContextRelation, I'm pretty sure I've changed the name throughout, but my brain hasn't synced up yet [15:22] niemeyer, (ContextRelation would also move) [15:22] fwereade: I don't have the context to tell whether a package makes sense, but I can try to help: why do you think a package makes sense? You've been going back and forth in other cases; what's the criteria you've used on those? [15:23] niemeyer, I'm planning to move it into the existing hook package [15:25] fwereade: Is that an answer to the above question? [15:25] niemeyer, not really, still composing [15:26] niemeyer, I moved it to uniter originally because I was sure that was "closer" to the "right place" for it, because there was clearly some overlap between Context and Relationer [15:27] niemeyer, it's probably not justified yet though [15:28] fwereade: My feeling is that Context will be strongly bound to the uniter data, but I don't really know yet [15:39] niemeyer, I *think* that with something like the following, uniter doesn't need to know about Context at all -- does this just look awful to you? http://paste.ubuntu.com/1271366/ [15:42] niemeyer, the trouble is that putting that in uniter seems wrong, but I can't really put it in hook if Context (et al) aren't there [15:44] niemeyer, fwereade: what do you think about log.Printf messages, and whether/how they should be prefixed? [15:45] the first log messages i did (in environs/ec2, for example) are prefixed with the package name. [15:45] TheMue, Aram: any thoughts? [15:46] wrtp, last time I prefixed normal log messages with the package, niemeyer suggested I remove them; but I'm not sure we have much in the way of conventions [15:46] wrtp: my personal logging package has the package es prefix in braces, and that's helpful [15:46] i think that some prefix is nice to have, as it makes it obvious where the messages are coming from [15:46] wrtp: so i don't have to think about, it's done automatically [15:46] fwereade: my thought has been: error messages have no prefix; printed messages get a prefix. [15:47] TheMue: that's a reasonable approach actually [15:48] TheMue: assuming we remove the launchpad.net/juju-core/ part of the package path [15:48] wrtp, doesn't sound unreasonable, but don't really have strong feelings [15:48] brb [15:48] wrtp: my package currently shows the full path, but yes, that should be configurable (as well as the logging level) [15:49] wrtp: see https://code.google.com/p/tcgl/source/browse/applog/applog.go [15:51] wrtp: Debugf() also shows filename, function name and line number [15:52]