| niemeyer | Mornings | 08:56 |
|---|---|---|
| fwereade_ | heya niemeyer | 08:56 |
| rog | niemeyer, fwereade_: yo! | 08:58 |
| fwereade_ | niemeyer, you're up early :) | 08:58 |
| niemeyer | fwereade_, rog: Yos! | 08:59 |
| niemeyer | fwereade_: Yeah, a bit earlier than usual today | 09:00 |
| TheMue | morning gustavo | 09:25 |
| niemeyer | TheMue: hey hey! | 09:25 |
| niemeyer | TheMue: Welcome! :-) | 09:26 |
| TheMue | niemeyer: thx | 09:26 |
| TheMue | niemeyer: sadly i have no access to our wiki | 09:26 |
| niemeyer | TheMue: That happens.. you should get it soon | 09:26 |
| TheMue | niemeyer: so i read the public stuff | 09:26 |
| niemeyer | TheMue: Are your details being sorted out already? | 09:27 |
| niemeyer | TheMue: All of the data for the project is public | 09:27 |
| TheMue | niemeyer: I've got my launchpad account working and the login to the wiki is granted | 09:29 |
| niemeyer | TheMue: That's cool | 09:29 |
| TheMue | niemeyer: but then I've got no right to read something | 09:29 |
| niemeyer | TheMue: Hm? | 09:30 |
| TheMue | niemeyer: here i am => https://launchpad.net/~themue | 09:30 |
| niemeyer | TheMue: Ok? | 09:31 |
| mpl | hmm, forgot to group the consts in the same declaration :/ | 09:50 |
| mpl | someday gofmt will be smart enough to do even that for me hehe :) | 09:50 |
| TheMue | gofmt in chuck norris mode would analyze the semantics of your project, optimize the code and add speaking comments for godoc. :D | 09:52 |
| mpl | uh weird, I've just received a mail saying that: "Launchpad encountered an internal error during the following operation: generating the diff for a merge proposal. It was logged with id OOPS-3635c3dab3398e5564a4a31dc006dd36. Sorry for the inconvenience." | 10:01 |
| mpl | niemeyer: hmm, got an error when trying to repropose | 10:23 |
| mpl | 2011/12/01 11:22:20 RIETVELD Failed to prepare request: computing base hashes: command [bzr cat -r revid:roger.peppe@canonical.com-20111116163854-05vsxizrv13b83r8 juju/Makefile] failed: exit status 3 | 10:23 |
| mpl | 2011/12/01 11:22:20 RIETVELD Response from server: Issue creation errors: {'base': [u'Base URL is required.'], 'subject': [u'This field is required.']} | 10:23 |
| niemeyer | mpl: Try to execute the bzr cat command locally and see what's the output | 10:25 |
| niemeyer | TheMue: Do you have the list of tasks to go over yet? | 10:25 |
| TheMue | niemeyer: Sarah passed me a starting point for day 1. | 10:27 |
| niemeyer | TheMue: COol | 10:27 |
| mpl | niemeyer: ok, found the problem. apparently I'm supposed to issue the command from the root of the repo. I was inside "juju", so the bzr cat command couldn't find juju/Makefile. | 10:27 |
| mpl | thx | 10:27 |
| niemeyer | mpl: Oh, interesting | 10:27 |
| niemeyer | mpl: I should fix that in lbox | 10:27 |
| mpl | that would be nice, yes. | 10:28 |
| TheMue | niemeyer: in parallel i'm reading the docs and look around the issues in florence (nice tool) | 10:28 |
| mpl | niemeyer: want me to file a bug report or something about that? | 10:28 |
| niemeyer | mpl: Yes, please! | 10:28 |
| mpl | niemeyer: k, will do. | 10:29 |
| niemeyer | mpl: Thanks! | 10:30 |
| mpl | sure. | 10:30 |
| _mup_ | juju/go r20 committed by gustavo@niemeyer.net | 10:36 |
| _mup_ | Merged juju-go-log branch from Mathieu Lonjaret. [r=niemeyer] | 10:36 |
| _mup_ | This branch adds support for logging into the juju package. | 10:36 |
| _mup_ | Logic in this package and in its subpackages should now call | 10:36 |
| _mup_ | juju.Logf or juju.Debugf to generate useful information about | 10:36 |
| _mup_ | what's happening. | 10:36 |
| niemeyer | mpl: Would you mind to explore the idea of making Debug and Logger as global variables in another branch, as rog suggested? | 10:56 |
| mpl | niemeyer: sure | 10:59 |
| niemeyer | mpl: Cheers! | 11:23 |
| TheMue | niemeyer: just for info, my launchpad profile is added to the canonical group and my access to the wiki does work now | 11:27 |
| niemeyer | TheMue: Superb | 11:37 |
| niemeyer | TheMue: But again, it doesn't matter much as far as juju goes | 11:37 |
| niemeyer | TheMue: It's all in the open | 11:37 |
| niemeyer | TheMue: You'll find some good details about how the company works, etc, there, though | 11:37 |
| TheMue | niemeyer: Yep, that's what I want to know today. First the organization to see what's important here for me, and then juju. You'll then get a lot of questions. *smile* | 11:38 |
| TheMue | niemeyer: I hope the source code is well commented to get the semantics. | 11:39 |
| TheMue | niemeyer: Setting up internal irc and mail now, those tasks. | 11:46 |
| rog | TheMue: hi and welcome! | 11:50 |
| TheMue | rog: hi and thx, now i'm on board too | 11:51 |
| rog | TheMue: cool | 11:51 |
| TheMue | another colleague interested in go here in germany also starts today. but he's working in a different team | 11:54 |
| mainerror | TheMue: Got hired by Canonical? | 11:54 |
| TheMue | mainerror: yep | 11:54 |
| mainerror | Nice! | 11:54 |
| mainerror | Congratulations. | 11:54 |
| niemeyer | TheMue: That sounds great | 11:56 |
| niemeyer | TheMue: Just let me know when you're ready to rock | 11:56 |
| TheMue | mainerror: thx | 11:59 |
| mainerror | You mentioned go. Go as in Go the programming language? | 11:59 |
| TheMue | niemeyer: you'll realize it with my questions. *smile* | 12:00 |
| TheMue | mainerror: exactly | 12:00 |
| mainerror | Cool. | 12:00 |
| TheMue | btw, anybody visiting the oop 2012 in january in munich? i've got two talks there. one about go and the app engine, one (a pecha kucha) about concurrency as a 'natural' paradigm | 12:01 |
| rog | niemeyer: when we're talking about stripping down go-juju-initial-ec2, how bare should it go. shall i keep it so it can still talk to ec2 (without the extraneous logic) or should i should i strip it to really bare bones, so there's almost nothing there apart from the structure? | 12:02 |
| rog | s/should it go./should it go?/ | 12:02 |
| niemeyer | rog: The latter | 12:02 |
| mainerror | TheMue: When in January? It wouldn't be that far for me but the date might collide with my visit to Budapest. | 12:03 |
| niemeyer | rog: Then, try to go the TDD route, introducing new logic with tests | 12:03 |
| TheMue | mainerror: end of jan, i'm in budapest too. | 12:03 |
| rog | niemeyer: so copy dummyProvider from juju for an initial step? | 12:03 |
| mainerror | Oh I see. | 12:03 |
| niemeyer | rog: By migrating from the previous branch chunk by chunk, and submitting for review once you're happy with a first delta | 12:03 |
| niemeyer | rog: That sounds reasonable | 12:04 |
| mainerror | Well then chances are good that we meet each other twice. :) | 12:04 |
| mainerror | +# | 12:04 |
| mainerror | s/+#// | 12:04 |
| mpl | niemeyer: should I make it a different package as well, as rog is suggesting? (I'm not sure your "and I'm happy with that." means you want me to go for it). | 12:14 |
| niemeyer | mpl: Yes, thanks a lot for pursuing that | 12:36 |
| TheMue | so, changed the configuration | 12:45 |
| mpl | niemeyer: hmm, I'm still struggling with bzr. I thought that since you merged, I should see rev 20 on https://launchpad.net/juju/go, or when doing a bzr pull from the lp:juju/go branch I have. what am I missing? | 12:47 |
| rog | mpl: from looking at this page, it looks like it hasn't been merged yet: https://code.launchpad.net/~mathieu-lonjaret/juju/juju-go-log/+merge/84074 | 12:58 |
| mpl | rog: hmm, and yet the _mup_ bot pasted a few lines above stating it had been merged. | 13:08 |
| rog | mpl: good point. i don't know what's going on there. maybe there's a delay | 13:08 |
| mpl | or I could simply keep on working from this not yet merged branch I suppose... | 13:09 |
| rog | mpl: i'd do that | 13:25 |
| rog | niemeyer: is this more the kind of thing you had in mind? https://codereview.appspot.com/5432056/ | 13:25 |
| niemeyer | rog: This patch set seems to include changes from the other branch you pushed | 13:26 |
| rog | niemeyer: if you look at the files, there's nothing in them. i think that lbox hasn't deleted them from the codereview page | 13:27 |
| niemeyer | rog: https://codereview.appspot.com/5432056/diff/1019/juju/dummyprovider_test.go | 13:28 |
| rog | niemeyer: and funnily enough, there are files that *should* be there (the jujutest package) | 13:28 |
| niemeyer | rog: Check your patch locally.. lbox simply sends what it finds | 13:28 |
| rog | hmm, i thought i branched from the most recent trunk | 13:29 |
| rog | so many branches! | 13:29 |
| rog | niemeyer: bzr ls shows the jujutest directory. | 13:30 |
| niemeyer | rog: The diff | 13:30 |
| rog | niemeyer: i think i'll just create a new merge request | 13:30 |
| niemeyer | rog: it'll do you no good | 13:30 |
| niemeyer | rog: It will send the same diff | 13:30 |
| rog | http://paste.ubuntu.com/755994/ | 13:31 |
| rog | jujutest is in there, but not on the codereview page | 13:32 |
| niemeyer | rog: How did you generate that diff? | 13:32 |
| rog | niemeyer: cd go-juju-initial-ec2; bzr diff -r ../go-trunk | 13:32 |
| rog | is that wrong? | 13:32 |
| niemeyer | rog: bzr diff -r ancestor:../go-trunk | 13:32 |
| rog | niemeyer: hmm. what's the difference? | 13:34 |
| niemeyer | rog: This will diff your branch against the merge base | 13:34 |
| niemeyer | rog: Which means it's generally the true changeset that will be applied when you actually bzr merge | 13:35 |
| rog | niemeyer: i don't understand. what's the difference between trunk tip and the merge base? | 13:35 |
| niemeyer | rog: and it's what lbox uses to send to codereview | 13:35 |
| niemeyer | rog: Maybe none, maybe there is | 13:35 |
| niemeyer | rog: It's none if nothing was committed in tip | 13:35 |
| rog | niemeyer: so in this case, i've added a new directory and files in it, but it's not showing up. what am i doing wrong? | 13:35 |
| niemeyer | rog: Either way, is the diff the same or not? | 13:35 |
| rog | no it's not. it's very different | 13:36 |
| niemeyer | rog: Cool, ok.. let me explain then | 13:36 |
| rog | http://paste.ubuntu.com/755999/ | 13:36 |
| niemeyer | rog: Let's call tip T, and you had a branch B1 | 13:36 |
| rog | (and i've just freshly branched go-trunk too) | 13:37 |
| niemeyer | rog: We debated about B1, and in the end some changes were forked off onto B2 | 13:37 |
| niemeyer | rog: But to generate B2, you actually *took* B1, and *removed* stuff from it | 13:37 |
| niemeyer | rog: Then, B2 got merged on T | 13:38 |
| rog | yup, that's exactly what i've done | 13:38 |
| rog | (i didn't remove anything from B1 that was in T though) | 13:38 |
| niemeyer | rog: Now, you're checking what would happen if you merged B1 into T | 13:38 |
| rog | B2, no? | 13:38 |
| niemeyer | B1.. B2 was already merged, no? | 13:38 |
| rog | i don't... think... so | 13:39 |
| niemeyer | merge go-juju-machine-to-instance | 13:40 |
| niemeyer | revno: 19 [merge] | 13:40 |
| niemeyer | Where was this taken from? | 13:40 |
| * niemeyer looks at the branch history | 13:40 | |
| rog | ok, i think i did a merge then removed stuff | 13:40 |
| rog | not realising that it might make a difference | 13:41 |
| niemeyer | rog: Yes, that was the case indeed: http://paste.ubuntu.com/756003/ | 13:42 |
| rog | i'm still confused. why are the changes that i've made since being ignored? | 13:42 |
| niemeyer | rog: So now you're trying to merge the original changes, but you already have _new_ history demonstrating that your latest interest is to remove that stuff | 13:42 |
| niemeyer | rog: So bzr looks at history and says "Oh, hey, I already merged those revisions.. all good!" | 13:43 |
| rog | because the trunk counts as newer than my current branch? | 13:43 |
| niemeyer | rog: They haven't been ignored.. on the contrary... they've already been merged | 13:43 |
| rog | but i've put them back again! | 13:43 |
| niemeyer | rog: That's the point, you haven't | 13:43 |
| niemeyer | rog: The revision you have locally is exactly the same revision that bzr has in trunk | 13:43 |
| rog | how can i put them back again then? | 13:44 |
| rog | perhaps if i just do branch from trunk, cp -r and bzr add, that'll work? | 13:45 |
| niemeyer | rog: You'll have to redo it, effectively creating a new revision | 13:45 |
| niemeyer | rog: That'd be a *MAJOR* disaster :-) | 13:45 |
| niemeyer | rog: Never, ever, do that | 13:45 |
| rog | oh? | 13:45 |
| niemeyer | rog: You're effectively killing everybody else's changes | 13:45 |
| niemeyer | rog: We can't ever assume we know the latest state of trunk | 13:46 |
| niemeyer | rog: The proper way now is this: | 13:46 |
| niemeyer | rog: branch from trunk again onto a new branch | 13:46 |
| niemeyer | rog: Apply the diff you really want to see happening onto this new branch | 13:47 |
| niemeyer | rog: (with patch, etc) | 13:47 |
| niemeyer | rog: and propose that one | 13:47 |
| rog | ok, patch rather than cp -r, of course | 13:47 |
| niemeyer | rog: This is a new changeset, so you're effectively reverting the revert :D | 13:48 |
| rog | same basic idea though - make local file changes rather than merging | 13:48 |
| niemeyer | rog: Yeah, basically teach bzr that you've changed your mind once more | 13:49 |
| rog | niemeyer: yeah, i didn't know that there were any bad implications from doing that | 13:49 |
| rog | niemeyer: i will never back-merge again | 13:49 |
| niemeyer | rog: Not a problem.. common gotcha of revision control | 13:49 |
| rog | patch is my friend | 13:49 |
| rog | if i can remember how to use it | 13:49 |
| rog | -p0 ? | 13:49 |
| niemeyer | rog: You just have to remember that history matters | 13:49 |
| niemeyer | rog: Did A commit rev1, undo A commit rev2, merge both.. Trying to merge rev1 again does nothing. | 13:50 |
| rog | niemeyer: that surprises me | 13:50 |
| rog | (well, not any more) | 13:50 |
| niemeyer | rog: That's DVCS 101.. hg, git, bzr, bitkeeper.. | 13:51 |
| niemeyer | rog: and yes, it surprised people often | 13:51 |
| niemeyer | surprises | 13:51 |
| rog | i'd assumed that in the absence of other merges, A+B-B+B == A+B | 13:51 |
| fwereade_ | niemeyer, hazmat: what situation would cause a unit settings node to be deleted and recreated? | 13:51 |
| niemeyer | rog: And that's what happens.. but that's not what was done.. | 13:52 |
| rog | but in fact A+B-B+B == A | 13:52 |
| niemeyer | rog: What you did was A + B + A, which is A + B | 13:52 |
| rog | where A+B means merge(A, B) | 13:52 |
| niemeyer | rog: You never did -B, btw.. there's no such a thing as removing a revision | 13:53 |
| niemeyer | rog: You added C with a reverting patch | 13:54 |
| fwereade_ | niemeyer, hazmat: because I can't see such a case, but there's a test which induces it, and if it's a realistic possibility (without the unit node itself being deleted) then I need to rethink things | 13:54 |
| rog | well, ok. trunk + {add foo} + {remove foo} + {add foo} == trunk | 13:55 |
| niemeyer | fwereade_: Can you please paste the test? | 13:55 |
| rog | where { } is a delta | 13:55 |
| fwereade_ | niemeyer, just grabbing an unmodified version | 13:55 |
| niemeyer | rog: Again, that's not what you did.. | 13:55 |
| niemeyer | rog: You never re-added foo | 13:55 |
| niemeyer | rog: You expected that your foo from the first action would be there, despite it being removed in a latter revision | 13:56 |
| niemeyer | rog: What you're doing _now_ is re-adding foo | 13:56 |
| rog | niemeyer: how is "bzr add foo" not adding foo? | 13:56 |
| fwereade_ | niemeyer, as it says in the test, some "unforseen mechanism" | 13:57 |
| fwereade_ | http://paste.ubuntu.com/756017/ | 13:57 |
| niemeyer | rog: You never re-added it.. | 13:57 |
| niemeyer | rog: Well, let me pick the history to make sure | 13:57 |
| rog | niemeyer: so "bzr add" doesn't count as an add? | 13:58 |
| rog | niemeyer: that's what confused me, i think | 13:58 |
| niemeyer | rog: You're being disingenuous now | 13:58 |
| rog | niemeyer: no, that's the central difficulty i have. | 13:58 |
| fwereade_ | niemeyer: it's not something I'd really worry about normally, but the existence of this test has made me all nervous ;) | 13:58 |
| rog | niemeyer: that "bzr add" doesn't necessarily add the file when the revision comes to be merged. | 13:59 |
| niemeyer | rog: If you add the same file 10 times in the same revision it's of course a NOOP | 13:59 |
| rog | niemeyer: but in this revision, i added it only once. | 14:00 |
| niemeyer | rog: The detail is that you never acknowledged the fact that the file had been _removed_ and then _readded_ it | 14:00 |
| niemeyer | rog: Exactly.. and it's still there, right? | 14:00 |
| niemeyer | rog: Now you're doing "bzr add" on it again.. and bzr is saying.. yep.. still there! | 14:00 |
| niemeyer | rog: Because you never merged the part of history that says "this file is being removed" | 14:00 |
| niemeyer | rog: History matters | 14:00 |
| niemeyer | rog: If you merge trunk onto your ec2 initial branch.. the file will be *gone* | 14:01 |
| niemeyer | rog: _then_ you can readd | 14:01 |
| niemeyer | rog: Have you ever read about vector clocks? | 14:02 |
| rog | niemeyer: didn't go-juju-machine-to-instance (merged) have the removal history in? | 14:02 |
| niemeyer | rog: It does | 14:03 |
| rog | niemeyer: yes, but i never fully got my head around them. or VCS. | 14:03 |
| niemeyer | rog: Ok | 14:03 |
| niemeyer | rog: Not a good analogy then | 14:03 |
| niemeyer | fwereade_: It makes sense to me | 14:04 |
| niemeyer | fwereade_: The point is precisely that a settings node being removed shouldn't cause a related unit to think that the configuration for the other side of the relation has changed | 14:04 |
| fwereade_ | niemeyer, the test makes sense in its own narrow context | 14:05 |
| niemeyer | fwereade_: It's likely dying instead | 14:05 |
| fwereade_ | niemeyer, however, if the mechanism it uses to verify that property is a realistic one, it means that settings node versions are not a reliable indicator of anything | 14:06 |
| hazmat | fwereade_, nothing comes to mind | 14:06 |
| rog | niemeyer: actually, the vector clock thing does make sense. i think you're saying that the changes to re-add the file come further back in vector "time" than my changes to remove the file. | 14:06 |
| hazmat | fwereade_, the only thing that should be deleting a settings node is the teardown of a test | 14:06 |
| rog | anyway, i'll just patch | 14:07 |
| niemeyer | rog: Precisely! | 14:07 |
| hazmat | fwereade_, btw. one other point on the restart, if its a container restart, we do want to fire the start hook.. | 14:07 |
| niemeyer | hazmat, fwereade_: The removal/cleanup of a unit can delete a settings node.. | 14:07 |
| niemeyer | hazmat, fwereade_: The logic to ignore the removal of the node continues to make sense to me. | 14:07 |
| fwereade_ | niemeyer: all I'm worrying about is settings node deletion *without* the unit being deleted | 14:08 |
| fwereade_ | niemeyer: there's no problem with that test | 14:08 |
| fwereade_ | niemeyer: I'm just checking that it's purely an artificial and unrealistic manipulation of ZK without known analogue in normal operation | 14:09 |
| niemeyer | fwereade_: I don't think we ever desired to support something like that consciously, at least, and I'm fine to say we don't | 14:09 |
| hazmat | fwereade_, when you say settings you don't mean relation settings, which path are you referencing? | 14:09 |
| fwereade_ | niemeyer: cool, thanks | 14:09 |
| niemeyer | fwereade_: Again, there is a relevant analogous | 14:09 |
| niemeyer | fwereade_: To precisely that test | 14:10 |
| niemeyer | fwereade_: It's not unrealistic at all | 14:10 |
| fwereade_ | niemeyer: ok, sorry, I missed an important bit | 14:11 |
| fwereade_ | niemeyer: deletion, fine | 14:11 |
| fwereade_ | niemeyer: *recreation*, not fine | 14:11 |
| niemeyer | fwereade_: Fine as well! | 14:11 |
| rog | niemeyer: right, got it. i think. | 14:11 |
| fwereade_ | niemeyer: hmm :( | 14:11 |
| niemeyer | fwereade_: The relation with the unit on the other side may be reestablished | 14:12 |
| hazmat | niemeyer, how? | 14:12 |
| niemeyer | fwereade_: In which case the settings node should be observed again | 14:12 |
| hazmat | either the unit was removed or the relation broken | 14:12 |
| hazmat | in either case the identity is different when restablished | 14:12 |
| niemeyer | hazmat: Why? | 14:12 |
| niemeyer | hazmat: Well, the identity of what is a better first question | 14:13 |
| hazmat | of either the unit or the relation would have changed | 14:13 |
| hazmat | which leads to a different settings path | 14:13 |
| niemeyer | hazmat: Huh? | 14:13 |
| niemeyer | hazmat: remove-relation a b; add-relation a b | 14:13 |
| niemeyer | ? | 14:13 |
| hazmat | niemeyer, its a different relation identity the second time | 14:13 |
| niemeyer | hazmat: I see, ok | 14:14 |
| hazmat | we do preserve unit settings in a relation post its removal, relying on ephemeral presence nodes for observation of membership | 14:15 |
| hazmat | the test is going against a pathologic case | 14:15 |
| niemeyer | hazmat: It's not pathologic.. the fact we keep data around forever shouldn't be trusted | 14:15 |
| hazmat | niemeyer, agreed | 14:16 |
| niemeyer | fwereade_: So, the behavior there looks good in terms of being resilient.. is there a reason why you'd like to not support that specifically? | 14:16 |
| hazmat | a garbage collector processing live relations, should not trigger an observation change | 14:16 |
| hazmat | when taking out the garbage | 14:16 |
| hazmat | fwereade_, so recreation of the path is not a scenario | 14:17 |
| fwereade_ | niemeyer, https://bugs.launchpad.net/juju/+bug/773600 points out that we'll need to pay attention to the settings node's versions to determine whether changes happened when the agent prcess was down | 14:17 |
| _mup_ | Bug #773600: Hook scheduler should have on disk persistence <juju:In Progress by fwereade> < https://launchpad.net/bugs/773600 > | 14:17 |
| hazmat | of the settings that is | 14:17 |
| fwereade_ | niemeyer: *if* recreation of the settings node is plausible (which I think, as hazmat says, it isn't), node versioning is not up to the job | 14:18 |
| fwereade_ | niemeyer: because the version gets reset to 0 on recreate | 14:18 |
| niemeyer | fwereade_: Aha, that makes the matter a lot more clear.. | 14:18 |
| * niemeyer thinks | 14:18 | |
| hazmat | fwereade_, right, because we need to reconcile any change while disoconnected with the live state | 14:18 |
| fwereade_ | hazmat: yep | 14:19 |
| hazmat | fwereade_, so just to be clear, there is no normal scenario that allow for a recreate of the unit rel settings node | 14:19 |
| niemeyer | fwereade_: It feels fine for us to state that we never remove a unit's settings node in a given relation for as long as the unit itself is alive, at least | 14:20 |
| hazmat | since we manage relations on a service level, the removal implies either the unit was removed, or the relation was removed | 14:20 |
| hazmat | and attempts to resurrect would imply either a new unit identity or new relation identity at a different path | 14:20 |
| fwereade_ | niemeyer, hazmat: cool, that all makes sense to me :) | 14:20 |
| fwereade_ | thanks :) | 14:20 |
| niemeyer | fwereade_: Sorry for the confusion.. I guided the conversation to the wrong path not understanding your context | 14:20 |
| fwereade_ | niemeyer: sorry, I could have been a lot clearer :( | 14:21 |
| fwereade_ | niemeyer, not to worry :) | 14:21 |
| hazmat | so the test is a pathlogical case if its recreating the node | 14:23 |
| niemeyer | hazmat: Ok, agreed | 14:24 |
| rog | niemeyer: finally! https://codereview.appspot.com/5432056 | 14:29 |
| rog | niemeyer: sorry for my obtuseness | 14:29 |
| niemeyer | rog: Woohay! | 14:31 |
| niemeyer | rog: Not worries at all | 14:32 |
| niemeyer | rog: I'm happy we've had that conversation.. you'll surely pass through similar circumstances | 14:32 |
| zirpu | how does one specify the machine size in a charm? i can't find that in the docs. | 14:40 |
| zirpu | i.e. for ec2 the default seems to be t1.small. for a redis server i'd like to bump it up. | 14:42 |
| hazmat | SpamapS, made some progress tracking down the precise builds | 14:47 |
| hazmat | SpamapS, i realize we can drop python-argparse as a dep for any release with py2.7 and it will remove this error | 14:47 |
| mpl | niemeyer: when trying to pull lp:~mathieu-lonjaret/juju/juju-go-log, I'm getting that error: "bzr: ERROR: These branches have diverged. Use the missing command to see how." and bzr missing doesn't give me much of a clue, sorry. | 14:49 |
| hazmat | its a pkg_resources import causing a warning on stderr, which juju thinks is a process error | 14:49 |
| hazmat | its early enough (import time) that the log machinery hasn't been setup yet to go to disk | 14:49 |
| hazmat | mpl, bzr merge the upstream should resolve it | 14:50 |
| hazmat | mpl, it implies that both branches have commits that aren't on the other side afaicr | 14:50 |
| niemeyer | mpl: Why are you trying to pull it? | 14:51 |
| niemeyer | mpl: You need a new branch now | 14:51 |
| mpl | niemeyer: because I don't have it anymore, I had removed it when I thought you had merged it. | 14:51 |
| niemeyer | mpl: I did! | 14:52 |
| niemeyer | mpl: Just update your trunk, and create a new branch from it | 14:52 |
| niemeyer | mpl: "bzr pull" on trunk | 14:52 |
| mpl | niemeyer: well, as I said above, it doesn't show on https://code.launchpad.net/~mathieu-lonjaret/juju/juju-go-log/+merge/84074 | 14:52 |
| niemeyer | mpl: Then follow the blog post on lbox again | 14:52 |
| niemeyer | mpl: Naming it differently | 14:52 |
| mpl | niemeyer: and bzr pull doesn't give me the rev 20 | 14:52 |
| niemeyer | mpl: Maybe I screwed up then | 14:53 |
| niemeyer | mpl: Hold on | 14:53 |
| mpl | niemeyer: the bot said you had merged. but nothing else seem to agree with that. :) | 14:53 |
| mpl | from my pov of course | 14:53 |
| niemeyer | mpl: The bot is optimistic indeed | 14:53 |
| mpl | haha | 14:53 |
| niemeyer | mpl: Yeah, it was my fault | 14:53 |
| niemeyer | mpl: Just pushed the change | 14:53 |
| niemeyer | mpl: Sorry about that | 14:54 |
| mpl | cool, thx. new branch it then. | 14:54 |
| mpl | no worries. | 14:54 |
| mpl | *it is then | 14:54 |
| niemeyer | rog: Reviewed ec2test | 14:54 |
| niemeyer | rog: Good work there man | 14:54 |
| rog | niemeyer: phew. i thought i might need a boatload of tests for the testing code. (i thought that was going a little too far, and there are *some* tests!) | 14:55 |
| rog | niemeyer: thanks BTW | 14:56 |
| niemeyer | rog: Yeah, testing the testing code would be a little too much.. :-D | 14:56 |
| mpl | I heard you like test code so I ... | 14:57 |
| niemeyer | rog: Firing goamz itself against it should be good enough | 14:57 |
| niemeyer | rog: But who tests the tests tests! OMG! | 14:57 |
| rog | indeed | 14:57 |
| rog | niemeyer: i will end up running more ec2 tests against it as functionality gets more complete | 14:58 |
| rog | niemeyer: oh such a pleasure to use codereview again! | 14:58 |
| niemeyer | rog: +1! | 14:59 |
| rog | niemeyer: BTW can you think of any way of avoiding the duplicate emails? | 14:59 |
| niemeyer | rog: That's been bothering me a bit too.. I don't have a good answer yet | 14:59 |
| rog | niemeyer: filters aren't that clever either:-) | 15:00 |
| niemeyer | rog: It would actually be possible to filter out, but I'm concerned we might lose real changes that happen on the MP side | 15:00 |
| rog | MP? | 15:00 |
| niemeyer | rog: merge proposal | 15:01 |
| rog | hmm, maybe the trick is to avoid the codereview emails | 15:02 |
| rog | ah, dammit | 15:02 |
| rog | no | 15:02 |
| niemeyer | Ok, past lunch time here.. bbl | 15:03 |
| SpamapS | hazmat: I wonder if thats a bug in the python-argparse package | 15:10 |
| hazmat | SpamapS, well its actually a pkg_resources thing.. py2.7 has argparse builtin, and we also have it as a package dep | 15:14 |
| hazmat | and pkg_resources basically flags a warning that we're shadowing a builtin package | 15:15 |
| hazmat | and because that happens so early on, it goes to stderr instead of the log file | 15:15 |
| SpamapS | hazmat: thats what I mean.. should the package even exist if it causes problems for pkg_resources ? | 15:15 |
| jcastro | SpamapS: fixes in statusnet. | 15:15 |
| jcastro | SpamapS: we're promulgating that today, I can FEEL it! | 15:15 |
| hazmat | SpamapS, its not a fatal error, juju interprets it as such even though the process exits normally | 15:16 |
| hazmat | we could be more discriminating about that, but right now it it interprets regardless of the exit code any stderr output of the launched unit agent as a failure since it should go to a log file per normal operations | 15:17 |
| SpamapS | jcastro: yeah, it was close yesterday. :) | 15:17 |
| jcastro | \o/ | 15:17 |
| zirpu | is there a way to specify the machine size for EC2 instances? | 15:18 |
| marcoceppi | zirpu: You can do it in the environments.yaml file | 15:19 |
| jcastro | http://askubuntu.com/questions/52021/how-do-i-adjust-the-instance-size-that-juju-uses | 15:19 |
| zirpu | cool. thanks! | 15:19 |
| SpamapS | jcastro: indeed, looks good, I'll promulgate, you fire up the T-shirt cannon for the party | 15:20 |
| jcastro | SpamapS: aka. "haha you have to test and blog this" | 15:20 |
| marcoceppi | Keep that t-shirt cannon warm, I think phpMyAdmin is almost ready :P | 15:20 |
| jcastro | SpamapS: when you're looking for a nice friday later afternoon hack make it so promulgate makes the bot go "Ding! New charm!" or something | 15:20 |
| zirpu | marcoceppi: you can't specify machine size in a charm? only the global environments.yaml? | 15:21 |
| marcoceppi | jcastro: Dude, the bot's written in erlang, my mind was nearly blown when trying to add questions to the feed | 15:21 |
| marcoceppi | zirpu: Not that I'm aware of, there's a spec to have deploy specify machine size, but it's not implemented | 15:22 |
| zirpu | ah. ok. thanks. | 15:22 |
| fwereade_ | robbiew, ping | 15:23 |
| robbiew | fwereade_: hey...there you are | 15:23 |
| robbiew | wasn't looking for the "_" :/ | 15:23 |
| SpamapS | zirpu: indeed, its #2 on the priority list | 15:23 |
| fwereade_ | robbiew, sorry, was afk, my brain melted down and I needed a coffee | 15:23 |
| robbiew | fwereade_: lol, no worries...got time for a catchup g+? | 15:23 |
| fwereade_ | robbiew, sure | 15:24 |
| robbiew | one sec...will shoot out invite | 15:24 |
| rog | niemeyer: hmm, the target has changed because of ec2 rename. should i continue with the old target (~gniemeyer) or make a new CL? | 15:34 |
| SpamapS | jcastro: done | 15:36 |
| * SpamapS wishes we had an audit log of promulgates | 15:36 | |
| jcastro | nice! Ok congrats everyone, there's one more charm! | 15:36 |
| SpamapS | pretty cool charm actually | 15:36 |
| hazmat | oi.. teamspeak3 charm is new as well | 15:38 |
| jcastro | SpamapS: ... and working awesome for me | 15:42 |
| jcastro | man, the speed from 0 to "out there" never gets old | 15:42 |
| mpl | rog: hmm, are you automatically notified of everything I lbox propose, or should I somehow add you as a reviewer in codereview when you're concerned? | 15:45 |
| mpl | s/hmm, // :) | 15:46 |
| hazmat | mpl, people generally get emails about it if they subscribe to the repo the merge is being proposed to | 15:49 |
| mpl | hazmat: thx. I suppose that means yes in the case of rog :) | 15:52 |
| hazmat | mpl, well assumptions are dangerous.. but i've been seeing your merge proposals ;-).. good stuff | 15:53 |
| SpamapS | hazmat: btw, thanks for looking into the argparse thing. So did you push a fix up, or you just think you might have one? | 15:55 |
| mpl | hazmat: well, it's all pretty simple and preworked for me by gustavo, so I can't take much credit there. but thx. :) | 15:55 |
| fwereade_ | niemeyer, hazmat: concurrent callbacks in RelationUnitWatcherBase: I don't quite understand how they can be safe, even if they are on changes to different nodes | 16:07 |
| fwereade_ | niemeyer, hazmat: HookScheduler.notify_change doesn't look to me like it will handle them correctly | 16:07 |
| fwereade_ | niemeyer, hazmat: I presume I'm missing something..? | 16:08 |
| hazmat | fwereade_, why not re the latter, that's how the changes are serialized into an event stream, the hook executor itself is the one that does the serialization off the ordered stream from the scheuduler | 16:08 |
| hazmat | fwereade_, i guess i'm not understanding the question.. how are they not safe? | 16:09 |
| fwereade_ | hazmat: ...ah, ok, notify_change doesn't yield | 16:09 |
| hazmat | fwereade_, yup.. its definitely synchronous | 16:09 |
| hazmat | that's a key point | 16:09 |
| fwereade_ | hazmat: hm, that probably covers that question | 16:09 |
| hazmat | SpamapS, i pushed a fix for some of the other test failures, i'm still looking at the most recent ones, but the argparse stuff needs a packaging change to fix | 16:11 |
| hazmat | SpamapS, given the latter, we should get some package builds | 16:12 |
| SpamapS | hazmat: that makes me think that the python-argparse package shouldn't even exist anymore. | 16:12 |
| hazmat | SpamapS, not in precise | 16:12 |
| SpamapS | hazmat: let me try a build w/o the dep | 16:12 |
| hazmat | SpamapS, well to be more precise ;-) .. it should exist if py2.6 exists | 16:13 |
| SpamapS | hazmat: a package can be made to not build for a particular version.. thats probably what needs to be done | 16:15 |
| hazmat | SpamapS, as regards juju, afaics its a question of specifying a different dep set based on distro series. | 16:16 |
| hazmat | or py version | 16:16 |
| mpl | rog: yeah I wasn't very happy with the name either, but couldn't find a better one. I like Destination. | 16:22 |
| SpamapS | hazmat: python-argparse can be installed with no symlinks to the .py files in the python2.7 dirs.. that will allow for the deps to remain the same for backports to older versions | 16:25 |
| SpamapS | hazmat: we've had python 2.7 for a long time tho... why would this show up now? | 16:25 |
| * SpamapS tries sbuilding juju w/o python-argparse in the deps | 16:28 | |
| * niemeyer respawns | 16:38 | |
| SpamapS | hazmat: sbuild test passed.. will try it in my PPA as well | 16:50 |
| m_3 | jcastro: you have an agenda or something for charm-school tomorrow? | 16:52 |
| jcastro | m_3: sort of | 16:52 |
| jcastro | we can sort it now if you'd like | 16:53 |
| jcastro | https://juju.ubuntu.com/CharmSchool/2December11 | 16:53 |
| m_3 | gimme 10 | 16:53 |
| jcastro | m_3: bah something came up, how about an hour from now? | 16:54 |
| jcastro | m_3: and I'm off tomorrow and most of next week so we can just bust out this week's charms easily. | 16:55 |
| m_3 | jcastro: good | 16:55 |
| jimbaker | hazmat, standup? | 17:02 |
| hazmat | jimbaker, full meeting today | 17:05 |
| SpamapS | m_3: I'd be up to work on an agenda for tomorrow | 17:05 |
| jimbaker | hazmat, sure. so are we doing it now? | 17:05 |
| hazmat | jimbaker, yup. i'm sending invites out | 17:06 |
| jimbaker | hazmat, cool | 17:06 |
| m_3 | SpamapS: promulgating atm... almost done | 17:06 |
| hazmat | SpamapS, jimbaker, bcsaller, fwereade_, niemeyer invites out | 17:09 |
| hazmat | TheMue, we do team meetings thursday on google plus | 17:10 |
| niemeyer | rog: ping? | 17:12 |
| rog | niemeyer: pong | 17:12 |
| rog | niemeyer: meeting? | 17:12 |
| niemeyer | TheMue: ping? | 17:13 |
| m_3 | marcoceppi: so what's the status of phpmyadmin? is the last revision you pushed ready to review again? | 17:32 |
| marcoceppi | m_3: Not yet, I'm having problems with sh/bash tests | 17:33 |
| marcoceppi | As soon as I iron that out and give it a full test it'll be ready | 17:33 |
| m_3 | ok, I'm gonna pull off the tag then... please re-add when it's ready for review | 17:33 |
| m_3 | thanks! | 17:33 |
| marcoceppi | np, can do! | 17:33 |
| marcoceppi | just found out dash and bash handle boolean operators differently in test :\ | 17:36 |
| m_3 | marcoceppi: yes, I've had problems with those differences myself | 17:39 |
| SpamapS | marcoceppi: certain operators, yes. ;) | 17:39 |
| * marcoceppi blames m_3 for suggesting dash over bash :P | 17:40 | |
| m_3 | marcoceppi: no way did _I_ suggest that... that was Clint | 17:40 |
| marcoceppi | curses! | 17:41 |
| m_3 | marcoceppi: I've been bitten by string expansion rules... ${MY_VARIABLE//\/*/} or ${MY_VARIABLE%%.ext} | 17:41 |
| m_3 | (use bash) | 17:41 |
| * m_3 runs | 17:41 | |
| marcoceppi | Anyways, I think I've got all the replacements for == just waiting for ec2 | 17:41 |
| m_3 | marcoceppi: cool | 17:41 |
| m_3 | TheMue: welcome! | 17:43 |
| SpamapS | marcoceppi: if you want to use bash, use bash. :) I find shell's limitations to force more elegant code in many instances, but sometimes it is a dirty language. | 17:55 |
| SpamapS | marcoceppi: perhaps we should have tests for charm-helpers | 17:55 |
| m_3 | SpamapS: +1 | 17:56 |
| m_3 | I was planning tests for charm-helpers-rb | 17:56 |
| marcoceppi | SpamapS: Good idea, how would that work exactly? just test each function and collect output -> compare to expected results? | 17:57 |
| SpamapS | yeah | 17:59 |
| m_3 | jcastro: so thinkup's lp:charm brnach is behind the george's branch... we need to maybe talk about MPs | 17:59 |
| SpamapS | m_3: I'm a little nervous about charm-helpers-rb ... can't you just use chef solo ? | 17:59 |
| m_3 | SpamapS: sure | 18:00 |
| SpamapS | m_3: we don't have to wait for the MP.. if there's good stuff there.. bzr merge.. bzr commit.. bzr push... rejoice | 18:00 |
| m_3 | there're a couple of juju-specific tools though | 18:00 |
| SpamapS | m_3: I mean, there may be stuff chef doesn't already have stuff for.. like verifying a downloaded file.. but I don't want us to be rewriting chef.. its already a rewrite of puppet ;) | 18:00 |
| m_3 | SpamapS: yeah, just didn't want the state of the "main" charms to be dependent on my happening to notice the new updates | 18:01 |
| m_3 | ha! | 18:01 |
| SpamapS | m_3: thats actually a good point... in debian we have watch files and a service which periodically refreshes the watch file... notifying us .. "there's a new upstream version, you should package it" | 18:02 |
| m_3 | yeah, understand... and do agree that we don't need to rewrite any tools that we could just use as-is | 18:02 |
| SpamapS | m_3: only if its simple | 18:02 |
| m_3 | right | 18:02 |
| SpamapS | m_3: if it takes 50 extra lines of ruby to use chef solo.. then F that. ;) | 18:02 |
| m_3 | no, it wouldn't | 18:02 |
| SpamapS | But I bet its a require or two and then some nice simple stuff. | 18:03 |
| m_3 | I'll get examples of it working over x-mas (off next week) | 18:03 |
| m_3 | I can even add a recipe or two for the juju-specific utilities I mentioned earlier | 18:04 |
| m_3 | beauty of such an approach in general is the charm-helper tools already having test suites | 18:05 |
| SpamapS | Yeah definitely | 18:06 |
| SpamapS | I wonder if we can use cucumber to have the same tests for different implemetations | 18:06 |
| SpamapS | mentations even | 18:06 |
| marcoceppi | I've got a question about relation hooks. I've got state: up for both services but MySQL charm hasn't given me all the data I need and it's been a while - how log can I expect it to run hook-changed againt? | 18:06 |
| SpamapS | marcoceppi: up just means the two sides are exchanging joined/changed/departed events | 18:07 |
| SpamapS | marcoceppi: you need to poll the actual provided service to find out if its ready yet | 18:08 |
| marcoceppi | How would I poll it? while loop? | 18:08 |
| SpamapS | marcoceppi: if mysql hasn't given the data.. perhaps check the charm log | 18:08 |
| marcoceppi | For the helper tests, would just putting it in a tests folder inside helpers/sh/ ? | 18:11 |
| m_3 | marcoceppi: great question | 18:12 |
| m_3 | perhaps start with that... helpers/sh/tests, | 18:13 |
| marcoceppi | Ok, cool. Shouldn't take long to write tests | 18:13 |
| m_3 | then we might be able to extract those to helpers/tests that're language neutral... great idea... might be hard to pull off though | 18:13 |
| marcoceppi | mm | 18:14 |
| m_3 | marcoceppi: BTW, hazmat mentioned a test where two sides of a relation play tictactoe through relation-changed hooks... I think they just keep firing as long as either side keeps 'relation-set'ing | 18:19 |
| m_3 | hazmat: ^^ does that exist? | 18:19 |
| marcoceppi | Well I know something is wrong with my relation-changed hook, because at the bottom it open's port 80 but never gets exposed when expose is run. | 18:20 |
| * marcoceppi continues investigation | 18:20 | |
| m_3 | marcoceppi: sometimes it can fail quietly.. that's why it's good to 'set -eu' in the outermost scripts | 18:22 |
| marcoceppi | What's the e do? | 18:23 |
| m_3 | have also hit problems if relation-changed gets stuck or is waiting a long time | 18:23 |
| m_3 | status is "up" (that just refers to the relation), but the relation-changed hook never completes | 18:24 |
| m_3 | e's just exit on error (in current shell or any subshells) | 18:25 |
| marcoceppi | ah, cool | 18:26 |
| m_3 | marcoceppi: have you worked with the debug-hooks command yet? | 18:26 |
| marcoceppi | kind of, I just ususally juju ssh <machine#> | 18:31 |
| marcoceppi | Doe the order of the machines in add-relation mater? | 18:31 |
| hazmat | m_3, no it doesn't, it was an idea, never put time serious time into it | 18:33 |
| m_3 | bummer | 18:37 |
| m_3 | marcoceppi: no | 18:37 |
| jcastro | m_3: yikes | 18:38 |
| jcastro | got held up, I am back now though if you wanna catch up | 18:39 |
| jcastro | marcoceppi: we're going to hash out an agenda for tomorrow's charm school if you feel like joining us | 18:39 |
| m_3 | jcastro: sounds good... SpamapS around too? | 18:39 |
| jcastro | yeah but I think he's distro-swamped still | 18:39 |
| m_3 | jcastro: ts3 is in now btw | 18:41 |
| jcastro | I saw | 18:41 |
| jcastro | \o/ | 18:41 |
| jcastro | 2 in one day! | 18:41 |
| m_3 | whoohoo | 18:41 |
| m_3 | jcastro: g+? | 18:42 |
| jcastro | m_3: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AoW1nhI7IMt3dFRvSFdkZmNqQ0t3RjZ2QTR2Z19teWc&hl=en_US#gid=0 | 18:45 |
| marcoceppi | jcastro: wher? | 18:51 |
| jcastro | marcoceppi: G+ | 18:54 |
| jcastro | I sent you an invite | 18:54 |
| jcastro | http://pad.ubuntu.com/charmschool | 18:54 |
| m_3 | for byobu-classroom, I usually... | 19:05 |
| m_3 | spin up one environment in ec2 using one email acct | 19:05 |
| SpamapS | You guys still G+'ing? | 19:06 |
| m_3 | then copy keys over and use that byobu-classroom to drive juju with another acct | 19:06 |
| jcastro | SpamapS: yeah, hop in | 19:06 |
| m_3 | yup | 19:06 |
| SpamapS | hazmat: confirmed, juju builds fine on buildd's without python-argparse .. I think this is a bug in python-argparse.. will discuss w/ python peeps | 19:38 |
| hazmat | SpamapS, cool, nice to have the precise builds working, thanks | 19:39 |
| TheMue | hazmat: You're maintaining our hangout in the calendar? Could you please send an invitation to my canonical address? | 19:40 |
| hazmat | TheMue, ack | 19:40 |
| === medberry is now known as mka | ||
| === mka is now known as medberry | ||
| niemeyer | hazmat: How's wtf being going for you guys? | 20:43 |
| niemeyer | s/being/been/ | 20:44 |
| robbiew | that reads funny if you don't have the context behind "wtf" | 20:53 |
| robbiew | lol | 20:53 |
| niemeyer | robbiew: LOL.. true | 21:01 |
| * SpamapS thinks WTF has been great since we started using it back in 2002 or so. better than OMFG I'd say | 21:04 | |
| SpamapS | r424 uploaded to precise | 21:18 |
| marcoceppi | Just deployed juju on ec2 to provide a fix for a failed CDN here at work - CTO is impressed :) | 21:27 |
| hazmat | niemeyer, haven't really checked it as much since it hanged on a rev a few weeks ago | 21:30 |
| hazmat | niemeyer, its very nice to have | 21:31 |
| hazmat | niemeyer, i sort of wish it would feed into the irc channel here | 21:31 |
| hazmat | blinking red lights and all ;-) | 21:31 |
| * hazmat hopes he can declare victory over the rodents | 21:32 | |
| SpamapS | marcoceppi: *NICE* | 23:01 |
| mpl | niemeyer: hmm, I don't get it. didn't it get through 45 mins ago? | 23:11 |
| mpl | I can rerun it again... | 23:11 |
| niemeyer | mpl: There's a single patch set in that change set | 23:12 |
| mpl | hmm what the hell | 23:13 |
| mpl | it sent it here: https://codereview.appspot.com/5448072 | 23:13 |
| mpl | dunno how I messed up, sorry. | 23:13 |
| mpl | lemme retry from scratch. | 23:16 |
| mpl | niemeyer: k, I had probably got the various branches confused when pulling. should be good now. | 23:20 |
| mpl | and off to bed, see you tomorrow. | 23:21 |
| SpamapS | sweeeeet... daily builds are fixed! | 23:40 |
| SpamapS | hazmat: ^5 | 23:40 |
| jimbaker | very nice to hear! | 23:40 |
| SpamapS | Now to figure out why python-argparse hasn't been removed | 23:40 |
| hazmat | SpamapS, nice | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!