[00:07] <davecheney> thumper: wanna shoot for a 1:1 today  ?
[00:26] <beisner> hi davecheney - what do you think?  are we trying something too crazy?
[00:30] <davecheney> beisner: deploying anything to machine 0 is crazy
[00:30] <davecheney> but that isn't the problme
[00:30] <davecheney> best I can tell the error is coming from upstart
[00:30] <beisner> davecheney, lol.
[00:30] <davecheney> deploying units to machine 0 has been responsible for 100% of customer data loss
[00:31] <beisner> davecheney, good to know.   fwiw, this is related to automated deployment testing, and we do that only for density.  the whole enviro gets torn down after openstack tempest tests run.
[00:32] <beisner> what else do you think, aside from our crazy unit 0 ways?  ;-)
[00:34] <davecheney> the error is coming from upstart
[00:34] <davecheney> can you make an issue and attach the raw file from upstart
[00:34] <davecheney> the one you pasted
[00:34] <davecheney> it has to be the raw file
[00:35] <davecheney> i suspect there is some control characters or other whitespace crap in there that is throwing off upstart
[00:36] <beisner> davecheney, yes, i'd be happy to.  will ping you in a bit.
[00:45] <thumper> davecheney: yeah, how about after lunch your time?
[01:00] <beisner> davecheney, so that's getting interesting (copying the raw file) with the 1/lxc/3 having "no internal address."
[01:02] <beisner> ahh never fear.  there's always /var/lib/lxc/juju-machine-1-lxc-3/rootfs/etc/   ... grabbing it.
[01:07] <beisner> davecheney, https://bugs.launchpad.net/juju-core/+bug/1420049
[01:07] <mup> Bug #1420049: jujud: Syntax error: word unexpected (expecting ")") <openstack> <uosci> <juju-core:New> <https://launchpad.net/bugs/1420049>
[01:29] <thumper> menn0: the more I think about it, the more I reckon the services running on the api server machines on behalf of another environment should not appear in the other environment log, but in the state server environment log
[01:30] <menn0> thumper: I guess that sort of makes sense
[01:30] <thumper> which does keep things much simpler
[01:31] <menn0> thumper: but if I was investigating a problem within an environment I might want to see those logs...
[01:31] <thumper> well, you'd have to ask
[01:31] <thumper> :)
[01:31] <thumper> I think we should definitely have some way to record which env certain logs are for...
[01:31] <menn0> thumper: but if I was a user with access to an env, but not the state server env then I wouldn't be able to
[01:31] <thumper> but probably as part of the module
[01:31] <thumper> exactly
[01:32] <thumper> I don't think this is a bad thing
[01:32] <menn0> thumper: it's certainly safer that way
[01:32] <thumper> much safer
[01:32] <thumper> and a good starting position
[01:32] <menn0> thumper: for a user like that, the state server should probably be a black box
[01:32] <thumper> I'm prepared to be convinced that we may want to change in the future
[01:33] <thumper> but as a solid well defined starting position
[01:33] <thumper> the state server for other environments is as you just mentioned, a black box
[01:33] <menn0> thumper: you've convinced me :)
[01:33] <thumper> menn0: lets start with that assumption then
[01:33] <thumper> and document decisions
[01:33] <menn0> thumper: not state server... JES
[01:33] <thumper> sure
[02:01] <thumper> axw: hey, updated http://reviews.vapour.ws/r/864/diff/#
[02:07] <axw> thumper: looking
[02:14] <axw> thumper: LGTM
[02:14] <thumper> axw: ta
[02:15] <thumper> axw: the expected behaviour is that if you created a new environ config instance with New, then it will fail if there is already one with the same noe
[02:15] <thumper> name
[02:16] <axw> thumper: ok, I'm just looking at the contract of EnvironInfo specifically
[02:16]  * thumper scratches his head
[02:16] <axw> thumper: I think it needs clarification
[02:16] <axw> not a big deal
[02:16] <thumper> also... all likely to change soon
[02:16] <axw> :)
[02:17] <thumper> you have me wondering now...
[02:17]  * thumper looks
[02:18] <thumper> I had to change the memory implementation to check for created and !initialized in order to get the second write working while failing two news
[02:19] <thumper> and thought that the check should be the same with the disk implementation
[02:19]  * thumper looks again
[02:21] <thumper> hmm...
[02:21] <thumper> I thought I tested that
[02:21] <thumper> just using !iniitalized in both places does work
[02:21]  * thumper goes with simpler
[03:10] <mattyw> morning all
[03:11] <mattyw> davecheney, ping?
[03:26] <axw> anastasiamac: https://github.com/juju/errors/pull/17 please
[03:27] <mattyw> anastasiamac, and when you're done with that would you mind taking a look at this one http://reviews.vapour.ws/r/903/ :)
[03:28] <anastasiamac> axw: done but m not graduated :D
[03:28] <axw> thanks
[03:28] <anastasiamac> mattyw: np - m going thru another one of axw
[03:28] <axw> thumper: teeny weeny change to errors, would you mind? https://github.com/juju/errors/pull/17
[03:28] <anastasiamac> mattyw: it's a lot of fun - storage - it' s huge
[03:29] <anastasiamac> mattyw: but will be done soon and will look at urs :D
[03:29] <mattyw> anastasiamac, wnjoy that - mine is just a backport of a pr that landed yesterday so should be simpler :)
[03:29] <anastasiamac> mattyw: sure thing :D
[03:35] <thumper> axw: done
[03:35] <thumper> davecheney: still want to do a 1:1?
[03:37] <mattyw> anastasiamac, and one more - I've tried to make it as trivial as possible
[03:37] <mattyw> anastasiamac, .... and here's the link: http://reviews.vapour.ws/r/904/ :)
[03:37] <anastasiamac> mattyw: i will .. thnx :D
[03:38] <mattyw> anastasiamac, you'll struggle to find a simpler one than /r/904 - ever I think
[03:38] <anastasiamac> mattyw: :D i'll let u know where it is on my scale...
[03:59] <axw> thumper: thanks
[04:13] <anastasiamac> mattyw: out of interest, where r the credentials for metrics set?
[04:14] <anastasiamac> mattyw: and yes, 904 is trivial. the only that would beat it, would a punctuation/typo correction ;D
[04:14] <anastasiamac> mattyw: urs takes the rpize
[04:15] <anastasiamac> prize*
[04:16] <mattyw> anastasiamac, they're set here https://github.com/juju/juju/blob/master/state/unit.go#L1790
[04:17] <mattyw> anastasiamac, it's one level up from the todo in the scheme of things
[04:17] <anastasiamac> mattyw: ah
[04:17] <mattyw> anastasiamac, but it makes everything much easier
[04:19] <anastasiamac> mattyw: thnx :D
[04:23] <bodie_> hmmmm; so I'm told the table test approach is hard to debug and I shouldn't use it except for trivial cases?
[04:23] <bodie_> just want to get confirmation of that
[04:27] <bodie_> i.e., for i, test := range []struct{...}{...}{do some tests on test}
[04:27] <thumper> bodie_: hey there
[04:27] <bodie_> o/
[04:27] <thumper> bodie_: I'd say tables are fine if the body of the test in the loop is simple
[04:27] <thumper> ie
[04:28] <thumper> minor setup
[04:28] <thumper> err := some-test
[04:28] <thumper> if test.err { c.Assert(err, gc.ErrMatches, test.err); }
[04:28] <thumper> else {
[04:28] <thumper> c.Assert(err, jc.ErrorIsNil)
[04:28] <thumper> other assertions
[04:29] <thumper> if there are other if statements in the body, break the tests apart
[04:29] <thumper> there are some table based tests in our code that really shouldn't be
[04:29] <bodie_> that makes sense
[04:29] <bodie_> :) thanks thumper
[04:29] <thumper> np
[04:31] <thumper> anastasiamac: here's a good one for you: http://reviews.vapour.ws/r/902/
[04:31]  * thumper runs away
[04:31] <anastasiamac> thumper: i'd add to it, that u might not want to have tables if u need to take adavantage of setup/teardown
[04:31] <thumper> anastasiamac: agreed
[04:33] <thumper> anastasiamac: FYI, a previous branch of mine added PrepareForCreateEnvironment, and renamed Prepare to PrepareForBootstrap
[04:33] <thumper> some environments need to do additional checks for bootstrap
[04:33] <thumper> like the local provider makes sure the ports aren't in use
[04:33] <bodie_> I wrote a super ugly one.. or two.. using a func(){}() to wrap a defer... :P
[04:33] <thumper> most other providers are much more simple
[04:34] <thumper> bodie_: while that isn't too terrible, it makes it harder to follow
[04:34] <thumper> one key indicator I have is "a test should be easy to follow and obviously correct"
[04:35] <thumper> it is hard enough to decode convoluted code
[04:35] <thumper> add convoluted tests to that and it just hurts more
[04:35]  * thumper looks at the uniter tests
[04:35] <bodie_> oh god
[04:36] <bodie_> I'll keep that in mind
[04:36] <thumper> night all
[06:00] <anastasiamac>  jam: thnx for ur elegant comments on RB894. i was hoping there was a convention :D
[06:00] <anastasiamac> jam: or at least a precedence
[06:00] <jam> anastasiamac: happy to, thanks for doing the review as well
[08:23] <Muntaner> ericsnow: fwereade, good morning
[08:23] <Muntaner> and good morning to every1
[08:29] <TheMue> morning
[08:42] <fwereade> Muntaner, o/
[08:42] <Muntaner> fwereade: can you have a look? https://bugs.launchpad.net/juju-core/+bug/1420155
[08:42] <mup> Bug #1420155: Juju fails to bootstrap on a private OpenStack cloud due to not finding image metadata <bootstrap> <cloud> <juju> <private> <ubuntu-openstack> <juju-core:New> <https://launchpad.net/bugs/1420155>
[08:43] <Muntaner> since I'm italian, maybe my english made this launchpad bug not understandable :)
[08:44] <fwereade> Muntaner, no, that's clear, and much appreciated
[08:44] <Muntaner> fwereade: I'm curious about how developers work
[08:44] <Muntaner> all of the confirmed bugs get fixed in a single release?
[08:45] <Muntaner> or you choose the most urgent and important and fix them ASAP?
[08:45] <fwereade> Muntaner, afraid not -- there are many bugs, and somewhat harsh constraints on which ones actually get chosen at a given time
[08:45] <fwereade> Muntaner, fwiw, I am rather grumpy that we have this particular bug and that it's lived so long
[08:46] <Muntaner> fwereade: maybe it came out because nobody had tried a configuration like mine
[08:46] <Muntaner> fwereade: is that possible? just thinking loud :)
[08:47] <fwereade> Muntaner, most likely, yes -- we see an awful lot of use of juju *deploying* private openstack clouds with maas
[08:47] <fwereade> Muntaner, and maas has its own image handling
[08:48] <Muntaner> fwereade: well, my situation is "more new" then - I don't have MAAS in my configuration
[08:49] <fwereade> Muntaner, yeah -- thank you very much for your help in tracking down the problem
[08:52] <Muntaner> fwereade: no problem! btw, I noticed that dimitern had reported this situation in another launchpad -> https://bugs.launchpad.net/juju-quickstart/+bug/1411574
[08:52] <mup> Bug #1411574: quickstart should detect private clouds somehow and generate metadata url in the environments.yaml <juju-quickstart:Triaged> <https://launchpad.net/bugs/1411574>
[08:52] <Muntaner> dunno if it needs to be merged
[08:53] <fwereade> Muntaner, quite possibly, and ericsnow found another that looked very closely related too
[08:53] <fwereade> Muntaner, funny how many ways there are of characterising the exact same underlying issue ;)
[08:54] <Muntaner> fwereade: so, the problem is that the upload of the metadatas fails in a LAN environment?
[09:01] <fwereade> Muntaner, I have a strong suspicion that the metadata-uploading is just *broken*, which is what I'm mainly so grumpy about
[09:02] <fwereade> Muntaner, I suppose that in general, for a prod environment, I'd expect a separate server for the metadata anyway, so maybe that's why it hasn't been spotted
[09:02] <Muntaner> fwereade: yes - I agree that our configuration is somewhat "raw" :)
[09:10] <mattyw> fwereade, ping?
[09:12] <mattyw> jam, ping?
[09:13] <jam> hey mattyw
[10:01] <voidspace> dooferlad: TheMue: making coffee, be with you in a minute or two...
[11:05] <perrito666> morning all
[11:08] <TheMue> perrito666: heya
[11:11] <voidspace> perrito666: o/
[11:42] <perrito666> man, I am waay to far from europe to get an ubuntu phone
[11:44] <TheMue> voidspace: the latest change on the Prepare... branch is pushed
[12:00] <voidspace> TheMue: cool
[12:03] <TheMue> voidspace: the current test for the exhausting of addresses knows the number of available IPs on a fresh dummy machine. that's no real good dependency. I added AddressesAvailable to subnet, but sadly I've got no access to the subnet from inside the test
[12:03] <TheMue> voidspace: so if you know a good approach here it's welcome
[12:10] <mattyw> is the build server feeling sick?
[12:13]  * TheMue is out to lunch
[12:13] <perrito666> mattyw: ?
[12:14] <mattyw> perrito666, seems to have been rejected branches for the last hour with all kinds of weird test failures
[12:14] <perrito666> mattyw: mm odd... well not that odd
[12:14] <perrito666> mgz ?
[12:25] <voidspace> TheMue: why do you need AddressesAvailable?
[12:25] <voidspace> TheMue: you have AllocatableIPLow and AllocatableIPHigh
[12:26] <voidspace> TheMue: available is High - low + 1 - numberAlreadyAllocated
[12:26] <voidspace> TheMue: I don't really understand your problem
[12:26] <voidspace> TheMue: point me to the test you think has the bad dependency
[12:36]  * TheMue is back
[12:37] <TheMue> voidspace: AddressesAvailable IS High - low + 1 - numberAlreadyAllocated ;)
[12:38] <TheMue> voidspace: I only created it to have an external access to this information
[12:38] <TheMue> voidspace: especially with the retrieval of the numberAlreadyAllocated
[12:39] <voidspace> TheMue: I don't understand the problem you're trying to solve
[12:39] <voidspace> TheMue: there is code that calculates this before attempting to pick a new address
[12:40] <voidspace> TheMue: so it knows if the address space is exhausted
[12:40] <voidspace> TheMue: and it has to fetch all the allocated IPs anyway
[12:40] <voidspace> TheMue: so it's no extra work
[12:40] <TheMue> voidspace: it's only for testing, I would like to know how many are still available opposite to simple pick them until they exhausted
[12:41] <TheMue> voidspace: it's not for the productive code
[12:41] <voidspace> TheMue: can't you create a subnet, then manually allocate specific addresses?
[12:41] <voidspace> TheMue: sorry, I thought you said you wanted to add AddressesAvailable to Subnet
[12:41] <voidspace> that *would* be external code
[12:41] <voidspace> why not just create a known situation
[12:42] <voidspace> TheMue: ah, but you don't have access to the subnet anyway?
[12:42] <voidspace> is that the problem
[12:42] <voidspace> so adding AddressesAvailable wouldn't help anyway
[12:42] <TheMue> voidspace: yep, no access inside the test
[12:42] <TheMue> voidspace: sadly currently not, exactly
[12:42] <voidspace> I don't think it's needed anyway
[12:42] <voidspace> TheMue: I'm about to leave :-/
[12:42] <TheMue> voidspace: ok, thanks anyway
[12:43] <voidspace> TheMue: you'd have to manipulate the test setup
[12:43] <voidspace> which with our test heirarchy is non-trivial
[12:43] <TheMue> voidspace: hoped for a simpler answer :D
[12:44] <TheMue> voidspace: currently my test relies on knowing the hard coded subnets of the dummy provider. but once somebody changes it the test would break.
[12:45] <perrito666> TheMue: well they will most likely notice :p
[12:45] <voidspace> TheMue: my answer would be that address space exhaustion is already tested
[12:45] <TheMue> perrito666: yeah, indeed
[12:45] <voidspace> TheMue: so it doesn't need testing at this level
[12:45] <voidspace> TheMue: mock out the call that would produce the error and check the error is handled well
[12:46] <voidspace> TheMue: but you don't need to simulate actual exhaustion
[12:46] <TheMue> voidspace: ok
[13:08] <wwitzel3> voidspace: do you have a maas setup?
[13:09] <voidspace> wwitzel3: yes
[13:09] <wwitzel3> voidspace: in all my attempts I am failing to reproduce https://bugs.launchpad.net/juju-core/+bug/1417875
[13:10] <voidspace> wwitzel3: I'll have to look at it on my return, I'm off out to a meeting
[13:10] <voidspace> wwitzel3: but I'll give it a go
[13:10] <wwitzel3> voidspace: all I need is for you to bootstrap and deploy something to using --to 0 and see if the logging gives you the x509 cert error.
[13:10] <wwitzel3> voidspace: thanks, appreciate it
[13:17] <perrito666> how did I not set my vim to run go fmt before saving before? this is glorious.
[13:29] <wwitzel3> perrito666: indeed, there is no other appropriate way
[13:30] <perrito666> wwitzel3: I used to, git diff, review, git commit, git push, notice go fmt is sad, scream, kick, insult, go fmt ./..., git commit --amend, git push
[13:30] <wwitzel3> perrito666: sounds exhausting
[14:53] <perrito666> restore 4 out of 6 merged :')
[15:02] <ericsnow> FYI, at some point Reviewboard will be down for (hopefully) at most an hour while we switch to a new environment
[15:02] <ericsnow> I'll be sure to notify everyone when we're close
[15:10] <TheMue> ericsnow: thx for info
[15:24] <ericsnow> natefinch: one-on-one?
[15:25] <ericsnow> natefinch: (in 5 min I guess)
[15:50] <perrito666> really another backup/restore bug breaking 1.21?
[15:51] <sinzui> perrito666, sorry, two in fact
[15:51] <perrito666> o ffs
[15:51] <perrito666> ok, on it
[15:53] <perrito666> I wonder if we should add testing support for this in the already bloated CI test
[15:55] <alexisb> hey there hazmat !
[15:55] <hazmat> alexisb: greetings
[17:06] <sinzui> Hi natefinch, do you have a moment to review http://reviews.vapour.ws/r/906/
[17:07] <natefinch> sinzui: ship it@
[17:07] <natefinch> !
[17:07] <sinzui> thank you natefinch
[17:07] <natefinch> sinzui: welcome
[18:12]  * perrito666 is back, from a 3g network in a dentist's waiting room
[18:21] <sinzui> katco, perrito666, ericsnow: CI just found a cross-compile regressions. bug 1420426
[18:21] <mup> Bug #1420426: backups_nonlinux.go import error <ci> <osx> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1420426>
[18:21] <perrito666> you have got to be kidding me
[18:22] <ericsnow> perrito666: perhaps we should just disable all tests in state/backups on non-linux
[18:23] <ericsnow> perrito666: (in package_test.go add c.Skip() if runtime.GOOS != "linux")
[18:23] <perrito666> ericsnow: could you tacle this one? I have my hands full with the other two restore blockers
[18:23] <ericsnow> perrito666: sure
[18:23] <perrito666> tx a lot, I owe a beverage of your chooice
[18:23] <perrito666> :)
[18:29] <perrito666> sinzui: I apologize, that was most likely my
[18:29] <perrito666> my fault
[18:55] <ericsnow> perrito666: http://reviews.vapour.ws/r/907/
[19:28] <voidspace> g'night all
[19:28] <voidspace> EOD
[19:57] <perrito666> orry I was suddenly trapped for the past hour in my mother in law's home, its a good thing I know how to tear apart a door
[20:00] <perrito666> ericsnow: that diff is correct?
[20:00] <perrito666> I am extremely curious how that got merged to begin
[20:05] <ericsnow> perrito666: because it would only have failed under non-linux (which I presume the merge bot does not try)
[20:05] <perrito666>   ah makes sense
[20:18] <ericsnow> davecheney: regarding that backups fix, I had considered checking runtime.GOOS, but version.Current.OS gives us better granularity
[20:34] <davecheney> ericsnow: replied on the review
[20:34] <ericsnow> davecheney: thanks
[20:41] <perrito666> sinzui: is it possible to backport (and release off course) a fix to 1.20?
[20:43] <sinzui> perrito666, we can, though it is disabled at this time
[20:44] <niedbalski> perrito666, sinzui 1.21 is OK to me, if you can confirm that juju upgrade-juju works from 1.20.8.1 to 1.21.x
[20:44] <niedbalski> :)
[20:45] <sinzui> niedbalski, 1.20.8.1 is either a custom build or juju built using upload-tools, it is not an official release and not in streams
[20:46] <sinzui> niedbalski, but I can confirm 1.20.x can upgrade to 1.21.x.
[20:46] <perrito666> ok, that is all I needed to hear
[20:47] <sinzui> niedbalski, but I will call your attention to https://bugs.launchpad.net/juju-core/+bug/1416928 which murdered my beloved juju-ci3 env
[20:47] <mup> Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Triaged> <juju-core 1.21:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1416928>
[20:47] <sinzui> niedbalski, suspect t juju flipped out when it found lxc installed in the bootstrap server
[20:51] <thumper> cmars: can I defer our call?
[20:51] <rharper> so, I'm trying to invoke an rpc of addmachine and I want to pass an arg that will be converted to a placement.instance, much lik what the juju cli does when you do juju machine add foo (it converts it to {env-uuid: foo}) ... I'm sending over a Placement value in the MachineParams structure, and the response is that it cannot unmarshal strings to an instance.Placement ;  so the question then is how do I pass the argument to the AddMachines
[20:51] <rharper>  request such that it does what the juju cli machine add does ?
[20:51] <niedbalski> sinzui, this is the simpler way to reproduce ( A. start an instance in a cloud and install lxc on it. With the manual provider, attempt to bootstrap it. )
[20:51] <niedbalski> ?
[20:51] <rharper> I'm using the python-jujuclient as the sender FWIW;
[20:57] <natefinch> rharper: placement expects to be scope:directive
[20:57] <natefinch> rharper: so, like lxc:1
[20:57] <rharper> except I can do juju add-machine foo
[20:57] <rharper> and it will do a env-uuid:foo as an instance.Placement
[20:57] <rharper> object
[20:57] <rharper> this allows me to have the provide add that machine (maas backend)
[20:58] <rharper> I want to do the same via rpc, but I can't see how to pass the args that the Init() in cmd/juju/machine/add.go does
[20:58] <rharper> it attempts to construct an placement object from the args value, and if it fails, it prepends 'env-uuid'
[20:59] <natefinch> rharper: this is the code that does the parsing of the string: https://github.com/juju/juju/blob/master/instance/placement.go#L53
[20:59] <rharper> yep
[20:59] <rharper> https://github.com/juju/juju/blob/master/cmd/juju/machine/add.go#L131
[21:00] <rharper> that's the bit where it takes extra args from machine add <args> and prepends 'env-uuid' and then calls instance.Placement()
[21:00] <cmars> thumper, sgtm
[21:00] <rharper> that's the code that appears to allow juju add-machine foo.maas to pass foo.maas (placement ) to the provide which in turns starts up foo.maas
[21:02] <rharper> natefinch: what I don't know is how incoming json rpc requests are unmarshal;  it appears from the response that it can't convert strings to instance.Placement objects ...  http://paste.ubuntu.com/10163887/
[21:03] <sinzui> niedbalski, That is one scenario
[21:05] <sinzui> niedbalski, for my case. I think I need to bootstrap 1.20.14, install lxc, reboot the machine, upgrade to 1.21. I think those are the events that happened on my server
[21:05] <natefinch> rharper: oh, I see, ok.  so for just normal json unmarshalling you just need to make placement an object with Scope and Directive string values  so, "Placement": { "Scope": "foo", "Directive": "bar"}
[21:06] <natefinch> rharper: I actually think that placement parsing code is for translation from the CLI
[21:06] <natefinch> sorry, my mistake
[21:06] <rharper> no worries;  just trying to figure out how to do the same thing the cli is doing via rpc;
[21:06] <rharper> lemme play with that now
[21:28] <sinzui> natefinch, do you have a minute to review http://reviews.vapour.ws/r/910/
[21:38] <perrito666> sinzui: the  2 restore ones are now committed to 1.21
[21:39] <sinzui> perrito666, you rock
[21:39] <perrito666> sinzui: in this case niedbalski rocks, because he put up with all the "try this" ideas I had and added some of his own :p
[21:40] <sinzui> thank you niedbalski
[21:47] <rharper> natefinch: thanks for the tip;  I've got it working, I need to extract the environment's config uuid, pass that in as the scope, and the directive uses the machine name;
[21:48] <natefinch> rharper: cool, glad you got it working
[21:56] <niedbalski> sinzui, np
[21:56] <niedbalski> perrito666, thanks for the fixes :)
[22:17] <perrito666> I really hate juju bot
[22:18] <jw4> perrito666: tsk tst
[22:21] <perrito666> jw4: we all do
[22:21] <perrito666> admit it
[22:27] <jw4> perrito666: lol
[22:30]  * hazmat pats juju bot on the head
[22:31] <jw4> heh
[22:32] <alexisb> ericsnow, release call?
[23:03] <sinzui> wallyworld_, can you review https://github.com/juju/juju/pull/1580
[23:03] <wallyworld_> sure
[23:04] <wallyworld_> well that was hard
[23:08] <ericsnow> alexisb: sorry, had a dentist appt.
[23:36] <anastasiamac> waigani: morning! as an OCR,could u plz cast ur eyes over http://reviews.vapour.ws/r/888/
[23:37] <waigani> anastasiamac: yep, just finishing a rather big one off, you're next on the list
[23:37] <anastasiamac> waigani: thnx :D