| davecheney | WHAT | 00:36 |
|---|---|---|
| davecheney | % juju status | 00:36 |
| davecheney | error: Get https://s3.amazonaws.com/juju-4218c46225cb7856d9d5ca3c1a685cd87b647996/provider-state: lookup s3.amazonaws.com: no such host | 00:36 |
| davecheney | internets is whack! | 00:36 |
| davecheney | amazon is sooooo slow today | 00:43 |
| davecheney | 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 |
| davecheney | happens a lot | 01:12 |
| davecheney | is this related to the version of mongo i'm running | 01:12 |
| SpamapS | davecheney: shouldn't you be hitting ap-southeast-1 ? | 01:35 |
| davecheney | SpamapS: doesn't make any difference | 01:36 |
| davecheney | s3 is still slow as shit | 01:36 |
| niemeyer | davecheney: Yeah, new mgo solves that | 02:40 |
| davecheney | niemeyer: hmm, maybe i didn't go get | 02:54 |
| davecheney | will double chekc | 02:54 |
| davecheney | no, i must have had too, otherwise it wouldn't compile | 02:55 |
| niemeyer | davecheney: It wouldn't? | 02:56 |
| davecheney | didn't you introduce a new symbol in the latest mgo ? | 02:57 |
| davecheney | and we use that in juju | 02:57 |
| niemeyer | davecheney: I introduced a symbol before the fix to the problem above was released | 02:58 |
| davecheney | ok | 02:59 |
| davecheney | niemeyer: i've recompiled | 02:59 |
| davecheney | thanks | 02:59 |
| niemeyer | davecheney: and mgo will still compile file even if juju lacks the fix to the problem above | 02:59 |
| davecheney | niemeyer: welcome to the unspoken dependency problem in go | 02:59 |
| niemeyer | davecheney: Yeah, it's kind of a general problem | 02:59 |
| niemeyer | davecheney: Also one of the reasons why I don't do interim announcements/releases | 03:00 |
| davecheney | niemeyer: yeah, there is no good way for people to _know_ they have the right release | 03:00 |
| davecheney | 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 |
| davecheney | but that isn't really a solution | 03:01 |
| niemeyer | davecheney: Yeah, not a general one at least.. we can easily add a test against a specific version, though | 03:03 |
| niemeyer | Assert(mgo.Version, Equals, Version) | 03:03 |
| niemeyer | davecheney: Assuming mgo.Version exists, which it doesn't at the moment | 03:04 |
| niemeyer | Anyway, I'm in serious need of some sleep | 03:04 |
| davecheney | niemeyer: later | 03:04 |
| niemeyer | It was a long day, both with great stuff and with unusually awkward stuff | 03:05 |
| niemeyer | davecheney: Have a good day there | 03:05 |
| davecheney | niemeyer: will have the charm audit done by this arvo | 03:06 |
| davecheney | am down to s | 03:06 |
| davecheney | with a larger sample size, the numbers are looking better | 03:06 |
| davecheney | fewer charms broken as a % of the total | 03:06 |
| davecheney | so, some intersting problems with subordinate charms | 05:15 |
| davecheney | they tend to clobber each other's apt-get requests | 05:16 |
| davecheney | and fail | 05:16 |
| davecheney | and this is what happens when you start too many instances | 05:22 |
| davecheney | 20: | 05:22 |
| davecheney | instance-id: pending | 05:22 |
| davecheney | 21: | 05:22 |
| davecheney | instance-id: pending | 05:22 |
| davecheney | 22: | 05:22 |
| davecheney | instance-id: pending | 05:22 |
| davecheney | lucky(~) % grep -c -- '- failed' ~/charm-audit.txt | 06:15 |
| davecheney | 24 | 06:15 |
| davecheney | lucky(~) % grep -c -- '- started' ~/charm-audit.txt | 06:15 |
| davecheney | 54 | 06:15 |
| davecheney | lucky(~) % grep -c -- '- unknown' ~/charm-audit.txt | 06:15 |
| davecheney | 5 | 06:15 |
| davecheney | will post full report tonight. | 06:15 |
| SpamapS | davecheney: I would not expect subordinates to install in parallel | 08:12 |
| fwereade | davecheney, how are you installing subordinates in the first place? :) | 08:16 |
| davecheney | fwereade: juju deply | 08:20 |
| davecheney | there are a few charms that don't do anyting | 08:20 |
| davecheney | the juju charm for example | 08:21 |
| davecheney | but others happily cohabitate | 08:21 |
| fwereade | davecheney, still don't see how that'd work -- what's deploying them? | 08:22 |
| davecheney | fwereade: try it yourself | 08:23 |
| davecheney | happy uniter is happy | 08:23 |
| fwereade | 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:24 |
| davecheney | fwereade: maybe it can't tell | 08:25 |
| fwereade | davecheney, but juju deploy exits early, before adding units, with subordinate charms | 08:26 |
| davecheney | fwereade: ahh | 08:27 |
| davecheney | i was mistaken | 08:28 |
| davecheney | juju is a subordinate | 08:28 |
| fwereade | davecheney, and Service.AddUnit refuses to add them anyway :) | 08:28 |
| davecheney | but charms like hadoop-master and hadoop-slave are cohabitatin | 08:28 |
| wrtp | davecheney, fwereade: morning | 08:28 |
| fwereade | davecheney, ah, cool... so you have hacked placements or something? | 08:29 |
| fwereade | wrtp, heyhey | 08:29 |
| davecheney | fwereade: nope | 08:29 |
| davecheney | that is just what happens | 08:29 |
| fwereade | davecheney, I has a suspicious | 08:29 |
| fwereade | davecheney, but well, hey, at least we're running them, even if it's not clear tome how ;p | 08:29 |
| SpamapS | sounds like the placement policy of "unused" machines isn't being respected | 08:30 |
| fwereade | SpamapS, yeah... | 08:30 |
| SpamapS | which would actually make quite a few people very happy ;) | 08:30 |
| fwereade | SpamapS, but then lots of things *do* end up on their own machines (right, davecheney?) | 08:30 |
| SpamapS | (even if it is dangerous and error prone) | 08:30 |
| fwereade | SpamapS, haha, yeah | 08:30 |
| davecheney | SpamapS: fwereade it could be related to the charm names | 08:30 |
| davecheney | it only happens to charms that have the same prefix | 08:30 |
| fwereade | davecheney, whoa, wtf? | 08:31 |
| davecheney | fwereade: try it | 08:31 |
| fwereade | davecheney, so cs:precise/hadoop-master and cs:precise/hadoop-slave end up cohabiting? | 08:31 |
| davecheney | yup | 08:32 |
| davecheney | two unit agents | 08:32 |
| davecheney | running at the same time | 08:32 |
| davecheney | fighting over the apt lock | 08:32 |
| SpamapS | http://blog.ancientlasers.com/wp-content/uploads/2012/03/Mind-Blown.jpg | 08:32 |
| fwereade | davecheney, hmm, this feels rather like a bug with a capital B, and probably capital U and G as well | 08:33 |
| SpamapS | 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:33 |
| davecheney | SpamapS: intersting | 08:34 |
| davecheney | isn't their a flag to apt to say 'please wait, forever if that is what it takes' | 08:34 |
| SpamapS | not that I know of | 08:36 |
| SpamapS | but I believe you can use aptd for that | 08:36 |
| davecheney | maybe i'm thinking of yum | 08:36 |
| * davecheney slaps himself | 08:36 | |
| SpamapS | davecheney: either way, its not just apt-get ... there may be other ordering issues | 08:38 |
| SpamapS | 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:38 |
| SpamapS | if you're going to have more than 1 unit per "container", you have to serialize all hook execution | 08:39 |
| * SpamapS really should go try to sleep again | 08:40 | |
| davecheney | SpamapS: more investigation is called for | 08:41 |
| SpamapS | davecheney: I'm still quite surprised that charms with similar names are being chosen to live on one machine | 08:42 |
| davecheney | SpamapS: it is possibly user error | 08:43 |
| fwereade | 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:01 |
| wrtp | fwereade: pkgname: fix git so it doesn't do X | 09:02 |
| wrtp | fwereade: Fixes bug NNN | 09:02 |
| fwereade | wrtp, ah, I thought there was meant to be a bug ref in the summary | 09:02 |
| fwereade | wrtp, cheers | 09:02 |
| wrtp | fwereade: i don't think so | 09:03 |
| wrtp | fwereade: but you can use --bug with lbox | 09:03 |
| wrtp | fwereade: (and you probably should) | 09:03 |
| fwereade | wrtp, last time I tried that it overwrote the description so I steered well clear | 09:03 |
| wrtp | fwereade: fairy nuff | 09:03 |
| fwereade | wrtp, https://codereview.appspot.com/6636056 should be a trivial, I think | 09:05 |
| fwereade | bbs | 09:06 |
| wrtp | 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:08 |
| Aram | moin. | 09:22 |
| fwereade | wrtp, b | 09:24 |
| fwereade | Aram, morning | 09:24 |
| fwereade | wrtp, we snapshot dir state at the end of each hook | 09:24 |
| wrtp | fwereade: which dir? | 09:25 |
| fwereade | wrtp, so git can be already running something in the uniter when we try to do status | 09:25 |
| fwereade | wrtp, the charm dir | 09:25 |
| wrtp | fwereade: wow. isn't that a bit... heavyweight? | 09:25 |
| fwereade | wrtp, on discussion a good while ago, it seemed to generally be considered to be a good thing | 09:26 |
| wrtp | fwereade: doesn't that mean that if you've got a large charm, it's read in its entirety on each hook? | 09:27 |
| wrtp | fwereade: i'm sure i'm missing something. what's this in aid of? | 09:27 |
| fwereade | wrtp, git has always seemed to me to be pretty efficient | 09:27 |
| fwereade | wrtp, what is it you're worried about? | 09:27 |
| wrtp | fwereade: i suppose if we trust mtimes, it won't be too bad. | 09:28 |
| wrtp | fwereade: i thought the charm directory was usually immutable actually | 09:28 |
| fwereade | wrtp, huh? the charm dir is anything but | 09:29 |
| fwereade | wrtp, IMO this is a serious drawback | 09:29 |
| wrtp | fwereade: you mean the directory containing the charm hooks &c ? | 09:29 |
| fwereade | wrtp, yeah, the deployemtn dir | 09:29 |
| wrtp | fwereade: interesting. so what does this enable? | 09:31 |
| wrtp | fwereade: i hope we don't have charms that put large database files in the charm directory. | 09:32 |
| wrtp | fwereade: because that could make things seriously slow (and we could use lots of disk space too) | 09:33 |
| fwereade | wrtp, mainly it's intended to help us figure out wtf has been going on when things go wrong | 09:34 |
| fwereade | wrtp, AIUI it's charm state that tends to get put in there | 09:34 |
| fwereade | wrtp, I don't think people are going to be installing postgres inside the charm dir, for example | 09:35 |
| wrtp | fwereade: if they do, we'll be in for a nasty surprise :-) | 09:35 |
| wrtp | s/we/they/ | 09:35 |
| fwereade | wrtp, if they do they're fucked whatever we do | 09:35 |
| fwereade | wrtp, because charm upgrades will do the snapshots anyway | 09:36 |
| fwereade | wrtp, this way, if people are messing with the charm dir other than in hooks, at least we find out fast | 09:36 |
| wrtp | fwereade: there's a difference between snapshotting once on upgrade, and snapshotting on every hook | 09:36 |
| wrtp | fwereade: what's wrong with messing with the charm dir other than in hooks? | 09:37 |
| fwereade | wrtp, how do you tell a hok isn't messing with the charm dir itself? | 09:37 |
| wrtp | 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:37 |
| wrtp | fwereade: i think you're saying that's frowned on | 09:38 |
| fwereade | wrtp, depends how they're mutated | 09:38 |
| wrtp | fwereade: it didn't depend on anything before AFAIK | 09:38 |
| fwereade | wrtp, if you've got, say, a cron job messing with the charm dir then, yeah, that's not sensible | 09:38 |
| wrtp | fwereade: why not? | 09:38 |
| wrtp | fwereade: do we document that? | 09:38 |
| fwereade | wrtp, I have no idea | 09:39 |
| fwereade | wrtp, (why we don't document it) | 09:39 |
| wrtp | fwereade: it makes me a little anxious | 09:39 |
| fwereade | wrtp, (*whether* we document it) | 09:39 |
| wrtp | 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 |
| fwereade | 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:40 |
| fwereade | 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 |
| wrtp | 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 |
| fwereade | wrtp, woudl you consider it sensible to change DB files youself, from outside the DB, while the DB was running? | 09:41 |
| wrtp | fwereade: no, but the DB will change its files while the hooks are running and while they're not, right? | 09:41 |
| fwereade | wrtp, how is that situation any different? | 09:41 |
| wrtp | fwereade: there are files that matter to us in the charm dir, and files that don't | 09:42 |
| fwereade | wrtp, I would personally put the data files somewhere in var | 09:42 |
| fwereade | wrtp, oh really? how do we tell what isn't important? | 09:42 |
| fwereade | wrtp, you seem to be assuming perfect knowledge of all current and future possible charm upgrades... | 09:43 |
| fwereade | wrtp, if you want to keep some charm-related state in the charm dir, and manipulate it in the hooks, great | 09:44 |
| fwereade | wrtp, if you want to install everything from the service in a non-standard place, on your own head be it ;) | 09:45 |
| wrtp | 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 |
| wrtp | fwereade: but we're going to break that | 09:45 |
| fwereade | wrtp, I don't see how that's possible | 09:45 |
| fwereade | wrtp, you can't do that at all ever anyway, can you? | 09:46 |
| wrtp | fwereade: huh? | 09:46 |
| fwereade | wrtp, (without it being risky/broken, anyway) | 09:46 |
| wrtp | fwereade: why's that? | 09:46 |
| fwereade | wrtp, how do you handle concurrent writes to the charm dir? | 09:46 |
| fwereade | wrtp, or writes/reads, whatever | 09:46 |
| wrtp | fwereade: how does who handle it? | 09:47 |
| wrtp | fwereade: the running database? | 09:47 |
| wrtp | fwereade: or juju? | 09:47 |
| fwereade | 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:48 |
| wrtp | fwereade: two things can happily write to two independent files without errors. i'm not sure i see the problem. | 09:49 |
| fwereade | wrtp, and how do you propose to ensure this? | 09:49 |
| wrtp | fwereade: i must be missing something here. we all share the same filesystem. | 09:49 |
| wrtp | fwereade: are you thinking about upgrades in particular here? | 09:50 |
| fwereade | wrtp, I'm thinking about charm upgrades, and every hook | 09:50 |
| fwereade | wrtp, all these things can write arbitrary things into the charm dir | 09:50 |
| fwereade | 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 |
| wrtp | 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:51 |
| wrtp | 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:52 |
| wrtp | 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 |
| fwereade | wrtp, I think you're saying that you can guarantee that the written files will be independent | 09:53 |
| fwereade | wrtp, which STM to be an unsupportable assertion | 09:53 |
| wrtp | 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 |
| wrtp | fwereade: how is the charm dir different from, say, /tmp ? | 09:54 |
| fwereade | wrtp, the charm dir is owned by juju, and juju expects to have control over it? | 09:55 |
| wrtp | 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 |
| fwereade | wrtp, would you install mysql inside postgres' data dir? | 09:55 |
| wrtp | fwereade: the problem is that the charm author might feel *they* have control over the charm dir | 09:56 |
| fwereade | wrtp, they have control over it, strictly mediated by juju | 09:56 |
| wrtp | fwereade: after all, they've created the files and populated the directories | 09:56 |
| wrtp | fwereade: it's not strictly mediated... | 09:56 |
| wrtp | fwereade: and i wouldn't be surprised if lots of charms used it for general scratch space | 09:57 |
| fwereade | wrtp, this STM like a documentation issue, fundamentally | 09:59 |
| wrtp | fwereade: and if they do, i we may have a problem | 09:59 |
| wrtp | fwereade: sure | 09:59 |
| wrtp | fwereade: it's also a potential backward-compatibility issue | 09:59 |
| fwereade | wrtp, IMO it's a latent-charm-bug issue | 10:00 |
| wrtp | 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 |
| fwereade | wrtp, I don;t think we ever claimed remotely that it was safe to modify juju's dirs while juju is running | 10:00 |
| wrtp | fwereade: it's only a bug because we've made it a bug | 10:01 |
| fwereade | wrtp, nothing stopping it from doing so | 10:01 |
| wrtp | fwereade: so it doesn't cache the current hooks then? | 10:01 |
| fwereade | 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:01 |
| fwereade | wrtp, no, it just executes whatever's there | 10:02 |
| wrtp | fwereade: we never claimed remotely that it *wasn't* safe to modify juju's dirs while juju is running AFAIK :-) | 10:02 |
| fwereade | wrtp, what makes you think that is a reasonable assumption? | 10:02 |
| wrtp | 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 |
| wrtp | fwereade: why not? | 10:03 |
| fwereade | 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 |
| fwereade | wrtp, details like "no, you cannot run juju tools outside hooks" seem to support this | 10:04 |
| wrtp | fwereade: is there not a hook that's run before an upgrade? | 10:05 |
| fwereade | wrtp, nope | 10:06 |
| fwereade | wrtp, that might also be considered a hint | 10:06 |
| wrtp | fwereade: that seems wrong actually | 10:06 |
| fwereade | wrtp, hmm, how would it help? | 10:07 |
| wrtp | 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 |
| fwereade | wrtp, whoa, why would upgrading the charm remotely justify screwing up the service? | 10:07 |
| wrtp | fwereade: depends on the service. | 10:08 |
| fwereade | wrtp, if, say, a config change causes us to want to change *service* version, then we can deal with that | 10:08 |
| fwereade | wrtp, conflating service version and charm version seems to be a fundamental error | 10:09 |
| wrtp | fwereade: there is a *post*-upgrade hook, right? | 10:10 |
| fwereade | wrtp, yes | 10:11 |
| fwereade | wrtp, AIUI this is essentially to give you the opportunity to rearrange the files inside the charm dir if required | 10:12 |
| wrtp | fwereade: well, you might also need to restart services, etc | 10:12 |
| fwereade | wrtp, what does a charm change matter to the service? | 10:13 |
| wrtp | fwereade: i'm talking about daemons, not juju services, sorry | 10:13 |
| fwereade | wrtp, yeah: why would a charm change justify such an action? | 10:14 |
| fwereade | wrtp, a config change might | 10:14 |
| wrtp | fwereade: what if the charm change is to make a daemon start with different command-line arguments? | 10:14 |
| wrtp | fwereade: or to use an alternative daemon for something | 10:15 |
| wrtp | fwereade: there are many possible reasons a charm might be upgraded | 10:15 |
| fwereade | wrtp, ok, fair enough -- then you can do that just fine in the post-upgrade hook with a minimum of downtime | 10:15 |
| fwereade | wrtp, what good would a pre-upgrade hook do? | 10:15 |
| === TheMue_ is now known as TheMue | ||
| fwereade | wrtp, although, more likely, you'll just do that in the subsequent config-changed anyway | 10:16 |
| wrtp | 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 |
| fwereade | wrtp, I agree that that is not a good idea | 10:16 |
| wrtp | fwereade: it's probably not a good idea anyway, but i bet lots of people do it | 10:17 |
| fwereade | wrtp, that is why people should not do it | 10:17 |
| fwereade | wrtp, the charm dir is for the charm | 10:17 |
| fwereade | wrtp, the service already has a standard place for everything, surely? | 10:17 |
| wrtp | fwereade: i see that. but what *you* think of as the charm is not what others might think of as the charm | 10:18 |
| wrtp | fwereade: what place is that? | 10:18 |
| wrtp | one mo, gotta do the bins | 10:18 |
| fwereade | wrtp, service-dependent, surely? | 10:18 |
| fwereade | wrtp, but the general philosophy is that we should be able to completely nuke juju, and leave the service running unhindered | 10:19 |
| fwereade | wrtp, if the service knows about juju, the charm is being bad | 10:19 |
| fwereade | wrtp, brb ciggie | 10:21 |
| wrtp | fwereade: is there a way for a charm to find out its service name? | 10:27 |
| wrtp | 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 |
| wrtp | fwereade: i wonder if we should provide each charm with its own temporary directory that it can do whatever it likes to. | 10:30 |
| wrtp | fwereade: then deprecate the whole idea of writing to the charm dir, whether inside or outside a hook. | 10:31 |
| fwereade | wrtp, +1 on that, but I think it's independent of the don't-let-the-service-know-about-the-charm issue | 10:32 |
| wrtp | fwereade: i was responding to your "the service already has a standard place for everything, surely?" - that's not necessarily true | 10:33 |
| wrtp | fwereade: but i agree with your sentiment in general | 10:34 |
| fwereade | wrtp, by convention, if nothing else | 10:34 |
| fwereade | wrtp, if you're installing X, you tend not to put X's data files inside Y's data dir | 10:35 |
| wrtp | fwereade: what if you're installing two Xs? | 10:35 |
| wrtp | fwereade: we really really really need to write some decent docs | 10:35 |
| fwereade | wrtp, agreed there :) | 10:36 |
| wrtp | fwereade: that was a genuine question above BTW; is there a way for a charm to find out its service name? | 10:36 |
| fwereade | wrtp, not directly, but it knows its unit name | 10:37 |
| wrtp | fwereade: ah, that's good enough then. | 10:37 |
| wrtp | fwereade: how does it find its own unit name? | 10:37 |
| fwereade | wrtp, JUJU_UNIT_NAME I think | 10:37 |
| fwereade | wrtp, yep | 10:38 |
| fwereade | wrtp, what would you expect to need it for? | 10:38 |
| fwereade | wrtp, (the service name, I mean) | 10:38 |
| wrtp | 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:39 |
| fwereade | wrtp, I'd expect the relation id to be the disambiguator, but maybe that's not right | 10:40 |
| wrtp | fwereade: there may be no relation | 10:41 |
| fwereade | wrtp, how do you deploy a subordinate without a relation? | 10:41 |
| wrtp | fwereade: i suppose for subordinates, there's always a relation | 10:41 |
| wrtp | fwereade: but do you know that relation id when you're executing the install hook? | 10:42 |
| fwereade | wrtp, shouldn't the install hook just, er, install? | 10:42 |
| wrtp | fwereade: it might need to install to some charm-external directory. same applies to the start hook. | 10:43 |
| fwereade | wrtp, I'm not sure that we're trying to solve the run-multiple-versions-of-the-same-software problem here are we? | 10:43 |
| wrtp | 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 |
| wrtp | 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:44 |
| wrtp | fwereade: (i'm imagining a subordinate service that provides some fairly general functionality, determined by the config settings) | 10:45 |
| fwereade | wrtp, then, in that case, surely the unit name is a reasonable disambiguator there | 10:45 |
| wrtp | fwereade: indeed | 10:46 |
| fwereade | wrtp, and the relation id is good for handling multiple relations run by the same charm | 10:46 |
| wrtp | fwereade: yeah | 10:46 |
| * fwereade once again fails to successfully use wrtp's fly-killing techniques | 11:50 | |
| fwereade | but it was *close* that time | 11:50 |
| wrtp | fwereade: you'll get there :-) | 11:50 |
| wrtp | fwereade: did it escape through the top or the bottom? | 11:50 |
| fwereade | wrtp, bottom | 11:50 |
| wrtp | fwereade: keep trying... | 11:51 |
| fwereade | wrtp, really impressively sharp turn away actually, it probably deserved to live | 11:51 |
| wrtp | fwereade: you're selecting for canny flies | 11:51 |
| wrtp | fwereade: a few more generations and you'll never get 'em | 11:51 |
| fwereade | wrtp, I'm not saying I won't try again next time it comes in range ;) | 11:51 |
| wrtp | crack crack crackity crack | 12:11 |
| * wrtp has just found out why his tests were passing when they couldn't possibly be passing | 12:12 | |
| wrtp | niemeyer: morning | 12:42 |
| wrtp | ! | 12:42 |
| niemeyer | Good morning! | 12:42 |
| wrtp | 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:44 |
| fwereade | niemeyer, heyhey | 12:45 |
| wrtp | niemeyer: i thought of something this morning and could not for the life of me think how the tests were passing | 12:45 |
| wrtp | niemeyer: and that's the reason... | 12:45 |
| niemeyer | wrtp: Hah | 12:46 |
| niemeyer | fwereade: yo | 12:46 |
| wrtp | niemeyer: i thought it all went a bit too smoothly! | 12:46 |
| niemeyer | Aram: ping | 12:54 |
| Aram | yo | 12:54 |
| Aram | hello | 12:54 |
| Aram | niemeyer: ^ ^ | 12:55 |
| niemeyer | Aram: Heya! | 12:55 |
| niemeyer | Aram: Good point regarding the check | 12:55 |
| niemeyer | 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 |
| Aram | niemeyer: perhaps it's still a good idea to check if pending is required at the begining of the logic. | 12:56 |
| Aram | so we do it only once | 12:56 |
| Aram | and then depending on that boolean and the rest of the logic determine what to actual returnm | 12:57 |
| Aram | does that make sense? | 12:57 |
| Aram | alteratively, we could do it once at the end. | 12:57 |
| Aram | but I think logic is simpler if we do it at the begining. | 12:57 |
| niemeyer | Aram: I think having this logic in a small method would be as nice, and perhaps more clear | 12:58 |
| Aram | good idea. | 12:58 |
| niemeyer | Aram: hasString and hasInt can probably be shared by all watchers | 13:00 |
| Aram | yes | 13:00 |
| fwereade | hmm, maybe I should eat something, bbiab | 13:07 |
| niemeyer | fwereade: Sounds wise | 13:07 |
| wrtp | niemeyer: fairly trivial: https://codereview.appspot.com/6641053 | 13:15 |
| wrtp | oops, the branch is misnamed | 13:16 |
| wrtp | niemeyer: renamed and reproposed | 13:17 |
| wrtp | https://codereview.appspot.com/6635062 | 13:17 |
| niemeyer | wrtp: On a call with flacoste.. back in a bit | 13:23 |
| wrtp | niemeyer: np | 13:23 |
| === andrewsmedina is now known as fssparademimipor | ||
| niemeyer | wrtp: Very ncie | 14:01 |
| niemeyer | nice | 14:01 |
| wrtp | niemeyer: thanks | 14:06 |
| wrtp | niemeyer: another fairly small one: https://codereview.appspot.com/6604061 | 14:12 |
| niemeyer | wrtp: LGTM | 14:14 |
| wrtp | niemeyer: lovely, thanks | 14:14 |
| === fssparademimipor is now known as andrewsmedina | ||
| niemeyer | Connection Timeout: disconnecting client after 300.0 seconds | 14:49 |
| niemeyer | bzr: broken pipe | 14:49 |
| niemeyer | Am I the only one facing those issues? | 14:49 |
| fwereade | niemeyer, I think so -- I did notice slightly greater than usual flakiness earlier this week but that's it | 14:50 |
| niemeyer | fwereade: Weird.. I can't really guess what could be causing it | 14:52 |
| niemeyer | Everything else seems to work normally | 14:52 |
| wrtp | Aram: i just saw this test failure. looks like something's not sorting the unit names as expected: http://paste.ubuntu.com/1271309/ | 15:07 |
| Aram | wrtp: sorry, my fault. | 15:08 |
| Aram | will fix right away | 15:08 |
| wrtp | Aram: thanks! | 15:08 |
| * wrtp only discovered this morning that you can do tail -f * and it works how you'd want. | 15:13 | |
| wrtp | niemeyer: next step: https://codereview.appspot.com/6615071 | 15:15 |
| Aram | wrtp: quick trivial so I fix the build: https://codereview.appspot.com/6625075/ | 15:17 |
| wrtp | Aram: LGTM | 15:17 |
| Aram | wrtp: sorry for the breakage, in my defense I always run the state tests 20 times before submitting, and it worked here.\ | 15:18 |
| fwereade | 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:19 |
| niemeyer | wrtp: done | 15:21 |
| niemeyer | fwereade: RelationContext or ContextRelation? | 15:21 |
| fwereade | niemeyer, ha, ContextRelation, I'm pretty sure I've changed the name throughout, but my brain hasn't synced up yet | 15:22 |
| fwereade | niemeyer, (ContextRelation would also move) | 15:22 |
| niemeyer | 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:22 |
| fwereade | niemeyer, I'm planning to move it into the existing hook package | 15:23 |
| niemeyer | fwereade: Is that an answer to the above question? | 15:25 |
| fwereade | niemeyer, not really, still composing | 15:25 |
| fwereade | 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:26 |
| fwereade | niemeyer, it's probably not justified yet though | 15:27 |
| niemeyer | fwereade: My feeling is that Context will be strongly bound to the uniter data, but I don't really know yet | 15:28 |
| fwereade | 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:39 |
| fwereade | 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:42 |
| wrtp | niemeyer, fwereade: what do you think about log.Printf messages, and whether/how they should be prefixed? | 15:44 |
| wrtp | the first log messages i did (in environs/ec2, for example) are prefixed with the package name. | 15:45 |
| wrtp | TheMue, Aram: any thoughts? | 15:45 |
| fwereade | 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 |
| TheMue | wrtp: my personal logging package has the package es prefix in braces, and that's helpful | 15:46 |
| wrtp | i think that some prefix is nice to have, as it makes it obvious where the messages are coming from | 15:46 |
| TheMue | wrtp: so i don't have to think about, it's done automatically | 15:46 |
| wrtp | fwereade: my thought has been: error messages have no prefix; printed messages get a prefix. | 15:46 |
| wrtp | TheMue: that's a reasonable approach actually | 15:47 |
| wrtp | TheMue: assuming we remove the launchpad.net/juju-core/ part of the package path | 15:48 |
| fwereade | wrtp, doesn't sound unreasonable, but don't really have strong feelings | 15:48 |
| fwereade | brb | 15:48 |
| TheMue | wrtp: my package currently shows the full path, but yes, that should be configurable (as well as the logging level) | 15:48 |
| TheMue | wrtp: see https://code.google.com/p/tcgl/source/browse/applog/applog.go | 15:49 |
| TheMue | wrtp: Debugf() also shows filename, function name and line number | 15:51 |
| wrtp | TheMue: tbh i think that's a bit heavyweight for what we want. | 15:52 |
| TheMue | wrtp: sure, that's my personal approach. but the automatic prefix could help | 15:52 |
| wrtp | TheMue: i'm happy with seeing the prefix in the message itself - then it's very obvious how the message is being made | 15:52 |
| wrtp | TheMue: i dunno, i could go either way | 15:53 |
| TheMue | wrtp: yes, doing it by convention may be enough | 15:54 |
| TheMue | wrtp: sometime i fall back in my mainframe history *lol* | 15:54 |
| * TheMue has to step out, wife needs me for shopping. bbl. | 15:56 | |
| niemeyer | fwereade, wrtp: We had jointly decided to drop these prefixes.. my reviews were merely attempting to put in place what we agreed | 16:01 |
| wrtp | niemeyer: ah, i don't think i saw that discussion | 16:01 |
| fwereade | niemeyer, likewise -- but not bothered by it :) | 16:02 |
| niemeyer | wrtp: You were part of it for sure.. it's just been a while | 16:02 |
| wrtp | niemeyer: personally, i think the prefixes are useful, particular when the messages from different workers are mixed up in the same file | 16:02 |
| niemeyer | fwereade, wrtp: We can change the convention.. I just don't want to be going back and forth pretending we have a convention when we don't | 16:02 |
| wrtp | niemeyer: ok, yeah, i definitely thought we had a convention to have prefixed for log messages but not for error messages. | 16:02 |
| wrtp | s/prefixed/prefixes/ | 16:03 |
| niemeyer | wrtp: I hadn't seen that distinction yet, but happy to have it | 16:03 |
| wrtp | niemeyer: i'm slightly wondering if you're thinking about the error-message prefix conventions | 16:03 |
| niemeyer | wrtp: Yes, I'm thinking of those too | 16:04 |
| wrtp | niemeyer: ah, i see | 16:04 |
| wrtp | niemeyer: i think there's a definite difference. | 16:04 |
| wrtp | niemeyer: error messages are usually printed as a suffix to something else | 16:04 |
| wrtp | niemeyer: log messages are printed by themselves. | 16:04 |
| niemeyer | wrtp: Not really | 16:05 |
| niemeyer | wrtp: We don't have that convention today in any meaningful way.. logged messages are all over the place | 16:05 |
| wrtp | niemeyer: all the log messages i've written have a prefix, i think | 16:05 |
| niemeyer | wrtp: "That's the way I do" != "That's the convention we use" | 16:05 |
| wrtp | niemeyer: indeed. i tried to make a convention by writing log messages that way, but we never discussed it. | 16:06 |
| niemeyer | wrtp: Can you please just send a message to juju-dev so that it's actually an agreed convention? | 16:06 |
| wrtp | niemeyer: ok, will do | 16:07 |
| niemeyer | wrtp: Thanks! | 16:10 |
| wrtp | niemeyer: done | 16:21 |
| niemeyer | fss: ping | 16:36 |
| niemeyer | Aram: ping | 16:37 |
| Aram | niemeyer: pong | 16:37 |
| niemeyer | Aram: Re. "Addressed review points. Not submitting because I'm waiting for changes | 16:37 |
| niemeyer | in firewaller and machiner, so I don't break the build." | 16:37 |
| niemeyer | Aram: What changes? | 16:37 |
| Aram | niemeyer: the firewaller and the machiner use the old, API incompatible version of the watcher | 16:37 |
| Aram | (the one that returns entities, not ids). | 16:38 |
| niemeyer | Aram: Would you mind to cover that as well so that we can integrate that change? | 16:38 |
| Aram | I'll take a look. | 16:39 |
| niemeyer | Aram: I think you can have an idea for the change by diffing.. hmmm | 16:39 |
| niemeyer | Aram: Within the firewaller directory: bzr diff -r 600..601 . | vi - | 16:40 |
| niemeyer | Aram: It should be fairly simple.. my suggestion is to, right below those case unit, ok := <-ud.watcher.Changes():" lines, actually load the unit | 16:41 |
| fss | niemeyer: pong | 16:41 |
| niemeyer | Aram: The rest will remain mostly untouched | 16:41 |
| niemeyer | fss: Hey | 16:41 |
| niemeyer | fss: I'm trying to merge your changes | 16:41 |
| niemeyer | fss: Both look good | 16:41 |
| niemeyer | fss: iam-deleteuser is conflicting with the previous branch, though | 16:42 |
| fss | niemeyer: =/ | 16:42 |
| niemeyer | fss: Can you please merge lp:goamz into iam-deleteuser, fix conflicts, run tests, and re-propose? | 16:42 |
| niemeyer | fss: I'll then submit | 16:42 |
| fss | niemeyer: sure | 16:42 |
| niemeyer | fss: Cheers! | 16:43 |
| fss | niemeyer: I'll do it in a second | 16:43 |
| fss | niemeyer: if I get in any trouble using bzr, I may ask for your help :-) | 16:44 |
| niemeyer | fss: Sure thing | 16:44 |
| fwereade | out for a while, have good evenings all | 16:49 |
| wrtp | fwereade: have fun | 16:53 |
| wrtp | niemeyer: does it matter that anything logged into the database can change the password for any other entity? | 16:53 |
| wrtp | niemeyer: i'm kinda presuming not, but it surprised me slightly. | 16:54 |
| niemeyer | wrtp: I mentioned it a few times when were brainstorming on the concept | 16:54 |
| wrtp | niemeyer: that must've gone over my head, sorry | 16:54 |
| niemeyer | wrtp: We won't be playing games with database permissions at the moment | 16:54 |
| niemeyer | wrtp: np | 16:54 |
| niemeyer | wrtp: Just saying it's expected | 16:54 |
| wrtp | niemeyer: cool | 16:55 |
| niemeyer | wrtp: The reason for the apparently silly care we're taking now is because this is the same logic we'll need once we have the API | 16:55 |
| niemeyer | wrtp: Once we get the API, we can easily cut down that kind of cross-talking | 16:55 |
| wrtp | niemeyer: i just wrote another test in state to verify that it works, because i thought it didn't :-) | 16:55 |
| niemeyer | wrtp: It surely does.. the authentication is against the database.. the user data is inside the database | 16:56 |
| wrtp | niemeyer: yeah - i guess i thought there was a difference between admin users and other users | 16:56 |
| niemeyer | wrtp: There is in fact | 16:56 |
| wrtp | niemeyer: ah yes, i remember | 16:57 |
| niemeyer | wrtp: We add the admin to the admin database, which means it can manipulate everything | 16:57 |
| wrtp | niemeyer: but it doesn't make any difference to us, because we only have two dbs | 16:57 |
| wrtp | niemeyer: i was thinking that only the admin could add users | 16:57 |
| niemeyer | wrtp: Certain commands can only be run against the admin database | 16:57 |
| niemeyer | wrtp: So there's actually some practical implication in addition to hat | 16:57 |
| niemeyer | that | 16:57 |
| niemeyer | wrtp: Only admins can add users to all databases | 16:58 |
| wrtp | niemeyer: uh huh | 16:58 |
| niemeyer | wrtp: We shouldn't worry too much about that, though.. our primary goals on that round is getting basic authentication and transport security in place | 16:59 |
| niemeyer | wrtp: We can split down capabilities on the next round, once we get the API stuff going | 16:59 |
| wrtp | niemeyer: take it or leave it, i don't mind. https://codereview.appspot.com/6636057 | 17:01 |
| niemeyer | wrtp: Hmm, that's pretty interesting | 17:07 |
| niemeyer | wrtp: I suspect we'll want to enable the machine to set a unit's password, *if* the unit is assigned to the machine | 17:08 |
| wrtp | niemeyer: yeah, that's a good point. | 17:08 |
| niemeyer | wrtp: So that we can deploy the unit within the machine with a password that is locally defined and thus known by the machine so that it can provide --initial-password | 17:09 |
| niemeyer | wrtp: It shouldn't be able to set the password for an unrelated unit, though | 17:09 |
| wrtp | niemeyer: agreed | 17:09 |
| wrtp | niemeyer: the test should probably assign the units to the given machine | 17:09 |
| wrtp | niemeyer: but maybe it's nice to have a test that will fail in an interesting way when we add appropriate capability checking | 17:10 |
| niemeyer | wrtp: Not sure.. I'd prefer to not waste time writing tests we know are wrong | 17:12 |
| wrtp | niemeyer: ok. i can easily do that for this test if you like; or i can just drop the CL for now. | 17:13 |
| niemeyer | wrtp: I sometimes do that when I'm not in charge of implementing the feature, just so I can tell when upstream has changed, but that's not the case.. we know exactly when that will be done, and know it won't be a trivial change | 17:13 |
| niemeyer | wrtp: I'm happy to have the CL with the Assign change.. it's already written, and this would verify intended behavior | 17:14 |
| wrtp | niemeyer: ok, will do | 17:14 |
| * niemeyer sips some nice coffee | 17:18 | |
| niemeyer | wrtp: Thanks man | 17:19 |
| wrtp | niemeyer: unit passwords: https://codereview.appspot.com/6632061 | 17:28 |
| niemeyer | wrtp: Checking | 17:31 |
| niemeyer | wrtp: done | 17:34 |
| wrtp | niemeyer: thanks | 17:34 |
| niemeyer | wrtp: np | 17:35 |
| wrtp | niemeyer: i've fixed the password test: https://codereview.appspot.com/6636057 | 17:36 |
| niemeyer | wrtp: LGTM.. would be nice to clarify the commit message | 17:37 |
| wrtp | niemeyer: will do. in fact, i'll submit tomorrow, as i hear a voice from below... | 17:38 |
| wrtp | niemeyer: have a good rest-of-day | 17:39 |
| wrtp | night all | 17:39 |
| niemeyer | wrtp: Thanks, and have a good one too! | 17:39 |
| fss | let the merge begin | 17:46 |
| niemeyer | fss: Good to go? | 17:54 |
| niemeyer | Hmm.. not yet | 17:55 |
| fss | lbox proposing :-) | 17:55 |
| fss | niemeyer: ptal | 17:56 |
| niemeyer | fss: Looking | 17:56 |
| niemeyer | fss: On the way | 17:59 |
| fss | niemeyer: \o/ | 18:04 |
| fss | niemeyer: later today i'll start sending iamtest package | 18:04 |
| niemeyer | fss: Sweet! | 18:06 |
| fss | niemeyer: https://codereview.appspot.com/6631063 | 18:55 |
| niemeyer | fss: Looking | 18:56 |
| fss | niemeyer: thanks :-) | 18:56 |
| fss | niemeyer: notice that I didn't use iamtest_test in tests, so it was easier to test the calls, accessing private members of Server directly. What do you think? | 18:57 |
| niemeyer | fss: Being able to ask the test server for which users exist sounds useful | 18:58 |
| niemeyer | fss: I'd prefer to have that as part of the public interface, and have the test not poking at internals | 18:58 |
| fss | niemeyer: I see | 18:59 |
| niemeyer | fss: Also, we really need the integration test in the same style we have within ec2 | 18:59 |
| niemeyer | fss: So that someone can run tests for goamz/iam and have an idea that Amazon is actually happy with the implementation | 19:00 |
| fss | niemeyer: hmm | 19:00 |
| niemeyer | fss: The existing stuff within ec2i_test.go should serve as inspiration | 19:00 |
| fss | niemeyer: I will add these integration tests | 19:00 |
| fss | niemeyer: then provide GetUser support on iam, and use it to test iamtest's CreateUser and DeleteUser | 19:01 |
| niemeyer | fss: Right, that's a great way to wire things together | 19:01 |
| fss | niemeyer: actually, I think I'll need GetUser for CreateUser and DeleteUser integration tests too | 19:02 |
| niemeyer | fss: Then you know that: a) goamz/iam works agains the real interface; b) goamz/iam works against the fake interface; Thus c) the real and the fake interface look alike | 19:02 |
| niemeyer | fss: Absolutely | 19:02 |
| niemeyer | fss: And you can do that with a single suite | 19:03 |
| fss | niemeyer: a single suite? | 19:03 |
| niemeyer | fss: Have a look at ec2i_test.go, and the relationship between ClientTests and AmazonClientSuite | 19:04 |
| fss | niemeyer: ok, thanks :-) | 19:04 |
| niemeyer | fss: Then, check out ec2t_test.go, and check how LocalServerSuite is defined | 19:04 |
| fss | niemeyer: cool, thanks for the help. Time for some fun | 19:08 |
| niemeyer | fss: np | 19:14 |
| fss | niemeyer: here is GetUser, I will use it in integration tests: https://codereview.appspot.com/6631064 | 19:17 |
| fss | niemeyer: now I will start to work on the integration suite | 19:17 |
| niemeyer | fss: Looking | 19:17 |
| niemeyer | fss: Looks good.. just a trivial on the doc | 19:20 |
| fss | niemeyer: opsss | 19:20 |
| fss | niemeyer: shame on me | 19:20 |
| fss | niemeyer: ptal | 19:22 |
| niemeyer | fss: No worries, and thanks | 19:22 |
| niemeyer | fss: That's in | 19:28 |
| fss | niemeyer: thanks, I'm looking ec2i_test and ec2t_test | 19:33 |
| fss | niemeyer: the integration suite already paid itself, the error treatment is broken. Should I send the fix with the integration tests cl, or in a separate CL? | 20:09 |
| niemeyer | fss: It's fine to be in the same CL in that case.. it's really the test for the fix | 20:10 |
| fss | niemeyer: ok | 20:14 |
| fss | niemeyer: do you have any trouble with lbox + vim? | 20:17 |
| fss | niemeyer: whenever I use vim, I get "error: Change summary is empty.". It's like vim is not actually saving the temporary file in the disc | 20:18 |
| niemeyer | fss: Hmm.. nope.. works fine here | 20:19 |
| niemeyer | fss: How does $EDITOR look like? | 20:19 |
| fss | EDITOR=/usr/local/vim | 20:19 |
| fss | I set it to nano, so I can send the cl | 20:19 |
| fss | /usr/local/bin/vim, sorry | 20:20 |
| fss | niemeyer: here we go: https://codereview.appspot.com/6625077 | 20:23 |
| niemeyer | fss: Looking | 20:24 |
| niemeyer | fss: Are you sure you're saving the file? I really can't imagine what might be going on | 20:24 |
| fss | ec2t_test.go is the test suite for the ec2test package? | 20:25 |
| fss | niemeyer: yes, I can `cat` it | 20:25 |
| niemeyer | fss: Very strange.. if you find what's up, please let me know | 20:25 |
| niemeyer | fss: On the previous question, yes | 20:26 |
| fss | niemeyer: I've compiled /usr/local/bin/vim by hand, I'll try /usr/bin/vim later and see if the problem persists | 20:26 |
| niemeyer | fss: Suite is great, thanks. Submitting | 20:26 |
| fss | niemeyer: okay, I'll add iamt_test in the previous iamtest CL | 20:26 |
| niemeyer | fss: Ah, please add to a new one | 20:26 |
| niemeyer | fss: I'm moving this one forward | 20:26 |
| fwereade | niemeyer, heyhey | 20:27 |
| fss | niemeyer: this one? https://codereview.appspot.com/6631063/ | 20:27 |
| niemeyer | fss: Ah, sorry, I misunderstood, that's great | 20:30 |
| niemeyer | fwereade: Heya | 20:30 |
| fwereade | niemeyer, re HookContext.service: perhaps I've been making bad assumptions re service config -- I had assumed that we'd be able to get the config for the unit's current charm without directly involving the service at all... but now I seem to recall a discussion in which you were planning to keep all a service's configs in a single document | 20:31 |
| fwereade | niemeyer, well, not necessarily planning | 20:31 |
| fwereade | niemeyer, I can't remember whether you were for or against it | 20:32 |
| niemeyer | fwereade: That's probably because I wasn't either for or against it :-) | 20:32 |
| fwereade | niemeyer, that would explain my inability to recall one or the other :) | 20:33 |
| niemeyer | fwereade: Hehe :) | 20:33 |
| niemeyer | fwereade: I'm still wondering, actually.. I leaning slightly towards different documents | 20:33 |
| fwereade | niemeyer, so, with that half-baked assumption in mind, it seemed clear that the service was enitrely transitory data | 20:33 |
| fwereade | niemeyer, I think my brain had drifted into a similar configuration | 20:33 |
| fwereade | niemeyer, it had crossed my mind that it would be convenient to key them on service name + charm url, which can be constructed trivially from a unit | 20:34 |
| fwereade | niemeyer, and so service seemed like a sort of unwanted appendix that didn't really deserve a field | 20:34 |
| niemeyer | fwereade: service.Config(charmURL) is perhaps the best candidate at the moment | 20:34 |
| niemeyer | fwereade: With optional charmURL, so service.Config(nil) returns the tip | 20:35 |
| fwereade | niemeyer, my heart says unit.ServiceConfig(), but I expect you have good reasons for your choice... yeah, it's more orthogonal | 20:35 |
| niemeyer | fwereade: That sounds slightly awkward.. unit.ServiceCharm()? unit.ServiceCharmURL()? :-) | 20:36 |
| fwereade | niemeyer, just so long as the unit is up to date, anyway -- but, yeah, at least the service wouldn't need a refresh | 20:36 |
| fwereade | niemeyer, it's not my heart: it's my lazy fingers that want it, and my brain has now overruled them | 20:37 |
| niemeyer | fwereade: LOL | 20:37 |
| fwereade | niemeyer, => service is an expected long-term feature of HookContext => it stays | 20:37 |
| fwereade | niemeyer, cheers | 20:38 |
| niemeyer | fwereade: Cool, I see your original reasoning as well, thanks | 20:38 |
| fwereade | niemeyer, btw, possible uniter weirdness | 20:39 |
| fwereade | niemeyer, given that .unit (and, I guess, .service ;)) are long-lived, I'm conflicted about when they should be being refreshed | 20:40 |
| niemeyer | fwereade: If we don't know it probably means we don't have to refresh (yet) | 20:41 |
| fwereade | niemeyer, ha, I have just looked at the state code... I'm sure I remember a time when we weren't always updating the local doc with the change we made | 20:42 |
| niemeyer | fwereade: Ah, we should, I think | 20:43 |
| fwereade | niemeyer, (was there some idea at one stage that a local state doc should always reflect the actual state of the remote document at some point in time, rather than being a palimspest?) | 20:43 |
| niemeyer | fwereade: I think we were unsure until the first sprint in Lisbon | 20:44 |
| fwereade | niemeyer, must have just missed more recent conversations | 20:44 |
| niemeyer | fwereade: That's when we explored the options in details, and agreed on doing what we have now | 20:44 |
| niemeyer | fwereade: I don't think we've changed the approach since then | 20:44 |
| fwereade | niemeyer, great | 20:44 |
| niemeyer | fwereade: That doesn't mean it's perfect, but at least so far things to be holding together | 20:45 |
| niemeyer | erm | 20:45 |
| niemeyer | things seem to be | 20:45 |
| fwereade | niemeyer, yeah, so far, digging deeper has always reassured me | 20:45 |
| fwereade | niemeyer, oh, btw | 20:46 |
| fwereade | niemeyer, filter has a config watch, which is only used in ModeAbide (but will probably also be used in ModeAbideDying, which wil emerge at some stage) | 20:47 |
| fwereade | niemeyer, however, I am in the position of adding a relations watch which is only going ot be useful to a single mode | 20:47 |
| niemeyer | fwereade: Cool | 20:47 |
| fwereade | niemeyer, and it's feeling a little bit off-kilter | 20:47 |
| niemeyer | fwereade: Because we're watching things we can't always act upon? | 20:48 |
| fwereade | niemeyer, partly... but more because ModeAbide, as a consumer, will be acting on uniter-wide state in response to these changes | 20:48 |
| niemeyer | fwereade: Hmm.. I don't yet see the light | 20:49 |
| fwereade | niemeyer, and it is, I think, flat-out *wrong* for any other mode to use those events and mess with state in response to them | 20:49 |
| fwereade | niemeyer, unless they do exactly what ModeAbide does | 20:49 |
| niemeyer | fwereade: Sure, but that sounds a bit of a general rule | 20:50 |
| niemeyer | fwereade: It's flat out wrong for any mode to watch state and do changes they shouldn't | 20:50 |
| fwereade | niemeyer, I think what I'm trying to say is that it's legitimate for different modes to respond to (say) resolved events in different ways | 20:51 |
| niemeyer | fwereade: I think I understand what you're saying, but IMO what you describe is one of the benefits we intended with the filter method | 20:52 |
| niemeyer | fwereade: To me it's a huge simplification the fact we can simply allow modes to care about stuff they should, and ignore the stuff (including events) they shouldn't act upon | 20:52 |
| fwereade | niemeyer, ok: (drags self laboriously towards point) I am conflicted over whether or not I should implement a WantRelationsEvent on filter | 20:53 |
| niemeyer | fwereade: I suggest not implementing it until there's a need for the logic | 20:54 |
| niemeyer | fwereade: It won't save us from someone using the method when they shouldn't, and it'll mean we'll have to write and read the logic for the whole thing | 20:55 |
| fwereade | niemeyer, well -- I'm not sure why it is a good idea to add complexity to filter -- which is pretty clean, but not unworthy of careful treatment | 20:56 |
| fwereade | niemeyer, when I can be pretty sure that only ModeAbide should ever be messing with those events | 20:57 |
| fwereade | niemeyer, especially considering that ModeInit and ModeAbideDying will themselves be expected to independently manipulate runtime relation state | 20:57 |
| niemeyer | fwereade: I don't understand how the two things link together | 20:57 |
| niemeyer | fwereade: Yes.. only ModeAbide should be receiving those events, so...? | 20:58 |
| fwereade | niemeyer, sorry, I'm rather thinking out loud | 20:58 |
| niemeyer | fwereade: Seems to be tightly related to everything I said above | 20:58 |
| fwereade | niemeyer, so it is bad and scary and wrong to let anyone else see them | 20:58 |
| niemeyer | <niemeyer> fwereade: I think I understand what you're saying, but IMO what you describe is one of the benefits we intended with the filter method | 20:58 |
| niemeyer | <niemeyer> fwereade: To me it's a huge simplification the fact we can simply allow modes to care about stuff they should, and ignore the stuff (including events) they shouldn't act upon | 20:58 |
| niemeyer | <niemeyer> fwereade: It won't save us from someone using the method when they shouldn't, and it'll mean we'll have to write and read the logic for the whole thing | 20:58 |
| fwereade | niemeyer, primarily because they are not recoverable in the way that, say, a resolved event is | 20:58 |
| fwereade | niemeyer, if there is only a single correct way to consume these events, and we cannot recover history, it seems unwise to leave them lying around on filter where not-William (;)) can use them | 21:00 |
| niemeyer | fwereade: Understood.. recoverable as in we can't request the same event to be sent again | 21:00 |
| niemeyer | fwereade: Right? | 21:00 |
| fwereade | niemeyer, yes | 21:01 |
| niemeyer | fwereade: Cool, so WantConfig would be fine it seems | 21:01 |
| niemeyer | fwereade: Except, do we want to run that at all times? | 21:01 |
| fwereade | niemeyer, WantConfig is ok because (1) it's recoverable and (2) it's used by 2 modes, even though one of them doesn't exist | 21:01 |
| fwereade | yet | 21:02 |
| niemeyer | fwereade: I don't think I get it.. WantConfig would mean we'd *always* get such an event | 21:02 |
| fwereade | niemeyer, yeah, that's exactly the idea | 21:02 |
| niemeyer | fwereade: and my understanding is that we don't want to run a config-changed hook unless the config changed, in normal situations | 21:02 |
| niemeyer | fwereade: which is what ModeAbide is about, in my understanding | 21:03 |
| fwereade | niemeyer, except when we enter ModeAbide -- we agreed this was a clean way to guarantee that start and upgrade-charm were always succeeded by config-changed | 21:03 |
| * fwereade twitches as an idea clicks | 21:04 | |
| fwereade | niemeyer, huh, I don't need it in ModeAbideDying | 21:04 |
| fwereade | niemeyer, so now we have relations more like config than anything else, and neither of them really deserves to dirty up the filter | 21:04 |
| niemeyer | fwereade: Won't we get into ModeAbide when we get out of an error state? Or out of a relatoin changed state? Etc? | 21:05 |
| fwereade | niemeyer, we discussed this, and yu were keen on it; the primary justification, which I was very happy with, was that if *any* hook *had* to be idempotent anyway, it was config-changed | 21:05 |
| niemeyer | fwereade: I totally agree with that | 21:06 |
| niemeyer | fwereade: I don't think I agreed we should run config-changed whenever we sneeze, though :-) | 21:06 |
| fwereade | niemeyer, the only extra time it's run is after ModeHookError AFAIR | 21:07 |
| niemeyer | fwereade: ModeAbide is the steady state.. we'll get into it everytime we get out of any other mode | 21:07 |
| fwereade | niemeyer, easy to change, happy to do it (queued hooks are already a thing), will be nicer :) | 21:08 |
| fwereade | niemeyer, at this stage the only reason to do it is historical | 21:08 |
| niemeyer | fwereade: Cool | 21:08 |
| fwereade | niemeyer, the uniter's shed a lot of complexity since then :) | 21:08 |
| niemeyer | fwereade: Indeed | 21:09 |
| fwereade | niemeyer, hum, ok | 21:11 |
| fwereade | niemeyer, wait | 21:11 |
| fwereade | niemeyer, we *also* run config-changed whenever we start up and first come into modeabide | 21:11 |
| fwereade | niemeyer, and that is necessary | 21:11 |
| niemeyer | fwereade: Right, after start | 21:12 |
| fwereade | niemeyer, because we don't have any permanent record of service config version | 21:12 |
| fwereade | niemeyer, no, any time we're bounced | 21:12 |
| niemeyer | fwereade: bounced? | 21:12 |
| fwereade | niemeyer, process death | 21:12 |
| fwereade | niemeyer, or even just the UA restarting the uniter | 21:12 |
| fwereade | niemeyer, I did think this was crazy | 21:13 |
| niemeyer | fwereade: Hmm.. why is it crazy? | 21:14 |
| fwereade | niemeyer, because it forces us to run one whenever we enter ModeaBIDE :) | 21:14 |
| niemeyer | fwereade: The two things sound pretty unrelated | 21:14 |
| fwereade | niemeyer, we're entering ModeAbide, and we might need to run a config-changed hook | 21:15 |
| fwereade | niemeyer, how do we tell? | 21:15 |
| niemeyer | fwereade: One is a high-level requirement, the other is an implementation detail | 21:15 |
| * niemeyer looks at fwereade | 21:15 | |
| niemeyer | fwereade: Okay, it's pretty late there.. I'll help.. how can we tell when is the first thing we do something inside a process or type? | 21:16 |
| niemeyer | s/first thing/first time | 21:16 |
| fwereade | niemeyer, ha :/ | 21:16 |
| fwereade | niemeyer, seems somehow wrong to have to store that state on the uniter itself | 21:16 |
| niemeyer | fwereade: There are many ways to do it, but it's far from a OMG case :) | 21:17 |
| niemeyer | fwereade: Sorry, I have to run a quick errand.. I'll be back in ~15mins | 21:19 |
| fwereade | niemeyer, quite so... it feels weird to make the uniter stateful like that | 21:19 |
| fwereade | niemeyer, np, will probably be around ;) | 21:19 |
| niemeyer | fwereade: LOL.. just ponder for a moment about that last statement regarding how it's weird to make the uniter stateful :-) | 21:19 |
| fss | niemeyer: here is it: https://codereview.appspot.com/6631063/ | 21:21 |
| fss | niemeyer: I've implemented iamt_test.go running full ClientTests suite, since they're born together | 21:21 |
| niemeyer | fwereade: Around again | 21:53 |
| niemeyer | fwereade: So, | 22:16 |
| niemeyer | fwereade: back to your point, the uniter is already pretty stateful.. we have a full state machine on it | 22:16 |
| fwereade | niemeyer, yeah, indeed | 22:16 |
| niemeyer | fwereade: (a pretty nice one, actually!) :-) | 22:16 |
| fwereade | niemeyer, I'm implementing it now, it's interesting | 22:16 |
| niemeyer | fwereade: I'm not sure if I misunderstood the heart of your point, though.. maybe it's becoming stateful in a way it wasn't? | 22:17 |
| fwereade | niemeyer, well, the state machine is really in the modes, which aren't in uniter fields, but I take your point | 22:17 |
| fwereade | niemeyer, I think the code will illustrate my perspective better than anything I can say, and I*think* it's nearly there | 22:18 |
| niemeyer | fwereade: There are actually other stateful bits too.. filter being a notable example | 22:18 |
| fwereade | niemeyer, yeah, indeed, I actually don;t think it's a bad thing -- I've just got very used to Modes not directly using uniter for state, except as a proxy for disk state | 22:20 |
| fwereade | niemeyer, I have a nervous feeling about this code, because I'm not sure whether or not you'll like it -- it's relatively neat, but I felt the need to comment to explain what it's doing in one place, which is always a bit of a worry | 22:36 |
| fwereade | niemeyer, ready to propose in a sec | 22:36 |
| fwereade | niemeyer, then I should go, need to be up tomorrow (bah) | 22:36 |
| niemeyer | fwereade: Thanks a lot, looking forward to checking it out | 22:37 |
| fwereade | niemeyer, ok, looking at it in codereview, I think it's pretty good :) https://codereview.appspot.com/6632062 | 22:43 |
| * fwereade suspects these words will come back to haunt him | 22:44 | |
| niemeyer | fwereade: Hehe :-) | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
