[00:00] <jw4> thumper: related to your recent change http://reviews.vapour.ws/r/419/
[00:01] <menn0> davecheney: finished reviewing the set change
[00:02] <menn0> davecheney: was that an intentional propellerheads reference?
[00:05] <menn0> davecheney: i'm not sure i understand what you mean regarding RelationUnitsChange
[00:06] <menn0> davecheney: out the types you've moved in that PR, it's the only one that isn't related to multiwatcher
[00:08] <menn0> davecheney: it isn't referred to or used by multiwatcher or allwatcher
[00:09] <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:10] <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:11] <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:12] <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:13] <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:16] <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:17] <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:18] <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:19]  * 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:20] <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:21] <ericsnow> davecheney: I have just a few follow-up comments in the review
[00:31] <katco> fwereade: lol sorry, wife and daughter just got home
[00:32] <thumper> katco: I think we all understand that :-)
[00:32] <katco> daughter has a fever :( we think maybe her teeth are coming in
[00:34] <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:35] <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:37] <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:48] <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:49] <davecheney> the contracts for the methods that use this do not reuqire or guarentee lexical sorting
[00:52] <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:58] <davecheney> yup
[00:58] <davecheney> package set; type String map[string]bool
[00:59] <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?
[01:02] <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:03] <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:11] <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:12] <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:13] <wallyworld> SameContents is your friend
[01:13] <fwereade> wallyworld, true
[01:13] <wallyworld> not DeepEquals
[01:14] <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:15] <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:28] <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:37]  * fwereade is really going to bed right now, but found http://thecodelesscode.com/case/167 amusing
[01:41] <katco> fwereade: you lie! but not in bed! ;)
[01:50] <thumper> davecheney: in godoc2md, is there a way to say "leave this bit" ?
[01:59] <davecheney> thumper: not really
[01:59] <davecheney> which bit ?
[01:59] <davecheney> do youi want a <pre /> section ?
[02:01] <thumper> davecheney: I just want output like this for the README.md:  [![GoDoc](https://godoc.org/github.com/juju/loggo?status.svg)](https://godoc.org/github.com/juju/loggo)
[02:02] <davecheney> ahh
[02:24] <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:29] <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:30] <ericsnow> davecheney: I'm going to revert the utils patch I merged a little while ago
[02:30] <davecheney> ericsnow: ok
[02:31] <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:32] <davecheney> thumper: +1
[02:32] <davecheney> ericsnow: ok
[02:32] <davecheney> but i don't really know what the problem is
[02:33] <davecheney> are you wanting to avoid updating dependencies.tsv twice ?
[02:36] <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:37] <ericsnow> davecheney: see https://github.com/juju/juju/pull/1119
[02:38] <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:39] <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:40] <davecheney> that will explain what the problem is
[02:42] <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:43] <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:44] <davecheney> right
[02:46] <ericsnow> davecheney: there should be a failed test in backups under PR1120
[02:47] <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:49] <ericsnow> davecheney: okeedokee :)
[02:51] <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:53] <davecheney> ericsnow: ok
[02:53] <davecheney> i see what has happened now
[02:54] <davecheney> please revert your utils change nad tell me the new hash
[02:54] <ericsnow> davecheney: will do
[02:56] <ericsnow> davecheney: b50b465fe6aceceb4d08f2093edaccb01e9d5fd4
[04:24] <wallyworld> axw: i decide to do the fix myself, to get it landed http://reviews.vapour.ws/r/426/
[04:25] <wallyworld> for the swift container issue
[04:26] <axw> wallyworld: cool. will look in a sec
[04:27] <wallyworld> ta, no hurry
[04:33] <axw> wallyworld: lgtm
[04:38] <wallyworld> axw: ty
[04:49] <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 :)
[05:04] <axw> wallyworld: were you +1ing my response or Katherine's comment about tags?
[05:04] <wallyworld> your response
[05:05] <axw> k
[05:26] <wallyworld> axw: thanks for fixes - i was unclear, i only meant the errors inside the loop
[05:29] <axw> wallyworld: cool
[06:11] <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:12] <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
[07:48] <davecheney> bot's broken, ya'll, https://github.com/juju/juju/pull/1116
[07:50] <axw> davecheney: ? there's a merge conflict
[07:50] <davecheney> sigh
[08:11] <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:12] <rogpeppe> axw: ^
[08:14] <axw> rogpeppe: I think if you follow the code location above the comment, it links to that rev/context
[08:14]  * axw tries
[08:15] <rogpeppe> axw: doesn't seem to work for me
[08:16] <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:18] <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:21] <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:22] <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:24] <wallyworld> dimitern: np, i'm keen to get beta2 unblocked :-)
[08:31] <dimitern> fwereade, ping
[08:31] <fwereade> dimitern, pong
[08:33] <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:34] <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:35] <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:36] <dimitern> fwereade, and re those 2 cases which set the charm url on the service or unit docs manually
[08:37] <dimitern> fwereade, I needed that so I can test the "sameCharm" or "differentCharm" assertions without messing up the settings refcount
[08:40] <fwereade> dimitern, hmm, would it be too unwieldy to preserve the refcount by setting charm urls on a distinct unit?
[08:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <fwereade> dimitern, indeed
[08:47] <fwereade> dimitern, I think the benefits of testing the actual interactions are pretty compelling
[08:48] <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:51] <dimitern> fwereade, alright
[08:51] <dimitern> fwereade, thanks, I'll implement your suggestions and land it then
[08:52] <fwereade> dimitern, cheers
[08:59] <voidspace> morning all
[09:01] <mattyw> morning everyone
[09:13] <TheMue> morning all
[09:34] <dimitern> morning mattyw, TheMue, voidspace
[09:34] <mattyw> dimitern, good morning
[09:35] <voidspace> dimitern: TheMue: o/
[09:36] <TheMue> o/
[09:53] <perrito666> morning
[10:43] <voidspace> dimitern: http://reviews.vapour.ws/r/429/diff/#
[10:43] <voidspace> dimitern: I'm getting coffee
[10:44] <dimitern> voidspace, looking
[10:44] <voidspace> dimitern: I'm getting coffee
[10:53] <dimitern> voidspace, LGTM +a couple of suggestions
[11:17] <voidspace> dimitern: thanks
[11:17] <voidspace> dimitern: your first suggestion looks good
[11:18] <voidspace> dimitern: I'm hesitant to add "will retry later" to the second message - will we retry?
[11:19] <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:21] <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:22] <dimitern> voidspace, it definitely looks like an error, an unexpected one even - which can be added to the log message
[11:23] <voidspace> dimitern: ok, I'll make it an Errorf
[11:23] <dimitern> voidspace, cheers
[11:24] <voidspace> dimitern: pushed, will merge...
[11:24] <perrito666> aghh really? another import cycle?
[11:25] <dimitern> voidspace, great, I pushed mine as well, finally
[11:26] <voidspace> dimitern: great
[11:26] <voidspace> perrito666: not so great
[11:29] <wallyworld> axw: hiya, i just noticed we assigned ourselves that tools bug at the same time
[11:30] <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:37] <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:38] <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:39] <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:40] <wallyworld> the first unit
[11:40] <wallyworld> and if that unit is removed, the other unit's links become invalid
[11:41] <fwereade> wallyworld, hmm, that is surely a problem, but shouldn't they just link to the jujud in their own tools dir?
[11:42] <wallyworld> likely, i haven't looked in tooo much detail, just reproduced the issue and saw the suboptimal symlinks
[11:57] <wallyworld> dimitern: i think you meant "Save warthogs!" :-p
[12:21] <perrito666> ericsnow: ping
[12:44] <dimitern> wallyworld, oops :) yeah
[12:45] <wallyworld> sorry, couldn't resist :-)
[12:49] <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:50] <wallyworld> jamestunnicliffe: juju source code has migrated to github
[12:50] <jamestunnicliffe> wallyworld: ah, thanks!
[12:51] <wallyworld> https://github.com/juju/juju
[12:59] <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/...)
[13:00] <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:02] <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:04] <jamestunnicliffe> wallyworld: that got it. Thanks!
[13:04] <wallyworld> \o/ great :-)
[13:13] <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:14] <jamestunnicliffe> I bootstrapped my environment with --upload-tools as it says in the README
[13:15] <wallyworld> jamestunnicliffe: hard to say without a little more info - output of juju status, plus the complete all-machines log file
[13:17] <jamestunnicliffe> wallyworld: http://paste.ubuntu.com/8986797/
[13:21] <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:23] <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:24] <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:25] <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:35] <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:37] <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:46] <dimitern> jw4, hey, yes I looked at the proposal and it looked nice
[13:47] <jw4> dimitern: cool
[14:27] <perrito666> ericsnow: ping
[14:32] <axw> wallyworld: doh. I have a PR up for it.
[14:41] <ericsnow> perrito666: hey
[14:42] <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:43] <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:44] <ericsnow> perrito666: that shouldn't need to move
[14:45] <ericsnow> perrito666: before I start making assumptions, what is the cycle?
[14:48] <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:49] <perrito666> so actually leaking state all over backups would be harmless
[14:49] <ericsnow> perrito666: where is environment imported?
[14:49] <perrito666> restore
[14:50] <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:51] <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:52] <ericsnow> perrito666: dependencies on state/env within state/backups cause cycles
[14:53] <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:55] <ericsnow> perrito666: NewBackups should stay in state/backups.go
[14:56] <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:57] <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:59] <perrito666> mmmpf, I really dont want to have yet another namespace here but seems I am going that way
[15:00] <ericsnow> perrito666: if you have a minute, let's talk about it over a hangout
[15:01] <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:02] <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:03] <perrito666> it is newStateConnection on state/backups/restore.go
[15:03] <ericsnow> perrito666: is there somewhere I could look at the code?
[15:05] <perrito666> ericsnow: and well there will be another one when I import agent/ReadConfig
[15:06] <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:07] <ericsnow> perrito666: fixing the cycles is usually complicated
[15:07] <perrito666> ericsnow: well it is not, I have done before
[15:08] <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:09] <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:10] <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:11] <wwitzel3> ask
[15:12] <TheMue> dimitern: later, currently meeting
[15:12] <dimitern> TheMue, np
[15:21] <voidspace> dimitern: sure
[15:26] <voidspace> dimitern: lgtm
[15:26] <dimitern> voidspace, thanks!
[15:28] <perrito666> ericsnow: there, I fixed the import cycle
[15:28] <perrito666> :p
[15:28] <perrito666> that was easy
[15:28] <ericsnow> perrito666: nice
[15:29] <perrito666> ericsnow: you have a set of constructors which are State+somethingElse related I just went from state to somethingElse
[15:42] <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:45] <dimitern> voidspace, looks great so far
[15:45] <voidspace> dimitern: so far... you mean there should be more of it!
[15:46] <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:47] <voidspace> dimitern: sure
[15:47] <dimitern> voidspace, np, thank you
[15:57] <perrito666> ericsnow:  (type *API has no field or method backups) <-- something changed there?
[15:57] <ericsnow> perrito666: API in api/backups/ ?
[15:58] <perrito666> apiserver/backups/restore.go in this case
[15:59] <alexisb> gsamfira, ping
[15:59] <alexisb> fwereade, ping
[16:00] <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:01] <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:02] <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:03] <mgz> fwereade: go for it
[16:03] <sinzui> fwereade, Please merge it
[16:03]  * fwereade has pressed the button
[16:04] <fwereade> ericsnow, btw, not sure you saw yourself flagged in https://github.com/juju/juju/pull/1098 ?
[16:05] <ericsnow> fwereade: didn't see that
[16:05] <ericsnow> fwereade: still looking into it though
[16:06] <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:07] <natefinch> wwitzel3: you on the tosca call?  Or are you going to come to the standup?  either is ok
[16:08] <perrito666> wouldn't it be nice to have picture in picture for meetings?
[16:08] <wwitzel3> natefinch: I'm on the tosca call
[16:09] <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:10] <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:23] <perrito666> heh, my dog tries to be on camera for the standup the day my cam is not working :p
[16:30] <fwereade> alexisb, it's merged now
[16:30] <alexisb> fwereade, sweet
[16:32] <jamestunnicliffe> alexisb: hangout time?
[16:34] <alexisb> hey jamestunnicliffe !
[16:53] <jw4> fwereade, dimitern - machineInterfacesWatcher does not suffer from the same defect that idPrefixWatcher did - fyi
[16:59] <wwitzel3> fwereade: another look over http://reviews.vapour.ws/r/318/ would be great
[17:38] <fwereade> wwitzel3, reviewed, bbl
[17:54] <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>
[18:01] <natefinch> sinzui: ok, will do
[18:05] <natefinch> wwitzel3: you around?
[18:14] <wwitzel3> natefinch: yeah
[18:14] <wwitzel3> natefinch: was about to hit lunch, the tosca call is over now
[18:15] <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:16] <wwitzel3> natefinch: yeah, do we have a maas to test with?
[18:17] <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:18] <sinzui> natefinch, wwitzel3 We test stable and devel maas http://reports.vapour.ws/releases/2069
[18:19] <sinzui> wwitzel3, I don't think we have setup zones
[18:27] <mattyw> night all
[18:34] <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:35] <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:37] <jjox> this is on a canonical bootstack deployment, owned by Canonical (IS team)
[18:38] <jjox> is there any way I can force the upgrade to 1.20.x , and/or recover this ?
[18:39] <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:42] <jjox> FYI $ juju --version
[18:42] <jjox> 1.20.11-trusty-amd64
[18:46] <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:47] <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:54] <natefinch> wwitzel3: where's that code?
[18:58] <voidspace> right folks, g'night
[19:05] <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:21] <perrito666> natefinch: meet jjox the only other person that managed to upgrade himself into 1.19
[19:23] <jjox> and feel not so-much-happy about it.
[19:24] <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:25] <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:26]  * 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:27] <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:28] <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:29] <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:30] <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:31] <sinzui> jjox, juju backup-and restore is not reliable with 1.18 and 1.19
[19:32] <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:33] <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:34] <sinzui> juju upgrade-juju --version=1.20.11 --show-log
[19:35] <jjox> sinzui: ok - before doing the upgrade-juju, just to be sure we're in sync:
[19:36] <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:37] <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:38] <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:39] <sinzui> jjox, okay, this is not so bad...juju will honour the upgrade if we get everything else upgraded
[19:40] <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:41] <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:42] <jjox> sinzui: fun, at https://pastebin.canonical.com/120424/ 18/lxc/0: shows dns-name: 127.0.0.1
[19:44] <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:45] <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:46] <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:47]  * sinzui thinks about how to intervene with 18's lxcs
[19:47] <jjox> FYI this is a running bootstack
[19:49] <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:50] <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:52] <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:53] <jjox> sinzui: all there ok afaics : https://pastebin.canonical.com/120430/
[19:54] <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:55] <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:56] <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:57] <jjox> sinzui: ok, I'll surgically rsync them there, and symlink, and restart
[19:57] <sinzui> jjox, +1
[20:15] <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:16] <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:17] <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:18] <sinzui> juju has trouble with lxc/kvm addresses
[20:19] <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:20] <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:22] <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:23] <sinzui> jjox, you can deploy individual services back to the machine like this: juju deploy -to 18/lxc/0 <service>
[20:24] <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:25] <sinzui> jjox, I think the case is sort of odd because machines are incrementally named. maybe I remember wrongly
[20:25] <jjox> ok
[20:30] <thumper> just realised that I hadn't started my irc client...
[20:30] <jjox> sinzui: https://pastebin.canonical.com/120432/ <- life: dying ...
[20:33] <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:41] <jjox> sinzui: but would terminate-machine --force work if there still units on it ?
[20:42] <sinzui> jjox, I don't know. of the other units to die, then we can used destroy-machine --force 18/lxc/1
[20:44] <jjox> sinzui: stars-aligning : --force 18/lxc/N goes by
[20:46] <jjox> sinzui: but eg landscape/0 still showing:
[20:46] <jjox>         life: dying
[20:46] <jjox>         machine: 18/lxc/1
[20:48] <sinzui> jjox, I need to rescue a child. I will be back in 15 minutes
[20:48] <jjox> sinzui: tnx
[20:52] <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:53] <jjox> that '5mins' sinzui magic value seem to have worked.
[21:03] <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:06] <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:42] <ericsnow> thumper: did you want to discuss the backups vs. backup topic?
[21:45]  * 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:46] <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:48] <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:50] <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:51] <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:53] <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:54] <thumper> could be 'juju backup environment'
[21:54]  * thumper shrugs
[21:54] <ericsnow> thumper: k
[21:55] <ericsnow> thumper: that reminds me, I wanted to talk with you about backups in a MESS world
[21:56] <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:57] <ericsnow> thumper: no worries; ping me when you're free
[22:11] <waigani> thumper: I'm confused. Sent you an email.
[22:22] <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:23] <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:36]  * davecheney starts to cry
[22:37] <davecheney> *WHY DOES THE STATE PACKAGE DEPEND ON BAKCUPS!!!*!*!
[22:37] <perrito666> davecheney: ah you also hit that
[22:38] <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:39] <perrito666> davecheney: ok Ill log a bug and then assign it to me
[22:39] <perrito666> since I already fixed that :p
[23:24] <perrito666> wallyworld: if you needed more info on the stable->devel update issue this is a canonical stack so you can have plenty
[23:25] <wallyworld> thanks
[23:25] <perrito666> I believe I covered all that is required
[23:26] <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:27] <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:28] <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:29] <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:30] <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:34] <wallyworld> so the state server was firewalled?
[23:49] <jw4> davecheney: what about github.com/juju/names package? should state not reference that ?
[23:54] <davecheney> no, it really shouldn't
[23:54] <davecheney> well
[23:55] <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:56] <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:57] <davecheney> and we do break this promise in one location