[00:00] thumper: related to your recent change http://reviews.vapour.ws/r/419/ [00:01] davecheney: finished reviewing the set change [00:02] davecheney: was that an intentional propellerheads reference? [00:05] davecheney: i'm not sure i understand what you mean regarding RelationUnitsChange [00:06] davecheney: out the types you've moved in that PR, it's the only one that isn't related to multiwatcher [00:08] davecheney: it isn't referred to or used by multiwatcher or allwatcher [00:09] davecheney: i think it belongs in state/watcher.go and everything that uses it can import it from state [00:09] jcsackett: hi [00:09] nope, not jcsackett, jw4 [00:09] hehe [00:09] I was guessing [00:09] I explicitly changed my nick to jw4 to suit fwereade who didn't like tabbing 3 times [00:10] davecheney: unless i'm missing something... [00:10] jw4: time between doesn't exclude boundaries [00:10] * fwereade feels bad now [00:10] fwereade: lol [00:10] thumper: I feel embarrassed if that's the case... [00:10] * fwereade *has* been appreciating jw though [00:10] even if that's not actually any easier to type than jw4 [00:10] jw4: I even added a test to testing/checkers to test boundaries [00:11] thumper: when I wrote that change I was thinking your fix was already in master [00:11] thumper: and something in the output lead me to beleive it was a boundary issue [00:11] jw4: nah, what it was was the serialisation in and out of mongo was losing precision [00:12] making it look like it was added before the start of the test [00:12] thumper: derp [00:12] thumper: okay. so just scratch that PR I guess? [00:12] fwereade: is in the little finger without stretching 4 is in the middle finger stretching, clearly tab is easier [00:12] if you do touch typing that is [00:12] jw4: yeah, I think so [00:12] thumper: ta [00:13] fwereade: I'm thinking of switching to /nick a~~~~ [00:13] 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] jw4, lol [00:13] jw4, don't make me rejig my muscle memory *again* [00:13] fwereade: hehe [00:16] 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] 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] katco, to be annoyingly enigmatic about it: http://thecodelesscode.com/case/97 [00:17] oh fark [00:17] meetings from 3-5 here [00:17] and 5-7 elsewhere tonight [00:17] katco, but I have not used protobuf in anger, and may be attacking straw men [00:17] hazaah [00:18] fwereade: get the feeling you are talking to yourself? [00:18] thumper, well, she sent an email 20 mins ago, so I feel it likely she will read it in the near future [00:18] uff meeting at 23 I so forgot that one [00:19] * thumper sighs [00:19] tomorrow is looking like a long meeting too [00:19] fwereade: can you do 9:30pm? [00:19] thumper, my 9:30? sure, will set an alarm now [00:19] fwereade: tomorrow night your time [00:19] pm [00:19] PM [00:19] thumper, perfect [00:20] ok [00:20] * thumper puts it in the calendar [00:20] davecheney: thanks for the reviews [00:20] davecheney: I've addressed most of the concerns in http://reviews.vapour.ws/r/402/ [00:21] davecheney: I have just a few follow-up comments in the review [00:31] fwereade: lol sorry, wife and daughter just got home [00:32] katco: I think we all understand that :-) [00:32] daughter has a fever :( we think maybe her teeth are coming in [00:34] 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] 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] 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] next on my shit list [00:48] why are almost all the values passed through a set sorted on the way out ? [00:49] the contracts for the methods that use this do not reuqire or guarentee lexical sorting [00:52] davecheney: i guess it depends on if it's a side-effect of ensuring uniqueness, or if it's explicitly performing sorting [00:52] davecheney: i haven't looked at that code, is it just using a map under the covers? [00:58] yup [00:58] package set; type String map[string]bool [00:59] so it's explicitly sorting? [00:59] yes, i'm seeing a lot of use of set.SortedValues [00:59] and I suspect it is so that the tests pass [00:59] ahh [00:59] not because the output is required to be sortedf [00:59] so to be clear, it's the callers at fault, not the set code? [01:02] katco: depends [01:02] 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] many of the things that are sorted [01:03] are only stable for testing data [01:03] ie, sorting a list of network interfaces [01:03] sorry, i guess what i meant is: is there a way of retrieving values from the set in a non-sorted way? [01:11] katco, fwiw, I feel we should by default be providing set-type results unsorted [01:11] fwereade: i agree [01:11] katco, we don't know in general whether a client cares about sorting them [01:11] katco, and when they don't care we're just wasting effort by testing them [01:11] fwereade: losing O(lg n) * # callers that don't need it [01:12] katco, exactly [01:12] that too [01:12] katco, so in general [01:12] katco, tests that say [sort expect] [sort actual] [assert actual == expect] STM to be the sweet spot [01:13] SameContents is your friend [01:13] wallyworld, true [01:13] not DeepEquals [01:14] katco, yes, wallyworld has it [01:14] katco, do you want a quick chat about protobuf and how you want to use it? [01:15] fwereade: have a stand-up right now [01:15] katco, in that case please ping me tomorrow when you get on? interested to talk [01:15] katco, but going to bed for now, I think [01:15] fwereade: no worries at all [01:15] fwereade: thank you, and sleep well :) [01:28] katco: fwereade i agree, i think gc.DeepEquals has forced the code to adopt to the test [01:28] s/adopt/adapt [01:37] * fwereade is really going to bed right now, but found http://thecodelesscode.com/case/167 amusing === kadams54-away is now known as kadams54 [01:41] fwereade: you lie! but not in bed! ;) [01:50] davecheney: in godoc2md, is there a way to say "leave this bit" ? [01:59] thumper: not really [01:59] which bit ? [01:59] do youi want a

 section ?
