| jw4 | thumper: related to your recent change http://reviews.vapour.ws/r/419/ | 00:00 |
|---|---|---|
| menn0 | davecheney: finished reviewing the set change | 00:01 |
| menn0 | davecheney: was that an intentional propellerheads reference? | 00:02 |
| menn0 | davecheney: i'm not sure i understand what you mean regarding RelationUnitsChange | 00:05 |
| menn0 | davecheney: out the types you've moved in that PR, it's the only one that isn't related to multiwatcher | 00:06 |
| menn0 | davecheney: it isn't referred to or used by multiwatcher or allwatcher | 00:08 |
| menn0 | davecheney: i think it belongs in state/watcher.go and everything that uses it can import it from state | 00:09 |
| thumper | jcsackett: hi | 00:09 |
| thumper | nope, not jcsackett, jw4 | 00:09 |
| jw4 | hehe | 00:09 |
| jw4 | I was guessing | 00:09 |
| jw4 | I explicitly changed my nick to jw4 to suit fwereade who didn't like tabbing 3 times | 00:09 |
| menn0 | davecheney: unless i'm missing something... | 00:10 |
| thumper | jw4: time between doesn't exclude boundaries | 00:10 |
| * fwereade feels bad now | 00:10 | |
| jw4 | fwereade: lol | 00:10 |
| jw4 | thumper: I feel embarrassed if that's the case... | 00:10 |
| * fwereade *has* been appreciating jw<tab> though | 00:10 | |
| fwereade | even if that's not actually any easier to type than jw4 | 00:10 |
| thumper | jw4: I even added a test to testing/checkers to test boundaries | 00:10 |
| jw4 | thumper: when I wrote that change I was thinking your fix was already in master | 00:11 |
| jw4 | thumper: and something in the output lead me to beleive it was a boundary issue | 00:11 |
| thumper | jw4: nah, what it was was the serialisation in and out of mongo was losing precision | 00:11 |
| thumper | making it look like it was added before the start of the test | 00:12 |
| jw4 | thumper: derp | 00:12 |
| jw4 | thumper: okay. so just scratch that PR I guess? | 00:12 |
| perrito666 | fwereade: <tab> is in the little finger without stretching 4 is in the middle finger stretching, clearly tab is easier | 00:12 |
| perrito666 | if you do touch typing that is | 00:12 |
| thumper | jw4: yeah, I think so | 00:12 |
| jw4 | thumper: ta | 00:12 |
| jw4 | fwereade: I'm thinking of switching to /nick a~~~~ | 00:13 |
| fwereade | katco, I'm tired and drunk but interested in a breif discussion of how protobuf will help you, it may prime me for a more helpful discussion tomorrow | 00:13 |
| fwereade | jw4, lol | 00:13 |
| fwereade | jw4, don't make me rejig my muscle memory *again* | 00:13 |
| jw4 | fwereade: hehe | 00:13 |
| fwereade | katco, in particular, I worry that programmatic translation is risky when agreement on protocols is not guaranteed, ie in distributed systems where versions may change out of sync | 00:16 |
| fwereade | katco, and so I have a bias towards explicit translation at boundaries, with tests tuned to catch changes in expectations on either side | 00:17 |
| fwereade | katco, to be annoyingly enigmatic about it: http://thecodelesscode.com/case/97 | 00:17 |
| thumper | oh fark | 00:17 |
| thumper | meetings from 3-5 here | 00:17 |
| thumper | and 5-7 elsewhere tonight | 00:17 |
| fwereade | katco, but I have not used protobuf in anger, and may be attacking straw men | 00:17 |
| thumper | hazaah | 00:17 |
| thumper | fwereade: get the feeling you are talking to yourself? | 00:18 |
| fwereade | thumper, well, she sent an email 20 mins ago, so I feel it likely she will read it in the near future | 00:18 |
| perrito666 | uff meeting at 23 I so forgot that one | 00:18 |
| * thumper sighs | 00:19 | |
| thumper | tomorrow is looking like a long meeting too | 00:19 |
| thumper | fwereade: can you do 9:30pm? | 00:19 |
| fwereade | thumper, my 9:30? sure, will set an alarm now | 00:19 |
| thumper | fwereade: tomorrow night your time | 00:19 |
| thumper | pm | 00:19 |
| thumper | PM | 00:19 |
| fwereade | thumper, perfect | 00:19 |
| thumper | ok | 00:20 |
| * thumper puts it in the calendar | 00:20 | |
| ericsnow | davecheney: thanks for the reviews | 00:20 |
| ericsnow | davecheney: I've addressed most of the concerns in http://reviews.vapour.ws/r/402/ | 00:20 |
| ericsnow | davecheney: I have just a few follow-up comments in the review | 00:21 |
| katco | fwereade: lol sorry, wife and daughter just got home | 00:31 |
| thumper | katco: I think we all understand that :-) | 00:32 |
| katco | daughter has a fever :( we think maybe her teeth are coming in | 00:32 |
| katco | fwereade: so, i'm not exactly proposing anything here, just interested in thoughts. but i was constraining my hypothetical usage to only arguments over the wire, not business entities | 00:34 |
| katco | fwereade: the network facade would handle translation from over-the-wire objects to actual function calls, where we might not even need a business entity per say | 00:35 |
| katco | fwereade: your comment about versions in distributed components is a valid one i think, but probably no different than if we were to write this manually | 00:37 |
| davecheney | next on my shit list | 00:48 |
| davecheney | why are almost all the values passed through a set sorted on the way out ? | 00:48 |
| davecheney | the contracts for the methods that use this do not reuqire or guarentee lexical sorting | 00:49 |
| katco | davecheney: i guess it depends on if it's a side-effect of ensuring uniqueness, or if it's explicitly performing sorting | 00:52 |
| katco | davecheney: i haven't looked at that code, is it just using a map under the covers? | 00:52 |
| davecheney | yup | 00:58 |
| davecheney | package set; type String map[string]bool | 00:58 |
| katco | so it's explicitly sorting? | 00:59 |
| davecheney | yes, i'm seeing a lot of use of set.SortedValues | 00:59 |
| davecheney | and I suspect it is so that the tests pass | 00:59 |
| katco | ahh | 00:59 |
| davecheney | not because the output is required to be sortedf | 00:59 |
| katco | so to be clear, it's the callers at fault, not the set code? | 00:59 |
| davecheney | katco: depends | 01:02 |
| davecheney | most of the methods i've found those in don't make it clea rif the result is required to be sorted or not | 01:02 |
| davecheney | many of the things that are sorted | 01:03 |
| davecheney | are only stable for testing data | 01:03 |
| davecheney | ie, sorting a list of network interfaces | 01:03 |
| katco | sorry, i guess what i meant is: is there a way of retrieving values from the set in a non-sorted way? | 01:03 |
| fwereade | katco, fwiw, I feel we should by default be providing set-type results unsorted | 01:11 |
| katco | fwereade: i agree | 01:11 |
| fwereade | katco, we don't know in general whether a client cares about sorting them | 01:11 |
| fwereade | katco, and when they don't care we're just wasting effort by testing them | 01:11 |
| katco | fwereade: losing O(lg n) * # callers that don't need it | 01:11 |
| fwereade | katco, exactly | 01:12 |
| katco | that too | 01:12 |
| fwereade | katco, so in general | 01:12 |
| fwereade | katco, tests that say [sort expect] [sort actual] [assert actual == expect] STM to be the sweet spot | 01:12 |
| wallyworld | SameContents is your friend | 01:13 |
| fwereade | wallyworld, true | 01:13 |
| wallyworld | not DeepEquals | 01:13 |
| fwereade | katco, yes, wallyworld has it | 01:14 |
| fwereade | katco, do you want a quick chat about protobuf and how you want to use it? | 01:14 |
| katco | fwereade: have a stand-up right now | 01:15 |
| fwereade | katco, in that case please ping me tomorrow when you get on? interested to talk | 01:15 |
| fwereade | katco, but going to bed for now, I think | 01:15 |
| katco | fwereade: no worries at all | 01:15 |
| katco | fwereade: thank you, and sleep well :) | 01:15 |
| davecheney | katco: fwereade i agree, i think gc.DeepEquals has forced the code to adopt to the test | 01:28 |
| davecheney | s/adopt/adapt | 01:28 |
| * fwereade is really going to bed right now, but found http://thecodelesscode.com/case/167 amusing | 01:37 | |
| === kadams54-away is now known as kadams54 | ||
| katco | fwereade: you lie! but not in bed! ;) | 01:41 |
| thumper | davecheney: in godoc2md, is there a way to say "leave this bit" ? | 01:50 |
| davecheney | thumper: not really | 01:59 |
| davecheney | which bit ? | 01:59 |
| davecheney | do youi want a <pre /> section ? | 01:59 |
| thumper | davecheney: I just want output like this for the README.md: [](https://godoc.org/github.com/juju/loggo) | 02:01 |
| davecheney | ahh | 02:02 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| thumper | davecheney: any way to format that code in the go docs, such that it makes something like that in the readme? | 02:24 |
| thumper | davecheney: or I may have to have a post process sed command :-) | 02:24 |
| thumper | oh... sed | 02:24 |
| davecheney | thumper: try | 02:29 |
| davecheney | \n | 02:29 |
| davecheney | 02:29 | |
| davecheney | \n | 02:29 |
| davecheney | ie, intend like markdown | 02:29 |
| davecheney | it's guess, it might work | 02:29 |
| ericsnow | davecheney: I'm going to revert the utils patch I merged a little while ago | 02:30 |
| davecheney | ericsnow: ok | 02:30 |
| ericsnow | davecheney: I'll merge it back in once you land that core patch for the set stuff | 02:31 |
| thumper | davecheney: sed is easier :-) and I have a make target already | 02:31 |
| davecheney | thumper: +1 | 02:32 |
| davecheney | ericsnow: ok | 02:32 |
| davecheney | but i don't really know what the problem is | 02:32 |
| davecheney | are you wanting to avoid updating dependencies.tsv twice ? | 02:33 |
| ericsnow | davecheney: apparently my merge landed in between the two set-related ones you have | 02:36 |
| ericsnow | davecheney: there should be a failing test in backups under http://reviews.vapour.ws/r/421/ | 02:36 |
| ericsnow | davecheney: see https://github.com/juju/juju/pull/1119 | 02:37 |
| davecheney | ericsnow: i don't understand | 02:38 |
| davecheney | we haven't updated to revision in dependencies.tsv yet | 02:38 |
| davecheney | oh, you updated to a new revision | 02:38 |
| davecheney | yup | 02:38 |
| davecheney | that change hasn't landed | 02:38 |
| ericsnow | davecheney: so either I temporarily revert my utils merge or you roll PR1119 into yours | 02:38 |
| davecheney | sorry, you'll have a merge conflict after 1120 lands | 02:39 |
| ericsnow | davecheney: I figured I'd just go the revert route | 02:39 |
| davecheney | ericsnow: you don't ahve to revert anything | 02:39 |
| davecheney | your change did not land | 02:39 |
| ericsnow | davecheney: my utils change landed, which breaks backups | 02:39 |
| davecheney | ericsnow: how did it land ? | 02:39 |
| davecheney | why did tests not pick that up >? | 02:39 |
| davecheney | ericsnow: i'm really confuised | 02:39 |
| davecheney | please send a PR | 02:39 |
| davecheney | that will explain what the problem is | 02:40 |
| ericsnow | davecheney: sorry, let me clarify: I merged a change into the utils repo that breaks backups in juju core (and PR 1119 resolves it) | 02:42 |
| davecheney | ericsnow: no you didn't | 02:43 |
| davecheney | nothing happens to juju core til dependencies.tsv is updated | 02:43 |
| ericsnow | davecheney: right | 02:43 |
| ericsnow | davecheney: which your patch does | 02:43 |
| davecheney | right | 02:44 |
| ericsnow | davecheney: there should be a failed test in backups under PR1120 | 02:46 |
| ericsnow | davecheney: if there's not then there's no need for me to revert anything :) | 02:47 |
| davecheney | ericsnow: is the build broken ? | 02:47 |
| davecheney | i don't think ti is | 02:47 |
| davecheney | so i don't think there is anything to do | 02:47 |
| ericsnow | davecheney: okeedokee :) | 02:49 |
| davecheney | ericsnow: one of our braches probably won't pass ci | 02:51 |
| davecheney | i'll fix it if it fails | 02:51 |
| ericsnow | davecheney: cool, thanks | 02:51 |
| === kadams54 is now known as kadams54-away | ||
| davecheney | ericsnow: ok | 02:53 |
| davecheney | i see what has happened now | 02:53 |
| davecheney | please revert your utils change nad tell me the new hash | 02:54 |
| ericsnow | davecheney: will do | 02:54 |
| ericsnow | davecheney: b50b465fe6aceceb4d08f2093edaccb01e9d5fd4 | 02:56 |
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| wallyworld | axw: i decide to do the fix myself, to get it landed http://reviews.vapour.ws/r/426/ | 04:24 |
| wallyworld | for the swift container issue | 04:25 |
| axw | wallyworld: cool. will look in a sec | 04:26 |
| wallyworld | ta, no hurry | 04:27 |
| axw | wallyworld: lgtm | 04:33 |
| wallyworld | axw: ty | 04:38 |
| jw4 | axw: Thanks! Good point about naming tests - I waffled and went the other way, but now I'll stick to more descriptive naming | 04:49 |
| axw | jw4: you're welcome/thanks :) | 04:49 |
| axw | wallyworld: were you +1ing my response or Katherine's comment about tags? | 05:04 |
| wallyworld | your response | 05:04 |
| axw | k | 05:05 |
| wallyworld | axw: thanks for fixes - i was unclear, i only meant the errors inside the loop | 05:26 |
| axw | wallyworld: cool | 05:29 |
| anastasiamac_ | axw: would gr8ly appreciate if u could cast ur eyes over this again :-) http://reviews.vapour.ws/r/407/ | 06:11 |
| anastasiamac_ | wallyworld: ^^ | 06:11 |
| axw | sure | 06:11 |
| anastasiamac_ | u r amazing! thnx ;-) | 06:12 |
| anastasiamac_ | axw: just running away to get my bay - bitten!! i actively dislike young age | 06:12 |
| anastasiamac_ | axw: brb | 06:12 |
| davecheney | bot's broken, ya'll, https://github.com/juju/juju/pull/1116 | 07:48 |
| axw | davecheney: ? there's a merge conflict | 07:50 |
| davecheney | sigh | 07:50 |
| rogpeppe | in reviewboard, if i'm looking at the comments on a review, is there any way to show the comment in the context of the code that it's commenting on? | 08:11 |
| rogpeppe | axw: ^ | 08:12 |
| axw | rogpeppe: I think if you follow the code location above the comment, it links to that rev/context | 08:14 |
| * axw tries | 08:14 | |
| rogpeppe | axw: doesn't seem to work for me | 08:15 |
| axw | rogpeppe: does for me... I just went to http://reviews.vapour.ws/r/338/, went to the first review by davecheney and went the "api/apiclient.go" above his first comment took me to the code where he made the comment | 08:16 |
| rogpeppe | axw: ah, got it, thanks | 08:18 |
| dimitern | rogpeppe, on the left next to the line numbers there are numbered boxes when there are comments for that line; alternatively clicking on the filename (left or right) takes you to the line | 08:18 |
| === alexlist` is now known as alexlist | ||
| davecheney | rogpeppe: the problem is people don't realise you can highlugh a section | 08:21 |
| davecheney | not jhust a line | 08:21 |
| davecheney | when you comment on a section, the comments make more sense | 08:21 |
| rogpeppe | davecheney: to make a comment? | 08:21 |
| davecheney | but nobody knows that | 08:21 |
| rogpeppe | davecheney: i have difficulty enough creating a comment anyway - it always seems to take about 4 clicks | 08:22 |
| davecheney | rogpeppe: yup, not defending rbt's ui | 08:22 |
| rogpeppe | davecheney: the most annoying thing is when you click outside a comment that you're making and it deletes your in-progress comment. i lost several substantial comments yesterday from that. | 08:22 |
| dimitern | wallyworld, wow, you've backported all my fixes to 1.21, thanks! :) | 08:22 |
| wallyworld | dimitern: np, i'm keen to get beta2 unblocked :-) | 08:24 |
| dimitern | fwereade, ping | 08:31 |
| fwereade | dimitern, pong | 08:31 |
| dimitern | fwereade, hey, a quick clarification re one of your review comments - about the revno and AddMetaCharm | 08:33 |
| dimitern | fwereade, I'm not quite sure what are you suggesting | 08:33 |
| fwereade | dimitern, `AddMetaCharm(..., 2)` | 08:34 |
| fwereade | dimitern, is it used elsewhere? | 08:34 |
| fwereade | dimitern, it just doesn't really seem worth the comment? | 08:34 |
| dimitern | fwereade, I have to check, but possibly in a few places | 08:34 |
| dimitern | fwereade, ah, you're saying drop the revno var and pass the number directly, without a comment about SetUpTest? | 08:35 |
| fwereade | dimitern, yeah exactly | 08:35 |
| fwereade | dimitern, it feels unnecessary from here | 08:35 |
| dimitern | fwereade, ok, sgtm | 08:35 |
| dimitern | fwereade, and re those 2 cases which set the charm url on the service or unit docs manually | 08:36 |
| dimitern | fwereade, I needed that so I can test the "sameCharm" or "differentCharm" assertions without messing up the settings refcount | 08:37 |
| fwereade | dimitern, hmm, would it be too unwieldy to preserve the refcount by setting charm urls on a distinct unit? | 08:40 |
| fwereade | dimitern, I just tend to get nervous about tests that mess with the db in ways that don't match real usage | 08:41 |
| dimitern | fwereade, I'll have a look to see if I can simulate the same without transactions | 08:41 |
| dimitern | fwereade, but for the service is Dead case, it can't be done | 08:41 |
| rogpeppe | davecheney: i've been seeing this error message sometimes recently when building tests: | 08:41 |
| rogpeppe | os/user(.text): missing Go type information for global symbol: code.google.com/p/go.crypto/curve25519.REDMASK51 size 8 | 08:41 |
| rogpeppe | davecheney: do you know what's going on there? | 08:41 |
| fwereade | dimitern, fwiw, you can use transactions inside txn hooks | 08:42 |
| dimitern | fwereade, I do it that way | 08:42 |
| fwereade | dimitern, I am evidently undercaffeinated | 08:42 |
| fwereade | dimitern, ofc you know that, you do it all the time | 08:42 |
| rogpeppe | davecheney: it happens even when i rm -r $GOPATH/pkg | 08:42 |
| dimitern | fwereade, :) np | 08:42 |
| dimitern | fwereade, I'll feel bad not testing the "service is Dead" case for SetCharm, even though it can't practically happen in real life | 08:43 |
| fwereade | dimitern, but I guess I'm not following why you want to avoid txns in this case? or do you mean avoid direct db access vs doing things over the published interface? | 08:44 |
| dimitern | fwereade, I guess I mean the latter | 08:45 |
| rogpeppe | davecheney: and it even happens when i rebuild go from scratch *and* remove $GOPATH/pkg | 08:45 |
| dimitern | fwereade, the published interface assumes a lot and cannot be used to test minute changes | 08:45 |
| fwereade | dimitern, agreed and understood | 08:46 |
| dimitern | fwereade, (well, I suppose it *can*, but it will mean making the test more complicated in order to follow the *exact* code path implemented right now around service destruction) | 08:46 |
| fwereade | dimitern, indeed | 08:47 |
| fwereade | dimitern, I think the benefits of testing the actual interactions are pretty compelling | 08:47 |
| fwereade | dimitern, I agree we can't *always* do it | 08:48 |
| fwereade | dimitern, and I'm prepared to accept that there may be cases in which doing so is yucky enough that we're better off taking a shortcut | 08:48 |
| dimitern | fwereade, alright | 08:51 |
| dimitern | fwereade, thanks, I'll implement your suggestions and land it then | 08:51 |
| fwereade | dimitern, cheers | 08:52 |
| voidspace | morning all | 08:59 |
| mattyw | morning everyone | 09:01 |
| TheMue | morning all | 09:13 |
| dimitern | morning mattyw, TheMue, voidspace | 09:34 |
| mattyw | dimitern, good morning | 09:34 |
| voidspace | dimitern: TheMue: o/ | 09:35 |
| TheMue | o/ | 09:36 |
| perrito666 | morning | 09:53 |
| voidspace | dimitern: http://reviews.vapour.ws/r/429/diff/# | 10:43 |
| voidspace | dimitern: I'm getting coffee | 10:43 |
| dimitern | voidspace, looking | 10:44 |
| voidspace | dimitern: I'm getting coffee | 10:44 |
| dimitern | voidspace, LGTM +a couple of suggestions | 10:53 |
| voidspace | dimitern: thanks | 11:17 |
| voidspace | dimitern: your first suggestion looks good | 11:17 |
| voidspace | dimitern: I'm hesitant to add "will retry later" to the second message - will we retry? | 11:18 |
| dimitern | voidspace, yeah, I've thought about it just after I sent it :) | 11:19 |
| dimitern | voidspace, why a warning though then? | 11:19 |
| voidspace | dimitern: so Errorf ? | 11:19 |
| voidspace | dimitern: that's for a genuine error that wasn't handled separately | 11:21 |
| voidspace | dimitern: i.e. it's *not* a 400, 403, 404, 409 | 11:21 |
| dimitern | voidspace, it definitely looks like an error, an unexpected one even - which can be added to the log message | 11:22 |
| voidspace | dimitern: ok, I'll make it an Errorf | 11:23 |
| dimitern | voidspace, cheers | 11:23 |
| voidspace | dimitern: pushed, will merge... | 11:24 |
| perrito666 | aghh really? another import cycle? | 11:24 |
| dimitern | voidspace, great, I pushed mine as well, finally | 11:25 |
| voidspace | dimitern: great | 11:26 |
| voidspace | perrito666: not so great | 11:26 |
| wallyworld | axw: hiya, i just noticed we assigned ourselves that tools bug at the same time | 11:29 |
| wallyworld | have you done much on it? i've found that the hook tools are being linked to a units symlinks rather than the jujud of the currently installed tools, so it should just be a matter of making the right symlinks | 11:30 |
| fwereade | wallyworld, define "currently installed tools"? different units will update at different times, and potentially even want to expose different hook tools to their contexts | 11:37 |
| wallyworld | fwereade: each version of tools gets a fir named after their version | 11:38 |
| wallyworld | dir | 11:38 |
| wallyworld | so there will/could be more than one tools dir | 11:38 |
| wallyworld | but the hook tools should link to tools/1.22-alpha1.1-trusty-amd64/jujud | 11:39 |
| wallyworld | not tools/unit-mysql-0/jujud | 11:39 |
| wallyworld | cause at the moment, all units hog smashed onto a machine link to the later | 11:39 |
| wallyworld | the first unit | 11:40 |
| wallyworld | and if that unit is removed, the other unit's links become invalid | 11:40 |
| fwereade | wallyworld, hmm, that is surely a problem, but shouldn't they just link to the jujud in their own tools dir? | 11:41 |
| wallyworld | likely, i haven't looked in tooo much detail, just reproduced the issue and saw the suboptimal symlinks | 11:42 |
| wallyworld | dimitern: i think you meant "Save warthogs!" :-p | 11:57 |
| perrito666 | ericsnow: ping | 12:21 |
| dimitern | wallyworld, oops :) yeah | 12:44 |
| wallyworld | sorry, couldn't resist :-) | 12:45 |
| jamestunnicliffe | Hi guys, just trying to go get -v launchpad.net/juju-core/... and I am getting some errors. http://paste.ubuntu.com/8986334/ | 12:49 |
| wallyworld | jamestunnicliffe: juju source code has migrated to github | 12:50 |
| jamestunnicliffe | wallyworld: ah, thanks! | 12:50 |
| wallyworld | https://github.com/juju/juju | 12:51 |
| jamestunnicliffe | wallyworld: that didn't build juju, but I got charm-admin, charmd and charmload out of it. Only message was | 12:59 |
| jamestunnicliffe | src/github.com/juju/juju/state/backups/metadata/metadata.go:71: m.SetFile undefined (type *Metadata has no field or method SetFile) | 12:59 |
| jamestunnicliffe | (go install -v github.com/juju/juju/...) | 12:59 |
| jamestunnicliffe | well, got plenty of non-errors as well | 13:00 |
| jamestunnicliffe | (or warning?) | 13:00 |
| wallyworld | i haven't pulled the entire source plus deps in a while but i thought go get would have worked | 13:00 |
| wallyworld | godeps is a tool that pulls all the right dependencies | 13:02 |
| wallyworld | go get launchpad.net/godeps | 13:02 |
| wallyworld | and then from the juju root dir godeps -u dependencies.tsv i think | 13:02 |
| jamestunnicliffe | wallyworld: that got it. Thanks! | 13:04 |
| wallyworld | \o/ great :-) | 13:04 |
| jamestunnicliffe | wallyworld: right, now I have a juju that will cooperate with my lxc (I am running trusty), I am trying that demo from yesterday's charm school. I am getting an error in the debug-log: | 13:13 |
| jamestunnicliffe | machine-0: 2014-11-13 13:08:33 ERROR juju.apiserver apiserver.go:281 error serving RPCs: error receiving message: read tcp 10.0.3.253:49477: connection reset by peer | 13:13 |
| jamestunnicliffe | machine-0: 2014-11-13 13:08:36 WARNING juju.worker.instanceupdater updater.go:246 cannot get instance info for instance "dooferlad-local-machine-1": no instances found | 13:13 |
| jamestunnicliffe | is that because I am running juju out of my home directory, but there are some services on my machine running an older version? | 13:13 |
| jamestunnicliffe | I bootstrapped my environment with --upload-tools as it says in the README | 13:14 |
| wallyworld | jamestunnicliffe: hard to say without a little more info - output of juju status, plus the complete all-machines log file | 13:15 |
| jamestunnicliffe | wallyworld: http://paste.ubuntu.com/8986797/ | 13:17 |
| wallyworld | jamestunnicliffe: nothing jumps out immediately. although juju status shows 1.21-alpha1 and if you are running from source (master) the version should show 1.22-alpha1 i think | 13:21 |
| wallyworld | if you have pulled the source, you could try cleaning up the current environment and trying again using the source you have pulled. go install github/juju/juju/... and then juju bootstrap etc | 13:23 |
| jamestunnicliffe | I am getting 1.22-alpha1-trusty-amd64 out of juju --version | 13:23 |
| jamestunnicliffe | OK, will give it a go. | 13:23 |
| wallyworld | that implies the juju in you path is an older binary | 13:23 |
| wallyworld | i have to drop off irc, after 11pm here, but someone else should be able to help you further | 13:24 |
| jamestunnicliffe | thanks wallyworld | 13:24 |
| wallyworld | np, sorry i can't hang around, tired | 13:25 |
| jamestunnicliffe | np, have a 3 month old daughter. Know the feeling :-) | 13:25 |
| wallyworld | ah, i miss those days | 13:25 |
| jw4 | dimitern, fwereade : about initial events in idPrefixWatcher - wrote failing test, and fixed bug LP-1391914 - merged last night : http://reviews.vapour.ws/r/417 | 13:35 |
| jw4 | dimitern: you wanted to see the changes. I'll plan on the same test and fix for the machineInterfacesWatcher today if that seems good. | 13:37 |
| dimitern | jw4, hey, yes I looked at the proposal and it looked nice | 13:46 |
| jw4 | dimitern: cool | 13:47 |
| perrito666 | ericsnow: ping | 14:27 |
| axw | wallyworld: doh. I have a PR up for it. | 14:32 |
| ericsnow | perrito666: hey | 14:41 |
| perrito666 | ericsnow: hey, I just merged with master and found that there is an import cycle caused by state/backups.go | 14:42 |
| perrito666 | ericsnow: and there is a potential other coming | 14:42 |
| perrito666 | since I need agent into the mix too | 14:43 |
| perrito666 | so I need to move NewBackups into state/backups/... any suggestions? | 14:43 |
| ericsnow | perrito666: that's one of the reasons state, etc. shouldn't leak into the state/backups package | 14:43 |
| ericsnow | perrito666: that shouldn't need to move | 14:44 |
| ericsnow | perrito666: before I start making assumptions, what is the cycle? | 14:45 |
| perrito666 | ericsnow: it is exactly the oposite | 14:48 |
| perrito666 | state/backups.go imports state/backups package | 14:48 |
| perrito666 | which imports environments | 14:48 |
| ericsnow | perrito666: correct | 14:48 |
| perrito666 | which imports agent | 14:48 |
| perrito666 | which imports state | 14:48 |
| perrito666 | so actually leaking state all over backups would be harmless | 14:49 |
| ericsnow | perrito666: where is environment imported? | 14:49 |
| perrito666 | restore | 14:49 |
| ericsnow | perrito666: so that env-related code should go in state/backups.go, right? | 14:50 |
| perrito666 | ericsnow: yes | 14:50 |
| perrito666 | or in state, but that is clearly out of the question :p | 14:50 |
| ericsnow | perrito666: the trickiest part of the backups implementation was sorting out the import cycles and state/backups.go was a big part of that | 14:51 |
| perrito666 | so you mean that if I move your function out of there Ill have another cycle? | 14:51 |
| ericsnow | perrito666: dependencies on state/env within state/backups cause cycles | 14:52 |
| ericsnow | perrito666: so I'd be surprised if it didn't | 14:53 |
| perrito666 | ok, ill try | 14:53 |
| ericsnow | perrito666: thanks | 14:53 |
| perrito666 | where would you like to have your NewBackups if not in state/backups.go ? | 14:53 |
| ericsnow | perrito666: NewBackups should stay in state/backups.go | 14:55 |
| ericsnow | perrito666: you may need to pull something out into apiserver/backups | 14:56 |
| ericsnow | perrito666: I had to do that with env storage before we switched to gridfs | 14:56 |
| ericsnow | perrito666: but that shouldn't need to impact the existing code | 14:57 |
| perrito666 | there is no reason to move things to apiserver | 14:57 |
| perrito666 | mmmpf, I really dont want to have yet another namespace here but seems I am going that way | 14:59 |
| ericsnow | perrito666: if you have a minute, let's talk about it over a hangout | 15:00 |
| perrito666 | ericsnow: not really, lets talk about it in the standup | 15:01 |
| ericsnow | perrito666: k | 15:01 |
| ericsnow | perrito666: would you mind pushing up your diff to RB? | 15:01 |
| perrito666 | ericsnow: I actually would, it does not compile at present | 15:02 |
| perrito666 | but the method that uses environments is there already | 15:02 |
| perrito666 | something changed lately | 15:02 |
| perrito666 | it is newStateConnection on state/backups/restore.go | 15:03 |
| ericsnow | perrito666: is there somewhere I could look at the code? | 15:03 |
| perrito666 | ericsnow: and well there will be another one when I import agent/ReadConfig | 15:05 |
| ericsnow | perrito666: the strategy is either to fix the cycles or get the information you need at a place where there are no cycles and bundle it up to pass into backups | 15:06 |
| ericsnow | perrito666: fixing the cycles is usually complicated | 15:07 |
| perrito666 | ericsnow: well it is not, I have done before | 15:07 |
| ericsnow | perrito666: no, I mean making it so that there isn't a state -> env -> agent -> state cycle | 15:08 |
| perrito666 | ericsnow: the issue here is state -> backups -> env -> agent | 15:08 |
| perrito666 | so to me the issue is state -> backups | 15:08 |
| ericsnow | perrito666: for provider storage I took the pull/bundle route | 15:09 |
| wwitzel3 | perrito666, ericsnow: I'm in the 1/2 day tosca review if you guys want to standup without me. | 15:09 |
| perrito666 | wwitzel3: you must be thrilling | 15:09 |
| dimitern | voidspace, TheMue, a quick review? http://reviews.vapour.ws/r/431/diff/2/ - this is just a backport of the same fix, to 1.21 | 15:10 |
| wwitzel3 | perrito666: well the meeting it being run well, so it actually isn't bad :) .. we are going through each issue in the TOSCA tracker and resolving, putting a pin in it, or deleting it. | 15:10 |
| perrito666 | that is actually useful | 15:10 |
| wwitzel3 | perrito666: kind of theraputic in a way and it bringing me up to speed on somethings I didn't know about :) | 15:10 |
| wwitzel3 | perrito666: but as me again at hour number 3 :P | 15:10 |
| wwitzel3 | ask | 15:11 |
| TheMue | dimitern: later, currently meeting | 15:12 |
| dimitern | TheMue, np | 15:12 |
| voidspace | dimitern: sure | 15:21 |
| voidspace | dimitern: lgtm | 15:26 |
| dimitern | voidspace, thanks! | 15:26 |
| perrito666 | ericsnow: there, I fixed the import cycle | 15:28 |
| perrito666 | :p | 15:28 |
| perrito666 | that was easy | 15:28 |
| ericsnow | perrito666: nice | 15:28 |
| perrito666 | ericsnow: you have a set of constructors which are State+somethingElse related I just went from state to somethingElse | 15:29 |
| voidspace | dimitern: when you have a chance, can you have a quick glance at this (not a review) | 15:42 |
| voidspace | https://github.com/voidspace/juju/compare/listnetworks-maas | 15:42 |
| voidspace | dimitern: is this what you have in mind for maas ListNetworks | 15:42 |
| dimitern | voidspace, sure, looking | 15:42 |
| voidspace | dimitern: thanks | 15:42 |
| dimitern | voidspace, looks great so far | 15:45 |
| voidspace | dimitern: so far... you mean there should be more of it! | 15:45 |
| voidspace | dimitern: just needs testing (and maybe some polish) if the basic approach is ok | 15:46 |
| dimitern | voidspace, just a couple of log messages near the end need to change slightly | 15:46 |
| voidspace | dimitern: ok, cool | 15:46 |
| voidspace | dimitern: thanks | 15:46 |
| voidspace | dimitern: much appreciated | 15:46 |
| dimitern | voidspace, it looks ok to me, but I'd like to see it when finished | 15:46 |
| voidspace | dimitern: sure | 15:47 |
| dimitern | voidspace, np, thank you | 15:47 |
| === Spads_ is now known as Spads | ||
| perrito666 | ericsnow: (type *API has no field or method backups) <-- something changed there? | 15:57 |
| ericsnow | perrito666: API in api/backups/ ? | 15:57 |
| perrito666 | apiserver/backups/restore.go in this case | 15:58 |
| alexisb | gsamfira, ping | 15:59 |
| alexisb | fwereade, ping | 15:59 |
| ericsnow | perrito666: apiserver/backups.API doesn't have backups any longer | 16:00 |
| fwereade | alexisb, pong | 16:00 |
| ericsnow | perrito666: use newBackups instead; see create.go for an example | 16:00 |
| perrito666 | ericsnow: ok | 16:00 |
| alexisb | fwereade, was curious if gsamfira had a chance to port the reboot work to 1,21-beta | 16:00 |
| ericsnow | perrito666: standup? | 16:01 |
| alexisb | the release team has agreed to accept it but we need to get it to them asap | 16:01 |
| perrito666 | oh true, let me fetch some form of headphone | 16:01 |
| fwereade | alexisb, I thought he had, I had him coordinating with mgz yesterday or the day before | 16:01 |
| alexisb | fwereade, ah ol | 16:02 |
| alexisb | ok | 16:02 |
| alexisb | I may be late to the game | 16:02 |
| alexisb | which is my bad, I have been out for a few days | 16:02 |
| fwereade | alexisb, no, looks like it never got an actual $$merge$$: https://github.com/juju/juju/pull/1098 | 16:02 |
| perrito666 | alexisb: fwereade https://github.com/juju/juju/pull/1098 | 16:02 |
| perrito666 | heh | 16:02 |
| alexisb | perrito666, fwereade can one of you get it merged? | 16:02 |
| fwereade | mgz, sinzui: any objections to me pulling the trigger there? | 16:02 |
| mgz | fwereade: go for it | 16:03 |
| sinzui | fwereade, Please merge it | 16:03 |
| * fwereade has pressed the button | 16:03 | |
| fwereade | ericsnow, btw, not sure you saw yourself flagged in https://github.com/juju/juju/pull/1098 ? | 16:04 |
| ericsnow | fwereade: didn't see that | 16:05 |
| ericsnow | fwereade: still looking into it though | 16:05 |
| fwereade | ericsnow, was really just a heads up, on the basis that it's likely enough work that you should make sure it's scheduled rather than trying to fit it into the gaps | 16:06 |
| ericsnow | fwereade: got it | 16:06 |
| natefinch | wwitzel3: you on the tosca call? Or are you going to come to the standup? either is ok | 16:07 |
| perrito666 | wouldn't it be nice to have picture in picture for meetings? | 16:08 |
| wwitzel3 | natefinch: I'm on the tosca call | 16:08 |
| natefinch | wwitzel3: that's the bug triage one, right? I was on it before I left for the cross team meeting | 16:09 |
| wwitzel3 | natefinch: we are going through the open issues in the tosca tracker, 5 minute time box per issue | 16:09 |
| natefinch | wwitzel3: ok cool | 16:09 |
| wwitzel3 | natefinch: yeah | 16:09 |
| natefinch | (ish) | 16:09 |
| wwitzel3 | haha | 16:09 |
| wwitzel3 | natefinch: it is over at 1pm, he had a break at 10:30, so we might do another at noon or just go til the end. | 16:10 |
| perrito666 | heh, my dog tries to be on camera for the standup the day my cam is not working :p | 16:23 |
| fwereade | alexisb, it's merged now | 16:30 |
| alexisb | fwereade, sweet | 16:30 |
| jamestunnicliffe | alexisb: hangout time? | 16:32 |
| alexisb | hey jamestunnicliffe ! | 16:34 |
| jw4 | fwereade, dimitern - machineInterfacesWatcher does not suffer from the same defect that idPrefixWatcher did - fyi | 16:53 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| wwitzel3 | fwereade: another look over http://reviews.vapour.ws/r/318/ would be great | 16:59 |
| === kadams54-away is now known as kadams54 | ||
| fwereade | wwitzel3, reviewed, bbl | 17:38 |
| === jog_ is now known as jog | ||
| === Spads_ is now known as Spads | ||
| === Spads_ is now known as Spads | ||
| sinzui | natefinch, Can you ask someone to look into bug 1392390 I expect the issue may need to be handed off to several people to get the fix merged and tested for tomorrow's release/ | 17:54 |
| mup | Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392390> | 17:54 |
| natefinch | sinzui: ok, will do | 18:01 |
| === tasdomas` is now known as tasdomas | ||
| natefinch | wwitzel3: you around? | 18:05 |
| wwitzel3 | natefinch: yeah | 18:14 |
| wwitzel3 | natefinch: was about to hit lunch, the tosca call is over now | 18:14 |
| natefinch | wwitzel3: np, thanks for taking all that time to be on that call | 18:15 |
| natefinch | wwitzel3: for your reward, can you look at the bug sinzui linked above? | 18:15 |
| natefinch | (after lunch of course) | 18:15 |
| wwitzel3 | natefinch: yeah, do we have a maas to test with? | 18:16 |
| natefinch | wwitzel3: not to my knowledge. sinzui - do we have a test maas? | 18:17 |
| wwitzel3 | natefinch: I can reinstall my virtual maas setup, I just haven't got to it since my reinstall | 18:17 |
| sinzui | natefinch, wwitzel3 We test stable and devel maas http://reports.vapour.ws/releases/2069 | 18:18 |
| sinzui | wwitzel3, I don't think we have setup zones | 18:19 |
| mattyw | night all | 18:27 |
| perrito666 | wwitzel3: natefinch hey I found someone else that upgraded to an unstable version of juju | 18:34 |
| jjox | hi guys - perrito666 is helping me with a bad juju upgrade-juju issue | 18:34 |
| jjox | original: 1.18.4-trusty-amd64 | 18:34 |
| jjox | did: juju upgrade-juju --upload-tools --version=1.20.11 | 18:35 |
| jjox | but seeing: | 18:35 |
| jjox | drwxr-xr-x 2 root root 4096 Jul 29 17:52 1.18.4-trusty-amd64 | 18:35 |
| jjox | drwxr-xr-x 2 root root 4096 Nov 13 18:14 1.19.4-trusty-amd64 | 18:35 |
| jjox | lrwxrwxrwx 1 root root 19 Nov 13 18:10 machine-0 -> 1.19.4-trusty-amd64 | 18:35 |
| jjox | lrwxrwxrwx 1 root root 19 Nov 13 18:14 unit-ksplice-9 -> 1.19.4-trusty-amd64 | 18:35 |
| jjox | then at log: | 18:35 |
| jjox | 2014-11-13 18:32:11 ERROR juju.worker.instanceupdater updater.go:267 cannot set addresses on "0": cannot set addresses of machine 0: cannot set | 18:35 |
| jjox | addresses for machine 0: state changing too quickly; try again soon | 18:35 |
| jjox | also | 18:35 |
| jjox | 2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:776 upgrade to 1.19.4-trusty-amd64 already completed. | 18:35 |
| jjox | 2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:757 upgrade to 1.19.4-trusty-amd64 completed. | 18:35 |
| jjox | this is on a canonical bootstack deployment, owned by Canonical (IS team) | 18:37 |
| jjox | is there any way I can force the upgrade to 1.20.x , and/or recover this ? | 18:38 |
| jjox | found above ERROR at https://bugs.launchpad.net/juju-core/+bug/1334773 fwiw | 18:39 |
| mup | Bug #1334773: Upgrade from 1.19.3 to 1.19.4 cannot set machineaddress <landscape> <lxc> <maas-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Released by axwalk> <juju-core 1.20:Fix Released by axwalk> <https://launchpad.net/bugs/1334773> | 18:39 |
| jjox | which perfectly matches my unwanted running version at node0 :( | 18:39 |
| jjox | FYI $ juju --version | 18:42 |
| jjox | 1.20.11-trusty-amd64 | 18:42 |
| wwitzel3 | natefinch: ok, installing a virtual maas now. I will get a couple zones setup, fill one, and reproduce the error, hopefully that will direct me towards the fix. | 18:46 |
| wwitzel3 | natefinch: reading the code where we iterator over the zones didn't expose anything obvious to me | 18:47 |
| wwitzel3 | and the selection code seems sane | 18:47 |
| natefinch | wwitzel3: where's that code? | 18:54 |
| voidspace | right folks, g'night | 18:58 |
| sinzui | natefinch, wwitzel3 : bugger, this is a related regression to maas zones bug 1392411 | 19:05 |
| mup | Bug #1392411: bootstrap on multi-zone MAAS leaves 'Allocated' nodes in all zones <cloud-installer> <landscape> <maas-provider> <regression> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1392411> | 19:05 |
| perrito666 | natefinch: meet jjox the only other person that managed to upgrade himself into 1.19 | 19:21 |
| jjox | and feel not so-much-happy about it. | 19:23 |
| natefinch | hi, I'm only half here, have a 1 year old in my lap currently. | 19:24 |
| natefinch | sinzui: do you remember if we were ever able to fix the other guy who managed to get onto 1.19? | 19:24 |
| sinzui | natefinch, I think a lot of db surgery was performed along with crafted configs | 19:25 |
| sinzui | natefinch, has it happened again? | 19:25 |
| perrito666 | sinzui: it has | 19:25 |
| * sinzui wonders if devel agents can ever be removed from released streams | 19:26 | |
| jjox | sinzui: I dumped what I did + found at logs ~20lines above | 19:26 |
| jjox | fyi this was: | 19:26 |
| jjox | juju upgrade-juju --upload-tools --version=1.20.11 | 19:26 |
| jjox | juju --version | 19:26 |
| jjox | 1.20.11-trusty-amd64 | 19:27 |
| sinzui | Juju CI used to test downgrades. they work very well juju upgrade== version=1.20.11 should work | 19:27 |
| sinzui | jjox, upload-tools is only needed if your env doesn't have network, or you are genunienly testing hacked juju | 19:28 |
| jjox | sinzui: was my understanding that we were firewalled (which later found not to be the case) | 19:28 |
| perrito666 | sinzui: btw, it did not work in this case | 19:28 |
| perrito666 | it did not upload current tools | 19:28 |
| perrito666 | and certainly did not mark them with the specified version | 19:28 |
| perrito666 | sinzui: do we have downgrade from develo -> stable? | 19:29 |
| sinzui | jjox, perrito666 downgrades do work, be we stopped testing it every revision a few months ago when we found a better way to make juju test the version we select | 19:29 |
| jjox | sinzui: how safe would be to 1) shutdown+backup mongodb 2) try downgrade to 1.18 ? if fails -> restore 1) ? | 19:30 |
| jjox | and binary symlinks, etc | 19:30 |
| sinzui | jjox, juju backup-and restore is not reliable with 1.18 and 1.19 | 19:31 |
| sinzui | jjox, if you have network, lets try to force a new configuration to upgrade... | 19:32 |
| jjox | sinzui: was thinking backup as in 'stop juju-db; tar ...' | 19:32 |
| jjox | sinzui: upgrade as in to 1.20 ? | 19:32 |
| sinzui | jjox, that is a proven recipe to destroy and env | 19:32 |
| sinzui | jjox, backup is selective about what gets copied...to much is bad | 19:33 |
| jjox | sinzui: ok | 19:33 |
| sinzui | jjox, juju set-env tools-metadata-url=http://streams.canonical.com/juju/tools/ | 19:33 |
| sinzui | juju upgrade-juju --version=1.20.11 --show-log | 19:34 |
| jjox | sinzui: ok - before doing the upgrade-juju, just to be sure we're in sync: | 19:35 |
| jjox | sinzui: this was 1.18.4, asked to be upgrded to 1.20.11 ( --upload-tools ) but got 1.19.4 | 19:36 |
| jjox | sinzui: with above ^ -> then ok (doing: juju upgrade-juju --version=1.20.11 --show-log) ? | 19:36 |
| sinzui | okay, thank you for being clear how you got into the awful state. Go ahead and upgrade after being explicit about the source of agents | 19:37 |
| jjox | (sorry to repeat myself here, but just wanted to be sure you got the full context ok) | 19:37 |
| jjox | sinzui: cool, ta. | 19:38 |
| jjox | running | 19:38 |
| sinzui | jjox, I think your case here is similar to the other cases where streams were ignored | 19:38 |
| wwitzel3 | natefinch: github.com/juju/juju/provider/maas | 19:38 |
| jjox | sinzui: failed with: | 19:38 |
| jjox | https://pastebin.canonical.com/120428/ | 19:38 |
| sinzui | jjox, okay, this is not so bad...juju will honour the upgrade if we get everything else upgraded | 19:39 |
| sinzui | jjox, that is a lot of machines. while upgrades can happen in 2 minutes, I have seen it take 1h. How long have you been waiting | 19:40 |
| jjox | sinzui: fwiw those units are all trashable, if needed | 19:40 |
| jjox | sinzui: ~1.5hs | 19:40 |
| sinzui | :( | 19:40 |
| jjox | sinzui: would restarting those agents help? | 19:40 |
| sinzui | jjox, YES | 19:40 |
| jjox | doing | 19:40 |
| jjox | sinzui: FYI juju status -> https://pastebin.canonical.com/120424/ | 19:41 |
| jjox | sinzui: took ~10mins to output | 19:41 |
| sinzui | jjox, juju-ci is a juju-env with rare archs like arm64. I have had to restart the agents to complete an upgrade. | 19:41 |
| jjox | sinzui: fun, at https://pastebin.canonical.com/120424/ 18/lxc/0: shows dns-name: 127.0.0.1 | 19:42 |
| sinzui | jjox, I had a case where an agent wasn't fully downloaded, stalling everything. I saw the url in the unit or machine long. I copied and pasted in the terminal to complete the download, then updated a symlink to point to t new agent, a restart unblocked everything. | 19:44 |
| jjox | sinzui: so, eg 18/lxc/0 (just restarted) - > $ /var/lib/juju/tools/machine-18-lxc-0/jujud --version | 19:45 |
| jjox | 1.18.4-precise-amd64 | 19:45 |
| jjox | seeing there -> 2014-11-13 19:45:05 ERROR juju.worker runner.go:218 exited "machiner": cannot set machine addresses of machine 18: cannot set machineaddresses for machine 18: state changing too quickly; try again soon | 19:45 |
| sinzui | jjox, yeah, I just suspected that would happen. | 19:46 |
| jjox | sinzui: you think it'd be feasible to destroy (and succeed) those services + units ? FYI these are landscape , nagios extras I was trying to complete to setup. | 19:46 |
| * sinzui thinks about how to intervene with 18's lxcs | 19:47 | |
| jjox | FYI this is a running bootstack | 19:47 |
| sinzui | jjox, I recall from the first incident that an address was blank in the unit's agent config. the fix was to add the missing address and restart the agents | 19:49 |
| jjox | where's that ? | 19:49 |
| jjox | /etc/init guess, lookin | 19:49 |
| * sinzui looks at a working machine to see | 19:49 | |
| perrito666 | jjox: /var/lib/juju/agents/yourmachine/agent.conf | 19:49 |
| jjox | ah, k | 19:49 |
| jjox | apiaddresses: | 19:50 |
| jjox | - 172.20.161.8:17070 | 19:50 |
| jjox | stateaddresses: | 19:50 |
| jjox | - 172.20.161.8:37017 | 19:50 |
| perrito666 | that is (should be) ok | 19:50 |
| sinzui | jjox, yep in each lxc container is a /var/lib/juju/agents/unit-*-0/agent.conf that might be missing the api and state server addresses | 19:52 |
| jjox | sinzui: all there ok afaics : https://pastebin.canonical.com/120430/ | 19:53 |
| sinzui | yep, I think w want to check if the agent was downloaded jjox , let me review my example machine | 19:54 |
| jjox | ta | 19:54 |
| jjox | sinzui: not there fyi: | 19:55 |
| jjox | root@infra:~# ls -ld /var/lib/lxc/juju-machine-18-lxc-*/rootfs/var/lib/juju/tools/1.* | 19:55 |
| jjox | drwxr-xr-x 2 root root 4096 Aug 15 21:15 /var/lib/lxc/juju-machine-18-lxc-0/rootfs/var/lib/juju/tools/1.18.4-precise-amd64 | 19:55 |
| jjox | drwxr-xr-x 2 root root 4096 Aug 15 21:15 /var/lib/lxc/juju-machine-18-lxc-1/rootfs/var/lib/juju/tools/1.18.4-precise-amd64 | 19:55 |
| jjox | drwxr-xr-x 2 root root 4096 Aug 15 21:15 /var/lib/lxc/juju-machine-18-lxc-2/rootfs/var/lib/juju/tools/1.18.4-trusty-amd64 | 19:55 |
| sinzui | jjox, we can see the version used in a container by ls -l /var/lib/juju/tools/ | 19:55 |
| jjox | sinzui: guess we crossed in irc , pasted above | 19:56 |
| sinzui | jjox, I have updated the symlink and restarted to proc before with success | 19:56 |
| sinzui | but we need to get the agent first | 19:56 |
| jjox | sinzui: ok, I'll surgically rsync them there, and symlink, and restart | 19:57 |
| sinzui | jjox, +1 | 19:57 |
| jjox | sinzui: ok - sweep dload + symlinked all 18-lxc | 20:15 |
| jjox | but still getting some agents have not upgraded to the current environment version 1.19.4: machine-18-lxc-0 ... | 20:15 |
| natefinch | wwitzel3: btw, I posted on that bug - there at least definitely is a "default" zone (or at least their api reported one) | 20:15 |
| jjox | checking there for the running binary from ps , to confirme. | 20:15 |
| jjox | 21373 ? Ssl 0:00 /var/lib/juju/tools/machine-18-lxc-0/jujud machine --data-dir /var/lib/juju --machine-id 18/lxc/0 --debug | 20:16 |
| natefinch | wwitzel3: also, I'm not convinced juju didn't try all zones and then only report the failure for the last one | 20:16 |
| jjox | (at the 18 host ) ^ | 20:16 |
| sinzui | jjox, have any on the lxc upgraded? | 20:16 |
| jjox | sinzui: root@infra:~# /var/lib/lxc/juju-machine-18-lxc-0/rootfs//var/lib/juju/tools/machine-18-lxc-0/jujud --version | 20:16 |
| jjox | 1.19.4-trusty-amd64 | 20:16 |
| jjox | sinzui: froma bove: sure running binary is 1.19.4, but still seen as not upgraded | 20:17 |
| jjox | sinzui: note fwiw that juju status is giving 127.0.0.1 as public address for that one (pastebin with juju status) | 20:17 |
| sinzui | juju has trouble with lxc/kvm addresses | 20:18 |
| jjox | sinzui: I've seen juju 10.0.3.x bipolarity, but 127.x is the 1st time I do | 20:19 |
| jjox | sinzui: anyway - | 20:19 |
| jjox | sinzui: just by luck, happens that these are really trashable | 20:19 |
| jjox | sinzui: would it make sense to try riping them ? | 20:20 |
| sinzui | machine 0 upgraded and its lxc's say 127.0.0.1 is public. I am looking for an option to make juju go though an upgrade, but I agree that sometimes it is better to replace broken machines | 20:20 |
| sinzui | jjox, if you destroy the units, try to complete the upgrade to 1.20.11 then redeploy | 20:22 |
| jjox | sinzui: ok (assuming redeploy== redeploy these ones only - others are not an option) | 20:22 |
| sinzui | jjox, you can deploy individual services back to the machine like this: juju deploy -to 18/lxc/0 <service> | 20:23 |
| jjox | yep, ok | 20:24 |
| sinzui | or juju deploy -to 18/lxc | 20:24 |
| jjox | intersting, didn't know about the 'full' --to 18/lxc/0 case | 20:24 |
| sinzui | jjox, I think the case is sort of odd because machines are incrementally named. maybe I remember wrongly | 20:25 |
| jjox | ok | 20:25 |
| thumper | just realised that I hadn't started my irc client... | 20:30 |
| jjox | sinzui: https://pastebin.canonical.com/120432/ <- life: dying ... | 20:30 |
| sinzui | jjox, okay, we may need to wait 5 more minutes. as machine 18 is listed as down, I wonder if we need juju destroy-machine 18 | 20:33 |
| sinzui | jjox, and maybe we need a --force to tell juju unregister it and ask the provider to make it go away now | 20:33 |
| === kadams54 is now known as kadams54-away | ||
| jjox | sinzui: but would terminate-machine --force work if there still units on it ? | 20:41 |
| sinzui | jjox, I don't know. of the other units to die, then we can used destroy-machine --force 18/lxc/1 | 20:42 |
| jjox | sinzui: stars-aligning : --force 18/lxc/N goes by | 20:44 |
| jjox | sinzui: but eg landscape/0 still showing: | 20:46 |
| jjox | life: dying | 20:46 |
| jjox | machine: 18/lxc/1 | 20:46 |
| sinzui | jjox, I need to rescue a child. I will be back in 15 minutes | 20:48 |
| jjox | sinzui: tnx | 20:48 |
| jjox | sinzui, perrito666 : wow, cool - terminate machine on those lxc/18/N atually kicked in at provider (saw a shutdown ... at the lxc) | 20:52 |
| jjox | and that f*xing service is gone. | 20:52 |
| jjox | peeking at other ones. | 20:52 |
| perrito666 | \o/ | 20:52 |
| jjox | yeah | 20:52 |
| jjox | that '5mins' sinzui magic value seem to have worked. | 20:53 |
| sinzui | jjox, okay, that means that --force wasn't too successful, but their is a fallback rule that if an machine agent hasn't called home and we don't needed, unregister it | 21:03 |
| wwitzel3 | natefinch: yep, read that comment, I grep'd for "default" first thing and noticed we don't hard code that anywere in gomaas or juju | 21:06 |
| wwitzel3 | natefinch: so I figured it must of been part of their setup | 21:06 |
| ericsnow | thumper: did you want to discuss the backups vs. backup topic? | 21:42 |
| * thumper thinks singular is better than plural | 21:45 | |
| thumper | otp with fwereade right now | 21:45 |
| thumper | saying 'juju backup restore' out loud doesn't sound as stupid as I thought | 21:45 |
| thumper | when you'd go 'juju backup create' or something | 21:46 |
| ericsnow | thumper: fWIW, I agree that "backup" is a better fit | 21:46 |
| ericsnow | thumper: yeah, I was thinking the same thing | 21:46 |
| ericsnow | thumper: my only additional concern is if we anticipate adding support for other kinds of backups down the road (e.g. charm-level backups) | 21:48 |
| ericsnow | thumper: then the use of "backup" for *state* backup would be a pain | 21:50 |
| ericsnow | thumper: we can pick this up when you're free | 21:50 |
| thumper | well... one things we do know | 21:51 |
| thumper | is that we'll want an 'unpriviliged' backup my environment thing | 21:51 |
| thumper | and a restore one... | 21:51 |
| thumper | not sure what that will look like yet | 21:51 |
| ericsnow | thumper: would that be the same (but limited) backup of state or would it entail other elements of the env? | 21:53 |
| thumper | it would likely be 'just state contents' | 21:53 |
| ericsnow | thumper: so that would still fit into the current model of backup | 21:53 |
| thumper | could be 'juju backup environment' | 21:54 |
| * thumper shrugs | 21:54 | |
| ericsnow | thumper: k | 21:54 |
| === Spads_ is now known as Spads | ||
| ericsnow | thumper: that reminds me, I wanted to talk with you about backups in a MESS world | 21:55 |
| ericsnow | thumper: I have a feeling that it won't work exactly right | 21:56 |
| thumper | ericsnow: which is what I was talking about | 21:56 |
| ericsnow | thumper: ah :) | 21:56 |
| thumper | ericsnow: happy to talk about it, just not right now | 21:56 |
| ericsnow | thumper: no worries; ping me when you're free | 21:57 |
| === kadams54-away is now known as kadams54 | ||
| waigani | thumper: I'm confused. Sent you an email. | 22:11 |
| thumper | ericsnow: I don't think a backup chat is going to happen today | 22:22 |
| thumper | ericsnow: lets try to catch up early next week | 22:22 |
| ericsnow | thumper: no worries | 22:22 |
| ericsnow | thumper: sounds good | 22:22 |
| thumper | ericsnow: are you needing a review on anything urgently? | 22:22 |
| thumper | or waiting on me for something? | 22:22 |
| ericsnow | thumper: if you wouldn't mind following up on the two you already reviewed, that would rock | 22:23 |
| thumper | ok | 22:23 |
| thumper | will do that after lunch | 22:23 |
| ericsnow | thumper: thanks | 22:23 |
| * davecheney starts to cry | 22:36 | |
| davecheney | *WHY DOES THE STATE PACKAGE DEPEND ON BAKCUPS!!!*!*! | 22:37 |
| perrito666 | davecheney: ah you also hit that | 22:37 |
| perrito666 | davecheney: cycle? | 22:38 |
| davecheney | you're killing me people | 22:38 |
| davecheney | perrito666: no, not a cycle | 22:38 |
| davecheney | but it's arse about | 22:38 |
| perrito666 | davecheney: I encountered a cycle bc of that and removed that dependency | 22:38 |
| davecheney | mgo <- state <- api <- everything else | 22:38 |
| davecheney | this is how it needs to be | 22:38 |
| davecheney | perrito666: log a bug | 22:38 |
| davecheney | i'll add it to my list | 22:38 |
| perrito666 | davecheney: ok Ill log a bug and then assign it to me | 22:39 |
| perrito666 | since I already fixed that :p | 22:39 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | wallyworld: if you needed more info on the stable->devel update issue this is a canonical stack so you can have plenty | 23:24 |
| wallyworld | thanks | 23:25 |
| perrito666 | I believe I covered all that is required | 23:25 |
| wallyworld | why was upload tools used? | 23:26 |
| perrito666 | wallyworld: they believed they where more firewalled than what they actually where | 23:26 |
| perrito666 | so, even though one would have expected to have juju upload local tools it just donwloaded 1.19 from streams | 23:26 |
| perrito666 | I am sure there is a bug there, just cant discern it very clearly | 23:27 |
| wallyworld | i'm not convinced yet that it downloaded 1.19 | 23:27 |
| perrito666 | wallyworld: I sshd into the machine | 23:27 |
| perrito666 | it did | 23:27 |
| perrito666 | trust me | 23:27 |
| wallyworld | can we get all the logs | 23:27 |
| wallyworld | or can i ssh in | 23:27 |
| perrito666 | wallyworld: we certainly can, ask IS for it triumph.bot-prototype <- machine 0 | 23:28 |
| perrito666 | wallyworld: you can both, ssh into an IS machine require for them to share a screen with you | 23:28 |
| perrito666 | its like shopping with a guard next to you :p | 23:28 |
| wallyworld | i'd rather then just get the logs | 23:28 |
| perrito666 | wallyworld: that is the machine | 23:29 |
| wallyworld | ok | 23:29 |
| perrito666 | I am eod-ish, or I would get them for you :p | 23:29 |
| wallyworld | np, i'll ask them to :-) | 23:29 |
| wallyworld | thanks for info | 23:29 |
| perrito666 | what I saw is, neither the users machine nor the server had other way to get 1.19.n and the machine not being firewalled was perfectly able to get it from streams, I tried wgeting it and it was downloaded, and the agents where actually migrated to 1.19 except some that had failed | 23:30 |
| wallyworld | so the state server was firewalled? | 23:34 |
| jw4 | davecheney: what about github.com/juju/names package? should state not reference that ? | 23:49 |
| davecheney | no, it really shouldn't | 23:54 |
| davecheney | well | 23:54 |
| davecheney | the idea is that we don't want state depending on big bunchs of functionality | 23:55 |
| davecheney | liek the multiwatcher | 23:55 |
| davecheney | or backups | 23:55 |
| davecheney | or presence | 23:55 |
| davecheney | actually | 23:55 |
| davecheney | i can't talk about this | 23:55 |
| davecheney | i don't have a celar enough picture | 23:55 |
| davecheney | but please, stop adding dependnecies to state | 23:55 |
| davecheney | what I do believe is the public api methods on state should only take types that are defined in the state package | 23:56 |
| davecheney | or primative types | 23:56 |
| davecheney | names is a good example | 23:56 |
| davecheney | and we do break this promise in one location | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
