[00:07] <jw4> davecheney: okay
[00:07] <jw4> davecheney: I'll leave it as is for now, but we may want to revisit names package I guess
[00:07] <davecheney> i want to shoot that in the head
[00:08] <davecheney> having api types in a seperate repo is just a mistake
[00:08] <davecheney> tags are api types
[00:08] <davecheney> they belong in the api
[00:08] <davecheney> my rule of thumb is, if you have to import two pacakges to use the functionality from one package, then they should be combined
[00:08] <jw4> davecheney: can't we just pull them back in to api now that we've cleaned up the api packages?
[00:09] <jw4> davecheney: that names package is tiny and maintining it is a pita
[00:11] <davecheney> jw4: raise an issue
[00:11] <davecheney> id' +1 that PR if you did it
[00:11] <jw4> kk
[00:11] <davecheney> in the past it wasn't clear that the names, or specificlly tags
[00:11] <davecheney> were an api type
[00:12] <davecheney> despite what fwereade keeps telling us
[00:12] <jw4> :D
[00:12] <davecheney> but, now we're had the clue bat applied
[00:12] <davecheney> it is clear that tags are api params
[00:12] <davecheney> so if you were to attempt that, it would be great
[00:12] <davecheney> id' do it like this
[00:12] <davecheney> 1. delete juju/names from your GOPATH
[00:12] <davecheney> copy all the Tags types to apiserver/params
[00:13] <davecheney> keep hitting things with sed til it works
[00:13] <jw4> davecheney: +1
[00:21] <jw4> davecheney: of course if we do that it seems even more important to not include the Tag types in the state package...
[00:22] <jw4> issue raised: lp-1392537
[00:25] <davecheney> urgh
[00:25] <davecheney> fuck
[00:25] <davecheney> forgot that
[00:26]  * davecheney throws a shoe
[00:26] <jw4> hehe
[00:26] <perrito666> <austin powers> who throws a shoe?
[00:27] <perrito666> http://www.youtube.com/watch?v=an0bVaTjF_Y
[00:28] <thumper> um... what's this about state not using names?
[00:28] <jw4> oh, oh.  now we're gonna catch it
[00:29] <thumper> tags aren't entirely api types
[00:29] <thumper> when an entity has a tag, and the entities come from state
[00:30] <thumper> then you need to pull them up out into a common library
[00:30] <thumper> which is what juju/names is
[00:30] <thumper> what's the problem?
[00:30] <thumper> ideally...
[00:30] <jw4> so then the dependency graph of state has to include juju/names as an acceptable dependency (obviously)
[00:30] <thumper> tags would live closer to the business types
[00:31] <thumper> no, I think it is a necessary dependency
[00:31] <jw4> thumper: as in 'shadow' or 'mirror' business types in the API layer?
[00:31] <thumper> jw4: later...
[00:32] <jw4> thumper: kk
[00:33] <thumper> davecheney: please don't bother removing juju/names dep from state at this stage
[00:34] <thumper> davecheney: there are other fish to gut
[00:36] <jw4> perrito666: just watched that clip - funny :)
[00:47] <davecheney> https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg
[00:48] <davecheney> thumper: understood
[01:15] <thumper> P.S. For those keeping score, this will be Go version control system number four. Go development started in Subversion, moved to Perforce, then Mercurial, and soon to Git.
[01:15] <thumper> at least we only used two
[01:20] <rick_h_> thumper: :)
[01:20] <rick_h_> thumper: aren't you glad you practiced your git and got ahead of the game now?
[01:21] <thumper> shuddup
[01:21]  * thumper is moving private project from bzr to git
[01:21] <thumper> for reasons
[01:25] <davecheney> Moving DVCS hosting as a Service!
[01:52] <mwhudson> davecheney: launchpad used to do that!
[01:53] <mwhudson> well still does i guess
[02:01] <thumper> :-)
[02:01] <thumper> davecheney: so... I have a question
[02:01] <thumper> and I think the answer is "don't do that"
[02:02] <thumper> but...
[02:02] <thumper> if I have an error
[02:02] <thumper> but it is a typed nil
[02:02] <thumper> how do I check that the pointer is nil?
[02:02] <thumper> because I can't check nil
[02:03] <thumper> I'm trying to make the library robust to stupid people
[02:03]  * thumper is guessing reflect package
[02:06] <thumper> reflect.ValueOf(err).IsNil() works
[02:06] <perrito666> thumper: can you not test for stupid users?
[02:07] <davecheney> thumper: hmm
[02:07] <davecheney> gimme a sec
[02:07] <davecheney> reflect is one way
[02:07] <davecheney> can you show me the code path ?
[02:07] <thumper> I'm writing the code path :-)
[02:08] <thumper> lemmie pastebin it
[02:08] <davecheney> k
[02:08] <thumper> http://paste.ubuntu.com/8996904/
[02:08] <thumper> so... I'm trying to make this robust for a nil error
[02:08] <thumper> even a typed nil
[02:09] <thumper> without the nil check, a typed nil supports the interface
[02:09] <thumper> so we need the nil check as well
[02:09] <thumper> perrito666: not easily
[02:14] <perrito666> few things make me happier than trimming loads of lines of code... perhaps some medicine for my cold would
[02:15] <davecheney> thumper:
[02:16]  * thumper waits
[02:16] <davecheney> err, ok := err.(ErrorStacker); if ok && err != ErrorStacker{}
[02:16] <davecheney> ^ guess
[02:16] <thumper> davecheney: but ErrorStacker is an interface
[02:16] <davecheney> then youre secrewed
[02:16] <thumper> reflect FTW
[02:16] <davecheney> sorry
[02:35] <davecheney> https://github.com/juju/juju/pull/1134
[02:35] <davecheney> small, hoefully uncontraversial change
[03:17] <thumper> first of three error and logging methods:
[03:17] <thumper> https://github.com/juju/errors/pull/13
[03:29] <thumper> https://github.com/juju/loggo/pull/6
[03:30] <thumper> https://github.com/juju/testing/pull/38
[03:31] <thumper> once these are merged, we can add dependencies to juju and take advantage of them
[03:31] <thumper> another friday, another kid off to brownie camp
[03:31]  * thumper away for now
[03:31] <thumper> cheers folks
[03:40] <davecheney> does anyone know how to do a stacked review on rbt ?
[03:40] <davecheney> can it do that ?
[03:44] <davecheney> ping, http://reviews.vapour.ws/r/436/
[03:55] <axw> davecheney: you can do pass "--parent" to rbt post
[03:55] <davecheney> axw how does that work with the bot that auto generates PRs ?
[03:55] <axw> not 100%, but I *think* you can do it after it's already been proposed
[03:56] <davecheney> i'll give it a go
[03:56] <axw> davecheney: also, LGTM on your rename branch
[03:56] <davecheney> i'll just merge then
[03:56] <davecheney> ta
[03:57] <davecheney> axw the next branch is far more intersting that a search + replace
[04:00] <davecheney> axw: fyi https://github.com/juju/juju/pull/1137
[04:05] <axw> a little more than I have time to review right now, but the description sounds nice
[04:05] <davecheney> kk
[04:05] <davecheney> that's about it from me for today
[04:05] <davecheney> one or two more cleanup branches then things are looking a lot better
[04:08] <ericsnow> davecheney: were you going to sort out the dependency issues causes by state/backups.go?
[04:09] <ericsnow> davecheney: I figured the most straight-forward thing would be to basically move it into state/backups.
[04:11] <davecheney> ericsnow: yes, the issue is assigned to me
[04:11] <jw4> name package refactor for beginning migration of Actions to using UUID identifiers : https://github.com/juju/names/pull/31
[04:11] <ericsnow> davecheney: okay
[04:11] <wallyworld> davecheney: multiwatcher refactor lgtm
[04:12] <davecheney> wallyworld: ta
[04:12] <davecheney> just waiting for the other branch to land
[04:13] <wallyworld> refactoring is good :-)
[04:13] <wallyworld> fixing dependencies is good :-)
[04:13] <davecheney> wallyworld: it's made thigns a lot cleaner
[04:13] <jw4> I'm unclear on api breaking changes with regards to Actions since they're not in use anywhere yet
[04:13] <davecheney> api/ no longer depends on state
[04:13] <wallyworld> \o/
[04:13] <wallyworld> and not should it
[04:13] <wallyworld> nor
[04:14] <davecheney> indeed
[04:14] <wallyworld> jw4: my view is go ahead with your changes, so long as they are truly not used anywhere
[04:14] <jw4> wallyworld: yep not yet, but that window closure is rapidly approaching
[04:15] <wallyworld> time to get it right then
[04:15] <wallyworld> before you ship a working solution
[04:15] <jw4> yeah, and this PR is groundwork for some realy good improvements :)
[04:16] <wallyworld> \o/
[04:22] <davecheney> jw4: names review done
[04:22] <jw4> tx davecheney
[04:34] <davecheney> wallyworld: axw https://github.com/juju/juju/pull/1137
[04:34] <davecheney> good to review now
[04:34] <wallyworld> looking
[04:34] <davecheney> just merged the prereq
[04:35] <wallyworld> davecheney: i just review that one did't i?
[04:35] <davecheney> yeah
[04:35] <davecheney> lgtm still stands ?
[04:43] <jw4> updated https://github.com/juju/names/pull/31 (davecheney ?)
[04:44]  * davecheney looks
[04:45] <davecheney> jw4: what about the panic in Join... ?
[04:45] <jw4> davecheney: what should it do?
[04:46] <jw4> davecheney: if someone calls it with invalid input?
[04:46] <davecheney> i think we have to apply the same logic as we do with tags
[04:46] <davecheney> NewXXTag will panic
[04:46] <davecheney> so you're not uspposed to call it outisde of a test without validating the input first
[04:46] <davecheney> ie, validating that it wont panic
[04:47] <jw4> davecheney: I see, so assume good input?
[04:48] <davecheney> not sure what you mean ?
[04:48] <jw4> well... since this is a public "constructor" it can be called with invalid input
[04:48] <jw4> not sure what to do in that case
[04:49] <davecheney> the rule of thumb is
[04:49] <davecheney> don't panic in non test code
[04:49] <davecheney> that goes double when dealing with user input
[04:52] <jw4> davecheney: so should JoinActionTag have an error return type?  If I understood you correctly you're saying that non test code should never call the other NewXXTag variants that also panic and don't return error.
[04:53] <jw4> davecheney: I might have misunderstood you before too - maybe the only use of this Join.. method is in Test code...
[04:53] <davecheney> if the method is only used in tests, then there is nothing to do
[04:53] <davecheney> sorry, i think i asked that
[04:53] <davecheney> but i wasn't clear enough
[04:54] <davecheney> panicing in tests is fine
[04:54] <jw4> davecheney: no you were clear, I just wasn't thinking right
[04:54] <davecheney> ericsnow: you're good to go on that PR
[04:54] <ericsnow> davecheney: thanks
[04:55] <ericsnow> davecheney: I'm hoping to land http://reviews.vapour.ws/r/402/ (the one where I get rid of the sub-packages) before any of my other patches
[04:55] <jw4> davecheney: so JoinActionTag is used entirely in test code except for closely coupled calls that I will fix in state
[04:56] <davecheney> i'll have a look
[04:56] <davecheney> jw4: ok
[04:56] <davecheney> ericsnow: oh, that was that two page review
[04:56] <davecheney> i'll have a look now
[04:56] <ericsnow> davecheney: k
[05:43] <ericsnow> davecheney: thanks for the followup review
[05:43] <ericsnow> davecheney: I'll look closely tomorrow
[05:50] <davecheney> np
[05:54] <jw4> Smallish initial refactor of Actions to use UUID instead of Sequence for suffix of _id : http://reviews.vapour.ws/r/441/
[05:55] <jw4> preparation for consolidating Actions and ActionResults into one entity, and improving of the watcher and notification design of actions
[06:02] <davecheney> jw4: reviewed
[06:02] <jw4> speedy gonzalez!
[06:02] <jw4> :)
[06:07] <jw4> davecheney: couple questions...
[06:07] <davecheney> shoot
[06:08] <jw4> 1) names.ActionTag is in an intermediate stage right now, where it has prefix and suffix, but the suffix is just a string, not guaranteed to be an UUID
[06:08] <jw4> after step two or three I hope to rid actions of the prefix/suffix id altogether
[06:08] <davecheney> jw4: ok, add a TODO
[06:08] <jw4> and the ActionTag will just be kind-UUID
[06:08] <jw4> kk
[06:08] <davecheney> and don't use dud data in tests
[06:09] <jw4> :-S
[06:09] <jw4> wait... what's the emoticon for embarrassed?
[06:09] <davecheney> i'm only know the ones for smashing things
[06:10] <jw4> 2) the Action.ActionTag() method returns an ActionTag but I don't know how to guarantee that the internal state will be correct
[06:11] <jw4> notwithstanding our earlier discussion, is it appropriate to panic in the case where an Action entity has invalid _id that will cause an invalid ActionTag?
[06:11] <davecheney> yes, but you should also provide a validation function
[06:12] <davecheney> so callers can know that they call that method, they'll get valid data
[06:12] <davecheney> or return an error
[06:12] <jw4> Ah!
[06:12] <jw4> derp ... so Action.ActionTag() should return names.Tag, bool
[06:12] <davecheney> yup
[06:12] <jw4> kk
[06:12] <davecheney> the key is we never create an invalid tag
[06:12] <davecheney> if we do that at the points where thigns are converted to tags
[06:13] <davecheney> then we have less error checking
[06:13] <jw4> makes sense
[06:13] <davecheney> and we _know_ that when someone talks about a tag, it is valid data
[06:13] <davecheney> that is the difference between a tag and string
[06:14] <jw4> pedantically speaking; since the return is names.ActionTag, bool not *names.ActionTag, bool then we will be returning an invalid tag when the bool is false
[06:14] <jw4> (parenthesis would have helped that sentence)
[06:14] <davecheney> yes, that is why names.NewXXXTag returns a tag or panics
[06:14] <davecheney> so there is no chance, even if you ignore the error, that you can use bad data
[06:15] <davecheney> so my preference is for somehing like
[06:15] <davecheney> action.ValidateTag() bool
[06:15] <davecheney> which does the check
[06:15] <davecheney> and action.Tag() whcih returns a tag or panics
[06:15] <davecheney> then, you can ditch validateTag once it is not needed
[06:15] <jw4> hmm; interesting.  I see. I'll go that route in this case
[06:16] <davecheney> its pretty gross
[06:16] <davecheney> but that is why tags are so strict
[06:16] <davecheney> once you have a tag
[06:16] <davecheney> you know whereever you use that data it is valid
[06:16] <davecheney> pretty gross, having to add that validate method
[06:17] <jw4> hmm; methinks I should keep that in mind for the next refactor of the names package too
[06:17] <davecheney> basically the rule is
[06:17] <davecheney> if you have a tag value, you _KNOW_ it is valid
[06:18] <davecheney> so any method you call on that will also return valid dta
[06:18] <davecheney> the cost of this is we need to be pedantic when parsing data to return a tag
[06:18] <davecheney> so, one option could be to relax the checks that action.ActionTag does
[06:18] <davecheney> thereby making more things valid action tags
[06:19] <jw4> not a terrible choice, especially in transition
[06:21] <davecheney> a valid tag is pretty much defined by it's consumers
[06:21] <davecheney> as long as there is nothing like
[06:21] <davecheney> if tag.String() == "" { return error }
[06:21] <davecheney> then it's fine
[06:22] <jw4> kk
[06:33] <jw4> updated http://reviews.vapour.ws/r/441/
[06:41] <jw4> thanks davecheney ; I'll need to update the names package again to make sure invalid UUID's cause the JoinActionTag to panic
[06:41] <jw4> also, interestingly utils.NewUUID() failed and returned an error in my tests a few minutes ago...
[06:42] <jw4> I'm going to head to bed, but I'll pick it up again in the morning.
[08:22] <rogpeppe> davecheney: ping
[08:22] <davecheney> rogpeppe: ack
[08:23] <rogpeppe> davecheney: can you see what i'm doing wrong here? http://paste.ubuntu.com/9001604/
[08:23] <rogpeppe> davecheney: in relation to this issue: https://code.google.com/p/go/issues/detail?id=9098
[08:23] <rogpeppe> davecheney: i *think* i'm guaranteed to be running from go tip there, no?
[08:23]  * davecheney looks
[08:24] <davecheney> rogpeppe: yes, thats go tip
[08:24] <davecheney> is the polyNNNN repo updated ?
[08:24] <davecheney> that repo has some asm which probalby needs to be updated
[08:24] <rogpeppe> davecheney: just making sure
[08:25] <mattyw> morning everyone
[08:25] <mattyw> rogpeppe, davecheney morning
[08:26] <rogpeppe> davecheney: ah, i guess that was the problem!
[08:26] <rogpeppe> davecheney: i'm sure i go get -u'd it but evidently not
[08:28] <davecheney> rogpeppe: i think the bug is in the poly repo
[08:28] <davecheney> or in a duff working copy
[08:28] <rogpeppe> davecheney: yeah
[09:08] <voidspace> morning all
[10:03] <voidspace> dimitern: morning
[10:03] <dimitern> voidspace, morning
[10:08] <voidspace> dimitern: http://reviews.vapour.ws/r/432/
[10:24] <wallyworld> axw: re: the test
[10:25] <wallyworld> it won't work on windows will it?
[10:25] <axw> wallyworld: ah, crap.
[10:25] <axw> nope
[10:25] <wallyworld> i'd prefer not to rely on the pysical machine
[10:25] <wallyworld> mock out the func
[10:25] <wallyworld> sorry, i hould have been more insistent
[10:25] <axw> wallyworld: the best we could do then is to check that the worker is started
[10:26] <wallyworld> started and calls some func
[10:26] <wallyworld> i'll kill the landing job
[10:26] <axw> thanks
[10:26] <axw> wallyworld: "and calls some func" ?
[10:27] <wallyworld> mock out the func that the worker calls to check for block devices, can't remember the details off hand
[10:27] <axw> wallyworld: I'd prefer doing that inside the worker tests
[10:27] <wallyworld> return a made up set of block devices
[10:27] <wallyworld> ok
[10:27] <wallyworld> maybe checking the worker had started is enough
[10:27] <axw> I'll move the current test inside worker/diskmanager as a linux-only test
[10:28] <wallyworld> but checking the worker has started doesn't check that it's wired up right
[10:28] <axw> faking bits out doesn't really either
[10:29] <axw> e.g. pretending that it'd work on Windows, when in reality it won't
[10:30] <axw> wallyworld: alternatively, we could just skip the test on non-Linux...?
[10:30] <axw> eventually it should work on Windows too
[10:30] <wallyworld> sure, but if we mock out listBlockDevices(), we can check that the worker calls that func
[10:31] <wallyworld> i guess yeah skip that test on windows
[10:31] <wallyworld> but we should have a test for the no op worker on windows?
[10:32] <wallyworld> ie test that the right worker is started on the given platform
[10:32] <axw> ok
[10:38] <perrito666> morning
[11:32] <axw> wallyworld: I've pushed again, with more tests and refactored to work better on Windows
[11:33] <wallyworld> ta, looking
[11:40]  * fwereade extended lunch to do parent teacher thing at school
[11:46] <wallyworld> axw: one comment - still about that machine agent test that relies on actually querying the machine hardware
[11:52] <voidspace> dimitern: I take it we *don't* have to account for the fact that a machine (maas node) may have multiple network interfaces with overlapping CIDRs (on different networks)
[11:53] <voidspace> dimitern: but we can assume that if a required address falls within a CIDR for a network then we should request the address allocation for that interface
[11:53] <dimitern> voidspace, hold on, how can the CIDRs be overlapping?
[11:53] <voidspace> dimitern: i.e. the algorithm is "list networks for instance", "find the first one where the requested IP falls within the CIDR"
[11:54] <voidspace> dimitern:  you can have the same IP address on different networks, right?
[11:54] <dimitern> voidspace, nope, I'd be surprised if you could
[11:54] <voidspace> dimitern: hmmm... ok, fair enough
[11:54] <voidspace> dimitern: I won't worry about it
[11:54] <dimitern> voidspace, how will the routing work otherwise?
[11:55] <voidspace> dimitern: so you can have two different networks both using the same address space - but not routable between each other
[11:55] <dimitern> voidspace, that's not possible in maas
[11:55] <voidspace> dimitern: cool
[11:56] <dimitern> voidspace, and in ec2 it's not an issue, as everything falls inside the vpc super-range
[11:56] <voidspace> dimitern: yep, great
[11:56] <voidspace> but for manual provider :-p
[11:56] <voidspace> which we're not worrying about now
[11:58] <dimitern> voidspace, for the manual provider and others we'll have to think, but not now, yeah :)
[12:04] <axw> wallyworld: the whole thing is not a unit test, it's a functional test. but yes, I can mock lsblk.
[12:04] <axw> will come back to it on monday
[12:04] <axw> thanks for the review
[12:05] <wallyworld> yeah, those jujud tests suck
[12:05] <wallyworld> nice not to propogate the badness just a little
[14:22] <voidspace> dimitern: if you're happy with http://reviews.vapour.ws/r/432/ could you add a shipit?
[14:25] <voidspace> dimitern: oh
[14:25] <voidspace> dimitern: you did :-)
[14:25] <voidspace> dimitern: thanks
[14:25] <voidspace> hadn't refreshed page
[14:37] <perrito666> natefinch: ?
[14:48] <dimitern> voidspace, :)
[14:52] <fwereade> perrito666, ping
[14:53] <fwereade> perrito666, actually just when you're around: http://reviews.vapour.ws/r/298/ is in the queue, but I think I'll need a guiding hand to be useful with it: do you need another reviewer, or can I leave it to people who alreayd have relevant state in mind?
[14:55] <perrito666> hey hey
[14:56] <perrito666> fwereade: the people involved already have a state of mind and have been involved somehow in the changes made since initial proposal I think we can manage for now :)
[14:58] <fwereade> perrito666, thanks
[14:59] <fwereade> ericsnow, similar questions re http://reviews.vapour.ws/r/346/ -- ISTM that dave/tim/jesse have already been looking into it in some detail, do you want my 2c as well or shall I leave it in their hands?
[15:04] <ericsnow> fwereade: I think we're good, but thanks (feel free to look things over though)
[15:04] <fwereade> ericsnow, it all looks fine as code, but the trouble is I'm a bit behind on necessary context for sane judgment
[15:05] <ericsnow> fwereade: no worries
[15:22] <perrito666> sinzui: I have to admit that my jaw dropped when I saw your mail not have an issue about restore :p
[15:23] <sinzui> perrito666, I hope you didn't jinx the tests
[15:23]  * sinzui looks
[15:31] <jw4> fwereade: thanks for the review - I think you're right about slashes versus hyphens... I know there was a reason, but I don't think it was insurmountable
[15:32] <jw4> fwereade: I don't think you've lost much context except maybe that switching from Sequence ID to UUID is a good initial step to consolidating Actions and ActionResults
[15:32] <jw4> fwereade: in fact I think both slashes and hyphens are supported
[15:33] <fwereade> jw4, so, the thing about uuids is that they're meant to be uu -- and so the leading service/unit bit would now seem to be redundant?
[15:33] <jw4> fwereade: exactly
[15:34] <fwereade> jw4, hmm, I would be happier if we didn't have alternative spellings of the "same" tag
[15:34] <jw4> fwereade: I was telling davecheney last night that this is an intermediate step
[15:34] <jw4> fwereade: +1
[15:34] <jw4> fwereade: I'll fix that too
[15:34] <fwereade> jw4, well, if it's intermediate towards "action-<uuid>" then the alternate spelling quibble is redundant too :)
[15:34] <jw4> fwereade: within a couple hops the ActionTags should be as clean as some of the other tags without the Prefix/Suffix mumbo jumbo
[15:35] <fwereade> jw4, <3
[15:35] <jw4> fwereade: yep end-state action-<uuid>
[15:35] <fwereade> jw4, fwiw, I think that NotNil in the review is redundant
[15:36] <fwereade> jw4, a nil error will fail the subsequent ErrorMatches
[15:36] <jw4> fwereade: derp
[15:36] <jw4> fwereade: *thats* why my test was failing, and why davecheney told me to drop it
[15:36] <jw4> :)
[15:36] <fwereade> jw4, and btw I'm not quite following the NewUUID thing?
[15:36] <jw4> fwereade: confused rambling
[15:36] <fwereade> jw4, if it's broken we should fix it
[15:37] <jw4> fwereade: it all hinges on the fact that my assert should have been gc.Nil
[15:37] <jw4> i.e. I was *trying* to assert no error
[15:37] <jw4> not that there *was* an error
[15:37] <jw4> :)
[15:38] <jw4> fwereade: in short there is no problem with NewUUID except in my formerly confused mind
[15:40] <fwereade> jw4, ok, I think that's an LGTM with trivials then
[15:40] <jw4> kk
[16:04] <wwitzel3> ericsnow, natefinch, perrito666
[16:05] <perrito666> mm, I seem to have some connection prob, be right there
[16:37] <rogpeppe> the proposal for the hook that runs if no other hook does is "default-hook", right?
[16:37] <rogpeppe> fwereade: ^
[16:38] <rogpeppe> dimitern: ^
[16:39] <dimitern> rogpeppe, I don't really know, sorry
[16:39] <rogpeppe> dimitern: ok, thanks
[16:40] <rogpeppe> dimitern: i'll go with default-hook for the time being...
[16:40] <dimitern> rogpeppe, +1
[17:49] <sinzui> natefinch, mgz do you have a minute to review https://github.com/juju/juju/pull/1145
[17:51] <mgz> sinzui: lgtm
[17:52] <wwitzel3> is there a way to set the debug level before you bootstrap?
[18:29] <wwitzel3> natefinch: found the issue with bug #1392390
[18:29] <mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <https://launchpad.net/bugs/1392390>
[18:30] <wwitzel3> natefinch: there are zero tests for that code is part of the problem, the for loop that looks at zones, if there was no error for a zone, it would keep process until the last zone instead of breaking out of the loop.
[18:31] <wwitzel3> natefinch: resulting in the twilight zone (which is full) being the last attempt, and hence returning the error.
[18:31] <voidspace> g'night folks
[18:31] <wwitzel3> nn voidspace have a good weekend
[18:31] <voidspace> wwitzel3: you too, thanks
[18:32] <natefinch> wwitzel3: interesting
[18:32] <wwitzel3> natefinch: I added a break after the err check, and it works just fine now.
[18:33] <natefinch> .....and a test? :)
[18:33] <wwitzel3> natefinch: I am probably going to break out the zone selection logic in to its own method, so it can actually be tested.
[18:33] <natefinch> huzzah!
[18:33] <wwitzel3> natefinch: because right now, testing it would be a nightmare (probably why it doesn't have them)
[18:34] <natefinch> My thumbs aren't big enough for the thumbs up I want to give that :)
[18:34] <perrito666> natefinch: get one of those gloves you guys use for sport games
[18:34] <natefinch> lol
[18:35] <wwitzel3> haha
[18:35] <wwitzel3> sinzui: bug #1392390 needs fixing in master as well, so once it is fixed there, what is the process of getting it in to 1.21 branch?
[18:35] <mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <https://launchpad.net/bugs/1392390>
[18:37] <sinzui> wwitzel3, branch 1.21, use git patch to apply changes from you master addition. request a pull...edit the destination from master to 1.21
[18:38] <wwitzel3> sinzui: got it, thanks
[19:09] <natefinch> ericsnow: did you need me to look at something?
[19:09] <ericsnow> natefinch: in a few minutes
[19:09] <natefinch> ericsnow: kk
[19:18] <ericsnow> natefinch: feel free to look over all the reviews or the whole patch, but I'd especially appreciate some feedback on the remaining (4) open issues on http://reviews.vapour.ws/r/402/.
[19:22] <ericsnow> natefinch: same with http://reviews.vapour.ws/r/346/ (which has no open issues)
[19:26] <natefinch> ericsnow: looking
[19:26] <ericsnow> natefinch: ta
[19:27] <perrito666> rick_h_: I think I found the solution to my problem with having inexpensive cards with ipmi http://blog.michaelboman.org/2013/01/poor-mans-ipmi.html
[19:49] <wwitzel3> ericsnow: is RB not auto pulling in PRs anymore?
[19:50] <ericsnow> wwitzel3: should be
[19:50] <ericsnow> wwitzel3: but now that you mention it
[19:50] <ericsnow> wwitzel3: github's API throttles your requests if you aren't properly authenticated
[19:50] <ericsnow> wwitzel3: I'm guessing that's the issue
[19:51] <ericsnow> wwitzel3: yep ("API rate limit exceeded"); I'm planning on fixing this today
[19:52] <ericsnow> wwitzel3: in the meantime you can still use rbt post
[19:55] <wwitzel3> ericsnow: I haven't reinstalled it since my laptop reinstall, guess I should do that
[19:55] <ericsnow> wwitzel3: no worries
[19:55] <ericsnow> wwitzel3: you can still get a review on github if need be
[19:57] <wwitzel3> ericsnow: https://github.com/juju/juju/pull/1146 fixes bug #1392390
[19:57] <mup> Bug #1392390: maas zone selected for deployment that is occupied <cloud-installer> <landscape> <maas-provider> <placement> <regression> <juju-core:Triaged by wwitzel3> <juju-core 1.21:Triaged by wwitzel3> <https://launchpad.net/bugs/1392390>
[20:01] <natefinch> ericsnow: sorry, kids woke up early from their naps and wife just got home from midwife and has been instructed to take it easy for a few days, so I gotta run.... also means I didn't get to that review
[20:01] <ericsnow> natefinch: no worries
[20:01] <perrito666> natefinch: tri a shot of scotch to each
[20:02] <natefinch> lol
[20:02]  * perrito666 would be a terrible parent
[20:23] <perrito666> ericsnow: did anything change on the way the mongo backup is done?
[20:23] <ericsnow> perrito666: a little
[20:24] <perrito666> ok, what exactly?
[20:24] <ericsnow> perrito666: restore will be responsible for deleting the "ignored" databases after mongorestore runs
[20:24] <ericsnow> perrito666: should be trivial
[20:24] <perrito666> ok, but what I am asking is, should I change the parameters I use for mongo when restoring?
[20:25] <perrito666> besides that?
[20:25] <perrito666> like, did you change the way you do the dump?
[20:25] <ericsnow> perrito666: nope
[20:25] <perrito666> cool
[20:25] <ericsnow> perrito666: :)
[21:42] <fwereade> rogpeppe, yes, that is default-hook. but fwiw I think that something-changed is a better general approach, so we don't end up running the same code 500 times for no benefit
[22:03] <rick_h_> perrito666: hah, that's one way to go