| === wedgwood is now known as wedgwood_away | ||
| jam | jtv1: poke about https://code.launchpad.net/~jtv/juju-core/no-go-env/+merge/142280 need help landing it? | 06:14 |
|---|---|---|
| jam | wallyworld_: I saw you landed your patches (which is great), but noticed you had some troubles with the first one. Is there a process issue or just a misunderstanding? | 06:15 |
| wallyworld_ | not sure - tarmac said there was a conflict but i could reproduce locally | 06:15 |
| wallyworld_ | couldn't | 06:16 |
| jam | couldn't ? | 06:16 |
| wallyworld_ | i recreated the branch and repushed and it was ok after that | 06:16 |
| jam | wallyworld_: so if I try to merge your first commit, I get a conflict in client/client.go. After your "merge trunk" commit things work successfully. | 06:18 |
| jam | I wonder if the bot/launchpad somehow didn't get your latest update. | 06:18 |
| jam | Maybe you forgot to push after doing the merge? | 06:19 |
| jam | but that doesn't match what is on the MP | 06:19 |
| wallyworld_ | could be, that would seem the mostly likely cause. perhaps i am used to lbox submit doing the final push | 06:19 |
| jam | it doesn't show any new commits after you marked it approved | 06:19 |
| wallyworld_ | i can't remember exactly what i did | 06:20 |
| jam | but then the MP seems to not show any new commits, I'm guessing the recreating the branch broke the MP | 06:20 |
| jam | as there is no diff, etc. | 06:20 |
| wallyworld_ | a bit of ifddling and it came good | 06:20 |
| wallyworld_ | i don't think there's anything wrong with tarmac, it must have been my issue | 06:20 |
| wallyworld_ | i always got to lbox submit and realise after i get an error that goose doesn't work that way anymore | 06:21 |
| wallyworld_ | and then i forget to copy the descriptin to the commit message | 06:22 |
| wallyworld_ | i'll get the muscle memeory right one of these days | 06:22 |
| wallyworld_ | gotta go pick up my som, back in a bit | 06:22 |
| jam | wallyworld_: so goose was trying to merge your first commit (ian.booth@canonical.com-20130211050134-up8560e45212lnc6) according to tarmac logs | 06:22 |
| jam | wallyworld_: see you later. | 06:22 |
| wallyworld_ | sorry that i have to go 1/2 way through, i'm late :-( | 06:23 |
| jam | np | 06:23 |
| jam | davecheney: I'm looking to land a patch which removes 'jujuc' and moves the functionality into 'jujud' https://code.launchpad.net/~jameinel/juju-core/only-jujud/+merge/148181 | 06:24 |
| jam | I want to make sure it doesn't break upload tools, et al. | 06:24 |
| jam | I think I've covered the bits (and the test suite passes), but you seem to be the one with the most tool-uploading experience. | 06:25 |
| jam | Is there anything you want me to test manually before I submit the change? | 06:25 |
| wallyworld_ | jam: back | 06:57 |
| wallyworld_ | i think maybe i just didn't have the latest local rev pushed, that would explain the behaviour i think | 06:58 |
| jam | wallyworld_: yeah, tarmac was definitely trying to merge an older revision | 06:58 |
| jam | so either it wasn't pushed to LP, or tarmac wasn't seeing it for some reason. | 06:58 |
| wallyworld_ | i'd guess the former | 06:59 |
| wallyworld_ | but in my mind i had pushed it | 06:59 |
| wallyworld_ | PBKAC | 06:59 |
| rogpeppe | fwereade: morning! | 07:13 |
| rogpeppe | TheMue: hiya | 07:13 |
| fwereade | rogpeppe, TheMue, heyhey | 07:13 |
| fwereade | rogpeppe, TheMue: there is a start up at https://codereview.appspot.com/7324049/ | 07:14 |
| fwereade | rogpeppe, TheMue: I'm more concerned about implementation sanity than with exactly what I'm implementing | 07:14 |
| fwereade | rogpeppe, TheMue: because... well, you know why. I can change them easily, but if I wait for perfect agreement on everything I'll wait forever | 07:15 |
| rogpeppe | fwereade: looking | 07:16 |
| TheMue | rogpeppe, fwereade: Good morning. | 07:18 |
| TheMue | fwereade: *click* | 07:19 |
| TheMue | fwereade: You've got a review. | 07:33 |
| fwereade | TheMue, tyvm | 07:34 |
| rogpeppe | fwereade: reviewed | 07:40 |
| fwereade | rogpeppe, cheers | 07:43 |
| fwereade | TheMue, the answer to your question is "yes" | 07:44 |
| fwereade | rogpeppe, is there some way to express `Constraints{CpuCores:&123}`? | 07:46 |
| rogpeppe | fwereade: only with an extra line | 07:46 |
| fwereade | rogpeppe, so, not in a top-level var for the tests? | 07:46 |
| rogpeppe | fwereade: i was just looking at tim's "gap" document. where do we stand on centralised logging support (something i believe pyjuju has)? | 07:46 |
| rogpeppe | fwereade: huh? | 07:47 |
| fwereade | rogpeppe, I guess I could do a little `pInt(int) *int` func or something | 07:47 |
| rogpeppe | fwereade: Constraints{CpuCores: &t.cpuCores} ? | 07:47 |
| fwereade | rogpeppe, how do I express nil in the tests then? | 07:47 |
| rogpeppe | fwereade: ah! | 07:47 |
| rogpeppe | fwereade: yeah, i think intp(123) would be better than using interface{} | 07:48 |
| fwereade | rogpeppe, ok, cool | 07:48 |
| TheMue | fwereade: Thx. ;) | 07:48 |
| rogpeppe | fwereade: although... | 07:49 |
| fwereade | rogpeppe, re logging I think there's a bug open | 07:49 |
| fwereade | rogpeppe, and, yeah, we need it | 07:50 |
| TheMue | Btw, anyone able to change the topic to the actual state/milestone goals? | 07:50 |
| rogpeppe | fwereade: if you moved the parsing code into state, it might work to specify a string instead. | 07:50 |
| fwereade | rogpeppe, that code does feel very cli-specific though | 07:51 |
| rogpeppe | fwereade: i'm not sure. i suspect we might use it as a universal serialisation format for constraints | 07:51 |
| fwereade | rogpeppe, hmm, I was expecting just to store documents in state | 07:52 |
| rogpeppe | fwereade: i'm thinking of the API | 07:52 |
| rogpeppe | fwereade: (also some other tools might want to parse constraint strings too) | 07:53 |
| rogpeppe | fwereade: i think people using the GUI should be able to type constraint strings in the same format that we've got on the command line. | 07:54 |
| rogpeppe | fwereade: and i'd prefer it if the GUI people didn't have to duplicate our parsing code | 07:55 |
| fwereade | rogpeppe, hm, I'd expect the constraints gui to be a little more graphical/restrictive than that | 07:55 |
| rogpeppe | fwereade: hmm, maybe | 07:56 |
| rogpeppe | fwereade: anyway, i still think that code would fit very nicely alongside the String code. | 07:56 |
| fwereade | rogpeppe, and it's not very consistent with setting env/service config | 07:56 |
| rogpeppe | fwereade: because those are yaml? | 07:57 |
| fwereade | rogpeppe, not in the API they're not | 07:57 |
| fwereade | rogpeppe, also SetgentTools etc | 07:58 |
| rogpeppe | fwereade: oh really? we have to translate env and config settings to and from js? | 07:58 |
| fwereade | rogpeppe, the whole API is written with the assumption that we want to use objects rather than identifiers everywhere | 07:58 |
| rogpeppe | fwereade: the tools parsing is next to the tools stringer | 07:58 |
| fwereade | rogpeppe, I never really liked it | 07:58 |
| rogpeppe | fwereade: i'm not sure how that's relevant here | 07:59 |
| fwereade | rogpeppe, don't we have to translate *everything* to and from js for the gui? | 08:02 |
| rogpeppe | fwereade: i guess so. it might make some things awkward though. people can express things in the config yaml that can't make it through a json round trip. | 08:03 |
| fwereade | rogpeppe, remind me, what's allowed that we'll lose? | 08:04 |
| rogpeppe | fwereade: (at least, i *think* they might be able to) | 08:04 |
| fwereade | rogpeppe, my fervent hope is that the schemas are tight enough that they can't | 08:05 |
| fwereade | rogpeppe, but a hope is ll it is :/ | 08:05 |
| * rogpeppe goes to look at the config settings code | 08:06 | |
| fwereade | jam, wallyworld_: do I need another goose update? openstack's localLiveSuite.TestPorts is failing | 08:13 |
| fwereade | jam, wallyworld_: nope, still failing: http://paste.ubuntu.com/1648509/ | 08:15 |
| rogpeppe | fwereade: hmm, we parse all config options into string, and silently throw away anything that doesn't fit. | 08:15 |
| rogpeppe | fwereade: that will probably work ok with json. | 08:16 |
| * fwereade raises a single eyebrow with titanic self-control | 08:16 | |
| fwereade | rogpeppe, that is surprising to me... both environment and service config? | 08:16 |
| rogpeppe | fwereade: just looking at service config there | 08:17 |
| rogpeppe | fwereade: i'll have a look at env parsing again | 08:17 |
| * fwereade wonders why we have types then | 08:18 | |
| rogpeppe | fwereade: env parsing is up to the provider. as long as providers stick to json-compatible values we'll be ok | 08:20 |
| jam | fwereade: I get "TestPorts(Work in Progress)" meaning it is skipped | 08:21 |
| jam | fwereade: using rev 891 of juju-core | 08:22 |
| jam | in environs/openstack/live_tests.go it has 2 functions, both of which comment out the Port tests. | 08:22 |
| jam | fwereade: now, IIRC mgz accidentally landed a possibly port-related patch yesterday, but found he made a mistake when doing so, so rolled back the commit about 5 min later. It doesn't make a lot of sense that you would have seen it inside that window, but it is possible. | 08:23 |
| jam | fwereade: can you do "bzr log" in your juju-core branch and check? | 08:23 |
| jam | It should end with an Ian Booth commit | 08:23 |
| jam | fwereade: ok, sorry about that, it looks like 890 was mgz's patch that exposes the global ports tests (and expects them to pass), but then 891 landed by wallyworld_ removes that change | 08:24 |
| fwereade | jam, yeah, but there's only one mgz commit before that | 08:24 |
| fwereade | jam, and I see no skipped ports test in 891 | 08:25 |
| jam | fwereade: yeah, something weird here, let me see if I have something wrong | 08:25 |
| fwereade | jam, thanks | 08:25 |
| rogpeppe | fwereade: *after* we've parsed service config options into string, we validate them with charm.Config.Validate. | 08:25 |
| rogpeppe | fwereade: but tbh i think it's a bit crackful that that validation is done by the command line command, not in the state. | 08:26 |
| jam | fwereade: I had 'bzr revert -r -2' a while back to check if something was a regression. So it looks like 890 does, indeed, enable those tests. I'll run them again to see if they pass here. | 08:26 |
| fwereade | rogpeppe, yeah, there's a hack in config-get saying essentially "remove this when Service.Config is no longer crack" | 08:26 |
| jam | fwereade: it fails here. | 08:26 |
| jam | Blame mgz :) I'll see what I can sort out | 08:26 |
| jam | It looks like an accumulator is getting the same entry 2 times and not stripping the double | 08:27 |
| fwereade | jam, cheers :) | 08:27 |
| rogpeppe | fwereade: this one? | 08:27 |
| rogpeppe | // TODO Remove this once state is fixed to report default values. | 08:27 |
| fwereade | rogpeppe, yeah | 08:27 |
| rogpeppe | fwereade: i think that state *does* report default values | 08:27 |
| rogpeppe | fwereade: but only because we make sure to put them in in the first place | 08:28 |
| jam | fwereade: as I'm checking this for you, can you test if environs/ec2: go test -live works for you? | 08:28 |
| fwereade | rogpeppe, we should definitely NOT do that | 08:28 |
| jam | It times out for me after 10 minutes, and 2 modules that take > 5min | 08:28 |
| rogpeppe | fwereade: ah, because they might change on upgrade? | 08:28 |
| fwereade | rogpeppe, yeah | 08:28 |
| rogpeppe | jam: go test -live needs to be run with a longer timeout | 08:29 |
| rogpeppe | jam: it usually takes about 15 minutes for me | 08:29 |
| jam | rogpeppe: how does one do that? | 08:29 |
| jam | (and can -live do it automagically?) | 08:29 |
| fwereade | rogpeppe, did you fix the bootstrap tests crazy teardown bit? | 08:29 |
| rogpeppe | jam: this is the script i call "livetest": | 08:29 |
| rogpeppe | go test -amazon -test.timeout 2h -gocheck.vv $* >[2=1] | timestamp | 08:29 |
| rogpeppe | fwereade: not yet | 08:30 |
| jam | rogpeppe: is timestamp your own tool? | 08:30 |
| rogpeppe | jam: yeah, sorry, ignore that bit | 08:30 |
| rogpeppe | jam: (though i do find it dead useful) | 08:30 |
| jam | rogpeppe: there is a 'timestamp' provided by the "Internetwork Routing Protocol Attack Suite", but that didn't seem fitting | 08:30 |
| jam | I imagine it logs what time each line came in | 08:30 |
| rogpeppe | jam: yeah | 08:30 |
| jam | which I've seen elsewhere, but not packaged. | 08:31 |
| fwereade | rogpeppe, trivial: https://codereview.appspot.com/7312099 | 08:31 |
| rogpeppe | jam: go get code.google.com/p/rog-go/cmd/timestamp | 08:32 |
| rogpeppe | :-) | 08:32 |
| rogpeppe | fwereade: looking | 08:32 |
| jam | fwereade: it looks like it is a local-ism. Probably Martin was testing against the -live server and it was working, and didn't run the tests again with only the local server. | 08:33 |
| jam | The local double lets you expose the same port twice | 08:33 |
| jam | but then reports that the port is *open* twice. | 08:33 |
| jam | so we'll need to patch goose for that it looks like. | 08:34 |
| jam | fwereade: I'll put up a patch quickly. | 08:34 |
| fwereade | jam, lovely, thanks | 08:34 |
| jam | (I haven't fully confirmed that, but it seems likely) | 08:34 |
| fwereade | jam, I'd expect -live to run them locally as well for verification's sake | 08:35 |
| jam | fwereade: it does | 08:35 |
| jam | I just tried it | 08:35 |
| jam | and it fails | 08:35 |
| * fwereade grumbles | 08:35 | |
| jam | so I'm not sure how this got through | 08:36 |
| jam | mgz should be up soon to ask | 08:36 |
| rogpeppe | fwereade: hmm, does this look right to you? i can't remember what unit names we intended to disallow: ^[a-z][a-z0-9]*(-[a-z0-9]*[a-z][a-z0-9]*)*/[0-9]+$ | 08:37 |
| fwereade | rogpeppe, I think that's right, yeah | 08:38 |
| fwereade | rogpeppe, service names ending with `-%d` are not allowed | 08:38 |
| rogpeppe | fwereade: ah yes, i see now. foggy memories of that regexp resurface :0) | 08:39 |
| rogpeppe | fwereade: reviewed | 08:45 |
| fwereade | rogpeppe, I don't think it complains about a string with a / in, it just strips off the "unit-", doesn't it? | 08:46 |
| rogpeppe | jam: ha. would help if i actually pushed it | 08:46 |
| fwereade | rogpeppe, subsequent complaints about unknown units are, I think, sane | 08:46 |
| fwereade | rogpeppe, but maybe "invalid unit specifier" should just be "invalid entity name" as above | 08:48 |
| rogpeppe | fwereade: if you pass in "unit-foo-bar", you'll see `"foo/bar" is not a valid unit name` but if you pass in "unit-foo", you'll see `invalid unit specifier "foo"` | 08:48 |
| rogpeppe | fwereade: they're both invalid unit names | 08:49 |
| fwereade | rogpeppe, ahh, yeah | 08:49 |
| rogpeppe | fwereade: so i think they should probably draw the same error | 08:49 |
| fwereade | rogpeppe, reproposed | 08:53 |
| fwereade | rogpeppe, I think it's useful to be clear about the unit name being the problem rather than the entity name | 08:54 |
| fwereade | rogpeppe, maybe that's pointless though | 08:54 |
| rogpeppe | fwereade: hmm | 08:54 |
| rogpeppe | fwereade: i think it might be pointless actually | 08:54 |
| rogpeppe | fwereade: i suspect all "invalid name" errors from that function should look the same | 08:55 |
| rogpeppe | fwereade: and should all mention the actual entity name that was typed in | 08:55 |
| rogpeppe | fwereade: sorry for pushing back on this pissy trivial issue :) | 08:56 |
| fwereade | rogpeppe, np, I'd prefer to get it right :) | 08:57 |
| rogpeppe | fwereade: but i suppose it is something that users will actually see | 08:57 |
| fwereade | rogpeppe, when whatever they're using to log in doesn't handle the user name right? or more cases? | 08:58 |
| rogpeppe | fwereade: hmm. maybe not actually. the user will never type an entity na,e. | 08:59 |
| fwereade | rogpeppe, I am now wondering whether we should be checking validity of machine and user ids as well though | 09:00 |
| fwereade | rogpeppe, what are the username restrictions (if any?) | 09:01 |
| rogpeppe | fwereade: i think that's ok because we don't mangle the id going into those functions | 09:01 |
| fwereade | rogpeppe, I think machine-henry is still an invalid entity name | 09:01 |
| rogpeppe | fwereade: it is. interestingly State.Machine doesn't check for a valid machine id either. | 09:03 |
| fwereade | rogpeppe, ha, that'd be my fault | 09:03 |
| rogpeppe | fwereade: how about having a regexp for valid entity names? | 09:03 |
| * fwereade has to fix id types but thinks it's less important than constraints :( | 09:03 | |
| fwereade | rogpeppe, -1, I think, it's not going to be pretty | 09:04 |
| rogpeppe | fwereade: it won't. although it could be built up of existing components | 09:04 |
| fwereade | rogpeppe, the service/unit ones are bad enough as it is :) | 09:04 |
| rogpeppe | fwereade: i'd reuse those | 09:04 |
| rogpeppe | fwereade: `^(unit-`+unitNameValid+`)|(machine-[0-9]+)| etc` | 09:05 |
| rogpeppe | fwereade: but given the user never types an entity name, i think we're going overboard | 09:05 |
| fwereade | rogpeppe, yeah, I'm about to propose with trivial machine id checking as well, and hope we'll never need to touch it gain :) | 09:06 |
| rogpeppe | fwereade: let's just leave it where you started, except perhaps pass the invalid name into State.Unit even if it has no slash in it | 09:07 |
| rogpeppe | fwereade: that way you'll always get a consistent error. | 09:07 |
| fwereade | rogpeppe, I think invalid is different to not found, and I've already written it :) | 09:08 |
| rogpeppe | fwereade: State.Unit returns an error on invalid names already | 09:08 |
| fwereade | rogpeppe, I still think there's something to be said for consistency at the level of this func alone | 09:09 |
| fwereade | rogpeppe, and I don't think it's a heavy cost to pay :) | 09:09 |
| fwereade | rogpeppe, reproposed | 09:09 |
| rogpeppe | fwereade: LGTM | 09:10 |
| fwereade | rogpeppe, cheers | 09:11 |
| fwereade | rogpeppe, http://paste.ubuntu.com/1648829/ (doesn't seem consistent, might have seen it once when other stuff was broken but not last time I ran these tests) | 09:20 |
| rogpeppe | fwereade: are you using trunk? | 09:23 |
| fwereade | rogpeppe, that was a paranoid re-run of all tests against the fix-auth-entity | 09:23 |
| rogpeppe | fwereade: i don't see a similar assert at line 557 and tests pass for me | 09:23 |
| fwereade | rogpeppe, branched from trunk very recently | 09:24 |
| fwereade | rogpeppe, weird | 09:24 |
| fwereade | rogpeppe, wish I hadn't deleted the branch after verifying I couldn't repro | 09:24 |
| rogpeppe | fwereade: the ErrShutdown assert is on line 616 in trunk | 09:24 |
| fwereade | rogpeppe, assume I'm on crack then, I'll complain if it happens again | 09:25 |
| rogpeppe | fwereade: except it *is* testing for ErrShutdown. it may well be a race. i'll have a closer look at the logic. | 09:26 |
| rogpeppe | fwereade: (if it is a race, it's a benign one - it doesn't really matter which of those errors is returned in practice) | 09:26 |
| fwereade | rogpeppe, agreed, I just don't like test failures :) | 09:26 |
| rogpeppe | fwereade: me neither. i end up asserting one of two possible errors. | 09:27 |
| rogpeppe | s/end/might end/ | 09:27 |
| fwereade | rogpeppe, fine by me if it's not simple to make it consistent | 09:27 |
| jtv1 | jam: I'm off today but yes, some help landing it would be very much appreciated! | 09:31 |
| jam | rogpeppe: how do you tell if a map is empty? | 09:36 |
| jam | can you use len(mymap) ? | 09:36 |
| rogpeppe | jam: yup | 09:37 |
| rogpeppe | jam: (works on nil maps too) | 09:37 |
| jam | rogpeppe: is there an easy way to check if maps are equal? Or do you have to iterate both and look them up in the other one? | 09:39 |
| rogpeppe | jam: in a test, i'd use DeepEqual | 09:42 |
| rogpeppe | jam: otherwise, yes | 09:42 |
| jam | rogpeppe: in tests that is fine, but in real code? | 09:42 |
| rogpeppe | jam: it depends really. DeepEqual is slow and often not what you want (depends on the type of the map values) | 09:43 |
| jam | rogpeppe: I know of DeepEquals from gocheck, where do you get DeepEqual from? (stdlib?, somewhere else?) | 09:43 |
| rogpeppe | jam: reflect | 09:44 |
| rogpeppe | jam: reflect.DeepEqual(x, y) | 09:44 |
| jam | rogpeppe: thx, this is a map[string]string | 09:44 |
| rogpeppe | jam: the other thing about DeepEqual is it's not type safe | 09:44 |
| jam | I just want to see if they are passing something I already have | 09:44 |
| rogpeppe | jam: i'd just write the comparison code. | 09:44 |
| rogpeppe | jam: it's only 6 lines or so | 09:45 |
| mariusko | Hi, does it exist some system for notification/autentication between charms? | 10:04 |
| mariusko | Other than (mis)-use relations | 10:04 |
| rogpeppe | mariusko: that's what relations are for | 10:05 |
| mariusko | I would like to trigger redeploy from a git server charm to e.g. node-app on git push received | 10:05 |
| mariusko | I thought of either setting the branch name again on node-app in that case to trigger it, or add a parameter to store the SHA1 to deploy | 10:06 |
| mariusko | But how would the app-charm get access to the git repo? Is there a magic authentication through ssh or something? | 10:08 |
| mariusko | Or access it through NFS? | 10:11 |
| fwereade | TheMue, ping | 10:31 |
| fwereade | mariusko, do you have a config setting for your git repo? feels like a job for an external tool: set the service config, and let the charm's config-changed hook handle it | 10:32 |
| TheMue | fwereade: pong | 10:33 |
| fwereade | TheMue, it crosses my mind that we probably don't want the storage backend implementation hidden away inside environs/local | 10:33 |
| fwereade | TheMue, how are you planning to deploy it? | 10:33 |
| TheMue | fwereade: If there's good multiple usage I can surely move it. | 10:33 |
| fwereade | TheMue, I'm probably missing something, but I don't see when it'll be used inside environs | 10:34 |
| TheMue | fwereade: The backend only indirectly. I only put it there as we so far had no other need for it. | 10:34 |
| fwereade | TheMue, what's the planfor actually running it? | 10:35 |
| TheMue | fwereade: It can be a standalone binary of maybe also a configurable part of the machine agent. But here I'm not yet secure enough, I haven't yet looked. | 10:35 |
| TheMue | fwereade: The component is flexible enough. | 10:36 |
| fwereade | TheMue, yeah, I'm wondering whether a worker might be the way forward | 10:36 |
| fwereade | TheMue, not something that needs to be done right away though, I guess | 10:37 |
| TheMue | fwereade: I will keep it in mind, but yes, that would be a good "environment" for the backend to live in. | 10:37 |
| fwereade | TheMue, although I imagine you're aiming for a bootstrap ASAP? | 10:37 |
| TheMue | fwereade: Exactly. | 10:38 |
| fwereade | TheMue, cool, I imagine it will fall out naturally soon enough then | 10:38 |
| TheMue | fwereade: Think so too. | 10:38 |
| fwereade | TheMue, can I ask you to take a little look at davecheney's stater work, and let me know whether any of that will potentially fit in well with what you need in the local provider? | 10:39 |
| TheMue | fwereade: Do you know how to change topic w/o op? | 10:39 |
| fwereade | TheMue, I'm afraid I don't | 10:39 |
| fwereade | TheMue, maybe ask niemeyer when he comes on? | 10:39 |
| * niemeyer is around | 10:40 | |
| TheMue | fwereade: Good idea, and yes, I will take a look at the stater. | 10:40 |
| niemeyer | morning folks | 10:40 |
| TheMue | niemeyer: Good morning. | 10:40 |
| TheMue | niemeyer: Nice video about maps btw. | 10:40 |
| niemeyer | Hmm.. actually, how do I allow the topic to be changed by everyone again? | 10:40 |
| * niemeyer looks at the help | 10:41 | |
| niemeyer | TheMue: Cheers! | 10:41 |
| fwereade | niemeyer, heyhey, sorry I missed you :) | 10:41 |
| fwereade | TheMue, it's stalled in review at the moment because dave is looking at other things, but I don;t think we can afford to exclude it from consideration -- if you can come up with a plan that fits both local and HA use cases I will send you virtual flowers | 10:42 |
| * fwereade needs to take an extended lunch today, off in a few mins, and will see everyone in a couple of hours | 10:43 | |
| TheMue | fwereade: Oh, Valentine's. *rofl* | 10:43 |
| === ChanServ changed the topic of #juju-dev to: I am a new topic. | ||
| niemeyer | TheMue: /msg chanserv topic #juju-dev <whatever> | 10:45 |
| TheMue | niemeyer: Great, thank you. | 10:47 |
| === ChanServ changed the topic of #juju-dev to: finish ALL THE THINGS | ||
| fwereade | if someone can come up with a better topic, go for it :) | 10:48 |
| * fwereade => off | 10:48 | |
| wallyworld_ | jam: mgz: dimitern: can we delay the meeting for 30 minutes or so? i've had a call from my wife and i unexpectedly have to go and pick her up from a work meeting | 11:25 |
| dimitern | wallyworld_: works for me, | 11:25 |
| jam | wallyworld_: if anyone else was here it would be delayed :), but yeah, wfm | 11:25 |
| wallyworld_ | ok, thanks :-) will leave now and hopefully be back in 1/2 hour or so | 11:26 |
| TheMue | lunchtime | 11:29 |
| mariusko | fwereade: I think I will have to try to hack a bit to see when I get time. Maybe add a connection between gitolite and node-app charm where either you specify a ssh key to fetch the updated code or that node-app adds a ssh key to the server | 11:34 |
| jam | dimitern: the rest of us are all here | 11:49 |
| wallyworld_ | dimitern: i'm back | 11:49 |
| dimitern | jam: just a sec | 11:49 |
| * rogpeppe goes for lunch | 12:01 | |
| rogpeppe | back, but i'll probably step out for a breath of fresh air later | 12:13 |
| dimitern | fwereade, others?: https://codereview.appspot.com/7303091 - refactoring of hook module | 12:28 |
| rogpeppe | just rebooting, back in a mo | 12:50 |
| fwereade | dimitern, ping | 13:31 |
| dimitern | fwereade: pong | 13:32 |
| dimitern | fwereade: that's the CL we were talking about yesterday | 13:32 |
| fwereade | dimitern, I think hook.Info shouldn't be in charm/hook -- that bit is very specific to the uniter | 13:32 |
| dimitern | fwereade: ah, ok, I can move that bit back into worker/uniter/hook ? | 13:33 |
| bac | hi i just set up my environment and have r892 of juju-core. i'm seeing test failures for state/api. trying to figure out if it is my environment or if that test is really broken in trunk. | 13:33 |
| fwereade | dimitern, yeah -- I know it'll make both packages feel a little anaemic, but I think it's the right division | 13:33 |
| dimitern | fwereade: sure, np | 13:34 |
| dimitern | fwereade: how about the ScanCharm ? | 13:34 |
| fwereade | bac, would you paste them? I know there was churn there in the last couple of days | 13:34 |
| bac | fwereade: sure | 13:34 |
| fwereade | dimitern, my first reaction was eww! to the Errors type, but I haven't looked closely enough to figure out whether that's a sensible response ;p | 13:34 |
| dimitern | fwereade: it's a bit iffy at first, but I think it makes sense for what it does | 13:35 |
| fwereade | dimitern, I think you should be ok trusting the contents of the Meta though -- it does validate on load | 13:36 |
| bac | fwereade: http://paste.ubuntu.com/1650787/ | 13:36 |
| dimitern | fwereade: including duplicate relations scanning? | 13:37 |
| fwereade | bac, both of those are known and don't indicate anything seriously wrong that won't be fixed today | 13:39 |
| bac | fwereade: great, thanks for looking | 13:39 |
| * fwereade looks meaningfully at rogpeppe and mgz, neither of whom appear to be around right now | 13:39 | |
| fwereade | dimitern, I think so, yeah | 13:39 |
| === TheRealMue is now known as TheMue | ||
| fwereade | dimitern, lines 99-102 in meta.go | 13:40 |
| fwereade | bac, btw, much love for the bzr revision and go version at the bottom of the paste :) | 13:40 |
| bac | :) | 13:40 |
| dimitern | fwereade: ok then, I'll remove this check - can you comment that? | 13:41 |
| fwereade | dimitern, yeah, will do, just going through it now | 13:41 |
| rogpeppe | fwereade, dimitern, jam, anyone else: a small CL that adds error codes to the rpc package: https://codereview.appspot.com/7311097 | 13:43 |
| dimitern | rogpeppe: looking | 13:46 |
| rogpeppe | dimitern: ta! | 13:46 |
| fwereade | dimitern, I think it's all doing a bit much, I'm afraid | 13:49 |
| fwereade | dimitern, I totally understand the temptation to use filepath.Walk | 13:49 |
| fwereade | dimitern, but I think it'll work out clearer if you just build up a list of possible hook names given the available relation names | 13:50 |
| dimitern | fwereade: why using Walk is bad? | 13:50 |
| fwereade | dimitern, because we don't care about anything except the actual hooks that juju might try to run | 13:51 |
| dimitern | fwereade: hmm.. | 13:51 |
| fwereade | dimitern, I think that all we need is to build a list of all the global hooks, plus 4 relation hooks for every relation | 13:52 |
| dimitern | fwereade: do you think it's better, once we have discovered all relations, just do a loop over and find whether they're there | 13:52 |
| fwereade | dimitern, we don't even care if they're not there | 13:52 |
| fwereade | dimitern, the only thing we should worry bout is if they're there but aren;t executable | 13:53 |
| dimitern | fwereade: so the executable check has to happen in ScanCharm? | 13:53 |
| fwereade | dimitern, g+? might be quicker than typing | 13:54 |
| dimitern | fwereade: sure, I'll start a hangout | 13:54 |
| fwereade | dimitern, cheers | 13:54 |
| dimitern | fwereade: https://plus.google.com/hangouts/_/a19365e0ad7fd87450ce5dcdb4539de6e2fa6ca8?authuser=0&hl=en | 13:54 |
| fwereade | rogpeppe, http://paste.ubuntu.com/1650787/ -- bac has been seeing EOFs too | 13:55 |
| rogpeppe | fwereade: thanks. i'm looking at that right now, though i haven't been able to reproduce it | 13:55 |
| * dimitern >> lunch | 14:13 | |
| bac | rogpeppe: thanks for looking. i've got a fresh install and am using bigjool's mongo PPA. | 14:25 |
| fwereade | rogpeppe, you have an LGTM on the error codes, but I'd like to see the NotFound stuff implemented for Machine soon -- I'm not 100% clear on how that'll look in practice | 14:29 |
| === wedgwood_away is now known as wedgwood | ||
| fwereade | rogpeppe, also, re the int suggestion for CpuPower, would you expand a bit on what you're thinking -- something like 1000 CpuPower == 1 ECU? | 14:33 |
| rogpeppe | fwereade: sorry, was in a hangout | 14:47 |
| rogpeppe | fwereade: thanks. that's the next step | 14:47 |
| fwereade | rogpeppe, np, I expected so | 14:47 |
| rogpeppe | fwereade: yeah, for CpuPower, something like that. probably 100 could be sufficient. | 14:47 |
| rogpeppe | fwereade: we can display it as a float if we want. | 14:48 |
| rogpeppe | fwereade: although probably easier not to | 14:48 |
| fwereade | rogpeppe, yeah, that's the plan -- I'd kinda like to keep a bit more accuracy in there than I expect us to need :) | 14:48 |
| rogpeppe | fwereade: i hope you don't mind my instinctive discomfort with floats. | 14:49 |
| rogpeppe | bac: can you reproduce the test failure consistently? | 14:49 |
| bac | rogpeppe: yes as can teknico | 14:49 |
| rogpeppe | bac: cool - i'll push a branch for you to test in a moment | 14:49 |
| fwereade | rogpeppe, no, I share it really, I just thought it might be clearer as a float | 14:49 |
| bac | rogpeppe: thanks | 14:50 |
| fwereade | rogpeppe, the best float bug I ever heard about was in some game with decent-sized worlds made up of smaller rooms... when the rooms (which were playtested originally in the centre of the universe) were placed far enough away from (0, 0, 0), the loss of resolution meant that the geometry was represented funkily enough to allow people to clip through walls/floors/etc | 14:52 |
| rogpeppe | fwereade: i bet they were using float32s | 14:53 |
| fwereade | rogpeppe, probably -- and take the details with a pinch of salt | 14:53 |
| rogpeppe | fwereade: cool bug! | 14:53 |
| fwereade | rogpeppe, but still, floats are bad :) | 14:53 |
| fwereade | rogpeppe, indeed | 14:53 |
| * rogpeppe likes floats... in the right place. | 14:53 | |
| fwereade | rogpeppe, probably not so cool to debug ;) | 14:53 |
| rogpeppe | fwereade: or probably to fix... | 14:53 |
| fwereade | rogpeppe, as long as nobody kids themselves they're numbers they're fine | 14:54 |
| fwereade | rogpeppe, ha, yeah | 14:54 |
| rogpeppe | bac: lp:~rogpeppe/juju-core/216-rpc-consistent-close-error | 14:57 |
| bac | rogpeppe: will try now | 14:57 |
| bac | teknico: ^^ | 14:57 |
| rogpeppe | bac: thanks | 14:57 |
| teknico | bac, rogpeppe, I'll try it too shortly | 14:58 |
| rogpeppe | fwereade, TheMue: it finally dies... | 15:09 |
| benji | hi all; I'm getting an error (well, lots of similar errors) when running "go get -v launchpad.net/juju-core/..." --> "import "crypto/rand": import path doesn't contain a hostname" | 15:13 |
| bac | rogpeppe, teknico: i now see a different failure, which i have seen before: http://paste.ubuntu.com/1651636/ | 15:17 |
| rogpeppe | bac: that's blue team's domain :-) | 15:18 |
| bac | jam: ^^ | 15:19 |
| teknico | sorry, on a call, haven't tried yet | 15:21 |
| rogpeppe | bac: have you tried go get -u launchpad.net/goose ? | 15:24 |
| rogpeppe | benji: instead of that, try go get -v launchpad.net/juju-core/cmd/juju | 15:24 |
| bac | rogpeppe: i did update goose but not goamz | 15:25 |
| rogpeppe | bac: so have you got it working now? | 15:26 |
| benji | rogpeppe: go install launchpad.net/juju-core/log: mkdir /usr/lib/go/pkg/linux_386/launchpad.net: permission denied | 15:26 |
| rogpeppe | benji: what's your GOPATH? | 15:26 |
| benji | I had a GOROOT set when I got the aformentioned error, now with no GOROOT I get the above | 15:26 |
| bac | benji: :) | 15:26 |
| rogpeppe | benji: you need a GOPATH | 15:26 |
| benji | % echo $GOPATH | 15:27 |
| benji | /home/benji/workspace/go | 15:27 |
| teknico | rogpeppe, as for bac, the "api_test.go:524: suite.TestStop" is gone, but the "live_test.go:0: localLiveSuite.TestPorts" is still there | 15:45 |
| teknico | is "blue team's domain" a reliable enough escape hatch? ;-P | 15:45 |
| rogpeppe | teknico: yeah, i see the error too | 15:46 |
| dimitern | rogpeppe: i believe mgz should have fixed that | 15:46 |
| rogpeppe | dimitern: cool | 15:46 |
| dimitern | rogpeppe: we're talking about disabling the ports test today | 15:46 |
| fwereade | teknico, we were expecting mgz to show up and fix it, and that has not happened -- I think I'll just propose a trivial that skips it again | 15:46 |
| teknico | fwereade, thanks, bac, ^^ | 15:48 |
| dimitern | why was the test failing again? | 15:48 |
| mgz | ah, did we not report in here? | 15:48 |
| mgz | it just wants a goose branch landed to make the test service return a sanish error in response to the juju-core tests checking duplicate rule behaviour and probably not being very well isolated | 15:50 |
| rogpeppe | mgz, dimitern: i've also seen this failure in openstack: http://paste.ubuntu.com/1651926/ | 15:50 |
| dimitern | oh, yeah | 15:51 |
| dimitern | it relies on some (undocumented?) ec2 error behavior | 15:51 |
| mgz | okay, I marked the proposal as approved so it should auto land shortly | 15:52 |
| dimitern | mgz: cool, thanks | 15:53 |
| mgz | rogpeppe: that's an isolating issue, that's *already* worked around on goose | 15:53 |
| mgz | *isolation | 15:53 |
| dimitern | fwereade: a thought - how about instead of having a Meta method returning a map[string]true, instead return a slice and have a separate method IsHook() which uses a map internally to check that quickly, because that's what we care about in expand/bundle anyway.. | 15:53 |
| rogpeppe | mgz: what do you mean by an "isolation issue"? | 15:53 |
| mgz | basically, live-esque tests don't reset state in the test service | 15:54 |
| fwereade | dimitern, remember that a Meta needs to be stored in state -- we don't want private fields | 15:54 |
| mgz | so, within a file, all tests share the same service, which means subsequent ones have stuff like left over security groups from the previous tests | 15:54 |
| dimitern | fwereade: ah, didn't realize that | 15:55 |
| mgz | okay, pull goose and rerun everyone | 15:55 |
| fwereade | dimitern, and I don't think that a list of possible hooks is important enough to make visible | 15:55 |
| dimitern | fwereade: it can use a private map var | 15:55 |
| rogpeppe | mgz, dimitern: oh yes, another problem - at least one test fails when run by itself: http://paste.ubuntu.com/1651977/ | 15:55 |
| fwereade | dimitern, I think I'd prefer to just create it explicitly in the rare situations it's needed | 15:56 |
| mgz | rogpeppe: that one is new to me :) | 15:56 |
| dimitern | fwereade: no, i meant something else, let me paste some code | 15:56 |
| fwereade | dimitern, ah sorry | 15:56 |
| dimitern | rogpeppe: I think that's my doing | 15:57 |
| dimitern | rogpeppe: i'll have a look shortly | 15:57 |
| rogpeppe | mgz: yeah, i see the issue - kinda the point of the live tests is so that you *don't* have to bootstrap the environment every time, so that we have some possibility of running the test suite in under a day... | 15:57 |
| rogpeppe | mgz: but that's inevitably going to lead to isolation-related issues | 15:57 |
| * fwereade doesn't want to impose a fedex-everyone-biscuits penalty for breaking the build, but is considering a wear-stupidest-available-hat-in-hangouts policy | 15:58 | |
| mgz | I'm fine with tht :) | 15:58 |
| rogpeppe | fwereade: excellent idea | 15:58 |
| mgz | just having a bot is better of course | 15:59 |
| rogpeppe | mgz: a bot would be a great thing. how's it working out for you guys? | 15:59 |
| mgz | the tests passed locally, because goose still had my fix installed, which isn't terribly easy to detect | 16:00 |
| fwereade | mgz, +1 in theory, but that doesn't feel like it would play cleanly with the irritating synchronized-checkins requirement | 16:00 |
| * fwereade still kinda feels like cloning goose into thirdparty/ is the cleanest solution while it's still changing | 16:00 | |
| fwereade | firstparty/ ? | 16:01 |
| dimitern | fwereade: hmm.. I can't decide whether having both Hooks() map[string]bool and AllHooks() []string | 16:01 |
| dimitern | fwereade: it seems a plain slice is useful, but then again having a map for quick lookup is also nice, and can be looped over like a slice for the keys | 16:02 |
| fwereade | dimitern, I'd stick with the first, but now you've mentioned it in public the weight of popular opinion my push us towards an []string with O(N^2) checks | 16:02 |
| fwereade | dimitern, what are the use cases? for the only one I know, the map gets us the most compact code, I think | 16:02 |
| fwereade | dimitern, is one better for ExpandTo, the other for BundleTo? | 16:03 |
| dimitern | fwereade: sure, map is what we need - with the lack of keys(), which you have to loop over anyway, so should be enough | 16:04 |
| fwereade | dimitern, cool | 16:04 |
| dimitern | fwereade: for expand/bundle map is perfect, since files are processed one at a time | 16:05 |
| fwereade | dimitern, sgtm | 16:05 |
| dimitern | rogpeppe: that error is due to not passing --upload-tools (or equiv) I think - i've seen it before | 16:06 |
| dimitern | rogpeppe: or maybe some ill bootstrapping | 16:06 |
| rogpeppe | dimitern: well, it passes when i run all the tests together | 16:06 |
| dimitern | rogpeppe: that's bad | 16:07 |
| rogpeppe | fwereade: ahem, shame on me, i submitted a branch accidentally: https://codereview.appspot.com/7324054/ | 16:07 |
| dimitern | rogpeppe: it's not idempotent | 16:07 |
| rogpeppe | fwereade: it's fairly trivial (two line change) but still | 16:07 |
| rogpeppe | fwereade: i thought i was submitting another branch | 16:07 |
| rogpeppe | fwereade: (it does fix trunk too) | 16:07 |
| fwereade | rogpeppe, retroactively LGTMed | 16:08 |
| dimitern | rogpeppe: so accidentally submitted the right thing? | 16:08 |
| dimitern | :) | 16:08 |
| rogpeppe | fwereade: thanks | 16:08 |
| rogpeppe | dimitern: too early :-) | 16:08 |
| * fwereade doesn't trust any of you, and is going to run all the tests from scratch again ;p | 16:08 | |
| dimitern | today's break the build day :) | 16:09 |
| dimitern | as a friend says - "if you break the build, you *become* the build" | 16:09 |
| dimitern | fwereade: given Meta needs to be stored in state, it isn't a problem to have m *Meta methods, right? | 16:10 |
| fwereade | dimitern, I don;t think so, but they probably shouldn't need to be, because I don't think they should modify it | 16:11 |
| dimitern | fwereade: ofc, right | 16:12 |
| fwereade | mgz, rogpeppe, bac, teknico: tests cleanly for me with fresh goose; thanks all for warnings and fixes as appropriate | 16:14 |
| rogpeppe | fwereade: me too. fresh goose made things all tasty again. | 16:16 |
| teknico | fwereade, thanks. for my education, is there a better way than "go get"ting everything all the time? | 16:16 |
| rogpeppe | teknico: with changing external dependencies, not currently, no | 16:17 |
| dimitern | rogpeppe: fresh goose always makes things better :) | 16:17 |
| mgz | we've generally tried to post to the list when there needs to be a syncronous juju-core/goose update, but that only works for planned breakage, and is pretty frequent given doing pretty much anything in go involves changing an api | 16:18 |
| mgz | no new optional param, no new ignorable field migrations | 16:18 |
| rogpeppe | mgz: you can add struct fields and methods without breakage in general | 16:25 |
| mgz | not if you need to actually use them somewhere :) | 16:26 |
| mgz | in python you'd just getattr something on a class if you want to run against a dep that may or may not be a new version | 16:27 |
| mgz | which is ugly in the long run, but nice as a workaround | 16:28 |
| rogpeppe | mgz: yeah, i don't think we want to be doing that :-) | 16:30 |
| mgz | so, lockstep updates are a way of life. | 16:30 |
| rogpeppe | i still think there's no *inherent* reason that version-number-as-path needs to be painful, but i haven't worked out how the workflow should go exactly. | 16:31 |
| mgz | 's fine once things are stable-ish, but atm they are not. | 16:32 |
| dimitern | mgz: if you bzr rm a file, propose it, then add another file at it's place and bzr add it, when proposing it complains: error: Failed to send patch set to codereview: can't upload base of worker/uniter/hook/hook.go: ERROR: Checksum mismatch. | 16:32 |
| dimitern | any idea is this a lp, bzr or lbox issue? | 16:33 |
| mgz | needing to bump a version in every goose and every juju-core file multiple times a week doesn't work with more than one person doing development | 16:33 |
| mgz | dimitern: sounds like an lbox bug | 16:33 |
| mgz | but is it actually a different file, or did you break history for fun? | 16:33 |
| mgz | 'd cp your current file, bzr revert the path, mv the file back, and unless the diff is complete nonsense use that | 16:34 |
| rogpeppe | mgz: it's not inherently more work than bumping a version in one file AFAICS | 16:35 |
| mgz | rogpeppe: I'm proposing a feature, Ian's proposing a feature, how do we both bump the version? | 16:36 |
| mgz | it's hostile to distributed workflows | 16:36 |
| rogpeppe | mgz: how do you do that in the python world? | 16:37 |
| rogpeppe | mgz: is there something that auto-increments the version with each merge or something? | 16:38 |
| mgz | mostly by having flexible apis and the tools to work against older deps, but otherwise, by having the version in exactly one place that can get bumped as a seperate proposal, and is a single conflict point | 16:38 |
| rogpeppe | mgz: i think that bumping the version as a separate proposal could work fine even if there are multiple files involved. the conflicts will be obvious and easy to resolve. | 16:39 |
| mgz | they're mixed up with the imports... | 16:39 |
| mgz | and it can't be seperate, otherwise the code using whatever new api thing it is won't build | 16:40 |
| rogpeppe | mgz: that's fine, won't it? you could even have a tool that automatically diagnoses version number conflicts, perhaps, because they'll be so predictably formed AFAICS. | 16:41 |
| mgz | but it's not just conflicts, it's development | 16:42 |
| rogpeppe | mgz: i *think* development could work ok too, as long as a) there's an easy way to change all imports and b) there's a single development branch that has a static path. | 16:43 |
| mgz | if you're baking a number into the import, it makes every feature branch into an ordering complication | 16:43 |
| dimitern | mgz: so i first removed worker/uniter/hook/*, then proposed, then added worker/uniter/hook/ - 2 different files (part of what was there before, same names), reproposed, got the error, did bzr checkout -b newbranch, lbox proposed, same error again, and if you look at https://codereview.appspot.com/7337043/ some of the files are not there (upload in progress), but others are | 16:44 |
| mgz | if it's just +=1, you get breakage from two people landing at the same time due to it not being clear which new feature is actually being depended upon | 16:45 |
| dimitern | I don't see what's special about removing and re-adding a file with the same path in the same branch | 16:46 |
| mgz | dimitern: you change the fileids | 16:46 |
| * fwereade is somewhat upset to find he is no longer capable of spelling "uint" as anything other than "unit" | 16:46 | |
| rogpeppe | fwereade: lol | 16:46 |
| mgz | bzr cares about fileids, I suspect lbox doesn't understand them and just keys off path | 16:46 |
| rogpeppe | mgz: presumably that's true of any monotonic version numbering scheme though | 16:46 |
| rogpeppe | mgz: yeah, i don't think codereview.com knows about fileids | 16:47 |
| dimitern | mgz: well, if you look at the diff in lp, is says confusing things: https://code.launchpad.net/~dimitern/juju-core/reorganize-charm-hooks/+merge/148500 (added directory, then removed the same dir, added a file inside it next) | 16:47 |
| mgz | right, but it's not in the import generally, so isn't directly tied to code changes in *both* sides of the dep link | 16:47 |
| mgz | dimitern: right, really you shouldn't do that | 16:48 |
| fwereade | dimitern, when this sort of thing happens I usually just clone a fresh trunk and copy everything in from the borked one | 16:48 |
| dimitern | mgz: what? is it because a dir was deleted and re-added ? | 16:48 |
| mgz | what you probably want to do is branch the initial version, change the files to your changes (not using bzr rm and bzr add, but by changing the files), and push --overwriting | 16:49 |
| dimitern | fwereade: yeah, almost did it, but decided to ask and maybe learn the error of my ways :) | 16:49 |
| mgz | dimitern: you've said the files are unrelated by doing that | 16:49 |
| mgz | which confuses lbox | 16:49 |
| mgz | and anyone using the dvcs history | 16:50 |
| dimitern | I dont's see how, provided the history is in the right order | 16:50 |
| mgz | you removed a file, then added another file with the same name, and similar contents | 16:50 |
| dimitern | mgz: yeah, so? how's this different from doing the same, with the same file, but on 2 subsequent proposals? | 16:52 |
| mgz | well, it breaks lbox apparently, is how it's different | 16:53 |
| dimitern | mgz: but bzr is ok with this, I mean | 16:53 |
| mgz | it's okay with it, but you should have used mv | 16:54 |
| mgz | because it looks like a break in the history, when it's really a mv | 16:54 |
| mgz | anyway, you still can fix this, if you just start from r-2 and redo the change | 16:55 |
| dimitern | mgz: I got you, i though bzr will pick it up rm+add, but if the contents differ a bit (even if only at the bottom) | 16:56 |
| mgz | no, it means something else | 16:57 |
| niemeyer | fwereade: Where is the juju store nowadays? | 16:57 |
| mgz | you need to use `bzr mv` which does have some switches for guessing | 16:57 |
| niemeyer | fwereade: I see it got killed on Wednesday | 16:57 |
| mgz | but it's best to just be explicit | 16:57 |
| fwereade | niemeyer, lp:juju-store | 16:58 |
| niemeyer | bzr branch lp:juju-store | 16:58 |
| niemeyer | bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/juju-store/". | 16:58 |
| niemeyer | fwereade: ^ | 16:58 |
| niemeyer | allenap: ping | 16:59 |
| fwereade | niemeyer, ah, hmm, you would seem to be right -- I saw the project but didn't check the code | 16:59 |
| niemeyer | fwereade, allenap: Has anyone has coordinated with the team that deploys the store code to update the deployment procedure? | 16:59 |
| * fwereade has not :/ | 17:00 | |
| niemeyer | fwereade: Was there any meetings that I lost about this change? | 17:00 |
| allenap | niemeyer: Nope. I don't know who deploys the store exactly, but I can ask the webops. | 17:01 |
| fwereade | niemeyer, the MP referenced the discussions in austin in which we all seemed to agree that the store was best off separate if it was being worked on by another team | 17:01 |
| dimitern | mgz: cheers | 17:01 |
| niemeyer | allenap: I'm a bit concerned that we seem to be shaking things without much coordination | 17:02 |
| niemeyer | fwereade: Maybe.. it doesn't seem like a reason on itself, though | 17:02 |
| fwereade | niemeyer, but you're absolutely right that nobody considered the deployment | 17:03 |
| fwereade | niemeyer, I'm not sure -- the more teams we have hitting the same codebase, even if the work is theoretically non-overlapping, the more confusion there seems to be | 17:03 |
| niemeyer | fwereade: I think it would be nice to have that in the same place, at least for a while | 17:04 |
| rogpeppe | thumper: yo! | 17:05 |
| niemeyer | fwereade: As I understand it, that new team has never worked with Go, or with juju-core | 17:05 |
| thumper | hi rogpeppe | 17:05 |
| thumper | rogpeppe: I was waiting on the hangout :) | 17:05 |
| niemeyer | fwereade: Having teams closer together would probably be beneficial | 17:05 |
| niemeyer | fwereade, allenap: We actually had a thread going in the mailing list about this.. | 17:06 |
| niemeyer | fwereade, allenap: So, where is the code now, and who will coordinate with IS to update the scripts and make sure they work? | 17:06 |
| fwereade | niemeyer, perhaps I remember wrongly -- I thought the thread was essentially a rejection of the theory that occasional failing tests were a good reason to separate it | 17:07 |
| allenap | niemeyer: It's in lp:juju-store, which is currently private. I'll talk to the webops. | 17:08 |
| niemeyer | allenap: Can I please have access? | 17:08 |
| niemeyer | allenap: Does it have to be private now? | 17:09 |
| niemeyer | allenap: This means you'll be dropping codereview for the moment, since lbox won't keep content private | 17:09 |
| allenap | niemeyer: ~juju was invited to the ~juju-store team a while back, but I'll add you individually for now. | 17:09 |
| niemeyer | allenap: Let me try to approve that | 17:09 |
| allenap | niemeyer: hazmat originally asked for it to be private, iirc, so I'm going to punt on that :) | 17:10 |
| niemeyer | hazmat? | 17:10 |
| dimitern | fwereade: finally, I think this is the last of it - https://codereview.appspot.com/7317045 | 17:10 |
| hazmat | allenap, niemeyer in meeting back shortly | 17:11 |
| dimitern | rogpeppe: you too perhaps? ^^ | 17:11 |
| niemeyer | allenap: When will you start work on it? | 17:11 |
| niemeyer | allenap: That justifies the change, and it being private? | 17:11 |
| allenap | niemeyer: I think the Red Squad were happier to use LP for code reviews. However, we're not going to be working on the store any more... so whoever takes it on may decide they want back in to juju-core. It shares history so it ought not to be too hard to merge back in. | 17:13 |
| niemeyer | allenap: Erm.. who's actually working on that code? | 17:13 |
| allenap | niemeyer: I don't know, to be honest. Deryck may be able to help. | 17:14 |
| niemeyer | allenap: https://launchpad.net/juju-store/trunk | 17:15 |
| niemeyer | allenap: The project doesn't even have code set up | 17:16 |
| niemeyer | allenap: So I guess no one right now | 17:16 |
| allenap | niemeyer: https://code.launchpad.net/~juju-store/juju-store/trunk | 17:17 |
| allenap | niemeyer: Also, https://launchpad.net/juju-store/trunk looks right to me. | 17:18 |
| niemeyer | allenap: Thanks, I wasn't properly logged in | 17:18 |
| allenap | niemeyer: Cool. | 17:18 |
| fwereade | allenap, where should I have been to find out that store work was now off your plate? did I miss something obvious? | 17:20 |
| allenap | fwereade: It should have percolated through via management I assume, but I don't know that it's written anywhere. | 17:22 |
| allenap | Not written anywhere I know of. | 17:22 |
| niemeyer | Okay, I'm sending an email to sync us up | 17:23 |
| fwereade | allenap, it's perfectly possible that I missed something, but it doesn't ring any bells here :) | 17:23 |
| hazmat | allenap, i though we belayed removing it for a copy? | 17:33 |
| * hazmat is confused about whose on first | 17:34 | |
| hazmat | allenap, when did that change re red not on store? | 17:35 |
| allenap | fwereade, hazmat: Okay, this is not the message I got in Austin, which was to reopen and land the break-out-juju-store branch. | 17:35 |
| fwereade | hazmat, allenap: a copy seems like a suboptimal solution from just about every perspective... things can but diverge and cause (more) confusion | 17:35 |
| allenap | The cavalry has arrived :) | 17:37 |
| allenap | fwereade, hazmat: We can revert if you want: r886 is the offender. | 17:38 |
| * allenap has to go to collect his kids about 10 minutes ago. | 17:38 | |
| fwereade | allenap, collect your kids, we'll figure it out :) | 17:39 |
| fwereade | deryck, am I right in thinking that there's no current work happening on the charm store? or am I just confused? | 17:39 |
| deryck | no current work, no | 17:40 |
| deryck | I'm otp so will have to answer questions as I can, just FYI | 17:40 |
| fwereade | deryck, hazmat: does anyone have any objections to moving it back until it gets a happy new home with loving parents? ;) | 17:41 |
| deryck | fwereade: what are we talking about? a revno? Or something else? Maybe hazmat is better to comment here. | 17:44 |
| fwereade | deryck, I'm talking about the store package's removal from juju-core, on the understanding (I thought) that red would be doing imminent work on it | 17:45 |
| deryck | ah | 17:45 |
| fwereade | deryck, if that's not happening now, I think it's probably best left in juju-core for the time being | 17:46 |
| deryck | That makes sense to me. But I also think work will happen in the short term on the store. either red or green. | 17:46 |
| deryck | just not happening now. | 17:46 |
| deryck | I'd also prefer to defer to hazmat ultimately on this question. | 17:47 |
| fwereade | deryck, ok, thanks :) | 17:47 |
| fwereade | hazmat, it sounds as though you may have a clearer picture than any of us..? | 17:47 |
| fwereade | hazmat, or maybe we're just accusing you of that without any basis in fact ;) | 17:48 |
| deryck | fwereade: did allenap have objections to putting the store back in core? sorry to join late. | 17:50 |
| fwereade | deryck, I haven't heard any objections yet | 17:50 |
| fwereade | deryck, np :) | 17:51 |
| deryck | ok cool | 17:51 |
| niemeyer | fwereade, deryck: hazmat replied on canonical-juju | 17:54 |
| fwereade | niemeyer, ah, thanks | 17:55 |
| fwereade | niemeyer, deryck: I need to stop for the night; I'll restore it tomorrow (or maybe later...) if nobody else gets there first | 17:56 |
| fwereade | sorry to dash | 17:56 |
| fwereade | dimitern, LGTM, a few trivials | 17:57 |
| niemeyer | fwereade: Have a good one | 17:57 |
| hazmat | fwereade, niemeyer sorry about the confusion, things have been unclear to me as well | 18:00 |
| dimitern | fwereade: cheers! | 18:00 |
| niemeyer | hazmat: No worries, thanks for clarifying | 18:00 |
| dimitern | rogpeppe: ping | 18:01 |
| rogpeppe | dimitern: pong | 18:01 |
| rogpeppe | dimitern: sorry, i was chatting with thumper | 18:01 |
| dimitern | rogpeppe: np, if you can take a look at https://codereview.appspot.com/7317045 | 18:02 |
| dimitern | i'd like to land it today | 18:03 |
| rogpeppe | dimitern: will do | 18:03 |
| rogpeppe | dimitern, fwereade: is it really worth defining a new package to deal with charm hooks? wouldn't it be ok to have that stuff in the charm package itself? | 18:11 |
| allenap | fwereade, deryck: No objections from me for putting it back in juju-core. | 18:16 |
| dimitern | rogpeppe: hooks work in contexts where charm is too much to ask | 18:21 |
| rogpeppe | dimitern: what do you mean by "too much to ask"? | 18:21 |
| dimitern | rogpeppe: :) i mean you're not interested in the whole charm, just need to work with hooks | 18:22 |
| rogpeppe | dimitern: that's fine - you don't need to use the other charm-related stuff | 18:22 |
| dimitern | rogpeppe: and in addition, there are a lot of places in the uniter where this has to change | 18:22 |
| dimitern | rogpeppe: charm.RelationJoined vs hook.RelationJoined | 18:23 |
| dimitern | rogpeppe: I agree it might be a stupid thing, but looks cleaner | 18:23 |
| rogpeppe | dimitern: i think charm.RelationJoined reads ok | 18:24 |
| dimitern | rogpeppe: well, it's the same to me, if fwereade agrees as well | 18:24 |
| rogpeppe | dimitern: actually, on reflection, i don't mind too much. | 18:25 |
| rogpeppe | dimitern: but i do think you should be aliasing charm/hook, not uniter/hook inside the uniter code | 18:25 |
| dimitern | rogpeppe: i did that before | 18:26 |
| rogpeppe | dimitern: orly? | 18:26 |
| dimitern | rogpeppe: but it seemed wrong and funny :) | 18:26 |
| dimitern | chook here, chook there | 18:26 |
| rogpeppe | dimitern: charmhook would work too | 18:26 |
| dimitern | i didn't know is aussie for chicken :) | 18:27 |
| rogpeppe | dimitern: chhook maybe | 18:27 |
| rogpeppe | dimitern: just i think that the principle of renaming the thing that's furthest away is a decent one | 18:27 |
| dimitern | rogpeppe: charmhook was my first choice, but it's too long for long case x,y,z lines | 18:28 |
| dimitern | rogpeppe: ok, I can changed the uniter code to use hook and chook? | 18:28 |
| rogpeppe | dimitern: i *think* that'll be better | 18:29 |
| rogpeppe | dimitern: although changing it all to charm. is an alternative too - no name collision there | 18:29 |
| dimitern | rogpeppe: ok, I can now see charm.* seems a better choice | 18:30 |
| rogpeppe | dimitern: though you may want a common prefix for the hook names (HRelationJoined, HRelationDeparted etc?) | 18:31 |
| dimitern | rogpeppe: then a few things need changing, like IsRelation -> IsRelationHook, Install->InstallHook maybe? charm.Install seems ambiguous | 18:31 |
| === deryck is now known as deryck[lunch] | ||
| rogpeppe | dimitern: charm.HInstall | 18:31 |
| rogpeppe | ? | 18:31 |
| dimitern | rogpeppe: I'd like to pass this through fwereade as well, since it touches a lot of the uniter code | 18:31 |
| rogpeppe | dimitern: definitely | 18:32 |
| dimitern | rogpeppe: otherwise, I'm fine | 18:32 |
| dimitern | rogpeppe: so I guess I'll leave it for tomorrow then | 18:32 |
| rogpeppe | dimitern: sorry about that | 18:32 |
| dimitern | rogpeppe: tyvm! | 18:32 |
| rogpeppe | dimitern: np. naming issues, pah | 18:32 |
| dimitern | rogpeppe: np, it'll be better | 18:32 |
| dimitern | rogpeppe: it's a trivial change, so it up to agreement for readability/convenience really | 18:33 |
| dimitern | i'm off then | 18:35 |
| dimitern | good night all | 18:35 |
| rogpeppe | i'm off too | 19:02 |
| rogpeppe | g'night! | 19:02 |
| rogpeppe | dammit, i just saw another "unexpected EOF" test failure and i can't see how it could possibly have happened :-( | 19:02 |
| thumper | morning | 20:13 |
| === deryck[lunch] is now known as deryck | ||
| thumper | how do you normally upgrade the trunks in a GOPATH layout? | 21:05 |
| thumper | if I want latest juju-core trunk | 21:05 |
| thumper | is it normally just a pull? | 21:05 |
| thumper | or is there a special go command? | 21:05 |
| thumper | niemeyer, fwereade, anyone... | 21:10 |
| * niemeyer heads up | 21:11 | |
| niemeyer | thumper: I personally just pull | 21:11 |
| thumper | niemeyer: ok, ta | 21:11 |
| niemeyer | thumper: go get does support a -u flag, though | 21:11 |
| thumper | pull works for me | 21:11 |
| niemeyer | thumper: That may not go so well with cobzr | 21:11 |
| niemeyer | thumper: I mean, -u | 21:11 |
| thumper | niemeyer: I'm not using cobzr :) | 21:12 |
| * thumper is special | 21:12 | |
| niemeyer | thumper: That's fine.. whatever works :) | 21:12 |
| thumper | niemeyer: how do you handle the situation of pulling a new version of trunk... do you then run the tests to make sure all the appropriate deps are there and the API hasn't changed? | 21:41 |
| thumper | I'm considering the email sometime before | 21:41 |
| thumper | about "you need to upgrade goose as well as juju-core" | 21:41 |
| thumper | how do I know if I have other things to pull? | 21:42 |
| niemeyer | thumper: I don't generally run tests when starting to hack | 21:42 |
| niemeyer | thumper: But if you're not sure if it's working, that's a good idea | 21:42 |
| thumper | go test, right? | 21:43 |
| thumper | or go test juju-core? | 21:43 |
| * thumper found it | 21:48 | |
| thumper | I'm getting failures running the tests on trunk with `go test launchpad.net/juju-core/...` | 21:59 |
| thumper | anyone else? | 21:59 |
| * thumper hates broken tests on trunk | 22:00 | |
| thumper | although it is probably broken deps | 22:00 |
| thumper | or deps not updated | 22:00 |
| thumper | wallyworld___: ping | 22:01 |
| wallyworld___ | thumper: g'day | 22:22 |
| thumper | wallyworld___: hey there | 22:23 |
| thumper | wallyworld___: long tail you have there | 22:23 |
| wallyworld___ | yeah, stupid quassel | 22:23 |
| thumper | wallyworld___: was hoping you could help me with some test stuff | 22:23 |
| wallyworld___ | sure | 22:23 |
| thumper | hangout? | 22:23 |
| wallyworld___ | ok | 22:23 |
| davecheney | aww fuck, | 22:57 |
| davecheney | # launchpad.net/juju-core/store_test | 22:57 |
| davecheney | store/branch_test.go:28: too many arguments in call to "launchpad.net/juju-core/testing".Charms.Dir | 22:57 |
| davecheney | store/store_test.go:114: too many arguments in call to "launchpad.net/juju-core/testing".Charms.ClonedDir | 22:57 |
| davecheney | thumper: % bzr merge -r 886..885 | 22:58 |
| davecheney | is that the correct incantation for a reverse merge ? | 22:58 |
| thumper | davecheney: something like that | 22:59 |
| davecheney | cool | 23:00 |
| davecheney | looks like the problem is a change made afterwards to some testing stuff | 23:00 |
| davecheney | merge proposal coming up real soon now | 23:00 |
| davecheney | thumper: can I get a hell yeah, https://code.launchpad.net/~dave-cheney/juju-core/080-revert-store-change/+merge/148571 | 23:09 |
| * thumper looks | 23:09 | |
| davecheney | hang on, intertubes still grinding | 23:09 |
| davecheney | done | 23:09 |
| thumper | davecheney: what is the api change? | 23:10 |
| davecheney | the testing.Charm helper had an argument which was always "series" | 23:10 |
| davecheney | so revno 887 removed the parameter and bought the value indoors | 23:11 |
| davecheney | http://bazaar.launchpad.net/~gophers/juju-core/trunk/revision/887 | 23:11 |
| thumper | davecheney: seems I'm not in gophers | 23:16 |
| davecheney | thumper: I will try to fix | 23:16 |
| davecheney | speaking of that | 23:16 |
| davecheney | i've stopped getting notifications from LP | 23:16 |
| davecheney | which is a double edged sword | 23:16 |
| thumper | for what? | 23:16 |
| davecheney | about anything | 23:17 |
| davecheney | not the continuall flood of changes related to intel chips | 23:17 |
| davecheney | and more importantly no bug change notifications | 23:17 |
| thumper | hmm... | 23:18 |
| thumper | I'm still getting emails | 23:18 |
| davecheney | niemeyer: can you please make me an administator of https://launchpad.net/~gophers/+members | 23:18 |
| davecheney | and or approve tim | 23:18 |
| thumper | I've added myself, but it needs approval | 23:19 |
| thumper | for the restricted team | 23:19 |
| thumper | davecheney: I left my mark on the merge proposal FWIW | 23:19 |
| davecheney | thumper: ta muchly, i'll get it sorted today | 23:20 |
| * thumper fires off another two emails to juju-dev | 23:21 | |
| thumper | actually, lunch first | 23:21 |
| niemeyer | davecheney: Done | 23:21 |
| niemeyer | davecheney: and done | 23:22 |
| davecheney | niemeyer: thanks muchly | 23:22 |
| davecheney | niemeyer: please ignore my email then | 23:22 |
| niemeyer | davecheney: and done as well on kicking | 23:22 |
| niemeyer | davecheney: There are a couple of proposed members there.. I'm not sure if they should be or not | 23:23 |
| niemeyer | davecheney: I'd wait until they come and explain their needs | 23:23 |
| davecheney | niemeyer: SGTM | 23:23 |
| davecheney | niemeyer: unrelated, did you get my mail about the guy with the GPIO board ? | 23:24 |
| niemeyer | Actually, we can disregard at least one of them | 23:24 |
| niemeyer | davecheney: Oh, I did.. but I just skimmed through and planned to go back.. I'll do that | 23:24 |
| niemeyer | davecheney: I may be interested, depending on what it is | 23:25 |
| davecheney | niemeyer: lemmie know before next tuesday, i'll forward you his price list | 23:25 |
| niemeyer | davecheney: I'd probably be happy even if it's just a cable that lands on the protoboard | 23:25 |
| niemeyer | davecheney: Thanks a lot | 23:25 |
| davecheney | niemeyer: are you waiting on the GPIO <> serial cable ? | 23:25 |
| niemeyer | davecheney: If it's too involved/pricey, I'll probably not want as it's likely microprocessed | 23:26 |
| davecheney | niemeyer: i don't think it is, just a breakout board for the 20 gpio pins in some sensible groupings | 23:26 |
| niemeyer | davecheney: Ah, sweet, that I'd be interested on | 23:27 |
| davecheney | forward'ed email, lets take the discussion there | 23:27 |
| niemeyer | davecheney: a friend did that by hand, splitting into spacing so that the two rows can land on both sides of the protoboard | 23:27 |
| niemeyer | davecheney: That's pretty cool | 23:27 |
| niemeyer | davecheney: One important detail to be aware of, which you probably already are, is that the pins aren't 5V-tolerant | 23:28 |
| niemeyer | davecheney: worth mentioning just in case | 23:28 |
| niemeyer | as this is the kind of thing one generally expects of such hardware | 23:29 |
| davecheney | niemeyer: this is the nice thing about what this guy has done, along with the sheild, is a set of click together units | 23:30 |
| davecheney | so you can just attach a light, or a button, etc | 23:30 |
| davecheney | which is exactly what I want, as I can't solder for shit | 23:30 |
| davecheney | it's been decades | 23:30 |
| niemeyer | davecheney: Alternatively, you can go a long way with protoboards.. these days there are some nice small ones for that kind of "deployment" | 23:32 |
| niemeyer | davecheney: It's more fun to evolve the project as well | 23:32 |
| davecheney | niemeyer: i'm not really interested (at the moment) in _using_ the gpio pins | 23:33 |
| davecheney | but I am interested in write an interface to them for Go | 23:33 |
| niemeyer | davecheney: Ah, I see.. you just want to write the software | 23:33 |
| niemeyer | davecheney: Neat, I thought about doing that as well.. will be glad to use your package instead. ;) | 23:33 |
| davecheney | last week I met Alex Bradbury from the RPi foundation | 23:33 |
| davecheney | actually, i'll send you my notes, that is easier | 23:34 |
| niemeyer | davecheney: For that, I think a led and a resistor would do | 23:34 |
| davecheney | niemeyer: exactly | 23:34 |
| davecheney | you can already using the GPIO in bash, via /sys | 23:34 |
| davecheney | the libgpio driver uses a mmap of a magic area of /dev/mem | 23:35 |
| niemeyer | davecheney: Yeah, that's quite neat.. the interrupts are probably more interesting, though | 23:35 |
| davecheney | yup, that is why I have ordered a button | 23:36 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!