| menn0 | waigani: I've never used it but Stacked Git would probably help with this kinda of thing if it becomes a common thing you want to do. http://www.procode.org/stgit/ | 00:12 |
|---|---|---|
| waigani | menn0: ah, thanks for the tip | 00:12 |
| waigani | what is the difference between state/api/params/internal.go and params.go? | 00:39 |
| wallyworld__ | the former is for when code running within the state server makes an api call, vs clients | 00:41 |
| waigani | wallyworld__: thanks :) | 00:45 |
| wallyworld__ | np | 00:45 |
| axw | wallyworld__: where should I put backlog cards on Leankit now? | 01:16 |
| wallyworld__ | axw: let me check | 01:17 |
| axw | onyx has a section | 01:17 |
| thumper | my recommendation is "in the backlog" | 01:18 |
| axw | thumper: there is no one backlog. there's "onyx", "features", "core 1", "defered", and "team nz/au" | 01:19 |
| axw | and now tanzanite :) | 01:19 |
| thumper | right | 01:19 |
| thumper | we can kill "team nz/au" | 01:19 |
| thumper | move all them to "defered" | 01:20 |
| thumper | I guess | 01:20 |
| wallyworld__ | axw: in the new tanzanite backlog lane i just created | 01:21 |
| axw | wallyworld__: thanks | 01:21 |
| wallyworld__ | axw: i hadn't had a chance to reply yet - i wanted to shutdown the github issue tracking as per the original plan. i don't think having 2 issue trackers is sensible, especially given we are using lp for scoping work for milestones etc | 01:32 |
| thumper | menn0, waigani: comments left on respective pull requests | 01:32 |
| waigani | thumper: thanks. I'm just reviewing my user info branch before pushing. | 01:33 |
| axw | wallyworld__: I don't have a strong opinion. You can do milestones in GitHub too though. | 01:33 |
| wallyworld__ | sure, but milestone in lp then relate to ppas etc and all that other good stuff | 01:34 |
| wallyworld__ | and our release processes are built around that | 01:34 |
| axw | yeah, it would be a shame to lose the integration bits | 01:34 |
| wallyworld__ | i just wanted to check in with you before replying to the thread | 01:35 |
| axw | it doesn't really bother me. there are pros and cons to both options. I'd kinda like to wait and see, but it may just be a hassle to maintain both | 01:40 |
| axw | if closed, we need a prominent message somewhere pointing people to launchpad | 01:40 |
| menn0 | thumper: thanks for the feedback. I've responded and will action the points you've raised. I'll probably wait until fwereade has seen these changes before landing though. | 01:49 |
| thumper | ok | 01:50 |
| axw | wallyworld__: FYI, I'm going to change the merge job to use the m3.xlarge instance type | 02:23 |
| wallyworld__ | axw: hol off, ec | 02:23 |
| wallyworld__ | sec | 02:23 |
| axw | ok | 02:23 |
| axw | wallyworld__: rebasing and force-pushing does *not* lose comments on GitHub. I'm sure it used to, but maybe I was just on crack | 02:24 |
| menn0 | thumper: let me know when/if you have a moment to talk about schema migrations | 02:26 |
| wallyworld__ | axw: https://plus.google.com/hangouts/_/grsvduf57lzffsqepsrfr6mdsqa | 02:27 |
| thumper | menn0: sure, just trying to submit a few expenses | 02:27 |
| menn0 | thumper: no rush | 02:27 |
| axw | wallyworld__: just a sec | 02:27 |
| wallyworld__ | axw: oh balls, just failed :-( | 02:40 |
| axw | bugger :/ | 02:40 |
| wallyworld__ | still, quick enough that we try with parallelisation first | 02:40 |
| thumper | menn0: how about now? | 02:41 |
| axw | wallyworld__: so it adds ~15 mins at worst? | 02:41 |
| menn0 | thumper: now is good | 02:41 |
| wallyworld__ | yeah or even a a bit less | 02:41 |
| menn0 | thumper: https://plus.google.com/hangouts/_/gujkllcsyr6ughkd5siy5jkdeya?authuser=1&hl=en-GB | 02:41 |
| axw | wallyworld__: seems fine. I was going to look into creating a fs lock for mongo tests. do you think that'd be worthwhile? | 02:41 |
| axw | wallyworld__: then we can run a bunch in parallel, but only those mgo ones will serialise | 02:42 |
| wallyworld__ | can't hurt, worth a spike on | 02:42 |
| wallyworld__ | this was the failure btw | 02:42 |
| axw | will see if I can whip something up | 02:42 |
| wallyworld__ | FAIL: container_initialisation_test.go:1: ProvisionerSuite.TearDownTest | 02:42 |
| wallyworld__ | /home/ubuntu/juju-core_1.19.4/src/github.com/juju/juju/juju/testing/conn.go:135: | 02:42 |
| wallyworld__ | c.Check(err, gc.IsNil) | 02:42 |
| wallyworld__ | ... value *errors.errorString = &errors.errorString{s:"error receiving message: write tcp 127.0.0.1:45210: broken pipe"} ("error receiving message: write tcp 127.0.0.1:45210: broken pipe") | 02:42 |
| wallyworld__ | ---------------------------------------------------------------------- | 02:42 |
| wallyworld__ | PANIC: provisioner_test.go:407: ProvisionerSuite.TestProvisionerSetsErrorStatusWhenNoToolsAreAvailable | 02:42 |
| axw | mmk | 02:42 |
| wallyworld__ | looks like a race tearing down a test | 02:42 |
| wallyworld__ | anyways, i'll change the job | 02:43 |
| axw | hmm, that's an error closing the API server | 02:43 |
| axw | API client event | 02:43 |
| wallyworld__ | ok, i didn't look past the error just yet | 02:43 |
| wallyworld__ | axw: my code is out of date, so line number doesn't match,but looks like we are in a cleanup and can't close api server. i wonder if it had already been shutdown | 02:45 |
| axw | yes that is the line | 02:47 |
| axw | not sure... | 02:47 |
| wallyworld__ | sure seems like a potential race | 02:48 |
| axw | wallyworld__: it's the client that can't be closed. apparently websockets require you to send data to close the connection. I guess the server has already gone away | 02:50 |
| wallyworld__ | yeah | 02:51 |
| axw | wallyworld__: so... I think the issue is that the client is being closed in an AddCleanup, whereas the server is closed by TearDownTest (prior to running other cleanups) | 02:56 |
| axw | I can take a look at fixing if you like | 02:56 |
| wallyworld__ | ok, that woud be great | 02:56 |
| wallyworld__ | axw: maybe also have a quick check of the code to see if there's other places where something similar is down, so we try and attack them all | 03:04 |
| axw | wallyworld__: is there a bug for this failure? | 03:18 |
| wallyworld__ | not yet that i know of | 03:18 |
| axw | k | 03:18 |
| wallyworld__ | axw: +1, now let's see how the new landing job goes | 03:31 |
| axw | thanks | 03:33 |
| axw | I really like that that we can see the bot's progress now | 03:34 |
| wallyworld__ | axw: \o/ | 03:49 |
| wallyworld__ | worked | 03:49 |
| wallyworld__ | +1 to seeing progress | 03:49 |
| axw | winning | 03:49 |
| axw | nice and quick | 03:49 |
| sebas5384 | there's a way to upgrade a bundle? | 03:49 |
| rick_h_ | sebas5384: no, not currently. | 03:50 |
| axw | wallyworld__: maybe we should stick with ephemeral instances then? | 03:50 |
| sebas5384 | oh rick_h_ thanks, but there's plans for it? | 03:50 |
| wallyworld__ | well, testing is down to 11 mins. building the instace takes about 5 | 03:50 |
| wallyworld__ | so 16mins vs 11 | 03:50 |
| wallyworld__ | worth a little more effort i think | 03:51 |
| rick_h_ | sebas5384: it's been talked about but not currently on the list of stuff being worked on. | 03:51 |
| axw | s'pose so. | 03:51 |
| wallyworld__ | but not much more | 03:51 |
| sebas5384 | rick_h_: ahh ok then, i imagine it isn't nothing simple | 03:52 |
| sebas5384 | there are so many complicated situations | 03:53 |
| sebas5384 | like adding a service, and then removing it, and thats the same for relations, etc... | 03:53 |
| thumper | davecheney: seems like your deps file is missing a tab juju-ci.vapour.ws:8080/job/github-merge-juju/17/? | 04:18 |
| waigani | thumper: ping | 04:23 |
| thumper | hai | 04:23 |
| waigani | thumper: I don't understand your review comment "Both user and stateServers for the environment need to read the jenv file. Perhaps consider doing that before?" | 04:23 |
| thumper | waigani: well, to get the user and the api end points, you need to read the jenv file | 04:23 |
| thumper | you are reading the jenv file twice | 04:23 |
| thumper | once in each method | 04:23 |
| waigani | oooh | 04:23 |
| waigani | got ya | 04:24 |
| thumper | (behind the scenes) | 04:24 |
| waigani | I'll reuse it | 04:24 |
| * thumper nods | 04:24 | |
| thumper | that's what I was meaning | 04:24 |
| thumper | waigani: what happens if there is no jenv file? | 04:24 |
| thumper | because that environment isn't bootstrapped? | 04:24 |
| thumper | tests for that>? | 04:24 |
| waigani | thumper: yep | 04:25 |
| thumper | cool | 04:25 |
| waigani | thumper: so i discussed this with menn0, and we wanted to support the scenario of switching to an bootstrapped environ - with no jenv file | 04:25 |
| thumper | waigani: you can't | 04:26 |
| waigani | thumper: in that case me code is wrong :( | 04:26 |
| thumper | waigani: if the environment isn't bootstrapped, there is no jenv file | 04:26 |
| waigani | as it currently suppresses file not found error | 04:26 |
| thumper | if there is a jenv file - it should be bootstrapped | 04:26 |
| menn0 | I don't recall talking about that :-/ | 04:26 |
| thumper | it is possible that you have a jenv file that points to an environment that someone else has destroyed | 04:27 |
| menn0 | actually now I do | 04:27 |
| waigani | so I can remove the error suppression and fail when trying to switch to an env with no jenv? | 04:28 |
| menn0 | it was so you could do "juju switch foo" and then "juju bootstrap" | 04:28 |
| waigani | menn0: yep, that's right | 04:28 |
| menn0 | seems like a reasonable thing to want to do, although not super critical | 04:29 |
| waigani | so the current code allows that | 04:29 |
| waigani | i mean my branch | 04:29 |
| waigani | thumper: do we want to support this usecase: "juju switch foo" and then "juju bootstrap" | 04:30 |
| thumper | yes | 04:30 |
| thumper | most definitely | 04:30 |
| thumper | I do it all the time | 04:30 |
| waigani | in which case we have to switch to an env without a jenv | 04:31 |
| thumper | yes, but that isn't what you said | 04:31 |
| waigani | what did I say? | 04:31 |
| thumper | you said "we wanted to support the scenario of switching to an bootstrapped environ - with no jenv file" | 04:31 |
| waigani | oh shit | 04:31 |
| waigani | UNbootstrapped | 04:31 |
| thumper | right | 04:32 |
| waigani | typo, sorry | 04:32 |
| thumper | that makes more sense | 04:32 |
| === vladk|offline is now known as vladk | ||
| waigani | right, all on the same page. I've covered it in the code and have tests. | 04:32 |
| jcw4 | are we using axw's gocov tool on juju regularly, or some other coverage tool? | 05:30 |
| davecheney | jcw4: go tool cover | 05:30 |
| axw | gocov is mostly redundant now | 05:31 |
| jcw4 | davecheney, axw I see... does go tool cover have a report function too? I need to go investigate | 05:31 |
| jcw4 | (I like gocov test | gocov report) | 05:32 |
| axw | jcw4: only as HTML, AFAIK | 05:32 |
| jcw4 | axw: ah. I guess lynx or something would be do-able on the command line | 05:33 |
| axw | jcw4: gocov just uses the builtin coverage analysis now anyway, so if you prefer that then there's no problem using it | 05:33 |
| davecheney | hold up | 05:33 |
| davecheney | http://dave.cheney.net/2013/11/14/more-simple-test-coverage-in-go-1-2 | 05:33 |
| axw | davecheney: yeah, it's not quite the same. "gocov report" gives you a breakdown by function | 05:34 |
| jcw4 | davecheney: thanks! I think that will be useful too. I'll probably end up using both | 05:35 |
| axw | it would be nice to have regular coverage reports | 05:35 |
| jcw4 | it's not in the juju ci pipeline? | 05:35 |
| axw | nope | 05:35 |
| jcw4 | hmm | 05:36 |
| jcw4 | I could even see it being tuned and added as a pre-push hook... | 05:36 |
| jcw4 | if you don't mind waiting forever | 05:36 |
| jcw4 | (metaphorically speaking) | 05:37 |
| axw | could do, I think it would be fine in the CI tho | 05:39 |
| axw | I prefer to use it just as a tool to guide testing, not to gate changes | 05:40 |
| jcw4 | axw: yeah, that makes sense. | 05:40 |
| jcw4 | otoh, 0% coverage is a pretty big red flag... | 05:41 |
| davecheney | jcw4: go test -cover github.com/juju/juju/... | 05:41 |
| davecheney | will give you a first aproximation | 05:41 |
| davecheney | make sure you have the latest cover tool | 05:41 |
| jcw4 | k | 05:42 |
| davecheney | there was a bug with external tests that showed 0 when there were no internal tests | 05:42 |
| jcw4 | it would be interesting to develop a hook that could run coverage tests only on modified files | 05:42 |
| jcw4 | and fail if less than some threshold, say 50% | 05:42 |
| davecheney | jcw4: sounds like a nice pipe dream | 05:43 |
| jcw4 | :-D | 05:43 |
| jcw4 | yep | 05:43 |
| davecheney | there are more serious issues atm I feel | 05:43 |
| davecheney | lack of mocks for the state server is the big one for me | 05:43 |
| davecheney | the fact the tests take 30 minutes to run is fucked | 05:43 |
| jcw4 | and that is mostly because of mongo dependencies? | 05:43 |
| davecheney | and they do this because we start one mongo per test | 05:43 |
| jcw4 | yeah | 05:44 |
| davecheney | 90% of the current test failures are when mongo just fails to start | 05:44 |
| jcw4 | what's interesting to me is that the mongo api seems so easy to mock... | 05:44 |
| jcw4 | are there subtleties I'm missing? | 05:44 |
| davecheney | nope | 05:44 |
| davecheney | an in memory mongo is a map and a lock | 05:44 |
| jcw4 | hmm. | 05:45 |
| jam1 | morning all, I had forgotten I had closed my IRC window. I hope everyone is doing well. | 05:51 |
| vladk | jam1: morning | 05:53 |
| lifeless | jam1: you're still in the middle east I guess? | 05:59 |
| jam1 | lifeless: yeah, in Dubai, UTC +4 | 06:00 |
| TheMue | morning | 07:03 |
| jam1 | TheMue: morning | 07:26 |
| jam1 | I think I have the outline for API versioning up for you | 07:26 |
| jam1 | fwereade: it would be good if you can give it a look over as well, to make sure my plotted trajectory is sane. | 07:27 |
| fwereade | jam1, great, tyvm | 07:27 |
| TheMue | jam1: great, finished the planning doc yesterday evening and now waiting for Nick to get it online | 07:28 |
| jam1 | TheMue: fwiw we'll probably want the API versioning document to become something in trunk developer docs as an .md file, I suppose I need to start reading up on markdown syntax | 07:30 |
| TheMue | jam1: I would like all developer docs, opposite to planning docs, in the standard repo too, yes | 07:32 |
| TheMue | jam1: makes more sense to keep them near and also always matching the releases | 07:33 |
| TheMue | jam1: thankfully md is pretty simply, and github renders it directly when somebody browses our repo | 07:34 |
| jam1 | api versioning is potentially a dual doc, since for people that want to consume Juju via the API we do want them to know how we plan to interact with them. | 07:34 |
| === vladk is now known as vladk|offline | ||
| dimitern | fwereade, jam1, hey, I still need an approval on https://github.com/juju/juju/pull/13 please! | 07:44 |
| jam1 | dimitern: I'm surprised to see the Disabled stuff come in after the review, I don't think that was part of the discussion so far, did I just miss that part? | 07:46 |
| TheMue | jam1: will talk to Nick about a process to also publish released developer docs out of our repo | 07:47 |
| dimitern | jam1, it was part of the discussions past :) | 07:47 |
| dimitern | jam1, i mean, we talked about configuring only the nics the user wanted, not all possible ones | 07:47 |
| dimitern | jam1, i did implement "find all nics/nets and configure them", but now as we're moving to a more dynamic model the networker can do that later eventually | 07:49 |
| === _mup__ is now known as _mup_ | ||
| voidspace | morning all | 08:14 |
| fwereade | dimitern, reviewed | 08:16 |
| fwereade | dimitern, although, thinking about the disabled stuff | 08:17 |
| fwereade | dimitern, I'm not sure it's the right time for that -- we should be able to guarantee that the ^foo networks won't be possible to configure already, so that bit's handled | 08:17 |
| fwereade | dimitern, but without the networker worker, to handle things the deployment of units that use a constrainted-but-disabled network | 08:18 |
| fwereade | dimitern, sane? or do we expect a functional networker so soon that it makes no odds? I'm a bit sceptical there, 1.20 is coming upon us apace | 08:19 |
| dimitern | fwereade, sorry, i don't quite follow - constrainted-but-disabled network ? | 08:24 |
| fwereade | dimitern, mentioned in constraints, so it'll be noted as an available network, but not specified with --networks and therefore not enabled | 08:24 |
| fwereade | dimitern, without a networker to enable it, we're better off leaving them all configured until we have the machinery in place to handle switching them on and off as required | 08:25 |
| fwereade | dimitern, otherwise we'll end up deploying units to machines that can't actually serve them | 08:28 |
| === vladk|offline is now known as vladk | ||
| rogpeppe | hmm, it looks as if the juju commit history was not filtered to remove the non-trunk commits. is that right? | 08:41 |
| rogpeppe | mgz: ^ | 08:41 |
| rogpeppe | the unfortunate implication of that seems to be that when using git filter-branch to factor out juju subdirs into their own repos while preserving history, none of the trunk commits (the ones with the actual useful messages) get preserved. | 08:43 |
| dimitern | fwereade, until we have the networker, we'll still use cloudinit for the setup | 08:44 |
| dimitern | fwereade, and in my PR i changed the logic to only bring up what the user wanted, leaving the rest disabled | 08:45 |
| fwereade | dimitern, yeah, and if cloudinit leaves some networks disabled then the model will happily assign units that need disabled networks to that machine, and they won't work | 08:45 |
| dimitern | fwereade, that's what we agreed upon in austin, isn't it? | 08:45 |
| dimitern | fwereade, how can that happen? | 08:46 |
| fwereade | dimitern, yeah -- but until we have the networker to switch on those networks when we need them, having them disabled is more broken not less broken | 08:46 |
| fwereade | dimitern, this machine records that it has access to foo, bar, baz | 08:46 |
| fwereade | dimitern, and it's started with --networks=foo | 08:46 |
| dimitern | fwereade, yes, this means we're enable only foo | 08:46 |
| fwereade | dimitern, the unit assignment logic should consider it a viable place to deploy a service that uses bar | 08:46 |
| rogpeppe | fwereade: how much do we care about commit history in git? | 08:47 |
| dimitern | fwereade, no yet anyway | 08:47 |
| fwereade | dimitern, expecting that the networker will set up the appropriate interface | 08:47 |
| dimitern | fwereade, the unit assignment logic + networks currently considers only empty machines | 08:47 |
| dimitern | fwereade, there's no way to break things automatically ;) | 08:47 |
| fwereade | dimitern, right -- you can start a machine with --networks, and constraints, and the unit assignment logic should consider that clean machine a viable place to put a unit | 08:48 |
| fwereade | dimitern, and it should not be worrying about the machine's --networks, or its constraints, only on the networks we record as potentially accessible | 08:48 |
| dimitern | fwereade, a new machine, not just a clean one | 08:48 |
| fwereade | dimitern, yes: it's new, so it's clean and empty, so it's in the running | 08:49 |
| voidspace | PR for someone: https://github.com/juju/juju/pull/24 | 08:49 |
| dimitern | fwereade, what you're describing involves doing add-machine --networks ... --constraints networks=... | 08:49 |
| fwereade | dimitern, and if it has recorded that net-bar *could* be set up, the unit assignment should consider it a viable location for a unit of a service that requires net-bar | 08:49 |
| fwereade | dimitern, no, it doesn't require any more than add-machine --networks | 08:50 |
| dimitern | fwereade, what networks *can* be configured on a machine comes from the interfaces discovered at provisioning time | 08:50 |
| fwereade | dimitern, right | 08:51 |
| fwereade | dimitern, create a machine with --networks | 08:51 |
| dimitern | fwereade, the disabled flag just signals not to enable them, but we still have the info in state, as unit assignment logic is concerned | 08:51 |
| fwereade | dimitern, that machine gets provisioned | 08:51 |
| fwereade | dimitern, it's recorded as capable of starting a big list interfaces, but it only actually starts one of them | 08:52 |
| fwereade | dimitern, now, much later, we create a unit | 08:52 |
| fwereade | dimitern, that unit's service specified --networks=bar | 08:52 |
| fwereade | dimitern, correct unit assignment logic says "that machine *could* configure net-bar, so we'll use it" | 08:52 |
| fwereade | dimitern, unit goes on machine, networker hasn't landed yet, unit can't use network | 08:53 |
| dimitern | fwereade, you're correct about that, but it's not implemented like that yet | 08:53 |
| dimitern | fwereade, the networker is coming soon anyway | 08:53 |
| dimitern | fwereade, unit assignment logic does not consider what networks are available on the machine yet | 08:54 |
| fwereade | dimitern, is there any doubt as to how it should, or will, be implemented? the point is to build a component that continues to work nicely even given the annoying way different streams of work progress at different times and in different ways | 08:54 |
| fwereade | dimitern, it should consider it, and it should happen soon, it's all part of the model | 08:55 |
| dimitern | fwereade, to do that, we need to take into account what network interfaces are there, constraints are not important there, just requested networks (but they will be configured anyway at provisioning time) | 08:55 |
| dimitern | fwereade, yes, it's part of the model, but we haven't got that far | 08:56 |
| jam1 | dimitern: fwereade: so my personal take on it… we shouldn't touch cloud-init, it should ignore anything about disabled, instead we should only have the networker set things up and have it pay attention to a new flag. | 08:56 |
| jam1 | then, while we are still on just cloud-init without a good worker, it still works | 08:56 |
| jam1 | and when we are using the worker instead, we get the better behavior | 08:56 |
| fwereade | jam1, yes, exactly | 08:57 |
| jam1 | I think cloud-init only starting some networks is going to just be a point of temporary brokeness | 08:57 |
| jam1 | brokenness ? | 08:57 |
| dimitern | fwereade, ok, so we're temporarily departing from what was important in austin - i.e. do what the user says about networks and no more, until we have the networker in place | 08:57 |
| dimitern | fwereade, fair enough, but I still want to keep the Disabled flag | 08:57 |
| jam1 | I ain't messing wit no broke broke, ya na wha I mean | 08:58 |
| jam1 | dimitern: so for me Disabled feels a bit weird, rather than having it just not be in Enabled, do we know all the potential networks that we aren't a part of yet | 08:58 |
| dimitern | fwereade, but if it wasn't clear, not disabling networks in cloudinit won't make the unit assignment logic "just work" :) until we change it to consider NICs | 08:58 |
| dimitern | jam1, maas knows all networks a machine can be on, and we expect the provider to tell us that | 08:59 |
| bigjools | potentially knows :) | 08:59 |
| dimitern | jam1, so out of these, the user picks what to enable, and we ca decide what can we deploy there | 08:59 |
| dimitern | hey bigjools ;) | 09:00 |
| bigjools | ahoy dimitern | 09:00 |
| fwereade | dimitern, the unit assignment logic *is* a pretty critical part of the model -- we have to apply that even for manual placement attempts | 09:00 |
| dimitern | ofc, maas knows if you told it | 09:00 |
| dimitern | fwereade, i agree, that's why i'm thinking of working on that as soon as we have the networker running as a MVP | 09:01 |
| fwereade | dimitern, gating that work on the networker is not optimal imo | 09:01 |
| dimitern | fwereade, until then, nothing will break that used to work before, but networking stuff might | 09:02 |
| dimitern | fwereade, well, until we have a way to configure additional nics on a running machine | 09:02 |
| dimitern | fwereade, we can only assume the networks will work or not | 09:02 |
| dimitern | fwereade, you're saying let's make them work by default, so we can wire the assignment logic? | 09:03 |
| fwereade | dimitern, yes | 09:03 |
| dimitern | fwereade, got you than :) that's possible before the networker then, sorry | 09:03 |
| fwereade | dimitern, cool, sorry I didn't explain clearly | 09:03 |
| dimitern | fwereade, you and me both i guess :) | 09:04 |
| dimitern | fwereade, re network names validation as part of constraints validation - i'm aware of the prechecker and similar things that are supposed to be useful for constraints validation, but wasn't obvious how to make it work | 09:05 |
| dimitern | fwereade, need to look some more into it, or possibly do a follow-up on that, as i suspect will blow up the PR even more | 09:06 |
| jam1 | dimitern: anyway, from a meta-perspective, adding this to the code during the middle of having it reviewed for other stuff makes it hard to see if the original questions were addressed | 09:13 |
| dimitern | jam1, hence my request to do it in a follow-up :) | 09:16 |
| jam1 | dimitern: I meant adding the Disabled stuff, but yes, the other would be true as well. | 09:16 |
| dimitern | fwereade, just to check something with you re constraints propagation | 09:25 |
| fwereade | dimitern, sure | 09:26 |
| * axw wishes you could batch comments on GitHub | 09:26 | |
| axw | so noisy | 09:26 |
| dimitern | fwereade, so if i have "networks=foo,^bar" at environ level, all services should inherit them (unless overridden at service level), and all units and machines should also inherit them (unless overridden) | 09:26 |
| dimitern | axw, oh me too! | 09:27 |
| voidspace | axw: thanks | 09:27 |
| axw | voidspace: no worries | 09:27 |
| axw | voidspace: I struggled to find an appropriate emoji to convey my feelings about this issue ;) | 09:27 |
| voidspace | axw: I thought you did very well... | 09:27 |
| dimitern | so :shit: it is :) | 09:27 |
| dimitern | fwereade, the same should be for service-level network constraints going down to units and machines | 09:28 |
| dimitern | fwereade, and i'm talking about new entities for each kind, not existing ones which might already have constraints | 09:29 |
| axw | voidspace: does that job (local-deploy-precise-amd64) just run directly on the jenkins machine? | 09:29 |
| axw | looks like it from the jenkins output | 09:29 |
| voidspace | axw: yes, it runs on the master | 09:30 |
| fwereade | dimitern, sort of -- a new machine's constraints should be immediately combined with environment constraints, and the result used to provision it | 09:30 |
| axw | mk | 09:30 |
| voidspace | axw: I'm not sure what specifically triggers a new job - it sometimes seems to take a couple of hours | 09:30 |
| voidspace | axw: but I'm not aware of it requiring manual intervention | 09:30 |
| voidspace | axw: I don't [believe I] have a login on that jenkins, so I can't manually start on | 09:31 |
| voidspace | if one hasn't run soon-ish I'll ping sinzui or abently | 09:31 |
| fwereade | dimitern, a new unit's constraints should be taken by snapshotting the combination of the current service and environment constraints | 09:31 |
| dimitern | fwereade, ok that's where i don't get it | 09:31 |
| fwereade | dimitern, when creating a new machine for that new unit, it should take exactly the constraints just calculated for its unit | 09:32 |
| dimitern | fwereade, " a new machine's constraints should be immediately combined with environment constraints" - why not the service as well? | 09:32 |
| dimitern | fwereade, i.e. when deploying the first unit of a service + netCons in an env + netCons, the new machine's cons = envCons+svcCons, no? | 09:33 |
| fwereade | dimitern, because when I say a new machine I mean the result of add-machine, not of deploy | 09:33 |
| axw | voidspace: I *do*, but only because I've been doing github things. I think it's just on a timer | 09:33 |
| dimitern | fwereade, or, alternatively machineCons = svcCons (assuming svcCons += envCons) | 09:33 |
| axw | I'm wary of kicking one off in case it buggers up the scheduling | 09:33 |
| fwereade | dimitern, when creating a machine for a specific unit, there aren't any other machine constraints -- we just take them from the unit | 09:34 |
| dimitern | fwereade, right, so if provisioning a machine just like that, not for deploying a unit | 09:34 |
| dimitern | fwereade, use the envCons, if a deployment is involved, use svcCons | 09:34 |
| fwereade | dimitern, yeah -- when provisioning a machine *not* for a unit, there's no service in the picture, just modify envCons with whatever was specified for that specific machine | 09:35 |
| dimitern | fwereade, ok, i think it's clear enough for me now, i can follow what's happening in that test | 09:35 |
| fwereade | dimitern, cool | 09:35 |
| voidspace | axw: ok | 09:36 |
| jam1 | fwereade: dimitern: I saw that you at least opened up the doc I sent about API versioning, any comments, or just haven't gotten to reading it yet | 09:43 |
| fwereade | jam1, sorry, it's in my tab queue | 09:43 |
| jam1 | np | 09:44 |
| jam1 | I fully understand | 09:44 |
| jam1 | fwereade: since you're around, shall we try to decide what actual URLs we want to connect to? | 09:51 |
| jam1 | https://host:port/ENVUUID/api | 09:51 |
| jam1 | https://host:port/environment-ENVUUID/api | 09:51 |
| jam1 | https://host:port/environment/ENVUUID/api | 09:51 |
| jam1 | concretely: "https://host:port/72e9779c-0c82-4d52-83f9-50bb594941e5/api" | 09:53 |
| jam1 | vs | 09:53 |
| jam1 | https://localhost:17070/environment-72e9779c-0c82-4d52-83f9-50bb594941e5/api | 09:53 |
| jam1 | https://localhost:17070/environment/72e9779c-0c82-4d52-83f9-50bb594941e5/api | 09:53 |
| * c7z votes first or third | 09:53 | |
| * TheMue too | 09:53 | |
| TheMue | jam1: to be more special, more for the third than the first | 09:54 |
| jam1 | its a SMOP, but we should decide before it lands | 09:54 |
| jam1 | TheMue: I think you mean "more specific", but sure | 09:54 |
| jam1 | to go with | 09:54 |
| TheMue | iiirks, eh, yes | 09:54 |
| jam1 | https://localhost:17070/environment/72e9779c-0c82-4d52-83f9-50bb594941e5/apilog | 09:54 |
| jam1 | https://localhost:17070/environment/72e9779c-0c82-4d52-83f9-50bb594941e5/api/log | 09:54 |
| jam1 | ugh | 09:54 |
| jam1 | stupid thing refuses to let me edit in place | 09:55 |
| jam1 | https://localhost:17070/environment/72e9779c-0c82-4d52-83f9-50bb594941e5/log | 09:55 |
| jam1 | https://localhost:17070/environment/72e9779c-0c82-4d52-83f9-50bb594941e5/charms | 09:55 |
| jam1 | and presumably what URL would we connect to when we are dealing with creating a new environment, /? /environment/ /api? | 09:55 |
| c7z | if we'll never need to serve other endpoints, first is better. third gives room for doing non-env specific things from the same server | 09:56 |
| === vladk is now known as vladk|offline | ||
| axw | also gives us a nice URL for listing environment UUIDs | 09:57 |
| axw | https://localhost:17070/environment/ | 09:57 |
| axw | that is | 09:57 |
| dimitern | jam1, haven't have time to read it, will do | 10:00 |
| === vladk|offline is now known as vladk | ||
| frankban | mgz: morning, does the CI lander handle changes to dependencies.tsv in the new git world? Or should we keep asking you to update/install packages? | 10:22 |
| voidspace | alexisb: ping | 10:25 |
| natefinch | voidspace: 3:30am her time right now, probably not awake :) | 10:26 |
| voidspace | natefinch: hah, thanks | 10:26 |
| voidspace | natefinch: do you know if we still have open headcount? | 10:27 |
| voidspace | natefinch: this position is still being advertised: | 10:27 |
| voidspace | https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=830 | 10:27 |
| natefinch | voidspace: we have one open spot with at least one person who we are working on given an offer.. however, there's a couple other related openings in related teams | 10:27 |
| voidspace | natefinch: cool | 10:29 |
| voidspace | thanks | 10:29 |
| axw | mgz: can you please fix https://github.com/juju/juju/pull/8 (or tell me how to) | 10:30 |
| axw | mgz: never mind, figured it out. just had to add "Build failed: " | 10:46 |
| === vladk is now known as vladk|offline | ||
| perrito666 | ok bbiab | 10:46 |
| voidspace | how do I get a test suite with a replica set? | 10:46 |
| voidspace | I think we have some tests that do that | 10:46 |
| dimitern | natefinch, voidspace, isn't "juju engineering" the solutions / ci / ecosystem team? | 10:47 |
| voidspace | dimitern: heh, I don't know | 10:47 |
| dimitern | natefinch, voidspace, (just looking at that open position) | 10:47 |
| dimitern | ah, ok | 10:47 |
| jam1 | dimitern: I think you are thinking "Juju Solutions" ? | 10:48 |
| dimitern | jam1, i'm confused with so many vaguely similarly sounding teams :) - the taleo offer there is for juju eng. | 10:49 |
| jam1 | I thought there was a Juju Engineering team, but I don't see it in directory | 10:49 |
| jam1 | yeah | 10:49 |
| c7z | axw: yeah, that's it. you can also hit rebuild on the job in jenkins | 10:50 |
| natefinch | It's pretty bad that people on the Juju team don't understand the job description on our jobs page :/ | 10:50 |
| natefinch | I'm pretty sure that job that voidspace linked to is for juju core. | 10:51 |
| c7z | axw: (sorry, missed ping, I blame cow-orking) | 10:51 |
| natefinch | but it goes to alexis, and she's driving a couple other positions as well | 10:51 |
| jam1 | natefinch: voidspace: the original link https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=830 is, indeed, for juju-core, we currently have 2 more slots though I think we're already trying to give a couple people offers | 10:52 |
| dimitern | c7z, you're taking pictures of cows? :) | 10:52 |
| dimitern | TIL: http://www.urbandictionary.com/define.php?term=orking | 10:52 |
| voidspace | jam1: cool. I've had a random-but-seemingly-good person email me. I've sent them that link and told them to apply anyway. | 10:55 |
| voidspace | jam1: we have one very good new person starting on Monday. | 10:55 |
| jam1 | voidspace: IIRC we have a couple more openings in related projects like JaaS, etc. so we still have a few | 10:55 |
| voidspace | jam1: do you know which team he will be joining? | 10:55 |
| jam1 | voidspace: I think it is still being sorted out | 10:55 |
| jam1 | you mean Eric, right? | 10:55 |
| voidspace | yes | 10:55 |
| voidspace | he should join natefinch's team... | 10:56 |
| natefinch | voidspace: I think he is | 10:56 |
| voidspace | awesome :-) | 10:56 |
| alexisb | voidspace, pong | 10:57 |
| voidspace | alexisb: no problem - all sorted | 10:57 |
| voidspace | alexisb: I had someone contact me asking about open positions | 10:58 |
| alexisb | voidspace, ack | 10:58 |
| voidspace | alexisb: I've told them to just apply... | 10:58 |
| === vladk|offline is now known as vladk | ||
| jam1 | dimitern: since your on-call-reviewer today anyway https://github.com/juju/juju/pull/26 | 11:04 |
| dimitern | jam1, sure, looking | 11:05 |
| jam | just realized, github doesn't do anything with the concept of "prerequisites" does it? | 11:10 |
| jam | to break up a bunch of changes into reviewable chunks. | 11:10 |
| jam | Is the only chance to rebase and break it into just tiny patches? | 11:10 |
| jam | c7z: ^^ | 11:11 |
| c7z | yeah, I didn't find anything as an analogue | 11:12 |
| jam | you could create PRs chaining one into the other one, but it wouldn't show up on the main queue, I think | 11:12 |
| c7z | indeed | 11:13 |
| === vladk is now known as vladk|offline | ||
| dimitern | jam, reviewed | 11:48 |
| jam | thx | 11:52 |
| wallyworld_ | mgz: still in other meeting, will ping soon | 12:01 |
| perrito666 | rogpeppe: ping_ | 12:05 |
| rogpeppe | perrito666: pong | 12:05 |
| === vladk|offline is now known as vladk | ||
| vladk | dimitern: please, take a look https://github.com/juju/juju/pull/16 | 12:07 |
| dimitern | vladk, looking | 12:10 |
| dimitern | vladk, reviewed | 12:19 |
| vladk | dimitern: thanks | 12:19 |
| vladk | dimitern: how to understand 'd' in the last comment? | 12:22 |
| dimitern | vladk, d="delete this line" :) | 12:22 |
| dimitern | it's a common shortcut | 12:22 |
| vladk | dimitern: when I fix all, how to kick the bot? | 12:24 |
| jam | vladk: you should push and then comment $$merge$$ | 12:27 |
| vladk | jam: thx, I wasn't sure I have such right | 12:28 |
| dimitern | vladk, but before that, please rebase most of these changes to squash them into one | 12:30 |
| dimitern | vladk, or a few | 12:30 |
| sinzui | voidspace, axw. https://docs.google.com/a/canonical.com/document/d/1ZQIJL2YNAYpDHDO4g3kwcq8tHTR8ax6L15xhAXELngc/edit#heading=h.f3goroun9jd1 | 12:32 |
| sinzui | ^ ci-director looks for new revs, triggers a build of the tarball, which causes a cascade of other bugs to run as resources come available | 12:33 |
| sinzui | git-merge is similar. (which is not ideal because branch merging should not be in resource contention with CI) | 12:34 |
| dimitern | fwereade, is there a particular reason state.Unit.constraints to be unexported? | 12:37 |
| voidspace | sinzui: thanks | 12:37 |
| voidspace | sinzui: I will read and digest | 12:37 |
| voidspace | sinzui: so that build is currently "waiting on resources" | 12:37 |
| voidspace | given that there are new revisions | 12:37 |
| sinzui | oh, CI is idle, I think almost 90% of resources are available | 12:38 |
| * sinzui investigates | 12:38 | |
| voidspace | that's a really useful document though, thanks | 12:38 |
| * TheMue is AFK for a moment | 12:38 | |
| voidspace | it will be useful to actually understand our CI infrastructure | 12:38 |
| voidspace | but for no | 12:39 |
| voidspace | *now | 12:39 |
| * voidspace lunches | 12:39 | |
| * sinzui fixes script blocking CI | 12:40 | |
| bodie_ | morning all! | 12:41 |
| === vladk is now known as vladk|offline | ||
| fwereade | dimitern, yes, because they're nobody's business but state's -- it just uses them to put the unit on a suitable machine | 13:00 |
| fwereade | dimitern, be it one whose HCs match, or a new one which gets the constraints copied straight over from the unit | 13:00 |
| fwereade | bodie_, morning :) | 13:02 |
| jam | fwereade: overloading methods that don't match the exposure rules falls pretty much into "spooky action at a distance"/side-effect programming. | 13:06 |
| fwereade | jam, yeah, I know, it *is* horrible, it's just that the other one is uglier to look at | 13:07 |
| jam | fwereade: yeah | 13:07 |
| jam | fwereade: hence why it wasn't a clear "do it this way" | 13:07 |
| jam | fwereade: we *can* do the nested embedding until the embedding is too deep and we just copy the whole thing | 13:08 |
| fwereade | jam, now I think of it, I realise that when I say "I'm not sure this is horrible or brilliant" I'm actually saying "this is horrible, independent of any brilliance it may also exhibit" ;p | 13:08 |
| dimitern | fwereade, yeah, but in this case I need them | 13:08 |
| dimitern | fwereade, do you mind exporting it? | 13:08 |
| jam | fwereade: :) | 13:08 |
| fwereade | dimitern, remind me exactly what for? | 13:08 |
| fwereade | dimitern, I might mind a bit | 13:09 |
| dimitern | fwereade, for this special case deploy --to lxc:<mid> --constraints networks=good,^bad | 13:09 |
| bodie_ | fwereade, mgz thought I should ping you about whether we want to have the Actions schema be a member of the Charm documents in State, or have its own collection, e.g. CharmActionSchemas | 13:09 |
| bodie_ | since altering the document could impact juju upgrades | 13:10 |
| fwereade | bodie_, I don't think action schemas vary independently of charms so I'm inclined to keep it in there | 13:10 |
| dimitern | fwereade, we create a dirty container to deploy the unit on, but since it's dirty the unit assignment logic bypassed | 13:10 |
| fwereade | bodie_, old charms will just deserialise it out to a nil actions, right? | 13:10 |
| bodie_ | hmmmm | 13:11 |
| fwereade | dimitern, is there any particular reason we can't just hook into the existing logic to create that container pre-loaded with the unit, just as we do when creating a new environ machine? | 13:12 |
| bodie_ | I think it'll come back empty since we're using omitempty -- we were having an issue with testing where a nonexistent actions.yaml was coming back with an empty Actions (a la Config) but it was being deserialized into a nil value | 13:12 |
| fwereade | bodie_, and that's just on the doc, so any Actions() method can just return an empty one | 13:12 |
| bodie_ | I have to admit I'm not totally clear on how the bson tags work | 13:12 |
| bodie_ | yeah | 13:13 |
| fwereade | dimitern, it feels like it's an oversight in the assignment logic in state, which is in danger of slipping out over the boundaries of that package | 13:13 |
| bodie_ | if anyone has a minute, I could use a sanity check here: https://github.com/binary132/juju/blob/charm-interface-actions-fix-interface-stripper/charm/actions.go#L79 | 13:13 |
| bodie_ | this function LOOKS like it should work correctly, but my tests think otherwise | 13:14 |
| axw | sinzui: would it be okay for me to get on the Jenkins machine and manually test the local provider at some stage? I'd like to see if we can get to the bottom of the HA thing, because it's going to be a PITA if we have to carry this code around forever | 13:14 |
| bodie_ | specifically, I'm getting an inner map[interface{}]interface{} | 13:15 |
| sinzui | axw you sure can. You will need to be mindful of http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/ | 13:16 |
| sinzui | axw, you can disable it if you need | 13:16 |
| dimitern | fwereade, well, there are a couple of state.Assign*() methods that can be used there instead, but not quite the same | 13:16 |
| axw | sinzui: thanks, I will probably disable it while I'm testing | 13:16 |
| dimitern | fwereade, first, in DeployService some trickery is done to "Create the new machine marked as dirty so that nothing else will grab it before we assign the unit to it" | 13:17 |
| axw | (not tonight tho, maybe tomorrow) | 13:17 |
| fwereade | dimitern, I guess what I'm asking is "why is there no AssignToNewContainer?" | 13:18 |
| dimitern | fwereade, there is AssignToNewMachineOrContainer | 13:18 |
| fwereade | dimitern, that sounds like a horrible hack plastered on at a different level to all the rest of the assignment stuff | 13:18 |
| dimitern | fwereade, which decides to use a container only if it's specified in the constraints | 13:18 |
| fwereade | dimitern, sorry not ATNMOC itself | 13:18 |
| fwereade | dimitern, how hard would it be to put that functionality into a new state method? | 13:19 |
| fwereade | dimitern, I'm really not keen on exposing internals to do calculations that should be done internally but which we just happen not to | 13:19 |
| dimitern | fwereade, I guess instead of that hack we can use AssignToNewMachine there, assuming the dirty flag not being set is ok and also we change ATNM to take containerType and use it if not empty, rather than relying on checking constraints | 13:22 |
| fwereade | dimitern, I suspect it needs a bit more analysis -- I suspect that breaking down the methods we expose by the use cases we have at that layer may be moreprofitable than overloading existing methods | 13:25 |
| fwereade | dimitern, wait, deploy --to with --constraints as well? | 13:25 |
| fwereade | dimitern, ah deploy --to directive not machine-id | 13:26 |
| === vladk|offline is now known as vladk | ||
| dimitern | fwereade, deploy --to lxc:XXX and --constraints networks=... specifically | 13:28 |
| bodie_ | this is weird | 13:30 |
| bodie_ | it's WORKING here | 13:30 |
| bodie_ | http://play.golang.org/p/MZ-3jwPZra | 13:30 |
| bodie_ | so I have to assume there's something wrong either with my test case, or with how I'm handling the values | 13:30 |
| * perrito666 sees a thread arrive to a length that makes it easier to actually do a pdf and read it in a kindle | 13:40 | |
| bodie_ | oh, cmon... the problem was a minor logical bug in my main loop | 13:41 |
| bodie_ | sigh | 13:41 |
| bodie_ | I have yet to learn the universal truth that IT'S ALWAYS SOMETHING DUMB! | 13:41 |
| perrito666 | sweet, my git vim plugin is useful again | 13:49 |
| perrito666 | natefinch: voidspace wwitzel3 at this point I am no longer sure if we stand up or not :p | 13:50 |
| natefinch | perrito666:let's stand up | 14:00 |
| natefinch | ^^ wwitzel3 voidspace | 14:02 |
| voidspace | ok | 14:03 |
| jam | dimitern: rogpeppe: I updated the proposal, sorry I didn't "lbox propose " the previous one where I had responded to your review questions, it should also be updated now if you want to read direct responses to your original requests | 14:04 |
| rogpeppe | jam: thanks | 14:04 |
| rogpeppe | jam: i've just responded to one of the responses | 14:05 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| bodie_ | okay, so let's say I want to rebase -i my noisy commits into something useful, but not overwrite the history of my existing branch | 14:18 |
| jam | rogpeppe: "/" is explicitly special | 14:18 |
| bodie_ | would I want to checkout -b a new branch, rebase in there, and then cherry-pick the combined commit into the feature branch, for example? | 14:18 |
| vladk | jam. fwereade, dimitern: I've got an error in the end of bot log in lander-merge-result. What to do? | 14:19 |
| vladk | http://juju-ci.vapour.ws:8080/job/github-merge-juju/24/consoleFull | 14:19 |
| rogpeppe | jam: really? i couldn't divine that from the docs | 14:19 |
| rogpeppe | jam: but if experiment bears you out, that should be ok (apart from the fact that you won't get a JSON error) | 14:19 |
| jcw4 | bodie_: what is the benefit of keeping your local branch history? | 14:20 |
| jam | rogpeppe: https://github.com/juju/juju/pull/26/files#diff-37b85f678233dbf691a5813acd25d6d9R217 | 14:20 |
| bodie_ | https://github.com/EugeneKay/git-jokes/blob/lulz/Jokes.txt | 14:21 |
| jam | rogpeppe: I did add an explicit test for connecting to random paths and have it fail | 14:21 |
| bodie_ | jcw4 -- I have it on my github repo as well | 14:21 |
| jam | vladk: I haven't seen that error before. It looks like a bug in the landing script | 14:21 |
| dimitern | mgz, c7z, it looks like some script on jujubot fails for vladk http://juju-ci.vapour.ws:8080/job/github-merge-juju/24/consoleFull | 14:21 |
| jam | so you could try voting "$$MERGE$$" again | 14:21 |
| jcw4 | bodie_: is there a specific line that I should read? | 14:21 |
| jam | or you could poke c7z and/or wallyworld_ etc | 14:22 |
| bodie_ | heh, no, just found some funnies at #git | 14:22 |
| c7z | dimitern: looking | 14:22 |
| jcw4 | bodie_: oh, it wasn't an answer to my question... sorry :) | 14:22 |
| c7z | vladk: yeah, awx hit that as well, but I'm not sure if he worked out *why* it happened | 14:23 |
| c7z | I'll add some debugging and requeue | 14:24 |
| bodie_ | jcw4, the answer was that my remote has the history, so I don't like overwriting existing server-side truth | 14:24 |
| voidspace | so, charm hooks can be "any executable" | 14:26 |
| voidspace | so long as those executables run on every platform juju supports, right? | 14:26 |
| jcw4 | bodie_: I'll have to explore a bit, but I'm not really considering my personal repo on github to be server-side truth at this point... If no-one is cloning my personal repo it feels more like a sandbox to me. | 14:26 |
| bodie_ | jcw4, in case mgz doesn't see #jujuskunkworks, I have to get moving in 30-60 minutes here to spend the day with family since they're leaving saturday -- I'll be working sat | 14:27 |
| c7z | bodie_: thanks (I'm mgz for today) | 14:27 |
| rogpeppe | jam: thanks - it looks like the docs should be a little better there | 14:27 |
| jcw4 | bodie_: yep, I saw that... hi mgz/c7z | 14:27 |
| jcw4 | c7z: upgrade from gzip to 7zip? | 14:28 |
| c7z | sidegrade :) | 14:28 |
| jcw4 | hehe | 14:28 |
| mattyw | natefinch, rogpeppe <- I'm picking you two at random - congratulations! Can you point me in the direction of someone who can answer some questions about the unit tests in core? Specifically I'd like to know how you use testing.RunCommand to test long-running services (if you do) | 14:36 |
| natefinch | mattyw: define long-running? | 14:37 |
| * rogpeppe goes to look at testing.RunCommand | 14:37 | |
| * natefinch does too | 14:37 | |
| voidspace | natefinch: I can get the session back out of the state with state.MongoSession() | 14:37 |
| natefinch | voidspace: that sounds good | 14:38 |
| rogpeppe | mattyw: RunCommand isn't for that | 14:38 |
| voidspace | natefinch: so I have tests that I think are now testing the right thing | 14:39 |
| voidspace | however they panic - but they don't fail! | 14:39 |
| rogpeppe | mattyw: it's really for testing short running Commands | 14:39 |
| mattyw | rogpeppe, what about things like the machine and unit agents? | 14:40 |
| rogpeppe | mattyw: for testing a long running command, i'd usually test it directly (testing.RunCommand really doesn't add much tbh) | 14:40 |
| voidspace | natefinch: and now they pass... | 14:40 |
| mattyw | rogpeppe, just compile and run the binary via cmd.exec? | 14:41 |
| voidspace | natefinch: WMode not set without replSet, it is set with replSet | 14:41 |
| rogpeppe | mattyw: if you look at how they're done, they instantiate the Command directly and there's a tomb in there that's used to tear down the command | 14:41 |
| natefinch | voidspace: awesome | 14:42 |
| perrito666 | hay guys, any of you is working ona virtualized ubuntu on osx? | 14:43 |
| mattyw | rogpeppe, I was looking for that kind of thing yesterday but couldn't see where that was going on - I'll have anther look | 14:43 |
| stokachu | sinzui, hi could you take another look at 1307434 | 14:43 |
| rogpeppe | mattyw: see MachineSuite.TestRunStop for a simple example | 14:44 |
| jcw4 | perrito666: sometimes... what are you seeing? | 14:44 |
| stokachu | sinzui, was hoping to get that included in the next-stable | 14:44 |
| * sinzui looks | 14:44 | |
| perrito666 | jcw4: well my current work computer does not support ram upgrading and its falling a bit short, so I noticed my mac has enough ram for both oses and Was wondering if dual booting or virtual in terms of having enough ram to compile | 14:45 |
| jcw4 | perrito666: I found that on my macbookpro with 14.04 in a virtualbox vm with 2 cores assigned and 4GB of ram that it worked very well | 14:46 |
| mattyw | rogpeppe, perfect, thanks for the pointers | 14:46 |
| mattyw | rogpeppe, you're a top bloke and no mistake | 14:47 |
| rogpeppe | mattyw: bet you say that to all the boys | 14:47 |
| jcw4 | perrito666: my bottleneck was disk I/O, but even that wasn't too bad | 14:47 |
| sinzui | stokachu, it is to be fixed in the next release (one-two weeks), where as next-stable (1.20) is more than one release away | 14:48 |
| jcw4 | perrito666: if you have an SSD it might not even be a problem | 14:48 |
| mattyw | rogpeppe, however I answer that it's going to be awkward | 14:48 |
| rogpeppe | mattyw: orly? :-) | 14:48 |
| stokachu | sinzui, ah ok | 14:48 |
| perrito666 | jcw4: tx, Ill take a look | 14:49 |
| stokachu | sinzui, is there a name being used for next point release? | 14:49 |
| voidspace | fwereade: testing the setting of write-majority turned out to be very easy | 14:49 |
| sinzui | stokachu, regardless of those two releases, if the fix does not require lots of new code, we can backport to 1.18.5 (because we don't think 1.120 will arrive soone enough) | 14:50 |
| stokachu | sinzui, ok sounds good | 14:50 |
| sinzui | stokachu, next-stable will be named 1.20.0 when the day comes | 14:50 |
| bodie_ | c7z, so am I making a new PR using my feature branch? I assume the other PR has now been closed | 14:51 |
| dimitern | jam, fwereade, can I get an LGTM on https://github.com/juju/juju/pull/13 ? | 14:51 |
| bodie_ | but, I got an email saying the bot had merged it | 14:51 |
| bodie_ | which confused the heck out of me... | 14:51 |
| c7z | O_O | 14:51 |
| c7z | bodie_: looking at the pr, and the revision linked, <https://github.com/juju/juju/pull/15> | 14:56 |
| c7z | looks like github just got confused when you (correctly) reverted your master branch back to be a mirror of upstream | 14:56 |
| c7z | bodie_: so, no harm done, carry on | 14:56 |
| c7z | and you can go ahead and repropose | 14:56 |
| bodie_ | OK, cool | 14:57 |
| bodie_ | I don't have a lot added, but I did ping fwereade about the question of charms in state | 14:57 |
| c7z | ace | 14:57 |
| bodie_ | or, uh, Actions docs in state.Charm | 14:57 |
| bodie_ | my understanding is that it won't be a breaking change to add Actions to Charm docs | 14:57 |
| bodie_ | since Actions will only change in step with changes to the Charm | 14:58 |
| fwereade | voidspace, if it's truly horrible I can accept a non-unit-tested writeconcern | 14:58 |
| fwereade | voidspace, but please record a bug as well | 14:58 |
| voidspace | fwereade: I said it *is* easy | 14:59 |
| voidspace | fwereade: have a look https://github.com/juju/juju/pull/17 | 14:59 |
| fwereade | voidspace, ah! cool | 14:59 |
| fwereade | voidspace, I have clearly lost the ability to read :/ | 14:59 |
| voidspace | heh | 14:59 |
| voidspace | you don't need it much | 15:00 |
| rogpeppe | frankban, dimitern, anyone else: huge but trivial PR - https://github.com/juju/juju/pull/28/files | 15:00 |
| rogpeppe | it factors utils out of juju core | 15:00 |
| dimitern | rogpeppe, is it just a mechanical change? | 15:03 |
| rogpeppe | dimitern: yup | 15:03 |
| dimitern | rogpeppe, right, LGTM then | 15:03 |
| rogpeppe | dimitern: thanks | 15:03 |
| voidspace | fwereade: I understand what you mean about MongoSession | 15:05 |
| voidspace | fwereade: it happens to be really useful for this test... (And of course was pre-existing this mp.) | 15:06 |
| voidspace | fwereade: it's only used in a few places, shouldn't be hard to resolve those specific use-cases one by one | 15:06 |
| fwereade | voidspace, if you happen to notice opportunities to drive-by them, I heartily endorse any and all such efforts | 15:07 |
| voidspace | fwereade: cool | 15:08 |
| hackedbellini | hi guys, | 15:08 |
| hackedbellini | I'm having some problems on my juju installation using lxc. hazmat told me that you can probably help me here | 15:08 |
| hackedbellini | The problem started when I did a "juju upgrade-juju" and it went from 1.18.x to 1.19.2 (it shouldn't since 1.19.x is not a stable version, but this is another issue) | 15:08 |
| hackedbellini | Now all my machines/units are spamming this on the log: http://pastebin.ubuntu.com/7573901/ (their agent-state is "down") | 15:08 |
| hazmat | basically his agents don't know where the api servers are | 15:10 |
| hazmat | this was post an accidental upgrade from 1.18 to 1.19 (unclear how that happened, no flags, pkg version, bug filed) | 15:11 |
| hazmat | when it was trying to go from 1.18.1 to 1.18.3 | 15:11 |
| hackedbellini | also, since I'm already on a development version, I wish to upgrade it (since we are having a problem on 1.19.2 already fixed on 1.19.3), but when I try to "juju upgrade-juju" it says: ERROR no more recent supported versions available | 15:11 |
| hackedbellini | I even tried with juju upgrade-juju --version 1.19.3, but this was the result: http://pastebin.ubuntu.com/7595390/ | 15:11 |
| hazmat | natefinch, ^ any ideas on how stateServers api addresses could go to empty? | 15:11 |
| rogpeppe | how do we track the progress of a commit that's being merged? | 15:12 |
| hazmat | hackedbellini, can you pastebin one of the agent confs on one of the agents thats not connecting/spinning | 15:12 |
| voidspace | the good news is that CI is running again | 15:12 |
| voidspace | the bad news is that the local-deploy-precise-amd64 job is still failing :-/ | 15:12 |
| hazmat | hackedbellini, curious to see what it has recorded for its state server addresses | 15:13 |
| voidspace | Exception: Timed out waiting for juju status to succeed: Command '('juju', '--show-log', 'status', '-e', 'local-deploy-precise-amd64')' returned non-zero exit status 1 | 15:13 |
| voidspace | Ah no, the real error is still: | 15:13 |
| voidspace | 2014-06-05 14:23:13 ERROR juju.cmd supercommand.go:308 cannot initiate replica set: Closed explicitly | 15:13 |
| voidspace | let's see what revision it is running, it shouldn't be trying to create a replica set if it's using master HEAD | 15:14 |
| hackedbellini | hazmat: yes I can. Just give me a minute, I need to ask someone with sudo powers to read it for me | 15:14 |
| natefinch | hazmat: I wonder if that's a problem with the HA upgrades that we did.... obviously upgrading from 18 to 19 is a huge bug, but it should still *work* | 15:14 |
| natefinch | hazmat: s/HA upgrades/HA modifications/ | 15:15 |
| voidspace | ah, the last revision it ran was one from 21 hours ago | 15:15 |
| voidspace | in fact, it has run that revision 5 times | 15:15 |
| voidspace | sinzui: local-deploy-precise-amd64 ran a bunch of times with some old revisions | 15:16 |
| sinzui | yeah, it was trying to finish the stalled revision under test | 15:18 |
| bodie_ | do I need to rebase my feature branch onto master before proposing? | 15:18 |
| rogpeppe | natefinch, sinzui: is it possible track the progress of a commit that's being merged? | 15:20 |
| hackedbellini | hazmat: oh, kiki took the conf from it's own .juju instead of the juju user. He went feed the dog and he will be back soon. Then I can show the conf | 15:21 |
| hackedbellini | in the mean time, he asked me to ask you if this is right: http://pastebin.ubuntu.com/7595448/ | 15:21 |
| hackedbellini | this is the contents of .juju/local | 15:21 |
| hackedbellini | is it right for all those directories be property of root? | 15:21 |
| rogpeppe | natefinch: ISTR seeing someone say it was, but i can't seem to find that info | 15:21 |
| sinzui | rogpeppe, some, but not all tests report the branch and revision under test | 15:21 |
| rogpeppe | sinzui: where can i see that? | 15:21 |
| rogpeppe | sinzui: i'm kind of expecting some comment on the PR eventually | 15:21 |
| sinzui | rogpeppe, the test that voidspace is looking at has http://juju-ci.vapour.ws:8080/job/local-deploy-precise-amd64/ | 15:22 |
| sinzui | the info in the build history | 15:22 |
| perrito666 | ha guys, could you take a look at this? the peergrouper section is to be credited to rogpeppe https://github.com/perrito666/juju/blob/update_HA_doc/doc/high_availability.md | 15:22 |
| voidspace | rogpeppe: once the pr is merged you get a comment from jujubot | 15:22 |
| rogpeppe | sinzui: so is it possible to find out if the 'bot has actually seen my commit? | 15:22 |
| sinzui | rogpeppe, we don't have a way to saw how many revisions trunk is ahead of CI | 15:22 |
| sinzui | yes... | 15:22 |
| * sinzui thinks | 15:23 | |
| rogpeppe | sinzui: i'm not sure i've got the format of my commit message right | 15:23 |
| voidspace | rogpeppe: $$merge$$ | 15:23 |
| voidspace | rogpeppe: as a comment on the pr, not the commit message | 15:23 |
| sinzui | rogpeppe, http://juju-ci.vapour.ws:8080/job/github-merge-juju/ | 15:23 |
| rogpeppe | voidspace: i *think* i used that | 15:23 |
| voidspace | heh | 15:23 |
| sinzui | ^ I think the branch name is listed as of today | 15:23 |
| voidspace | rogpeppe: you should get a comment from the jujubot within 30 seconds | 15:23 |
| voidspace | rogpeppe: so if there's no comment, it hasn't been seen | 15:23 |
| rogpeppe | sinzui: what should i look at in that page? | 15:24 |
| rogpeppe | sinzui: (and is that http address stable?) | 15:24 |
| sinzui | rogpeppe, build history | 15:24 |
| sinzui | rogpeppe, yes, the address is stable | 15:24 |
| voidspace | rogpeppe: see the comments here for example https://github.com/juju/juju/pull/17 | 15:24 |
| rogpeppe | hmm, still no comment | 15:25 |
| rogpeppe | i'm looking at https://github.com/juju/juju/pull/28 | 15:25 |
| bodie_ | https://github.com/juju/juju/pull/29 | 15:26 |
| bodie_ | woop woop! | 15:26 |
| rogpeppe | sinzui: so in http://juju-ci.vapour.ws:8080/job/github-merge-juju/, i see build #25 flashing, but nothing to indicate what it might be working on | 15:26 |
| bodie_ | c7z/mgz, let me know how that looks to you | 15:26 |
| voidspace | rogpeppe: comment looks good to me, but the juju bot hasn't noticed it | 15:26 |
| rogpeppe | voidspace: ok | 15:26 |
| voidspace | mgz: ^ | 15:26 |
| voidspace | mgz: https://github.com/juju/juju/pull/17 | 15:27 |
| voidspace | mgz: jujubot doesn't seem to have noticed the magic-merge-message | 15:27 |
| voidspace | mgz: gah, wrong url | 15:27 |
| voidspace | mgz: https://github.com/juju/juju/pull/28 | 15:27 |
| bodie_ | fwereade, PR opened for charm interface actions -- https://github.com/juju/juju/pull/29 -- feedback appreciated! | 15:27 |
| c7z | rogpeppe: not sure why the bot hates you | 15:31 |
| c7z | I'll find out | 15:31 |
| c7z | bodie_: looks good, thanks! | 15:32 |
| rogpeppe | sinzui: it seems wrong that the 'bot tries the tests several times on failure | 15:32 |
| c7z | rogpeppe: write better tests then :P | 15:32 |
| rogpeppe | sinzui: that means that if you get something trivial wrong, it delays everything a lot | 15:32 |
| c7z | (we still have issues with tests that aren't reliable when run conccurently) | 15:33 |
| rogpeppe | c7z: i'm looking at http://juju-ci.vapour.ws:8080/job/github-merge-juju/25/consoleFull | 15:33 |
| c7z | it will exit out earlier when it's a build or check-catchable issue | 15:33 |
| sinzui | rogpeppe, It does because ec2 can fail. We see several failures each week because the mirrors are stale | 15:33 |
| natefinch | rogpeppe: is your membership public in juju? | 15:33 |
| bodie_ | c7z, woot | 15:33 |
| rogpeppe | natefinch: i've no idea | 15:33 |
| rogpeppe | natefinch: what does that mean? | 15:33 |
| natefinch | https://github.com/orgs/juju/members?page=2 | 15:33 |
| natefinch | set yourself to public | 15:34 |
| c7z | rogpeppe: it's not, that's it | 15:34 |
| sinzui | rogpeppe, but we all agree tests and test environment should be 100% repliabe | 15:34 |
| natefinch | I don't know what it means | 15:34 |
| c7z | good call nate | 15:34 |
| natefinch | but you need to be publicx | 15:34 |
| sinzui | mgz, http://juju-ci.vapour.ws:8080/job/github-merge-juju/24/console implies the tests pass, the the handoff of the result failed | 15:34 |
| rogpeppe | natefinch: ah, that's probably the reason | 15:34 |
| voidspace | natefinch: I need to pick something new | 15:36 |
| c7z | sinzui: yah, I'm debugging that | 15:36 |
| voidspace | natefinch: our lane is sparse | 15:36 |
| c7z | I will also in the script merge make sure that kind of thing comes up red | 15:36 |
| natefinch | voidspace: getting you something... | 15:37 |
| jam | voidspace: given our history with --relpSet and Precise, is your new test going to fail running the test suite on Precise ? | 15:38 |
| voidspace | jam: hah! | 15:38 |
| voidspace | jam: I *really* hope not | 15:38 |
| voidspace | jam: however, the test that was failing was the deploy test - not the test suite | 15:38 |
| voidspace | jam: and we have other tests that use replSet too | 15:38 |
| hackedbellini | hazmat: here is the conf: http://pastebin.ubuntu.com/7595574/ (I removed some possible private information and marked them as <removed> | 15:41 |
| jcw4 | c7z: to write private tests, I need to be in the same package right? | 15:46 |
| jcw4 | c7z: so can I access the state_test package somehow from state package? | 15:46 |
| jcw4 | c7z: normal imports don't seem to work very well | 15:46 |
| c7z | sorry, that sounds backwards | 15:47 |
| jcw4 | :) | 15:47 |
| jam1 | jcw4: non test code should never import test code | 15:47 |
| jcw4 | c7z: I want to test private functions in state package | 15:47 |
| jcw4 | jam1: agreed | 15:47 |
| c7z | if you have state_test, you need to import state, and any objects you need in testing must either be Public, or aliased public in an export_test.go file | 15:47 |
| jam1 | jcw4: i missed context, is there something you need help sorting out? | 15:48 |
| jcw4 | jam1: want to test private functions in state package | 15:48 |
| jcw4 | to date, my tests for state have been in state_test | 15:48 |
| jam1 | jcw4: either create a state_internal_test.go with package "state" at the top, or use export_test.go to expose the private things only in the test suite. | 15:49 |
| jam1 | we've generally gone with export_test route | 15:49 |
| jam1 | you should have plenty of examples | 15:49 |
| jcw4 | jam1: I think export_test is what I'm looking for... thanks! | 15:49 |
| jam1 | var MadePublic = madePublic | 15:49 |
| jam1 | is a pretty common pattern | 15:49 |
| jam1 | then it is available as "state.MadePublic" only in the test suite | 15:50 |
| jcw4 | jam1: makes a lot of sense! cool. | 15:50 |
| * natefinch twitches a little at export_test | 15:53 | |
| jcw4 | natefinch: why you no like? | 15:55 |
| voidspace | natefinch: shall I pick up "add ability to set state server's state to down for maintenance"? | 15:56 |
| natefinch | voidspace: sounds good | 15:56 |
| voidspace | natefinch: all the others are backup related and need orchestrating - probably sequentially | 15:57 |
| voidspace | natefinch: what do we want it to do? | 15:57 |
| natefinch | jcw4: for one, it's unnecessarily complex when you can just put the test in the same package and test the function directly | 15:57 |
| voidspace | natefinch: by "turn off the api" do we mean that all subsequent calls will error with a useful error code/message? | 15:57 |
| voidspace | natefinch: and if the api is off, how can it be turned on again | 15:58 |
| natefinch | voidspace: I'm making this stuff up as I go along :) | 15:58 |
| voidspace | natefinch: should we ensure it is safe to stop mongo once the status has been set | 15:58 |
| voidspace | natefinch: hehe, great | 15:58 |
| voidspace | natefinch: is there anywhere else the status can/should be visible *other* than via the api? | 15:59 |
| natefinch | voidspace: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.wjndmqkw7j22 | 15:59 |
| voidspace | natefinch: ok, reading - thanks | 15:59 |
| natefinch | voidspace: there's not a ton of detail, maybe fwereade has ideas | 15:59 |
| natefinch | (re backup and restore) | 16:00 |
| natefinch | jcw4: I also don't like that now your tests are referencing a function that looks like it is exported from the package, but is not, outside of test time | 16:01 |
| perrito666 | ptal https://github.com/juju/juju/pull/30 | 16:01 |
| natefinch | markdown is so nice | 16:03 |
| perrito666 | natefinch: not really, but the rendered result is | 16:03 |
| perrito666 | :p | 16:03 |
| natefinch | perrito666: better than html... or most alternatives | 16:04 |
| perrito666 | natefinch: true | 16:04 |
| === vladk is now known as vladk|offline | ||
| alexisb | mgz, fwereade: no one was on the actions call | 16:11 |
| alexisb | was it canceled for today? | 16:11 |
| alexisb | bodie_, jcw4 ^^? | 16:11 |
| jcw4 | alexisb: we just got off | 16:11 |
| alexisb | heh | 16:11 |
| alexisb | I missed you | 16:11 |
| alexisb | was excited I was finally going to be able to join | 16:11 |
| jcw4 | alexisb: We can hop back on? :) | 16:12 |
| jcw4 | alexisb: but bodie_ won't be able to make it | 16:12 |
| alexisb | no, I have nothing of value to add | 16:12 |
| alexisb | I was just going to stalk | 16:12 |
| jcw4 | alexisb: on the other hand it might be worth it... it was a rare video sighting of mgz /c7z | 16:12 |
| jcw4 | alexisb: I should've snapped a pic | 16:12 |
| alexisb | I know! I saw him this morning | 16:13 |
| alexisb | we had a 1x1 earlier | 16:13 |
| jcw4 | alexisb: I think he did it just to counter the rumours that he's a bot | 16:14 |
| alexisb | :) | 16:14 |
| jcw4 | natefinch: how do you access state_test package stuff from your private state tests that are in the state package? | 16:15 |
| natefinch | jcw4: can't... but the reverse works... put the test code in state package and state_test can access it as if it were always in state. that's what export_test does | 16:18 |
| perrito666 | rogpeppe: just let me know when you are finished reviewing :) so I read the whole mail thread and correct it | 16:20 |
| rogpeppe | perrito666: yeah, sorry - i'd much prefer to go through making comments and send them all at once, but github doesn't like that. | 16:21 |
| jcw4 | natefinch: I see, but if I want to test state private code using established state_test stuff (ConnSuite) I just have to export the state private code | 16:22 |
| perrito666 | rogpeppe: not a problem, but it is easier for me to wait until the dust from mail settles :p | 16:22 |
| rogpeppe | perrito666: definitely | 16:22 |
| hazmat | hackedbellini, i meant for not machine-0 | 16:25 |
| hazmat | hackedbellini, one of the agents that can't connect | 16:25 |
| hackedbellini | hazmat: ahh, ok. This was the only one I found... but probably they are inside the lxc machines, right? | 16:35 |
| hackedbellini | I'm checking it right now | 16:35 |
| perrito666 | rogpeppe: done? | 16:37 |
| rogpeppe | perrito666: just writing a final comment | 16:37 |
| perrito666 | heh ok, just asked because my phone stopped going crazy | 16:38 |
| hackedbellini | hazmat: http://pastebin.ubuntu.com/7595873/ http://pastebin.ubuntu.com/7595869/ http://pastebin.ubuntu.com/7595875/ | 16:38 |
| hackedbellini | the first is the machine agent.conf, the second is unit-jenkins and the last one is unit-landscape | 16:38 |
| c7z | rogpeppe: 002-move-utils seems to have failed at build | 16:38 |
| rogpeppe | c7z: darn | 16:39 |
| c7z | not sure if it's you or me yet :) | 16:39 |
| hackedbellini | really strange that those confs, although on the same machine, have different "upgradedToVersion" | 16:40 |
| rogpeppe | c7z: hmm, this looks like the culprit: | 16:40 |
| rogpeppe | imports github.com/juju/juju/names: cannot find package "github.com/juju/juju/names" in any of: | 16:40 |
| rogpeppe | ahh | 16:41 |
| rogpeppe | no juju/juju/names has gone away | 16:41 |
| hazmat | hackedbellini, got time for a g+? | 16:42 |
| rogpeppe | ah, it's in goose | 16:42 |
| rogpeppe | i'm surprised the tests passed when the names package was moved | 16:42 |
| perrito666 | rogpeppe: thanks a lot for your corrections :D | 16:42 |
| rogpeppe | perrito666: np :-) | 16:43 |
| jcw4 | rogpeppe: c7z , could it be a merge issue? | 16:43 |
| rogpeppe | c7z: hmm, weird, i don't see any references to juju/juju/names in my entire source tree | 16:44 |
| rogpeppe | c7z: so i have to suspect some kind of build problem | 16:45 |
| hackedbellini | hazmat: sure. Lets go now? | 16:46 |
| redir | rogpeppe: I am seeing that to after a pull from upstream master | 16:47 |
| rogpeppe | redir: you're seeing the same error? | 16:48 |
| hackedbellini | hazmat: I'm online there. Just call me, or pm me the hangout link | 16:48 |
| rogpeppe | redir: do you see the same problem if you remove $GOPATH/pkg and reinstall everything? | 16:48 |
| redir | rogpeppe: it is in state/apiserver/networker/networker.go | 16:48 |
| redir | rogpeppe: it is imported in that file juju/juju/names | 16:49 |
| rogpeppe | redir: ah, i don't have that file in my branch | 16:49 |
| rogpeppe | redir: it must have been pushed recently | 16:49 |
| redir | rogpeppe: yeah I just did a pull from upstream | 16:50 |
| voidspace | natefinch: I can't find it in that doc at all! | 16:50 |
| c7z | ha, so it is a merge issue then | 16:51 |
| redir | rogpeppe: https://github.com/juju/juju/commit/c5a50a458a12da8e61c0f83704e53e8f3fa0f891 | 16:51 |
| c7z | and this is why we do the testing on the post-merge build | 16:51 |
| c7z | shame the error message is not that helpful | 16:51 |
| c7z | rogpeppe: so, merging/rebasing on upstream should work | 16:52 |
| rogpeppe | c7z: ah yes, i just merged but i should have rebased | 16:52 |
| rogpeppe | c7z: except that i've published the branch | 16:52 |
| rogpeppe | c7z: so i guess i'll just push the merge | 16:53 |
| c7z | rogpeppe: try what ever, we'll see what happens! | 16:53 |
| voidspace | natefinch: I assume that by "set status to down for maintenance" that is what we want "juju status" to report | 16:54 |
| voidspace | natefinch: so all api calls except that one should error | 16:54 |
| voidspace | fwereade: ping, you still around? | 16:54 |
| voidspace | hmmm... my merge failed | 16:55 |
| voidspace | and it was one of the new tests that failed | 16:55 |
| voidspace | hmmm | 16:55 |
| rogpeppe | it's great to see how much faster linking is with go 1.3 | 16:56 |
| voidspace | hah, it passed on my branch - when I merge head it fails | 17:01 |
| voidspace | dammit | 17:01 |
| c7z | voidspace: ha! the same thing | 17:01 |
| voidspace | who killed my test!! | 17:02 |
| voidspace | I am seeing this: [LOG] 0:00.914 DEBUG juju.state connection failed, will retry: dial tcp 0.1.2.3:1234: invalid argument | 17:02 |
| rogpeppe | hmm, what does "Waiting for next available executor" mean | 17:02 |
| rogpeppe | it seems to be waiting for quite a long time | 17:02 |
| rogpeppe | oh here it goes | 17:02 |
| c7z | voidspace: it means you're in the queue | 17:02 |
| voidspace | c7z: I think you meant rogpeppe ... | 17:02 |
| c7z | meh, whichever :P | 17:03 |
| voidspace | I'm flattered by the thought that we're interchangable, but I assure you it's not true | 17:03 |
| rogpeppe | voidspace: we could try it :-) | 17:03 |
| === vladk|offline is now known as vladk | ||
| voidspace | hehe | 17:05 |
| voidspace | I think our respective wives might object for starters... | 17:05 |
| voidspace | heh, the error is "no reachable servers" | 17:10 |
| voidspace | adding a time.Sleep(time.Second * 20) fixes it | 17:10 |
| voidspace | so how should I *really* fix it | 17:10 |
| c7z | :D | 17:10 |
| voidspace | find something I can usefully poll I guess | 17:10 |
| voidspace | this is the issue I fixed (and reverted) as part of trying to get replicasets to work for local provider I think | 17:11 |
| voidspace | we start replica set initiation, but don't wait until it is completed | 17:11 |
| === dpritchett is now known as Supernova09 | ||
| === Supernova09 is now known as dpritchett | ||
| rogpeppe | c7z: hmm: sudo: go: command not found | 17:12 |
| rogpeppe | c7z: from http://juju-ci.vapour.ws:8080/job/github-merge-juju/28/consoleFull | 17:12 |
| rogpeppe | c7z: that doesn't look as if it's anything to do with my branch | 17:13 |
| rogpeppe | hmm, how *did* that networker change go in after names was deleted | 17:13 |
| rogpeppe | ? | 17:13 |
| c7z | that does seem like a race, lets see | 17:15 |
| natefinch | voidspace: sorry, had to step out | 17:17 |
| c7z | rogpeppe: okay, same thing again... | 17:20 |
| voidspace | natefinch: I've agreed with will to talk to him tomorrow | 17:22 |
| voidspace | natefinch: meanwhile I'm trying to fix my write-majority test that fails now | 17:22 |
| voidspace | natefinch: it passed reliably until I merged in head :-) | 17:22 |
| natefinch | voidspace: ug, ok | 17:23 |
| voidspace | natefinch: I thinjk this is the issue I fixed (and reverted) as part of trying to get replicasets to work for local provider I thin | 17:23 |
| voidspace | natefinch: we start replica set initiation, but don't wait until it is completed | 17:23 |
| voidspace | natefinch: so the server is unreachable until it is initiated | 17:23 |
| natefinch | brb sorry | 17:24 |
| c7z | sinzui, rogpeppe: W: Failed to fetch bzip2:/var/lib/apt/lists/partial/us-east-1.ec2.archive.ubuntu.com_ubuntu_dists_trusty-updates_main_source_Sources Hash Sum mismatch | 17:25 |
| rogpeppe | c7z: awesome | 17:25 |
| c7z | not sure what I can do about fixing that | 17:25 |
| rogpeppe | c7z: it's that pesky NSA again | 17:25 |
| voidspace | natefinch: and I can't call CurrentStatus to poll (in this test) because I don't have a session | 17:25 |
| natefinch | voidspace: hmm | 17:28 |
| redir | rogpeppe: looks like networker was a newly added file, with the import in it. | 17:30 |
| rogpeppe | redir: yeah, but how did it get through? | 17:30 |
| rogpeppe | redir: because presumably when it was merged, everything had been changed to use the new names repo and the old one was removed | 17:31 |
| rogpeppe | redir: .... unless | 17:31 |
| rogpeppe | redir: i bet the 'bot doesn't clean the pkg directory | 17:31 |
| redir | rogpeppe: seems reasonable guess | 17:31 |
| sinzui | c7z: yep happens all the time, the test should try 3 times because of that | 17:32 |
| c7z | sinzui: the issue is this is pre-test | 17:33 |
| c7z | are other clouds less pants about corrupting our archive mirrors? | 17:33 |
| sinzui | c7z: yes, the test needs to try again | 17:33 |
| rogpeppe | here's another trivial pull request, using the new juju/filetesting and removing the old one: https://github.com/juju/juju/pull/31 | 17:33 |
| rogpeppe | review, anyone? | 17:34 |
| sinzui | c7z, rogpeppe every cloud has this problem. aws and azure are the worst, though aws might *appear* to be worse because 50% of testing happen there | 17:34 |
| natefinch | voidspace: not sure what to tell you, it sounds like we need a session to be able to poll so we can know when things should succeed | 17:34 |
| rogpeppe | sinzui: which problem? randomly corrupting network data? | 17:34 |
| voidspace | natefinch: I can get another session to poll with | 17:34 |
| voidspace | natefinch: although dialling at all is proving problematic | 17:34 |
| sinzui | rogpeppe, probably the cache. | 17:34 |
| rogpeppe | sinzui: ha. randomly corrupting on-disk data. that's worse. | 17:35 |
| sinzui | rogpeppe, c7z : when http://juju-ci.vapour.ws:8080/view/Cloud%20Health/ this page lists a cloud repeated;y failing becaus of mirrors, we raise the issue with IS | 17:35 |
| voidspace | natefinch: current theory is I need to set DialDirect | 17:35 |
| rogpeppe | natefinch: what's the problem? | 17:36 |
| rogpeppe | oops | 17:36 |
| voidspace | natefinch: nope | 17:36 |
| rogpeppe | voidspace: what's the problem? | 17:36 |
| voidspace | natefinch: I *really* have to EOD | 17:36 |
| * rogpeppe too | 17:36 | |
| natefinch | voidspace: go, it's ok, we'll figure it out | 17:36 |
| voidspace | rogpeppe: if you're around in the morning I'll ask you | 17:36 |
| voidspace | natefinch: I can sort it tomorrow - it's my PR that's failing to merge so it's no-one else's problem | 17:36 |
| rogpeppe | i'd very much like a rubber stamp on https://github.com/juju/juju/pull/31 before i do EOD, if poss. | 17:36 |
| rogpeppe | please | 17:37 |
| voidspace | g'night all | 17:37 |
| sinzui | c7z, I will setup a dedicated slave for the git-merge-juju job. This guarantees fast availability and mostly working mirrors, but then the test needs to cleanup | 17:37 |
| c7z | sinzui: my work list include unifying that script with the existing job so we can just pass in the params for an existing slave | 17:38 |
| sinzui | c7z, I am doing something similar for all key series-archs so that I have a reliable way to test tarballs, build packages, and test local-provider | 17:38 |
| redir | rogpeppe: LGTM | 17:39 |
| rogpeppe | redir: ta! | 17:39 |
| c7z | rogpeppe: have people said juju/jujuutils and such to you yet? | 17:40 |
| rogpeppe | c7z: no | 17:41 |
| redir | rogpeppe: who would ensure the bot does make clean or whatevs? | 17:41 |
| redir | and rogpeppe good evening... | 17:41 |
| rogpeppe | c7z: not quite sure what you mean there | 17:41 |
| c7z | utils is a bad package name, and I'm not sure just being under the juju organisation is great namespacing | 17:42 |
| rogpeppe | c7z: ah yes. | 17:42 |
| c7z | redir: make clean is not the issue, it's all in a tmp GOPATH anyway | 17:43 |
| rogpeppe | c7z: i dunno though. they're not very juju-specific | 17:43 |
| c7z | it's more the stuff like lingering mongo processes and other more subtle cruft/leakage | 17:43 |
| c7z | rogpeppe: that's a fair point for utils, various unix/ubuntu its mostly | 17:43 |
| c7z | *bits | 17:44 |
| redir | c7z: I see | 17:45 |
| c7z | sinzui: ec2 seems pretty broken atm | 17:51 |
| rogpeppe | g'night all | 17:52 |
| c7z | night rogpeppe, I may try and land your bits later, otherwise requeue tomorrow | 17:52 |
| jcw4 | rogpeppe: o/ | 17:52 |
| rogpeppe | c7z: thanks that would be nice | 17:52 |
| rogpeppe | o/ | 17:52 |
| sinzui | c7z, The errors last about 30 minutes. The run unit tests jobs are doing okay. The test just needs to keep trying when It believes the cloud is at fault | 17:53 |
| sinzui | c7z, we have seen many AMIs *spontaneous combust* We had to select new AMIs to get tests to work | 17:54 |
| c7z | sinzui: should it poll on the instance when the apt call fails? spinning up new ones seems bad... | 17:54 |
| c7z | but lolo, exploding amis would be a problem | 17:54 |
| sinzui | c7z, since git-merge-juju cargo culted the run-unit-tests, it lots the power to switch from AMI to an existing host | 17:55 |
| c7z | sinzui: right, I'll get that bit back | 17:56 |
| sinzui | c7z I think we just need that script to accept an optional path to a tarball. | 17:56 |
| c7z | but we don't have an existing way to be robust agains mirror errors for the machine-per-run case as far as I see | 17:56 |
| c7z | sinzui: yeah, that's the plan | 17:56 |
| c7z | plus unifying the other changes | 17:57 |
| perrito666 | mm, I can mention people on the commits, rogpeppe did you get any notification about that? | 18:01 |
| c7z | perrito666: depends on his notification settings | 18:05 |
| marcoceppi | I really want to use actions, any idea what release that will be available in? (Will we see it in a 1.19.x?) | 18:05 |
| c7z | jcw4: ^ | 18:05 |
| jcw4 | marcoceppi: c7z ; we're making progress... I'm not sure what the 1.19.x timeline looks like | 18:06 |
| jcw4 | marcoceppi: c7z I think so | 18:06 |
| c7z | marcoceppi: code is landing on trunk now | 18:07 |
| marcoceppi | c7z: yeah, I saw the GH notifications | 18:07 |
| marcoceppi | c7z: jcw4: is there any prelim documentation so I can start including actions in charms I'm writing now? | 18:07 |
| marcoceppi | has the format been outlined yet? | 18:07 |
| jcw4 | marcoceppi: good question.. fwereade has been after us to produce those | 18:07 |
| alexisb | jcw4, there will be a 1.19.x release next week | 18:07 |
| alexisb | then the following week we plan to release 1.20 | 18:07 |
| * marcoceppi is not after you guys | 18:07 | |
| marcoceppi | /not/now/ | 18:08 |
| jcw4 | alexisb, marcoceppi in that case I don't expect Actions in 1.19.x | 18:08 |
| jcw4 | 1.20 is hopeful | 18:08 |
| marcoceppi | you mean 1.21? | 18:08 |
| alexisb | yes he means 1.21 :) | 18:08 |
| c7z | I thought we were dropping odd/even | 18:09 |
| * marcoceppi was concerned the release pattern had changed *whew* | 18:09 | |
| alexisb | jcw4, 1.20 will be the stable release | 18:09 |
| alexisb | c7z, yes | 18:09 |
| * marcoceppi is concerned again | 18:09 | |
| alexisb | so 1.21beta1 will be the first development with the tag | 18:09 |
| c7z | this conversation is hillarious | 18:09 |
| jcw4 | marcoceppi: what can we do to help | 18:09 |
| jcw4 | c7z: I take umbrage at that... :) | 18:10 |
| c7z | I love working with you guys | 18:10 |
| marcoceppi | Oh I really don't care about the release things, just actions will literally rock my world | 18:10 |
| alexisb | marcoceppi, why is that | 18:10 |
| * jcw4 is a little nervous about literally rocking the world | 18:10 | |
| alexisb | jcw4, I think that just means a big party and marcoceppi is bringing the refreshments | 18:11 |
| jcw4 | alexisb: whew | 18:11 |
| marcoceppi | alexisb: A lot of my charms use the notion of an external repository for user maintained assets (like the wordpress charm, and now the nginx-site charm) so having an action to sync this content that a user can initaite agains the charm is funderful | 18:11 |
| jcw4 | marcoceppi: what kind of docs would be most helpful... API docs for defining actions in your charm? | 18:12 |
| marcoceppi | jcw4: yes, how do I add actions to my charm would be the best document | 18:12 |
| marcoceppi | I can also help get that doc in to the juju docs for when actions land | 18:12 |
| alexisb | jcw4, mgz, fwereade: it may be good to invite marcoceppi to one of your interlocks so you can hammer out details on documentation for charmers | 18:13 |
| jcw4 | marcoceppi: we've (I've) been mostly focused on plumbing and innards... bodie_ has been working on the Actions() method on Charm... but I don't think we have a fully fleshed out API yet. | 18:13 |
| jcw4 | alexisb: good idea | 18:13 |
| jcw4 | marcoceppi: what timezone are you in? | 18:13 |
| marcoceppi | jcw4: I've trancended timezones, but I'm mostly awake during EDT | 18:13 |
| jcw4 | we meet daily at 1600 UTC | 18:14 |
| alexisb | heh | 18:14 |
| marcoceppi | jcw4: cool, feel free to ping me when you do, I'm not afraid to run trunk to hammer out features landing | 18:14 |
| marcoceppi | hammer on, even | 18:14 |
| jcw4 | and sometimes we chat in #jujuskunkworks | 18:14 |
| jcw4 | although we try to keep discussion in here until it gets too noisy | 18:14 |
| marcoceppi | cool | 18:15 |
| jcw4 | marcoceppi: the hangout link is in the topic for that channel too | 18:15 |
| * marcoceppi lurks in there | 18:15 | |
| marcoceppi | Cool, thanks for the info jcw4 alexisb c7z et al | 18:16 |
| jcw4 | marcoceppi: thanks for the added impetus | 18:16 |
| perrito666 | anyone here is in charge-ish of https://juju.ubuntu.com/docs/contributing.html ? I have docs I want to add but I am not really sure about the criteria for the naming | 18:55 |
| jcw4 | perrito666: jcastro maybe? | 18:56 |
| perrito666 | jcastro: ? | 18:56 |
| jcastro | hi! | 18:56 |
| jcastro | naming which part? | 18:56 |
| perrito666 | jcastro: the source for the docs has the doc names preceded by things like authors- charms- config- howto- | 18:57 |
| perrito666 | so | 18:57 |
| perrito666 | I want to add docs on HA, what is the prefix for "feature documentation" | 18:57 |
| jcastro | howto-ha | 18:58 |
| jcastro | though, howto-highavailability probably makes more sense | 18:58 |
| perrito666 | yes | 18:58 |
| perrito666 | just wanted to be sure, I gues that i used to present the data so I didnt want my doc to end in the wrong section | 18:58 |
| perrito666 | tal | 18:58 |
| jcw4 | did the networker.go merge issue get fixed and merged in yet? | 19:03 |
| jcw4 | i.e. are we just waiting for CI to finish? | 19:03 |
| jcw4 | rogpeppe, mgz ^^ | 19:08 |
| jcw4 | I don't see a PR to fix it | 19:09 |
| jcw4 | s/PR/MR/ | 19:10 |
| jcw4 | crickets... | 19:22 |
| jcw4 | https://github.com/juju/juju/pull/32 | 19:22 |
| natefinch | sorry, no idea what you're talking about | 19:22 |
| jcw4 | natefinch: tx | 19:23 |
| jcw4 | natefinch: for the LGTM that is | 19:23 |
| natefinch | :) | 19:23 |
| natefinch | I knew what you meant | 19:23 |
| jcw4 | :) | 19:23 |
| jcw4 | fwereade, mgz any chance of a $$merge$$ ^^ | 19:27 |
| natefinch | jcw4: for the thing I LGTM'd? | 19:34 |
| natefinch | I thought you could do that. I can do that if you want | 19:35 |
| sinzui | *** I am forcing a rebuilt of the git-merge-juju job to see if the mirror issue is resolved*** | 19:48 |
| sinzui | *** I will build a dedicated slave if this fails *** | 19:49 |
| perrito666 | omg, that thread will never die | 19:53 |
| natefinch | perrito666: which one? :) | 19:55 |
| perrito666 | natefinch: hosting projects... | 19:56 |
| natefinch | yep.. well, it hits close to home for a lot of people. Both tools are so complex, it's hard to know both of them really well, so there's a lot of misunderstanding on both sides, I'd imagine. Luckily, I don't know either of them very well, so it's all the same for me :) | 19:57 |
| natefinch | (bzr vs git that is.... LP vs github is a little easier to reason about, I think) | 19:58 |
| perrito666 | its vi vs emacs | 19:58 |
| natefinch | yep | 19:58 |
| perrito666 | sadly its a thread unlikely to be ended by godwin lay | 20:01 |
| natefinch | I've also heard that when you argue about things that people use to define themselves (I'm a python programmer, I'm a Christian, I'm a vi user)... that you basically can never win. That attribute is so closely tied to how they identify themselves, that they can't and won't listen to reason about why it might not be good. | 20:01 |
| perrito666 | law | 20:01 |
| perrito666 | I will say only this, git branch is oh so much faster than bzr branches | 20:09 |
| natefinch | yeah, that's cause git branch does almost no work | 20:09 |
| natefinch | it is pretty cool | 20:10 |
| perrito666 | also since my .vimrc was heavily tuned for working with git now I have a changed lines indicator which makes my life easier | 20:13 |
| natefinch | that's cool | 20:14 |
| natefinch | Honestly, I'm happy to get the chance to work more in git in my daily work, since that's what most people use these days, and I'd like to be more proficient with it. My last company used SVN, and I only used git in minor side projects, so not a lot of merging, rebasing, squashing etc. | 20:15 |
| jcw4 | thanks natefinch ; I'm not a member of the juju team so I can't do the $$merge$$... | 20:21 |
| jcw4 | what is the apt mirror corrupted issue on CI? | 20:21 |
| jcw4 | mgz: ^^ | 20:22 |
| sinzui | jcw4, I am working on it | 20:22 |
| jcw4 | sinzui: thanks! | 20:22 |
| sinzui | I was going to build an instance, but abentley has a hack to change the mirrors that I should try first | 20:23 |
| sinzui | jcw4, I moved a rule from run-unit-tests into the git-merge-juju job. When we unify the job with run-unit-tests, the job will get all the goodness | 20:35 |
| sinzui | tests are running again | 20:35 |
| jcw4 | sinzui: thanks! | 20:35 |
| natefinch | sinzui: I see a test failed here for a differnt pull request? https://github.com/juju/juju/pull/32 | 20:36 |
| natefinch | 32 and 33 at the bottom there | 20:36 |
| natefinch | I guess that's build 33 not PR 33 | 20:36 |
| sinzui | natefinch, it is spurious | 20:36 |
| natefinch | sinzui: figured, just making sure | 20:37 |
| sinzui | sorry. I moved some love from run-unit-tests into the job to get past the mirror issue. CI is using newer solutions to common problems | 20:37 |
| * sinzui adds local tarball support to run-unit-tests | 20:37 | |
| * thumper goes to walk the dog | 20:53 | |
| menn0 | morning all | 21:06 |
| jcw4 | menn0: morning :) | 21:14 |
| === vladk is now known as vladk|offline | ||
| thumper | o/ | 21:43 |
| thumper | menn0: so, I told people last night that you would be taking the db-schema upgrade process to the list :) | 21:45 |
| thumper | hmm... | 21:46 |
| thumper | the volume of email I now get is much bigger | 21:46 |
| thumper | github has very chatty reviews | 21:46 |
| jcw4 | dimitern and davecheney are reviewers today, but not online right now... | 21:53 |
| jcw4 | mgz, fwereade https://github.com/juju/juju/pull/33 | 21:53 |
| jcw4 | thumper: lots more chatting coming from that PR ^^ | 21:54 |
| thumper | um... | 21:54 |
| * jcw4 looks around nervously... | 21:55 | |
| jcw4 | yes... | 21:55 |
| * thumper looks at menn0 | 21:55 | |
| thumper | 'tis friday | 21:55 |
| jcw4 | urg... gotta get my timzone math right | 21:55 |
| jcw4 | wait... it's not friday for natefinch... | 21:56 |
| * thumper replies to waigani's email | 21:57 | |
| menn0 | HFS, go | 22:00 |
| menn0 | ignore that :) | 22:00 |
| menn0 | thumper: sorry I didn't see all this. I had Google Docs full screen while working on a schema migration doc | 22:00 |
| menn0 | thumper: I will be taking that to the list | 22:01 |
| menn0 | thumper: using Google Docs because all the details are getting lost in the email thread | 22:01 |
| * thumper nods | 22:01 | |
| thumper | ack | 22:01 |
| menn0 | thumper: I'm pretty happy with how the design is working out. Your idea cracked it. | 22:02 |
| thumper | cool, happy to help | 22:02 |
| thumper | waigani: around? | 22:02 |
| waigani | thumper: yep | 22:03 |
| thumper | waigani: did you want to come around today? | 22:03 |
| waigani | oh right | 22:03 |
| thumper | waigani: I think we could nail the switch thing | 22:03 |
| waigani | ah, I don't have a car | 22:03 |
| waigani | I've addressed all your comments | 22:03 |
| waigani | just adding formatting to list now | 22:03 |
| waigani | I'm down on castle st | 22:04 |
| waigani | hmmm ... i *might* be able to steal molly's car | 22:04 |
| waigani | hang on | 22:04 |
| waigani | thumper: I've got wheels! Shall I head your way? | 22:11 |
| thumper | yeah | 22:11 |
| waigani | thumper: I just pushed my branch - addressed everything but formatted output to list | 22:12 |
| thumper | waigani: let's go over it here | 22:12 |
| waigani | okay, see you soon | 22:12 |
| * thumper turns on the coffee machine | 22:17 | |
| === sebas538_ is now known as sebas5384 | ||
| sinzui | wallyworld_, mgz: FYI https://code.launchpad.net/~sinzui/juju-ci-tools/local-tarball/+merge/222266 | 22:38 |
| === sebas538_ is now known as sebas5384_ | ||
| thumper | davecheney: o/ | 23:04 |
| bigjools | wallyworld_: do I need to come round and put a hammer through your router? | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!