[02:01]  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]  ahh
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
[02:24]  davecheney: any way to format that code in the go docs, such that it makes something like that in the readme?
[02:24]  davecheney: or I may have to have a post process sed command :-)
[02:24]  oh... sed
[02:29]  thumper: try
[02:29]  \n
[02:29]      
[02:29]  \n
[02:29]  ie, intend like markdown
[02:29]  it's guess, it might work
[02:30]  davecheney: I'm going to revert the utils patch I merged a little while ago
[02:30]  ericsnow: ok
[02:31]  davecheney: I'll merge it back in once you land that core patch for the set stuff
[02:31]  davecheney: sed is easier :-) and I have a make target already
[02:32]  thumper: +1
[02:32]  ericsnow: ok
[02:32]  but i don't really know what the problem is
[02:33]  are you wanting to avoid updating dependencies.tsv twice ?
[02:36]  davecheney: apparently my merge landed in between the two set-related ones you have
[02:36]  davecheney: there should be a failing test in backups under http://reviews.vapour.ws/r/421/
[02:37]  davecheney: see https://github.com/juju/juju/pull/1119
[02:38]  ericsnow: i don't understand
[02:38]  we haven't updated to revision in dependencies.tsv yet
[02:38]  oh, you updated to a new revision
[02:38]  yup
[02:38]  that change hasn't landed
[02:38]  davecheney: so either I temporarily revert my utils merge or you roll PR1119 into yours
[02:39]  sorry, you'll have a merge conflict after 1120 lands
[02:39]  davecheney: I figured I'd just go the revert route
[02:39]  ericsnow: you don't ahve to revert anything
[02:39]  your change did not land
[02:39]  davecheney: my utils change landed, which breaks backups
[02:39]  ericsnow: how did it land ?
[02:39]  why did tests not pick that up >?
[02:39]  ericsnow: i'm really confuised
[02:39]  please send a PR
[02:40]  that will explain what the problem is
[02:42]  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]  ericsnow: no you didn't
[02:43]  nothing happens to juju core til dependencies.tsv is updated
[02:43]  davecheney: right
[02:43]  davecheney: which your patch does
[02:44]  right
[02:46]  davecheney: there should be a failed test in backups under PR1120
[02:47]  davecheney: if there's not then there's no need for me to revert anything :)
[02:47]  ericsnow: is the build broken ?
[02:47]  i don't think ti is
[02:47]  so i don't think there is anything to do
[02:49]  davecheney: okeedokee :)
[02:51]  ericsnow: one of our braches probably won't pass ci
[02:51]  i'll fix it if it fails
[02:51]  davecheney: cool, thanks
=== kadams54 is now known as kadams54-away
[02:53]  ericsnow: ok
[02:53]  i see what has happened now
[02:54]  please revert your utils change nad tell me the new hash
[02:54]  davecheney: will do
[02:56]  davecheney: b50b465fe6aceceb4d08f2093edaccb01e9d5fd4
=== 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
[04:24]  axw: i decide to do the fix myself, to get it landed http://reviews.vapour.ws/r/426/
[04:25]  for the swift container issue
[04:26]  wallyworld: cool. will look in a sec
[04:27]  ta, no hurry
[04:33]  wallyworld: lgtm
[04:38]  axw: ty
[04:49]  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]  jw4: you're welcome/thanks :)
[05:04]  wallyworld: were you +1ing my response or Katherine's comment about tags?
[05:04]  your response
[05:05]  k
[05:26]  axw: thanks for fixes - i was unclear, i only meant the errors inside the loop
[05:29]  wallyworld: cool
[06:11]  axw: would gr8ly appreciate if u could cast ur eyes over this again :-) http://reviews.vapour.ws/r/407/
[06:11]  wallyworld: ^^
[06:11]  sure
[06:12]  u r amazing! thnx ;-)
[06:12]  axw: just running away to get my bay - bitten!! i actively dislike young age
[06:12]  axw: brb
[07:48]  bot's broken, ya'll, https://github.com/juju/juju/pull/1116
[07:50]  davecheney: ? there's a merge conflict
[07:50]  sigh
[08:11]  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]  axw: ^
[08:14]  rogpeppe: I think if you follow the code location above the comment, it links to that rev/context
[08:14]  * axw tries
[08:15]  axw: doesn't seem to work for me
[08:16]  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]  axw: ah, got it, thanks
[08:18]  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
=== alexlist` is now known as alexlist
[08:21]  rogpeppe: the problem is people don't realise you can highlugh a section
[08:21]  not jhust a line
[08:21]  when you comment on a section, the comments make more sense
[08:21]  davecheney: to make a comment?
[08:21]  but nobody knows that
[08:22]  davecheney: i have difficulty enough creating a comment anyway - it always seems to take about 4 clicks
[08:22]  rogpeppe: yup, not defending rbt's ui
[08:22]  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]  wallyworld, wow, you've backported all my fixes to 1.21, thanks! :)
[08:24]  dimitern: np, i'm keen to get beta2 unblocked :-)
[08:31]  fwereade, ping
[08:31]  dimitern, pong
[08:33]  fwereade, hey, a quick clarification re one of your review comments - about the revno and AddMetaCharm
[08:33]  fwereade, I'm not quite sure what are you suggesting
[08:34]  dimitern, `AddMetaCharm(..., 2)`
[08:34]  dimitern, is it used elsewhere?
[08:34]  dimitern, it just doesn't really seem worth the comment?
[08:34]  fwereade, I have to check, but possibly in a few places
[08:35]  fwereade, ah, you're saying drop the revno var and pass the number directly, without a comment about SetUpTest?
[08:35]  dimitern, yeah exactly
[08:35]  dimitern, it feels unnecessary from here
[08:35]  fwereade, ok, sgtm
[08:36]  fwereade, and re those 2 cases which set the charm url on the service or unit docs manually
[08:37]  fwereade, I needed that so I can test the "sameCharm" or "differentCharm" assertions without messing up the settings refcount
[08:40]  dimitern, hmm, would it be too unwieldy to preserve the refcount by setting charm urls on a distinct unit?
[08:41]  dimitern, I just tend to get nervous about tests that mess with the db in ways that don't match real usage
[08:41]  fwereade, I'll have a look to see if I can simulate the same without transactions
[08:41]  fwereade, but for the service is Dead case, it can't be done
[08:41]  davecheney: i've been seeing this error message sometimes recently when building tests:
[08:41]  os/user(.text): missing Go type information for global symbol: code.google.com/p/go.crypto/curve25519.REDMASK51 size 8
[08:41]  davecheney: do you know what's going on there?
[08:42]  dimitern, fwiw, you can use transactions inside txn hooks
[08:42]  fwereade, I do it that way
[08:42]  dimitern, I am evidently undercaffeinated
[08:42]  dimitern, ofc you know that, you do it all the time
[08:42]  davecheney: it happens even when i rm -r $GOPATH/pkg
[08:42]  fwereade, :) np
[08:43]  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]  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]  fwereade, I guess I mean the latter
[08:45]  davecheney: and it even happens when i rebuild go from scratch *and* remove $GOPATH/pkg
[08:45]  fwereade, the published interface assumes a lot and cannot be used to test minute changes
[08:46]  dimitern, agreed and understood
[08:46]  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]  dimitern, indeed
[08:47]  dimitern, I think the benefits of testing the actual interactions are pretty compelling
[08:48]  dimitern, I agree we can't *always* do it
[08:48]  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]  fwereade, alright
[08:51]  fwereade, thanks, I'll implement your suggestions and land it then
[08:52]  dimitern, cheers
[08:59]  morning all
[09:01]  morning everyone
[09:13]  morning all
[09:34]  morning mattyw, TheMue, voidspace
[09:34]  dimitern, good morning
[09:35]  dimitern: TheMue: o/
[09:36]  o/
[09:53]  morning
[10:43]  dimitern: http://reviews.vapour.ws/r/429/diff/#
[10:43]  dimitern: I'm getting coffee
[10:44]  voidspace, looking
[10:44]  dimitern: I'm getting coffee
[10:53]  voidspace, LGTM +a couple of suggestions
[11:17]  dimitern: thanks
[11:17]  dimitern: your first suggestion looks good
[11:18]  dimitern: I'm hesitant to add "will retry later" to the second message - will we retry?
[11:19]  voidspace, yeah, I've thought about it just after I sent it :)
[11:19]  voidspace, why a warning though then?
[11:19]  dimitern: so Errorf ?
[11:21]  dimitern: that's for a genuine error that wasn't handled separately
[11:21]  dimitern: i.e. it's *not* a 400, 403, 404, 409
[11:22]  voidspace, it definitely looks like an error, an unexpected one even - which can be added to the log message
[11:23]  dimitern: ok, I'll make it an Errorf
[11:23]  voidspace, cheers
[11:24]  dimitern: pushed, will merge...
[11:24]  aghh really? another import cycle?
[11:25]  voidspace, great, I pushed mine as well, finally
[11:26]  dimitern: great
[11:26]  perrito666: not so great
[11:29]  axw: hiya, i just noticed we assigned ourselves that tools bug at the same time
[11:30]  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]  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]  fwereade: each version of tools gets a fir named after their version
[11:38]  dir
[11:38]  so there will/could be more than one tools dir
[11:39]  but the hook tools should link to tools/1.22-alpha1.1-trusty-amd64/jujud
[11:39]  not tools/unit-mysql-0/jujud
[11:39]  cause at the moment, all units hog smashed onto a machine link to the later
[11:40]  the first unit
[11:40]  and if that unit is removed, the other unit's links become invalid
[11:41]  wallyworld, hmm, that is surely a problem, but shouldn't they just link to the jujud in their own tools dir?
[11:42]  likely, i haven't looked in tooo much detail, just reproduced the issue and saw the suboptimal symlinks
[11:57]  dimitern: i think you meant "Save warthogs!" :-p
[12:21]  ericsnow: ping
[12:44]  wallyworld, oops :) yeah
[12:45]  sorry, couldn't resist :-)
[12:49]  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]  jamestunnicliffe: juju source code has migrated to github
[12:50]  wallyworld: ah, thanks!
[12:51]  https://github.com/juju/juju
[12:59]  wallyworld: that didn't build juju, but I got charm-admin, charmd and charmload out of it. Only message was
[12:59]  src/github.com/juju/juju/state/backups/metadata/metadata.go:71: m.SetFile undefined (type *Metadata has no field or method SetFile)
[12:59]  (go install -v github.com/juju/juju/...)
[13:00]  well, got plenty of non-errors as well
[13:00]  (or warning?)
[13:00]  i haven't pulled the entire source plus deps in a while but i thought go get would have worked
[13:02]  godeps is a tool that pulls all the right dependencies
[13:02]  go get launchpad.net/godeps
[13:02]  and then from the juju root dir godeps -u dependencies.tsv i think
[13:04]  wallyworld: that got it. Thanks!
[13:04]  \o/ great :-)
[13:13]  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]  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]  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]  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]  I bootstrapped my environment with --upload-tools as it says in the README
[13:15]  jamestunnicliffe: hard to say without a little more info - output of juju status, plus the complete all-machines log file
[13:17]  wallyworld: http://paste.ubuntu.com/8986797/
[13:21]  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]  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]  I am getting 1.22-alpha1-trusty-amd64 out of juju --version
[13:23]  OK, will give it a go.
[13:23]  that implies the juju in you path is an older binary
[13:24]  i have to drop off irc, after 11pm here, but someone else should be able to help you further
[13:24]  thanks wallyworld
[13:25]  np, sorry i can't hang around, tired
[13:25]  np, have a 3 month old daughter. Know the feeling :-)
[13:25]  ah, i miss those days
[13:35]  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]  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]  jw4, hey, yes I looked at the proposal and it looked nice
[13:47]  dimitern: cool
[14:27]  ericsnow: ping
[14:32]  wallyworld: doh. I have a PR up for it.
[14:41]  perrito666: hey
[14:42]  ericsnow: hey, I just merged with master and found that there is an import cycle caused by state/backups.go
[14:42]  ericsnow: and there is a potential other coming
[14:43]  since I need agent into the mix too
[14:43]  so I need to move NewBackups into state/backups/... any suggestions?
[14:43]  perrito666: that's one of the reasons state, etc. shouldn't leak into the state/backups package
[14:44]  perrito666: that shouldn't need to move
[14:45]  perrito666: before I start making assumptions, what is the cycle?
[14:48]  ericsnow: it is exactly the oposite
[14:48]  state/backups.go imports state/backups package
[14:48]  which imports environments
[14:48]  perrito666: correct
[14:48]  which imports agent
[14:48]  which imports state
[14:49]  so actually leaking state all over backups would be harmless
[14:49]  perrito666: where is environment imported?
[14:49]  restore
[14:50]  perrito666: so that env-related code should go in state/backups.go, right?
[14:50]  ericsnow: yes
[14:50]  or in state, but that is clearly out of the question :p
[14:51]  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]  so you mean that if I move your function out of there Ill have another cycle?
[14:52]  perrito666: dependencies on state/env within state/backups cause cycles
[14:53]  perrito666: so I'd be surprised if it didn't
[14:53]  ok, ill try
[14:53]  perrito666: thanks
[14:53]  where would you like to have your NewBackups if not in state/backups.go ?
[14:55]  perrito666: NewBackups should stay in state/backups.go
[14:56]  perrito666: you may need to pull something out into apiserver/backups
[14:56]  perrito666: I had to do that with env storage before we switched to gridfs
[14:57]  perrito666: but that shouldn't need to impact the existing code
[14:57]  there is no reason to move things to apiserver
[14:59]  mmmpf, I really dont want to have yet another namespace here but seems I am going that way
[15:00]  perrito666: if you have a minute, let's talk about it over a hangout
[15:01]  ericsnow: not really, lets talk about it in the standup
[15:01]  perrito666: k
[15:01]  perrito666: would you mind pushing up your diff to RB?
[15:02]  ericsnow: I actually would, it does not compile at present
[15:02]  but the method that uses environments is there already
[15:02]  something changed lately
[15:03]  it is newStateConnection on state/backups/restore.go
[15:03]  perrito666: is there somewhere I could look at the code?
[15:05]  ericsnow: and well there will be another one when I import agent/ReadConfig
[15:06]  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]  perrito666: fixing the cycles is usually complicated
[15:07]  ericsnow: well it is not, I have done before
[15:08]  perrito666: no, I mean making it so that there isn't a state -> env -> agent -> state cycle
[15:08]  ericsnow: the issue here is state -> backups -> env -> agent
[15:08]  so to me the issue is state -> backups
[15:09]  perrito666: for provider storage I took the pull/bundle route
[15:09]  perrito666, ericsnow: I'm in the 1/2 day tosca review if you guys want to standup without me.
[15:09]  wwitzel3: you must be thrilling
[15:10]  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]  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]  that is actually useful
[15:10]  perrito666: kind of theraputic in a way and it bringing me up to speed on somethings I didn't know about :)
[15:10]  perrito666: but as me again at hour number 3 :P
[15:11]  ask
[15:12]  dimitern: later, currently meeting
[15:12]  TheMue, np
[15:21]  dimitern: sure
[15:26]  dimitern: lgtm
[15:26]  voidspace, thanks!
[15:28]  ericsnow: there, I fixed the import cycle
[15:28]  :p
[15:28]  that was easy
[15:28]  perrito666: nice
[15:29]  ericsnow: you have a set of constructors which are State+somethingElse related I just went from state to somethingElse
[15:42]  dimitern: when you have a chance, can you have a quick glance at this (not a review)
[15:42]  https://github.com/voidspace/juju/compare/listnetworks-maas
[15:42]  dimitern: is this what you have in mind for maas ListNetworks
[15:42]  voidspace, sure, looking
[15:42]  dimitern: thanks
[15:45]  voidspace, looks great so far
[15:45]  dimitern: so far... you mean there should be more of it!
[15:46]  dimitern: just needs testing (and maybe some polish) if the basic approach is ok
[15:46]  voidspace, just a couple of log messages near the end need to change slightly
[15:46]  dimitern: ok, cool
[15:46]  dimitern: thanks
[15:46]  dimitern: much appreciated
[15:46]  voidspace, it looks ok to me, but I'd like to see it when finished
[15:47]  dimitern: sure
[15:47]  voidspace, np, thank you
=== Spads_ is now known as Spads
[15:57]  ericsnow:  (type *API has no field or method backups) <-- something changed there?
[15:57]  perrito666: API in api/backups/ ?
[15:58]  apiserver/backups/restore.go in this case
[15:59]  gsamfira, ping
[15:59]  fwereade, ping
[16:00]  perrito666: apiserver/backups.API doesn't have backups any longer
[16:00]  alexisb, pong
[16:00]  perrito666:  use newBackups instead; see create.go for an example
[16:00]  ericsnow: ok
[16:00]  fwereade, was curious if gsamfira had a chance to port the reboot work to 1,21-beta
[16:01]  perrito666: standup?
[16:01]  the release team has agreed to accept it but we need to get it to them asap
[16:01]  oh true, let me fetch some form of headphone
[16:01]  alexisb, I thought he had, I had him coordinating with mgz yesterday or the day before
[16:02]  fwereade, ah ol
[16:02]  ok
[16:02]  I may be late to the game
[16:02]  which is my bad, I have been out for a few days
[16:02]  alexisb, no, looks like it never got an actual $$merge$$: https://github.com/juju/juju/pull/1098
[16:02]  alexisb: fwereade https://github.com/juju/juju/pull/1098
[16:02]  heh
[16:02]  perrito666, fwereade can one of you get it merged?
[16:02]  mgz, sinzui: any objections to me pulling the trigger there?
[16:03]  fwereade: go for it
[16:03]  fwereade, Please merge it
[16:03]  * fwereade has pressed the button
[16:04]  ericsnow, btw, not sure you saw yourself flagged in https://github.com/juju/juju/pull/1098 ?
[16:05]  fwereade: didn't see that
[16:05]  fwereade: still looking into it though
[16:06]  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]  fwereade: got it
[16:07]  wwitzel3: you on the tosca call?  Or are you going to come to the standup?  either is ok
[16:08]  wouldn't it be nice to have picture in picture for meetings?
[16:08]  natefinch: I'm on the tosca call
[16:09]  wwitzel3: that's the bug triage one, right?  I was on it before I left for the cross team meeting
[16:09]  natefinch: we are going through the open issues in the tosca tracker, 5 minute time box per issue
[16:09]  wwitzel3: ok cool
[16:09]  natefinch: yeah
[16:09]  (ish)
[16:09]  haha
[16:10]  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]  heh, my dog tries to be on camera for the standup the day my cam is not working :p
[16:30]  alexisb, it's merged now
[16:30]  fwereade, sweet
[16:32]  alexisb: hangout time?
[16:34]  hey jamestunnicliffe !
[16:53]  fwereade, dimitern - machineInterfacesWatcher does not suffer from the same defect that idPrefixWatcher did - fyi
=== kadams54 is now known as kadams54-away
=== kadams54-away is now known as kadams54
=== kadams54 is now known as kadams54-away
[16:59]  fwereade: another look over http://reviews.vapour.ws/r/318/ would be great
=== kadams54-away is now known as kadams54
[17:38]  wwitzel3, reviewed, bbl
=== jog_ is now known as jog
=== Spads_ is now known as Spads
=== Spads_ is now known as Spads
[17:54]  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]  Bug #1392390: maas zone selected for deployment that is occupied        
[18:01]  sinzui: ok, will do
=== tasdomas` is now known as tasdomas
[18:05]  wwitzel3: you around?
[18:14]  natefinch: yeah
[18:14]  natefinch: was about to hit lunch, the tosca call is over now
[18:15]  wwitzel3: np, thanks for taking all that time to be on that call
[18:15]  wwitzel3: for your reward, can you look at the bug sinzui linked above?
[18:15]  (after lunch of course)
[18:16]  natefinch: yeah, do we have a maas to test with?
[18:17]  wwitzel3: not to my knowledge.  sinzui  - do we have a test maas?
[18:17]  natefinch: I can reinstall my virtual maas setup, I just haven't got to it since my reinstall
[18:18]  natefinch, wwitzel3 We test stable and devel maas http://reports.vapour.ws/releases/2069
[18:19]  wwitzel3, I don't think we have setup zones
[18:27]  night all
[18:34]  wwitzel3: natefinch hey I found someone else that upgraded to an unstable version of juju
[18:34]  hi guys - perrito666 is helping me with a bad juju upgrade-juju issue
[18:34]  original: 1.18.4-trusty-amd64
[18:35]  did: juju upgrade-juju --upload-tools --version=1.20.11
[18:35]  but seeing:
[18:35]  drwxr-xr-x 2 root root 4096 Jul 29 17:52 1.18.4-trusty-amd64
[18:35]  drwxr-xr-x 2 root root 4096 Nov 13 18:14 1.19.4-trusty-amd64
[18:35]  lrwxrwxrwx 1 root root   19 Nov 13 18:10 machine-0 -> 1.19.4-trusty-amd64
[18:35]  lrwxrwxrwx 1 root root   19 Nov 13 18:14 unit-ksplice-9 -> 1.19.4-trusty-amd64
[18:35]  then at log:
[18:35]   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]              addresses for machine 0: state changing too quickly; try again soon
[18:35]  also
[18:35]  2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:776 upgrade to 1.19.4-trusty-amd64 already completed.
[18:35]   2014-11-13 18:26:04 INFO juju.cmd.jujud machine.go:757 upgrade to 1.19.4-trusty-amd64 completed.
[18:37]  this is on a canonical bootstack deployment, owned by Canonical (IS team)
[18:38]  is there any way I can force the upgrade to 1.20.x , and/or recover this ?
[18:39]  found above ERROR at https://bugs.launchpad.net/juju-core/+bug/1334773 fwiw
[18:39]  Bug #1334773: Upgrade from 1.19.3 to 1.19.4 cannot set machineaddress         
[18:39]  which perfectly matches my unwanted running version at node0 :(
[18:42]  FYI $ juju --version
[18:42]  1.20.11-trusty-amd64
[18:46]  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]  natefinch: reading the code where we iterator over the zones didn't expose anything obvious to me
[18:47]  and the selection code seems sane
[18:54]  wwitzel3: where's that code?
[18:58]  right folks, g'night
[19:05]  natefinch, wwitzel3 : bugger, this is a related regression to maas zones bug 1392411
[19:05]  Bug #1392411: bootstrap on multi-zone MAAS leaves 'Allocated' nodes in all zones       
[19:21]  natefinch: meet jjox the only other person that managed to upgrade himself into 1.19
[19:23]  and feel not so-much-happy about it.
[19:24]  hi, I'm only half here, have a 1 year old in my lap currently.
[19:24]  sinzui: do you remember if we were ever able to fix the other guy who managed to get onto 1.19?
[19:25]  natefinch, I think a lot of db surgery was performed along with crafted configs
[19:25]  natefinch, has it happened again?
[19:25]  sinzui: it has
[19:26]  * sinzui wonders if devel agents can ever be removed from released streams
[19:26]  sinzui: I dumped what I did + found at logs ~20lines above
[19:26]  fyi this was:
[19:26]  juju upgrade-juju --upload-tools --version=1.20.11
[19:26]  juju --version
[19:27]  1.20.11-trusty-amd64
[19:27]  Juju CI used to test downgrades. they work very well juju upgrade== version=1.20.11 should work
[19:28]  jjox, upload-tools is only needed if your env doesn't have network, or you are genunienly testing hacked juju
[19:28]  sinzui: was my understanding that we were firewalled (which later found not to be the case)
[19:28]  sinzui: btw, it did not work in this case
[19:28]  it did not upload current tools
[19:28]  and certainly did not mark them with the specified version
[19:29]  sinzui: do we have downgrade from develo -> stable?
[19:29]  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]  sinzui: how safe would be to 1) shutdown+backup mongodb 2) try downgrade to 1.18 ? if fails -> restore 1) ?
[19:30]  and binary symlinks, etc
[19:31]  jjox, juju backup-and restore is not reliable with 1.18 and 1.19
[19:32]  jjox, if you have network, lets try to force a new configuration to upgrade...
[19:32]  sinzui: was thinking backup as in 'stop juju-db; tar ...'
[19:32]  sinzui: upgrade as in to 1.20 ?
[19:32]  jjox, that is a proven recipe to destroy and env
[19:33]  jjox, backup is selective about what gets copied...to much is bad
[19:33]  sinzui: ok
[19:33]  jjox, juju set-env tools-metadata-url=http://streams.canonical.com/juju/tools/
[19:34]  juju upgrade-juju --version=1.20.11 --show-log
[19:35]  sinzui: ok - before doing the upgrade-juju, just to be sure we're in sync:
[19:36]  sinzui: this was 1.18.4, asked to be upgrded to 1.20.11 ( --upload-tools ) but got 1.19.4
[19:36]  sinzui: with above ^ -> then ok (doing: juju upgrade-juju --version=1.20.11 --show-log) ?
[19:37]  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]  (sorry to repeat myself here, but just wanted to be sure you got the full context ok)
[19:38]  sinzui: cool, ta.
[19:38]  running
[19:38]  jjox, I think your case here is similar to the other cases where streams were ignored
[19:38]  natefinch: github.com/juju/juju/provider/maas
[19:38]  sinzui: failed with:
[19:38]  https://pastebin.canonical.com/120428/
[19:39]  jjox, okay, this is not so bad...juju will honour the upgrade if we get everything else upgraded
[19:40]  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]  sinzui: fwiw those units are all trashable, if needed
[19:40]  sinzui: ~1.5hs
[19:40]  :(
[19:40]  sinzui: would restarting those agents help?
[19:40]  jjox, YES
[19:40]  doing
[19:41]  sinzui: FYI juju status -> https://pastebin.canonical.com/120424/
[19:41]  sinzui: took ~10mins to output
[19:41]  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]  sinzui: fun, at https://pastebin.canonical.com/120424/ 18/lxc/0: shows dns-name: 127.0.0.1
[19:44]  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]  sinzui: so, eg 18/lxc/0 (just restarted) - > $ /var/lib/juju/tools/machine-18-lxc-0/jujud --version
[19:45]  1.18.4-precise-amd64
[19:45]  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]  jjox, yeah, I just suspected that would happen.
[19:46]  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]  FYI this is a running bootstack
[19:49]  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]  where's that ?
[19:49]   /etc/init guess, lookin
[19:49]  * sinzui looks at a working machine to see
[19:49]  jjox: /var/lib/juju/agents/yourmachine/agent.conf
[19:49]  ah, k
[19:50]  apiaddresses:
[19:50]  - 172.20.161.8:17070
[19:50]  stateaddresses:
[19:50]  - 172.20.161.8:37017
[19:50]  that is (should be) ok
[19:52]  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]  sinzui: all there ok afaics : https://pastebin.canonical.com/120430/
[19:54]  yep, I think w want to check if the agent was downloaded jjox , let me review my example machine
[19:54]  ta
[19:55]  sinzui: not there fyi:
[19:55]  root@infra:~# ls -ld /var/lib/lxc/juju-machine-18-lxc-*/rootfs/var/lib/juju/tools/1.*
[19:55]  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]  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]  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]  jjox, we can see the version used in a container by ls -l /var/lib/juju/tools/
[19:56]  sinzui: guess we crossed in irc , pasted above
[19:56]  jjox, I have updated the symlink and restarted to proc before with success
[19:56]  but we need to get the agent first
[19:57]  sinzui: ok, I'll surgically rsync them there, and symlink, and restart
[19:57]  jjox, +1
[20:15]  sinzui: ok - sweep dload + symlinked all 18-lxc
[20:15]  but still getting some agents have not upgraded to the current environment version 1.19.4: machine-18-lxc-0 ...
[20:15]  wwitzel3: btw, I posted on that bug - there at least definitely is a "default" zone (or at least their api reported one)
[20:15]  checking there for the running binary from ps , to confirme.
[20:16]  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]  wwitzel3: also, I'm not convinced juju didn't try all zones and then only report the failure for the last one
[20:16]  (at the 18 host ) ^
[20:16]  jjox, have any on the lxc upgraded?
[20:16]  sinzui: root@infra:~# /var/lib/lxc/juju-machine-18-lxc-0/rootfs//var/lib/juju/tools/machine-18-lxc-0/jujud --version
[20:16]  1.19.4-trusty-amd64
[20:17]  sinzui: froma bove: sure running binary is 1.19.4, but still seen as not upgraded
[20:17]  sinzui: note fwiw that juju status is giving 127.0.0.1 as public address for that one (pastebin with juju status)
[20:18]  juju has trouble with lxc/kvm addresses
[20:19]  sinzui: I've seen juju 10.0.3.x bipolarity, but 127.x is the 1st time I do
[20:19]  sinzui: anyway -
[20:19]  sinzui: just by luck, happens that these are really trashable
[20:20]  sinzui: would it make sense to try riping them ?
[20:20]  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]  jjox, if you destroy the units, try to complete the upgrade to 1.20.11 then redeploy
[20:22]  sinzui: ok (assuming redeploy== redeploy these ones only - others are not an option)
[20:23]  jjox, you can deploy individual services back to the machine like this: juju deploy -to 18/lxc/0 
[20:24]  yep, ok
[20:24]  or juju deploy -to 18/lxc
[20:24]  intersting, didn't know about the 'full' --to 18/lxc/0 case
[20:25]  jjox, I think the case is sort of odd because machines are incrementally named. maybe I remember wrongly
[20:25]  ok
[20:30]  just realised that I hadn't started my irc client...
[20:30]  sinzui: https://pastebin.canonical.com/120432/ <- life: dying ...
[20:33]  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]  jjox, and maybe we need a --force to tell juju unregister it and ask the provider to make it go away now
=== kadams54 is now known as kadams54-away
[20:41]  sinzui: but would terminate-machine --force work if there still units on it ?
[20:42]  jjox, I don't know. of the other units to die, then we can used destroy-machine --force 18/lxc/1
[20:44]  sinzui: stars-aligning : --force 18/lxc/N goes by
[20:46]  sinzui: but eg landscape/0 still showing:
[20:46]          life: dying
[20:46]          machine: 18/lxc/1
[20:48]  jjox, I need to rescue a child. I will be back in 15 minutes
[20:48]  sinzui: tnx
[20:52]  sinzui, perrito666 : wow, cool - terminate machine on those lxc/18/N atually kicked in at provider (saw a shutdown ... at the lxc)
[20:52]  and that f*xing service is gone.
[20:52]  peeking at other ones.
[20:52]  \o/
[20:52]  yeah
[20:53]  that '5mins' sinzui magic value seem to have worked.
[21:03]  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]  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]  natefinch: so I figured it must of been part of their setup
[21:42]  thumper: did you want to discuss the backups vs. backup topic?
[21:45]  * thumper thinks singular is better than plural
[21:45]  otp with fwereade right now
[21:45]  saying 'juju backup restore' out loud doesn't sound as stupid as I thought
[21:46]  when you'd go 'juju backup create' or something
[21:46]  thumper: fWIW, I agree that "backup" is a better fit
[21:46]  thumper: yeah, I was thinking the same thing
[21:48]  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]  thumper: then the use of "backup" for *state* backup would be a pain
[21:50]  thumper: we can pick this up when you're free
[21:51]  well... one things we do know
[21:51]  is that we'll want an 'unpriviliged' backup my environment thing
[21:51]  and a restore one...
[21:51]  not sure what that will look like yet
[21:53]  thumper: would that be the same (but limited) backup of state or would it entail other elements of the env?
[21:53]  it would likely be 'just state contents'
[21:53]  thumper: so that would still fit into the current model of backup
[21:54]  could be 'juju backup environment'
[21:54]  * thumper shrugs
[21:54]  thumper: k
=== Spads_ is now known as Spads
[21:55]  thumper: that reminds me, I wanted to talk with you about backups in a MESS world
[21:56]  thumper: I have a feeling that it won't work exactly right
[21:56]  ericsnow: which is what I was talking about
[21:56]  thumper: ah :)
[21:56]  ericsnow: happy to talk about it, just not right now
[21:57]  thumper: no worries; ping me when you're free
=== kadams54-away is now known as kadams54
[22:11]  thumper: I'm confused. Sent you an email.
[22:22]  ericsnow: I don't think a backup chat is going to happen today
[22:22]  ericsnow: lets try to catch up early next week
[22:22]  thumper: no worries
[22:22]  thumper: sounds good
[22:22]  ericsnow: are you needing a review on anything urgently?
[22:22]  or waiting on me for something?
[22:23]  thumper: if you wouldn't mind following up on the two you already reviewed, that would rock
[22:23]  ok
[22:23]  will do that after lunch
[22:23]  thumper: thanks
[22:36]  * davecheney starts to cry
[22:37]  *WHY DOES THE STATE PACKAGE DEPEND ON BAKCUPS!!!*!*!
[22:37]  davecheney: ah you also hit that
[22:38]  davecheney: cycle?
[22:38]  you're killing me people
[22:38]  perrito666: no, not a cycle
[22:38]  but it's arse about
[22:38]  davecheney: I encountered a cycle bc of that and removed that dependency
[22:38]  mgo <- state <- api <- everything else
[22:38]  this is how it needs to be
[22:38]  perrito666: log a bug
[22:38]  i'll add it to my list
[22:39]  davecheney: ok Ill log a bug and then assign it to me
[22:39]  since I already fixed that :p
=== kadams54 is now known as kadams54-away
[23:24]  wallyworld: if you needed more info on the stable->devel update issue this is a canonical stack so you can have plenty
[23:25]  thanks
[23:25]  I believe I covered all that is required
[23:26]  why was upload tools used?
[23:26]  wallyworld: they believed they where more firewalled than what they actually where
[23:26]  so, even though one would have expected to have juju upload local tools it just donwloaded 1.19 from streams
[23:27]  I am sure there is a bug there, just cant discern it very clearly
[23:27]  i'm not convinced yet that it downloaded 1.19
[23:27]  wallyworld: I sshd into the machine
[23:27]  it did
[23:27]  trust me
[23:27]  can we get all the logs
[23:27]  or can i ssh in
[23:28]  wallyworld: we certainly can, ask IS for it triumph.bot-prototype <- machine 0
[23:28]  wallyworld: you can both, ssh into an IS machine require for them to share a screen with you
[23:28]  its like shopping with a guard next to you :p
[23:28]  i'd rather then just get the logs
[23:29]  wallyworld: that is the machine
[23:29]  ok
[23:29]  I am eod-ish, or I would get them for you :p
[23:29]  np, i'll ask them to :-)
[23:29]  thanks for info
[23:30]  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]  so the state server was firewalled?
[23:49]  davecheney: what about github.com/juju/names package? should state not reference that ?
[23:54]  no, it really shouldn't
[23:54]  well
[23:55]  the idea is that we don't want state depending on big bunchs of functionality
[23:55]  liek the multiwatcher
[23:55]  or backups
[23:55]  or presence
[23:55]  actually
[23:55]  i can't talk about this
[23:55]  i don't have a celar enough picture
[23:55]  but please, stop adding dependnecies to state
[23:56]  what I do believe is the public api methods on state should only take types that are defined in the state package
[23:56]  or primative types
[23:56]  names is a good example
[23:57]  and we do break this promise in one location