[00:29] <thumper> wallyworld: ping
[00:30] <wallyworld> yo
[00:30] <thumper> wallyworld: got a minute for a question?
[00:30] <thumper> hangout?
[00:30] <wallyworld> sure
[00:30] <thumper> wallyworld: just use or 1:1 hangout
[00:30] <wallyworld> ok
[00:31] <wallyworld> thumper: i'm here, in our 1:1
[00:32] <thumper> hmm... so am I
[00:32]  * thumper tries again
[04:53] <axw> wallyworld: that review seems to lack a diff
[04:53] <axw> looks like the hook got part way through and then died
[04:53] <wallyworld> axw: hmmm, i didn't check if there were any diff, i just noticed the review showed up after i created the PR
[04:53] <wallyworld> seems like there's an issue with the new hook
[04:54] <wallyworld> i'll ask eric
[05:43] <wallyworld_> anastasiamac: http://streams.canonical.com
[05:46] <wallyworld_> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1309207
[05:46] <mup> Bug #1309207: bad apt proxy config file in deployed nodes <apt-http-proxy> <cloud-installer> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1309207>
[05:50] <axw> wallyworld_: FYI, I've added a new section to the storage doc about provider requirements for implementation
[05:50] <axw> mainly of interest for MAAS
[05:51] <wallyworld_> axw: ok, thanks, will look a little later
[06:11] <anastasiamac> axw: thnx for review comments. did u c my corrections/comments? :-)
[06:17] <axw> anastasiamac: sorry laptop froze
[06:17] <axw> last time I looked there was no new diff to review
[06:17] <axw> I guess the integration hook
[06:18] <axw> isn't quite working properly
[06:24] <axw> anastasiamac: reviewed on github
[06:31] <anastasiamac> axw: brilliant! thnx :-)
[07:49] <voidspace> morning all
[07:51] <mattyw> morning everyone
[09:05] <TheMue> jam: ping
[09:05] <jam> hey TheMue, be there in a couple mins, sorry Im late
[09:05] <TheMue> jam: no problem
[09:28] <jam> TheMue: I'm here now
[10:06] <voidspace> dimitern: ping
[10:07] <dimitern> voidspace, pong
[10:18] <voidspace> jam: http://bazaar.launchpad.net/~virtual-maasers/charms/precise/virtual-maas/trunk/view/head:/README-nojuju.txt
[10:21] <voidspace> jam: https://insights.ubuntu.com/2013/11/15/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/
[10:42] <voidspace> are we still manually closing review board reviews once a branch is merged?
[10:51] <voidspace> jam: "static-ipaddresses" is in the capabilities api - just not listed in the documentation
[10:51] <voidspace> jam: I'll file an issue
[10:57] <voidspace> ah, already fixed apparently
[10:57] <voidspace> https://bugs.launchpad.net/maas/+bug/1375647
[10:57] <mup> Bug #1375647: 'static-ipaddresses' capability in 1.6 not documented. <doc> <trivial> <MAAS:Fix Committed by julian-edwards> <https://launchpad.net/bugs/1375647>
[11:23] <dimitern> voidspace, TheMue, jam, guys, I just got notified I'll be without power for some time while they fix some issue, so I'll be back when it's on again
[13:27] <jcastro> Can I do `instance-type: m3.xlarge` in environments.yaml and have that dtrt?
[13:30] <w7z> jcastro: nope
[13:37] <jcw4> ericsnow: any idea why http://reviews.vapour.ws/r/201/ (super trivial PR) doesn't include a diff on reviewboard?
[13:40] <jcw4> ericsnow: I did an rbt post -u and the diff appeared (and added the whole juju-team as reviewers)
[13:45] <sinzui> Ladies and Gentleman. This might be a bad day. No version of Juju we try can bootstrap with azure: https://bugs.launchpad.net/juju-core/+bug/1383310
[13:46] <mup> Bug #1383310: Juju stable and devel cannot bootstrap Azure <azure-provider> <bootstrap> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383310>
[13:49] <jcw4> sinzui: sounds like azure changed their configuration offerings to make them incompatible with our default constraints?
[13:49] <sinzui> informative, thank you jcastro
[13:50] <sinzui> jcw4, ^
[13:50] <jcw4> lol :)
[13:50] <jcastro> it's ok, I'm on ec2 today anyway. :)
[13:50] <jcw4> hehe
[13:55] <perrito666> ericsnow: natefinch: Hey I have some people working at home around me, Ill have to skip this one sorry :(
[14:01] <ericsnow> jcw4: I'll take a look
[14:01] <jcw4> ericsnow: ta
[14:04] <jcw4> sinzui: did the CI build machine run out of space? ("write /mnt/tmp/juju-tgz519656690: no space left on device")
[14:04] <jcw4> http://juju-ci.vapour.ws:8080/job/github-merge-juju/947/console
[14:05] <w7z> jcw4: that's generally a symptom of aws in general being unhappy, I'll investigate
[14:05] <jcw4> w7z: thanks
[14:05] <sinzui> jcw4, If it did, it was cleaned up There is space now
[14:06] <jcw4> w7z: are you mgz?
[14:06] <w7z> yup, sorry
[14:06] <jcw4> lol
[14:06] <jcw4> sinzui: hmm; okay maybe I'll try again
[14:07] <jcw4> wwitzel3, w7z : pre-push hook improvement PR http://reviews.vapour.ws/r/197/
[14:08] <fwereade> dimitern, ping
[14:08] <sinzui> jcw4, both / and /mnt are fine and /tmp was cleaned.
[14:08] <jcw4> sinzui: weird
[14:08] <dimitern> fwereade, pong
[14:08] <fwereade> dimitern, in HookContext, when getting public/private address
[14:09] <fwereade> dimitern, we have a check for IsCodeNoAddressSet
[14:09] <fwereade> dimitern, do you remember why?
[14:09] <sinzui> jcw4, The test script running will cleanup, so disk really could have been used up. The machine currently as 24G and 122G available on both partitions
[14:09] <fwereade> dimitern, (git blames you for those lines ;p)
[14:09] <dimitern> fwereade, because it might be unavailable yet?
[14:09] <fwereade> dimitern, I'm assuming it's because moving addresses t the machine introduced a race
[14:10] <fwereade> dimitern, yeah
[14:10] <jcw4> sinzui: hopefully my second try will work
[14:10] <fwereade> dimitern, can you think of any reason not to delay hook execution until there is an address?
[14:11] <fwereade> dimitern, ISTM that the current behaviour is still buggy, it just means the uniter doesn't fall over
[14:11] <fwereade> dimitern, but it pushes the bugginess into the charm's lap
[14:12] <fwereade> dimitern, I guess the question is for how long we might be without an address
[14:14] <dimitern> fwereade, delaying the hook sgtm
[14:14] <fwereade> dimitern, are there any cases we might be left without an address for arbitrarily long time?
[14:14] <dimitern> fwereade, how long? well.. hard to tell, but it shouldn't be long in the usual case - as soon as the instance poller runs and gets an address
[14:15] <fwereade> dimitern, and we'll get both public and private still?
[14:15] <dimitern> fwereade, iirc that haven't changed
[14:15] <fwereade> dimitern, even if there's no public address (ie we return the private one?)
[14:15] <fwereade> dimitern, cool
[14:15]  * perrito666 runs the whole test suite before pring and has time to brew tea
[14:15] <w7z> jcw4: I'm not mad about that script still being bash with that much added logic
[14:16] <jcw4> w7z: whew
[14:16] <jcw4> :)
[14:41] <dimitern> axw, are your still around by any chance?
[14:42] <katco> dimitern: it's pretty late for him i think... ~11pm
[14:43] <dimitern> katco, yep, just checking :)
[14:54] <sinzui> natefinch, can you organise an effort to understand bug 1383310? I fear azure cloud changed and we need new stable and devel juju's to work with it
[14:54] <mup> Bug #1383310: Juju stable and devel cannot bootstrap Azure <azure-provider> <bootstrap> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1383310>
[15:04] <blackboxsw> in
[15:06] <natefinch> sinzui: ok
[15:20] <jcw4> w7z: any preference for the extracted verification script name? verify.bash seems a little generic
[15:25] <dimitern> any reviewers wanna have a look at a trivial branch http://reviews.vapour.ws/r/202/ ?
[15:28] <jcw4> w7z: (and any other reviewers) pre-push hook update: http://reviews.vapour.ws/r/197/
[15:32] <dimitern> voidspace, if still around ^^
[15:33] <voidspace> dimitern: sure
[15:34] <voidspace> dimitern: hah, nice and easy :-)
[15:35] <voidspace> dimitern: in the whitebox test, why  did you add the extra config to the NewNetwork calls?
[15:35] <dimitern> voidspace, it is :)
[15:35] <jcw4> dimitern: fwiw, I just did an rbt post -u and my diff appeared along with the juju-team reviewer being added
[15:35] <dimitern> jcw4, ha, good to know, thanks! :)
[15:35] <dimitern> voidspace, because of the gomaasapi changes
[15:36] <dimitern> voidspace, now "ip" and "netmask" are required attributes for a network inside the MAAS test server
[15:36] <voidspace> dimitern: ok
[15:36] <voidspace> dimitern: so for maas there's no test of the false or error cases?
[15:36] <voidspace> dimitern: only the true case
[15:37] <dimitern> voidspace, it's a bit shitty, but the reason is "/ipaddresses/?op=reserve&network=1.2.3.4/5" expects network= to be a CIDR of an existing network, while *everywhere* else a network can be referred to by name or other things (i.e. "ip:1.2.3.4", etc)
[15:39] <dimitern> voidspace, yes, because as agreed in brussels, we'll be dropping support for maas pre 1.6 and 1.7 will be SRU-ed into trusty
[15:39] <voidspace> dimitern: but there's still an untested code path - even if it's an "unsupported" code path
[15:40] <voidspace> dimitern: I mean, it's trivial code - so maybe it's alright
[15:40] <dimitern> voidspace, expand a bit please?
[15:40] <dimitern> voidspace, you mean testing "IsFalse" case?
[15:40] <voidspace> dimitern: you could hard code the maas implementation of SupportAddressAllocation to return true
[15:40] <voidspace> dimitern: and no tests would fail
[15:41] <dimitern> voidspace, that's true
[15:41] <voidspace> dimitern: yes, the IsFalse case
[15:41] <dimitern> voidspace, the maas test server is really not easy to tweak, so it can return the capability or not
[15:41] <voidspace> right
[15:41] <dimitern> voidspace, but it will work in the real world - returning false against an older maas
[15:42] <voidspace> dimitern: the code certainly *looks* correct ;-)
[15:42] <voidspace> dimitern: anyway, LGTM
[15:42] <dimitern> voidspace, cheers!
[15:43] <voidspace> dimitern: I assigned that card to you as it was previously assigned to me
[15:43] <dimitern> voidspace, yeah, thanks - I realized this PR actually implements the SAA() cap, so I'll move both to merged once the PR lands
[15:57] <voidspace> dimitern: new private  method for checking default vpc is on ec2/ec2.go:environ right?
[15:58] <voidspace> or on ec2Instance
[15:58] <dimitern> voidspace, yeah, it should return (VpcId, bool)
[15:58] <dimitern> voidspace, on environ
[15:58] <voidspace> dimitern: coolio, thanks
[16:32] <bodie_> anyone have a thought briefly about whether batch calls on the api client should be exported?
[16:36] <bodie_> for example, I can imagine a use case where the client wants to find the action schemas for multiple services
[16:55] <sinzui> natefinch, could this be relevant to the azure failures: http://azure.microsoft.com/blog/2014/10/17/azure-service-bus-namespacetype-default-value-change/
[16:56] <sinzui> ah, that doesn't say the change will be enforced until the 26th
[16:57] <natefinch> sinzui: yeah, I don;t think that would be the problem . Sorry, I haven't been able to dive into the azure problem just yet, but will in just a little bit.  I know it's obviously very critical
[17:32] <mattyw> ericsnow, ping?
[17:32] <ericsnow> mattyw: ping
[17:33] <mattyw> ericsnow, just a quick question about the review board integration (thanks very much by the way)
[17:33] <mattyw> ericsnow, if I push updates to a pr. Does the review board branch need to have the changes published or is it automatic?
[17:35] <ericsnow> mattyw: it is automatic
[17:52] <mattyw> ericsnow, me again, there doesn't seem to have been a diff generated: http://reviews.vapour.ws/r/203/
[17:53] <ericsnow> mattyw: yeah, no reviewers are getting set which ultimately causes no diff to get attached
[17:53] <ericsnow> mattyw: I'm working on fixing it :(
[17:53] <mattyw> ericsnow, I set juju-team as the group
[17:53] <ericsnow> mattyw: perfect
[17:54] <mattyw> ericsnow, I did that before publishing - but there still seems to be no diff
[17:54] <mattyw> ericsnow, is there something I should/ can do or can you sort it?
[17:54] <ericsnow> mattyw: until I get this fixed you'll have to use rbt -u
[17:54] <mattyw> ericsnow, I don't mind using rbt
[17:54] <mattyw> ericsnow, cool
[18:27] <voidspace> g'night all
[19:13] <thumper> ericsnow: hey
[19:13] <ericsnow> thumper: hey
[19:13] <thumper> ericsnow: with the new github integration stuff
[19:14] <thumper> I have a review that was pushed last week
[19:14] <thumper> if I just push to github
[19:14] <thumper> will it pick up the new diff?
[19:14] <thumper> or do I still need to use rbt for that?
[19:14] <ericsnow> thumper: sorry, no (keep using rbt for that)
[19:14] <thumper> ok
[19:15] <ericsnow> thumper: also FYI the integration is currently broken (I'm working on a fix)
[19:15] <perrito666> ericsnow: ah gtk, so I should hold my pr then?
[19:16] <ericsnow> perrito666: I support you could
[19:16] <perrito666> ericsnow: seems your english integration just broke too
[19:16] <ericsnow> perrito666: or just do it, and then publish the auto-generated review request and use rbt -u to push the diff
[19:16] <ericsnow> perrito666: haha
[19:17] <perrito666> ericsnow: oh, I can just go ad do the publish by hand?
[19:17] <ericsnow> perrito666: muscle memory
[19:17] <ericsnow> basically yeah
[19:17] <perrito666> I thought broken means nothing works at all
[19:17] <katco> is anyone familiar with machine/container id formats as they're stored in mongo?
[19:18] <ericsnow> perrito666: no, the review request gets created, but without any reviewers set
[19:18] <perrito666> ericsnow: works for me I know how to finish that by han
[19:18] <perrito666> d
[19:19] <ericsnow> perrito666: cool
[20:08] <natefinch> sinzui: what's up with azure?
[20:15] <sinzui> natefinch, I think West US is bad
[20:15] <sinzui> natefinch, We have not been able to use it for 3 days. I set East US and juju works
[20:16] <sinzui> natefinch, ...I find it hard to believe that West US has been over saturated for 3 days that we have had no successful bootstraps
[20:17] <sinzui> natefinch, abentley jog. We have a passing cloud-health check and revision tests because I setup CI for East US.
[20:17] <natefinch> sinzui: that does seem unlikely, but I also don't know why US west would fail while East passes
[20:18] <sinzui> natefinch, abentley purges our account of all resources. We didn't have much beyond a storage account and a network
[20:19] <sinzui> natefinch, mayeb azure has rules at a higher level. Canonical as a company may have reached a limit for the West region?
[20:19] <natefinch> sinzui: could be.  Do you know if we have contacts over there?
[20:19] <sinzui> Antonio has contacts.
[20:21] <sinzui> My own report of usage shows were are using less that 5% of any one resource
[20:23] <sinzui> natefinch, I think this bug is implicitly fixed with the release of 1.21.0 because users wont need to specify storage: https://bugs.launchpad.net/juju-core/+bug/1236136
[20:23] <mup> Bug #1236136: Azure bootstrap fails when 'location' and 'storage-account-name' are not in the same region <azure-provider> <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1236136>
[20:25] <thumper> o/ davecheney
[20:26] <davecheney> thumper: sorry, still a bit jetlagged
[20:26] <thumper> davecheney: that's ok
[20:26]  * thumper has just been hacking
[20:27]  * davecheney heads for the hangout
[20:27] <natefinch> sinzui: we should talk to Microsoft about Azure and why we might be getting that error on West.  It sounds like it's an azure problem, honestly.  If they can't give us an instance with 2 GB of RAM.... that seems like a pretty severe problem on their side.
[20:31] <sinzui> natefinch, funny you should mention 2G ram. Azure can give us 4G or 1.75G. Maybe I find constraints that will select a machine in the region
[20:32] <natefinch> sinzui: I thought i saw a constraint given that said 2GB.... juju just treats that as a minimum and will pick the cheapest instance with at least that much TAM
[20:32] <natefinch> RAM
[20:33] <sinzui> yes, RAM
[20:37] <natefinch> sinzui: hrm, creating a machine manually from the azure website in US West seems to work ok
[20:38] <sinzui> yep
[20:38] <sinzui> natefinch, setting constraints to 2G, 4G and 8G fails.
[20:45] <natefinch> sinzui: there was a big microsoft azure presentation today
[20:46] <natefinch> sinzui: in SF.... maybe a lot of people are poking at Azure US West today
[20:46] <natefinch> though you said it's been a few days
[20:46] <sinzui> natefinch, azure west died on the 17th, as we were EOD
[21:05] <davecheney> thumper: https://bitbucket.org/goarm64/go/commits/all
[21:05] <davecheney> so you can see what is going on
[21:05] <davecheney> i added 'howbazaar'
[21:06] <thumper> davecheney: cheers
[22:00] <alexisb> thumper, on and ready when you are