[00:07] <menn0> thumper: easy one: http://reviews.vapour.ws/r/5482/
[00:08] <menn0> axw: when you're around can we talk about bug 1569632 please?
[00:08] <mup> Bug #1569632: status: decide on statuses for migration <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1569632>
[01:00] <perrito666> thumper: well that is awkwards, menn0 gave you a nice ship it and I just added a bunch of issues
[01:03] <axw> menn0: I'm around now
[01:04] <redir> wallyworld: I think I'm ready for a consult
[01:04] <redir> if you're available
[01:04] <wallyworld> ok
[01:04] <wallyworld> standup ho?
[01:06] <perrito666> wallyworld: that is an awful thing to call redir
[01:06] <wallyworld> perrito666: you funny
[01:06] <wallyworld> btw
[01:06] <wallyworld> i am having acl issues
[01:06] <wallyworld> there's some code left in the admin_root which checks for read only calls
[01:06] <wallyworld> and the list of read only calls in incorrect
[01:07] <wallyworld> and we don't even need that check anymore
[01:07] <perrito666> wallyworld: well we can nuke that
[01:07] <wallyworld> yep, doing it
[01:07] <perrito666> I decided to nuke it post-implement acls
[01:07] <perrito666> just as a failsafe
[01:07] <wallyworld> sure, i need to remove it for my branch to work
[01:07] <wallyworld> users can't list models
[01:07] <wallyworld> admins can, but not others
[01:07] <redir> brt
[01:08] <perrito666> wallyworld:mm, after reading the list models method I assumed it would show to each user their own models
[01:08] <perrito666> therefore it was safe to make it RO
[01:08] <perrito666> since RO users will just not get results
[01:08] <wallyworld> it is, but that hard coded list omitted the ListModels call
[01:08] <perrito666> ahh I see
[01:08] <wallyworld> RO users need to be able to see their own models
[01:09] <wallyworld> anyways, all fixed now
[01:09] <wallyworld> i just wanted to check that you agreed we should remove that code
[01:21] <thumper> katco: no
[01:24] <thumper> perrito666: hmm... we often don't check the error returns of fmt.Fprintf as well
[01:25] <thumper> perrito666: given the number of places we call flush without checking, I think this is ok
[01:26] <perrito666> thumper: I assumed so, It tickled me because we where checking it in just one place and you removed it, but I believe its ok too
[01:27] <perrito666> thumper: the other ones are valid though :p
[01:27] <thumper> you expect me to file bugs for dfc's old comment?
[01:27] <thumper> that's a bit rough
[01:28] <thumper> perrito666: and changing other fmt.errorf calls...
[01:28] <perrito666> thumper: you are the one that said that we should .... meh forgot the words but something about leaving stuff neater than we found, also you passed by that code and dfc was your teammate :p at least re-own it
[01:28] <thumper> :P
[01:30] <perrito666> anyway, eod, cheers all
[01:31] <wallyworld> thumper: running a minute late
[01:31] <katco> thumper: yay
[02:16] <wallyworld> thumper: with colour, axw had a good point - you need to keep the * still, for the current controller etc even when it is a terminal and colour is used
[02:16] <thumper> wallyworld: let me show you something
[02:16] <axw> (for colour blind people; unless the contrast between green and white is enough?)
[02:16] <thumper> ah...
[02:16] <thumper> good point
[02:16] <thumper> it was so good though :)
[02:17] <wallyworld> having an extra * is not big deal, it's still green
[02:20] <thumper> wallyworld: intermittent failure :(
[02:20] <wallyworld> faaaaaaaarrrrkkkk
[02:21]  * thumper needs foot
[02:21]  * thumper needs food
[02:22]  * thumper has two feet 
[02:46] <axw> wallyworld: RB bot is asleep, can you please review https://github.com/juju/juju/pull/6034
[02:46] <wallyworld> sure
[02:46] <axw> wallyworld: I decided not to make the change to the machiner worker after all, if you force destroy a machine you shouldn't expect it to uninstall cleanly
[02:46] <axw> wallyworld: and there's another scenario where it could happen, with a note that we explicitly don't handle it because state could just be borked
[02:47] <wallyworld> that's the change to react to not found?
[02:47] <axw> wallyworld: and uninstalling because of a bug would be bad
[02:47] <axw> wallyworld: yes. so I just changed the cleanup to not force destroy on destroy-model
[02:47] <wallyworld> ok
[02:49] <wallyworld> axw: lgtm, thanks
[02:49] <axw> ta
[03:02] <thumper> wallyworld: landed!!!!
[03:02] <thumper> \o/
[03:02] <wallyworld> awesome
[03:02] <katco> thumper: grats
[03:02] <wallyworld> will propose my branch now
[03:06] <wallyworld> thumper: http://reviews.vapour.ws/r/5483/
[03:07] <thumper> wallyworld: why have you removed read only calls?
[03:07] <wallyworld> 1. out of date, 2. did you read horatio's email?
[03:07] <thumper> no...
[03:07] <thumper> also
[03:07] <wallyworld> no longer needed since permission checks are on each moethod now
[03:08] <thumper> what would the mechanism be to block all modifying calls for things like migration?
[03:08] <wallyworld> the methods do permission checks
[03:08] <wallyworld> sigh, so many issues this week with people not reading their emails
[03:08] <thumper> well, been a bit busy
[03:08] <wallyworld> all facade methods are expected to have a permission check now
[03:09] <wallyworld> as a code review checklist step, that must be enforced
[03:09] <wallyworld> sometimes the check is done for the entire facade at construction time
[03:09] <wallyworld> if all methods require write for example
[03:11] <wallyworld> that hard coded list was also out of date - it omitted legitimate read only methods
[03:11] <wallyworld> so people were not maintaining it
[03:14] <anastasiamac> wallyworld: great idea ^^ could u plz add it to our review checklist? https://github.com/juju/juju/wiki/Code-Review-Checklists
[03:16] <wallyworld> i thought it had been, i'll need to double check it
[03:19] <anastasiamac> it's there :D "Do facades and methods have the required authorization checks? "
[03:39] <veebers> thumper: I'm late to the game but the colour output is pretty damn sweet
[03:39] <thumper> :)
[03:39] <thumper> ta
[03:39] <mup> Bug #1614809 opened: api-caller remains post migration <juju-core:New for menno.smits> <https://launchpad.net/bugs/1614809>
[03:50] <wallyworld> thumper: thanks for review, i was also wondering about MODEL UUID
[03:51] <wallyworld> i started with CONTROLLER but thought it looked a bit wrong tbh
[03:51] <wallyworld> i can go with that and we'll get feedback i'm sure
[03:53] <wallyworld> i went with Controller because it's not a table header
[03:54] <anastasiamac> wallyworld: axw: menn0:thumper: can u get to RB?
[03:54] <natefinch> is reviews.vapour.ws broken for anyone else?
[03:54] <axw> anastasiamac: nope
[03:54] <axw> AccessDenied
[03:54] <wallyworld> just broke right now
[03:54] <wallyworld> ffs
[03:54] <anastasiamac> yep. the same :(
[03:54] <menn0> broken for me
[03:55] <katco> this test has defeated me. /EOD
[03:56] <wallyworld> katco: wow, you're on late
[03:57] <anastasiamac> axw: wallyworld: I've cleaned up PR, PTAL https://github.com/juju/juju/pull/6023
[03:57] <wallyworld> real soon
[04:11] <thumper> axw: my cunning plan to use the poolmanager has been poleaxed by an import cycle
[04:12] <thumper> stateenvirons
[04:12] <axw> thumper: what about stateenvirons?
[04:13] <thumper> axw: I was trying to use it in migration_import and export
[04:13] <thumper> which are in state
[04:13] <axw> thumper: yeah, you can't/shouldn't use stateenvirons from state. you also shouldn't need it
[04:13] <thumper> to get a NewStorageProviderRegistry
[04:13] <axw> un moment
[04:14] <axw> thumper: func (st *State) storageProviderRegistry() (storage.ProviderRegistry, error)
[04:14] <thumper> ah ha
[04:18] <thumper> axw: think I figured out a way to not expose the pool global key malarky
[04:18] <axw> thumper: move the poolmanager code into state? :)
[04:18] <axw> thumper: how?
[04:18] <thumper> you'll see
[04:19]  * thumper does more fixes
[04:19] <axw> okey dokey
[04:20]  * thumper crosses fingers while tests run
[04:21] <thumper> axw: I think this last attempt will may you much happier
[04:21] <thumper> w00t, tests pass
[04:21] <thumper> now a bit of cleanup
[04:24] <thumper> axw: https://github.com/juju/juju/pull/6024
[04:26] <axw> thumper: yes, much nicer :)
[04:40] <thumper> wallyworld, axw, menn0: https://github.com/juju/juju/pull/6036
[04:40] <thumper> not sure about the green for current actually
[04:40] <thumper> I was thinking something that "pops" a bit more
[04:40] <menn0> thumper: light blue?
[04:41]  * wallyworld is looking at another pr
[04:42] <thumper> menn0: not sure
[04:42] <menn0> thumper: LGTM to me anyway
[04:43] <menn0> gah...
[04:43]  * menn0 is tired
[04:44] <thumper> perhaps we land and bikeshed over color?
[04:44] <thumper> or make the color definable with an env var?
[04:44] <thumper> heh
[04:44]  * thumper out
[04:44] <natefinch> so we're bikeshedding on what to bikeshed on now?
[04:45] <natefinch> every time I look at gojsonschema it looks worse
[04:45] <axw> wallyworld: pretty sure the ssh issue is another latent bug, woohoo
[04:46] <wallyworld> yay
[04:47] <axw> wallyworld: the instance poller backs off when it sees a machine that isn't provisioned, doesn't start querying again immediately when it is provisioned
[04:48] <axw> wallyworld: so it takes a while for it to kick back in, since the machines are taking around a minute to come up
[04:48] <wallyworld> i can beliebe that - the poller is independent of the provisioner
[04:48] <wallyworld> if only we had pubsub
[04:49] <axw> wallyworld: nah it's just crappy implementation, it *can* react to the machine change
[04:49] <axw> and I will fix it to do that now
[04:49] <wallyworld> ok
[04:51] <menn0> thumper-afk: I probably shouldn't tell you this but "less -R" will let you use less with colors ... could be interesting to integrate into debug-log
[05:12] <wallyworld> anastasiamac: latest pr is much smaller change set from the first one which is good; for some reason i find it easier to review on rb compared to github
[06:06] <mup> Bug #1614835 opened: Unittest guiVersionSuite.TearDownSuite fails <ci> <unittest> <juju-core:Triaged> <https://launchpad.net/bugs/1614835>
[06:07] <anastasiamac> wallyworld: \o/
[06:07] <anastasiamac> wallyworld: also hosted arch is added so that we can validate upload tools..
[06:08] <wallyworld> anastasiamac: but it's not an arch supported by the substrate
[06:08] <wallyworld> if you bootstrap from amd64 and try and run an arm64 controller that should break
[06:09] <wallyworld> when uploading tools, ther question to ask is - does the cloud and image i will be using to bootstrap on match the arch of my bootstrap client
[06:10] <wallyworld> adding host arch to the list of supported arches subverts that
[06:10] <anastasiamac> wallyworld: let me clean up this pr and if this is the question to ask then validateuploadallowed is not asking it
[06:10] <anastasiamac> wallyworld: i really need to land it, u can fix as an iteration. this fix fixes my bug
[06:11] <wallyworld> but introduces a new one
[06:13] <anastasiamac> wallyworld: i dont see how it introduces new one - currnet behavior
[06:13] <wallyworld> it's not current behavour, that's the issue
[06:14] <wallyworld> if you try and upload tools from an amd64 client to a ppc64 cloud it will fail
[06:14] <wallyworld> or more so, from a s390 client to aws for example
[06:15] <anastasiamac> if there is a test, then i will not b able to land my change. at this stage = all tests pass
[06:56] <axw> wallyworld: PTAL, https://github.com/juju/juju/pull/6037
[06:58] <axw> wallyworld: BTW I was confused, we don't get updates on the machine doc in general; only lifecycle changes
[06:59] <axw> so I've left it as polling for now, but changed it to only back off after it's been provisioned
[07:47] <wallyworld> axw: yeah, that's why i was wishing for pubsub - could easily notify of such changes, looking now
[07:56] <wallyworld> axw: i think i'm reading the test wrong - it seems that prior to m.setInstanceId("inst-ance") we *want* case <-polled and thereafter not, but it seems the test is the other way around?
[07:58] <axw> wallyworld: before setInstanceId, the test fails if <-polled. after, it fails if it times out waiting for <-polled
[07:58] <wallyworld> yeah, that's what's confusing me
[07:58] <wallyworld> before set instace id, machine is not provisioned so we want regular polling
[07:59] <wallyworld> so we'd expect to see,_polled, no?
[08:00] <axw> wallyworld: perhaps the var name is throwing you off. <-polled means that it queried the provider for instance info
[08:00] <wallyworld> i was thinking polled was for querying instance addresses
[08:01] <wallyworld> which we want to do regularly until provisoned
[08:01] <axw> wallyworld: and that hasn't changed, the only change is that there's no backoff. that's proven by the clock advancing exactly the "short poll" amount of time
[08:01] <axw> wallyworld: nope, how would you do that without an instance ID?
[08:01] <wallyworld> good point
[08:01] <wallyworld> i haven't context switched in the code properly
[08:02] <wallyworld> lgtm though, i was was confused
[08:02] <mattyw> hey folks, I'm getting an XML AccessDenied from reviewboard, anyone else?
[08:03] <wallyworld> mattyw: yeah, it's borked
[08:04] <mattyw> wallyworld, awesome, hello by the way!
[08:04] <wallyworld> hey!
[09:19] <voidspace> fwereade_: ping
[09:20] <fwereade_> voidspace, pong
[09:21] <voidspace> fwereade_: txn-revno is maintained by the txn layer, so all I need to use it is to declare it in the doc. Right? Like this: http://pastebin.ubuntu.com/23069609/
[09:21] <fwereade_> voidspace, so long as you *only* read that doc and don't write it, yes
[09:22] <fwereade_> voidspace, iirc accidentally writing a txn-revno can mess everything up
[09:22] <voidspace> fwereade_: sounds like fun
[09:22] <voidspace> fwereade_: http://pastebin.ubuntu.com/23069620/
[09:23] <voidspace> fwereade_: although I think that code should return no-ops if the hostports are equal (it doesn't currently do that either)
[09:23] <fwereade_> voidspace, +1 to that
[09:23] <voidspace> kk
[09:23] <fwereade_> voidspace, and if you just declare that doc inside that func then you shoudl be safe from anyone accidentally writing it in future
[09:24] <voidspace> yep
[09:26] <voidspace> fwereade_: I don't think this particular contention problem is possible to test directly - other fixes we've committed didn't have new tests
[09:27] <voidspace> fwereade_: so if the existing tests pass (checking that they're good tests of course) I'll call it good
[09:27] <voidspace> currently they pass - just trying again with the NoOp path
[09:29] <fwereade_> voidspace, hm, surely you can test SetAPIHostPorts racing with itself at least?
[09:29] <voidspace> fwereade_: I'm hoping there is already a race test :-)
[09:29] <voidspace> maybe optimistic
[09:31] <fwereade_> voidspace, fwiw I can think of two: (1) BeforeHook change to a new value, check 2 txn attempts; (2) BeforeHook change to desired value, check 1 attempt only
[09:32] <voidspace> fwereade_: understood
[09:32] <voidspace> fwereade_: there's at least one concurrent test already
[09:32] <fwereade_> voidspace, cool
[09:32] <voidspace> two - ConcurrentSame and ConcurrentDifferent
[09:32] <fwereade_> huh, access denied from reviews.vapour.ws
[09:32] <voidspace> fwereade_: reading them
[09:32] <fwereade_> anyone else
[09:32] <fwereade_> voidspace, awesome
[09:33] <fwereade_> voidspace, the test names seem good, anyway ;)
[09:33] <voidspace> fwereade_: yep, me too
[09:33] <fwereade_> mgz, I think of you as the person who effortlessly fixes everything, is that something you can address? ^^
[09:34] <voidspace> All current tests pass, that's a good sign
[09:51] <hoenir> how to know if juju is using the default tools or the tools that I specified ?
[09:52] <hoenir> this means it's using the deafult?
[09:52] <hoenir> https://paste.ubuntu.com/23069672/
[09:53] <hoenir> cmd is juju bootstrap maas maas --debug --show-log --config agent-metadata-url='192.168.122.157/toolsdir/tools/' --bootstrap-series='trusty'
[09:53] <hoenir> anyone?
[10:15] <perrito666> hoenir: looks a lot like its using the default
[10:17] <hoenir> perrito666, how can I use my own tools?
[11:43] <mup> Bug #1614929 opened: Panic when destroying controller <juju-core:New> <https://launchpad.net/bugs/1614929>
[11:57] <fwereade_> voidspace, if you have a moment, https://github.com/juju/juju/pull/6040
[11:57] <fwereade_> voidspace, the critical thing is really to QA it, and come to a conclusion re the JustRemoveOp(..., -1); everything else has been reviewed in detail by many people
[12:02] <voidspace> fwereade_: about to go on lunch - can look after that
[12:04] <fwereade_> voidspace, cheers
[12:46] <mup> Bug #1614929 changed: Panic when destroying controller <juju-core:Invalid> <https://launchpad.net/bugs/1614929>
[12:46] <mup> Bug #1614948 opened: cmd/juju: "error" capitalisation is inconsistent <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1614948>
[12:56] <jam> natefinch-afk: ping if you're around
[13:27] <natefinch> jam: pong
[13:28] <perrito666> tha lag
[13:29] <perrito666> mgz: could you kick reviewboard server?
[13:31] <mup> Bug #1614961 opened: juju ssh to azure hosts fails <azure-provider> <ci> <jujuqa> <regression> <ssh> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1614961>
[13:40] <mgz> perrito666: I don't think I can
[13:40] <perrito666> mgz: I think you do :p
[13:40] <perrito666> that is one of CI machines, I am sure of it
[13:41] <mgz> well, I guess I do have ssh access, just not the management creds
[13:41] <perrito666> or you can provide me access+sudo and Ill gladly dig into the pile of... code
[13:41] <mgz> so i can poke around at least
[13:41] <mgz> perrito666: you have it
[13:41] <perrito666> mgz: oh
[13:42] <mgz> cloud-city and ssh with the staging-juju-rsa key
[13:44] <mgz> hm, proxy error spam
[13:44] <mgz> why is it even trying to access /releases/unknown-outcome
[13:46] <mup> Bug #1614961 changed: juju ssh to azure hosts fails <azure-provider> <ci> <jujuqa> <regression> <ssh> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1614961>
[13:48] <voidspace> hmmm... reviewboard is borked again
[13:50] <mgz> yeap, not sure what the fix is
[13:51] <perrito666> voidspace: looking into it
[13:51] <voidspace> perrito666: thanks
[14:00] <rick_h_> natefinch voidspace ping for standup
[14:00] <voidspace> rick_h_: omw
[14:07] <sinzui> perrito666: voidspace I am going to reboot review board. the services are healthy. I think the host or the proxy have thrown a wobbly
[14:09] <voidspace> sinzui: much appreciated
[14:10] <babbageclunk> voidspace, frobware: Could you take a look at this please? (github link since there's no RB link) https://github.com/juju/juju/pull/6042
[14:10] <voidspace> babbageclunk: I think my review plate is full until EOD I'm afraid
[14:11] <babbageclunk> voidspace: :(
[14:11] <voidspace> babbageclunk: I have two to do and I want to leave and go to mountains, sorry
[14:11] <babbageclunk> voidspace: Well, at least it's not just on my hard drvie now!
[14:11] <voidspace> babbageclunk: haha, yeah - ice
[14:11] <voidspace> I mean *nie
[14:11] <voidspace> *nice dammit
[14:11] <voidspace> fat fingers
[14:11] <babbageclunk> voidspace: That's wjat I meant too.
[14:11] <voidspace> babbageclunk: new SSD or repaired computer yet?
[14:12] <voidspace> ERROR invalid config: lxd version 2.1, juju needs at least 2.0.0
[14:12] <voidspace> anyone seen that - is it fixed on master?
[14:12] <babbageclunk> voidspace: using a loaner that Rodney gave me - it's a beast! 8 cores and 32Gb
[14:12] <voidspace> I guess I can check master...
[14:12] <voidspace> babbageclunk: wow
[14:13] <babbageclunk> voidspace: test runs are nice and quick. Not much fun biking home with it though.
[14:13] <voidspace> babbageclunk: yow
[14:13] <voidspace> yeah, I bet
[14:23] <katco> with juju/errors, how can i retrieve the underlying error if it has been Wrap(..)ed
[14:34]  * katco crosses fingers and does a full test run of cmd/juju/application
[14:37]  * rick_h_ looks for a chicken to sacrifice to the test run gods, but finds none
[14:37] <natefinch> katco: if you want the original error, you can get Cause(err) ... if there's N wraps, that gives you the first one, if you want the N-1th one, I'm not sure you can
[14:37] <katco> natefinch: hm, that didn't seem to work
[14:38] <katco> natefinch: i'll sanity check and try again after this run is done. didn't get much sleep
[14:38] <natefinch> katco: oh, wrap, yeah...
[14:39] <natefinch> wrap changes the cause to the new error
[14:39] <natefinch> you want Underlying()
[14:40] <katco> hm, i thought i tried that too
[14:41] <katco> i think it just gave me back the wrapped error or something. i probably screwed it up
[14:42] <natefinch> it might that if it's wrapped and then gets annotated, you lose access to the underlying error
[14:43] <katco> ahhh that is almost definitely what's going on
[14:43] <natefinch> in theory you're not supposed to need to know what the underlying error is
[14:43] <katco> so this was inflicted by my own hand. a very techy error was making it out to the cli, so i wrapped it. mask and annotate still leak the techy error
[14:43] <rick_h_> katco: can you also look at natefinch's PR please. In the bug is a direct link to the .sh script to QA with and get the security report which should work against a lxd deploy I htink.
[14:44] <katco> natefinch: actually, no, the full history is still in the error because i can gc.Matches on errors.Details(err)
[14:44] <rick_h_> natefinch: I'm assuming you've done this as well to make sure it works
[14:44] <katco> rick_h_: ok
[14:45] <katco> not bad: OOPS: 204 passed, 1 PANICKED, 1 FIXTURE-PANICKED, 1 MISSED
[14:45] <katco> that's down from hundred failing/panicing
[14:45] <rick_h_> katco: <3
[14:46] <natefinch> rick_h_: I haven't, actually. I should do that.
[14:46] <natefinch> I'm sure it'll pass, since I hand-wrote the list of ciphers we support, but it would be good to verify with the tool they're using
[14:46] <rick_h_> natefinch: rgr, it's what the bug is filed with so if we don't pass the tool, the bug reportor will come back at us.
[14:53] <mup> Bug #1614724 changed: Juju isn't protected from new versions of LXD <juju-release-tools:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1614724>
[14:53] <mup> Bug #1614992 opened: Cannot assign unit: unable to connect <add-unit> <ci> <intermittent-failure> <jujuqa> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1614992>
[15:08] <natefinch> lol, I've forgotten how to bootstrap 1.25
[15:09] <katco> not sure i've done that myself in awhile
[15:10] <natefinch> you have to switch environments first and then juju bootstrap without specifying the environment
[15:10] <natefinch> but now it's saying no registered provider for lxd, which is weird
[15:10] <katco> lxd is a 2.0 thing haha
[15:11] <katco> believe it or not. it's been that long
[15:11] <natefinch> lol
[15:11] <natefinch> wow
[15:11] <katco> have to use local i think? or lxc
[15:11] <natefinch> lcoal yeah
[15:11] <natefinch> lulz
[15:12] <natefinch> and gce panics during bootstrap with a nil pointer
[15:13] <natefinch> oy
[15:13] <katco> wtf? on latest in 1.2x?
[15:14] <natefinch> yep.  I'm guessing it's this line:
[15:14] <natefinch> 		// The missing credentials will be caught later.
[15:14] <natefinch> 		return nil, nil
[15:14] <natefinch> oh, they were caught all right
[15:15] <katco> sigh... please raise a critical bug. gce flat out not working is a huge deal i imagine. rick_h_ ^^^
[15:15] <natefinch> it's an edge-ish case, I think.  my config specifies a credentials file that apparently isn't there
[15:15] <natefinch> lemme double check if that's the problem
[15:16] <katco> ah
[15:16] <katco> that would make me feel loads better
[15:17] <natefinch> no, that's not it.  Sorry, let me figure out exactly what's causing it
[15:17] <katco> i hope it's an edge case
[15:19] <natefinch> yeah, my config is all messed up. wrong property names and stuff. Possibly from very very early in gce lifetime
[15:20] <natefinch> Let me attempt to fix it and double check gce works, but I'm pretty sure that's it
[15:23] <mup> Bug #1615008 opened: jujud uses max cpu cores 100% overnight <juju-core:New> <https://launchpad.net/bugs/1615008>
[15:31] <natefinch> ahhh..... this is not a helpful error message: ERROR there was an issue examining the environment: invalid config: key "project_id" not supported
[15:31] <natefinch> what environment? what config? where?
[15:32] <katco> natefinch: like ~/.juju/environments.yaml under "local"
[15:32] <katco> likely
[15:32] <natefinch> yeabut.. that key doesn't exist there
[15:32] <natefinch> and I don't have JUJU_HOME set
[15:33]  * rick_h_ runs to long family lunch today biab
[15:33] <natefinch> or any JUJU_* variable, actually
[15:33] <katco> grep -r project_id ${HOME}
[15:34] <natefinch> yeah, just started running that.  gonna be a while
[15:35] <natefinch> funny seeing it pick up javascript in my browser cache
[15:37] <natefinch> Skills: 5+ years of Agile, Scrum
[15:38] <natefinch> oh recruiters
[15:39] <natefinch> MUST have long projects and long time in US
[15:39] <natefinch> ...what does that even mean?
[15:39] <perrito666> natefinch: wrong channel?
[15:39] <natefinch> nope
[15:40] <natefinch> recruiter sent me an email for a .Net job.
[15:40] <perrito666> probably means they wont do the h1 for you
[15:40] <natefinch> We are looking to fill a contract opportunity with one of our direct customers and like to check if you have any resources available for the same. Please submit the resume with rate, contact details, and availability.  Kindly note that each resource submitted must be on your W2 payroll.
[15:40] <katco> i once had a recruiter attempt to recruit me to my old company
[15:41] <mgz> what's a w2 payroll?
[15:41] <mgz> "must have long projects, must not have long hair"
[15:41] <natefinch> W2 is the form a business uses to report your income to the government (and to you)
[15:42] <natefinch> it sounds like this was half rewritten from something sent to a contracting company
[15:42] <natefinch> Job Title : Superstar .Net Technical Lead/Architect (strong SQL) (Chi)-multi-year contract (long projects)
[15:42] <mgz> yeah, they seem to think you are an owner of resources
[15:43] <perrito666> I thought owning such resources was sort of illegal
[15:43] <perrito666> for at least a couple of hundred years?
[15:43] <natefinch> haha
[15:43] <natefinch> you don't own them, you just rent them out
[15:46] <redir> morning
[15:46] <katco> hey redir
[15:50] <natefinch> katco: I figured out the gce problem... I'm using a file to hold my gce credentials, and evidently that file format does not work for 1.25.  I'll test in a minute if it works for 2.0
[15:50] <katco> ah cool
[15:57] <perrito666> btw, reviewboard is back, you can thank sinzui for that
[15:58] <natefinch> 2016-08-19 15:57:27 ERROR juju.cmd supercommand.go:429 cannot initiate replica set: cannot dial mongo to initiate replicaset: no reachable servers
[15:58] <natefinch> ERROR failed to bootstrap environment: subprocess encountered error code 1
[15:58] <natefinch> ffffffffffffff....
[16:11] <natefinch> me testing this bug fix: https://www.youtube.com/watch?v=d1CYncXkCv4
[16:55]  * natefinch abandons gce for now and bootstraps amazon
[17:05] <natefinch> uh hmm
[17:05] <natefinch> is 1.25  supposed to work on xenial?
[17:08] <redir> natefinch: does that mean you'll be breaking bad soon?
[17:09] <natefinch> redir: gotta break sumethin'
[17:11] <redir> natefinch: lemme know when it happens, I'll make popcorn:)
[17:14] <mup> Bug #1615051 opened: Dubious hook failures deploying trivial charm <ci> <deploy> <hooks> <jujuqa> <regression> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1615051>
[17:14] <rick_h_> natefinch: 1.25 is packed ajd in universe for xenial...so yes? 1.25 and local...not so much
[17:15] <cmars> fix for LP:#1614330, http://reviews.vapour.ws/r/5484/
[17:15] <mup> Bug #1614330: agree command uses 'less' for a pager, fails on windows <windows> <juju-core:In Progress by cmars> <https://launchpad.net/bugs/1614330>
[17:15] <rick_h_> perrito666: can you review ^ please?
[17:20] <perrito666> rick_h_: certainly
[17:20] <rick_h_> perrito666: ty much
[17:21] <natefinch> hm... I seem to remember there being some extra tweak I had to do to TLS for mongo because mongo was being a turd
[17:21] <katco> really quick review for someone who has a few seconds: http://reviews.vapour.ws/r/5485/
[17:21] <natefinch> yes yes, I have it
[17:30] <perrito666> cmars: did you see thumper's patch that now takes stuff and writes them into a writer?
[17:30] <cmars> perrito666, no
[17:30] <perrito666> cmars: landed last night iirc
[17:31] <perrito666> cmars: you tried this with latest masteR?
[17:32] <cmars> perrito666, implemented & tested this on top of 3785445 which is pretty recent
[17:33] <perrito666> cmars: please try with current master and if so ill ship it
[17:34] <cmars> perrito666, it's up to date with current master, a fetch & a rebase show it's still up to date w/master. i tested this maybe 30 min ago
[17:35] <perrito666> k, ship it
[17:36] <cmars> perrito666, thanks
[17:36] <perrito666> np
[17:53] <natefinch> katco: I updated http://reviews.vapour.ws/r/5480/ with steps to test using the script from the bug (after verifying it myself).
[17:53] <katco> natefinch: ta. i will finally be getting around to this in just a bit
[17:53] <natefinch> good timing then :)
[18:13] <natefinch> katco: welp... - https://bugs.launchpad.net/juju-core/+bug/1477712
[18:13] <mup> Bug #1477712: GCE provider dumps stacktrace when missing a config option/value <config> <gce-provider> <panic> <juju-core:Triaged> <https://launchpad.net/bugs/1477712>
[18:14] <natefinch>  reported by Charles Butler on 2015-07-23 importance: medium
[18:14] <katco> wow this was reported over a year ago
[18:16] <natefinch> also this one: https://bugs.launchpad.net/juju-core/+bug/1533790
[18:16] <mup> Bug #1533790: GCE provider is very restrictive when using a config-file (json) <docteam> <juju-core:Triaged> <https://launchpad.net/bugs/1533790>
[18:16] <natefinch> both are 1.25 only
[18:16] <natefinch> it behaves nicely in 2.0
[18:16] <redir> EAsy review anyone http://reviews.vapour.ws/r/5486/
[18:23] <rick_h_> natefinch: katco good to know, I'm glad to hear we cleaned it up in 2.0.
[18:23] <rick_h_> natefinch: with that in can you look at redir's pr please?
[18:23] <natefinch> rick_h_: yep
[18:24] <rick_h_> katco: I'll QA yours here in a sec just need someone to do the code review
[18:24] <katco> rick_h_: cool ty
[18:40] <katco> natefinch: qa checks out
[18:43] <rick_h_> katco: QA in, it wasn't clear what changes to expect in this branch vs not expect so feel free to tell me to be patient for future branches
[18:43] <katco> rick_h_: it only corrects the bugs mentioned in the commit message
[18:44] <rick_h_> katco: right, but in my QA it only fixes the local case in that bug not the full bug
[18:44] <katco> rick_h_: which now that i type that i remember you had listed multiple issues
[18:44] <katco> rick_h_: let me fix the rest. that bit is trivial now that i can just write unit tests
[18:44] <rick_h_> katco: rgr, it was a wrapper for several "deploy" scenarios around the exposure of "add charm" which shows up in the QA several cases still
[18:44] <rick_h_> katco: k
[18:47] <rick_h_> katco: <3 on the reduction of api connections and such
[18:48] <katco> rick_h_: yeah that was kind of rediculous
[18:48] <katco> rick_h_: but that's what i mean when i say cruft builds up. people are understandably just trying to get their change in, and they just cargo-cult bad practice
[19:00] <redir> aka tech debt
[19:07] <natefinch> rick_h_: can I jfdi this backport of the security fix?  the changes are very localized and highly unlikely to break anything unrelated.
[19:08] <natefinch> (for 1.25)
[19:08] <rick_h_>  natefinch shoulnd't need to since you can fixes-xxxxx
[19:08] <rick_h_> natefinch: unless I'm missing something?
[19:08] <natefinch> rick_h_: not sure how that works for private bugs
[19:09] <natefinch> rick_h_: I can try :)
[19:11] <rick_h_> natefinch: well this all came about because the bot told voidspace he couldn't land because it wasn't that fix so I'd expect it to work
[19:11] <natefinch> ha, ok
[19:11] <rick_h_> natefinch: obviously, if that doesn't you're fixing a blocking critical so jfdi seems the only way around it
[19:12] <natefinch> rick_h_: yeah, just didn't realize it was a blocker since I usually use juju.fail for that, which I believe you mentioned has that blind spot for private bugs
[19:12] <rick_h_> natefinch: rgr
[19:17] <natefinch> redir: your PR fixes https://bugs.launchpad.net/juju-core/+bug/1614732 - so that's the thing bug should be testing, right?
[19:17] <mup> Bug #1614732: Race in github.com/juju/juju/api/state.go <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Fix Committed by reedobrien> <https://launchpad.net/bugs/1614732>
[19:18] <redir> natefinch: I  don't follow
[19:18] <natefinch> redir: sorry, changed thoughts mid-sentence
[19:19] <redir> natefinch: understood
[19:19] <natefinch> redir: the QA steps are a little unclear.
[19:19] <redir> ahh
[19:19] <redir> I'll update
[19:20] <natefinch> redir: I should apply the mgo patch and then run the api test suite with -race on a slow AWS machine, and it should trigger the race?  And then apply your patch and it should no longer trigger the race?
[19:22] <redir> natefinch: to clarify when running the fix on the aws instance it was no longer triggering hte race that it fixes, but the other race which has a fix htat is waiting for upstream to incormprate. So I applied that patch too, to make sure it doesn't hide the race that this PR is addressing.
[19:22] <redir> I do'nt know if htat is more clear but Le t me know if not
[19:23] <redir> and I'll update the PR desc on RB
[19:23] <natefinch> redir: I get it.  Just wanted to make sure I was understanding it correctly
[19:23] <redir> OK
[19:32] <natefinch> f yeah, tests that rely on files in the git, thanks!
[19:33] <katco> ......
[19:33] <natefinch> panic: cannot read repository found at "/home/nate/src/github.com/juju/juju/testcharms/charm-repo"
[19:34] <natefinch> I geuss it was foolish to think we had isolated tests.  I was trying to avoid having to set up a whole dev environment on an aws server in order to catch a race condition
[19:35] <natefinch> maybe if I just run hangouts and compile juju while I run the tests, that'll be slow enough to trigger the race
[19:36] <katco> we have to chip away at this stuff as we see it. it's the only way forward
[19:39] <rick_h_> natefinch: 1hr limit, if you can't QA it in that time then just review the code please and let the CI runs figure out if the race appears again or not
[19:39] <natefinch> rick_h_: ok, thanks
[19:39] <natefinch> ls
[19:46] <redir> natefinch: just symlink /home/ubuntu to home/nate...
[19:48] <redir> natefinch: also. Uh, I'll update the wiki
[19:49] <natefinch> redir: I was trying to run a test binary on a machine without any of our code or anything... it probably would have failed due to not having mongo there anyway
[19:49] <natefinch> sinzui: is the landing bot for 1.25 using go 1.2?  It seems to be missing TLS ciphers that are in 1.6 but not 1.2
[19:50] <sinzui> natefinch: check the Makefile
[19:51] <natefinch> sinzui: I don't know where the makefile is
[19:51] <redir> natefinch: true. I installed mongo on the instance and rsynced the env up... whatevs
[19:51] <sinzui> natefinch: the landing bot is go 1.6. the tests come from the juju branch. If the Makefile in the branch installs the wrong go, then you found your problem
[19:52] <perrito666> aghh this is ridiculous, I need to fix a bug to be able to reproduce another
[19:52] <sinzui> natefinch: in my experience, the Makefile is rarely updted to match the deps
[19:52] <natefinch> sinzui: oh, THAT makefile. Sorry
[19:52] <sinzui> perrito666: get in line. natefinch is about 4 bugs deep trying to fix  azure windows deploy.
[19:53] <perrito666> sinzui: I am starting to be suspicious of one of the reports as it sounds odd that they could actually find that issue with the other in place
[19:53] <natefinch> sinzui: I thought axw was working on the azure bug
[19:53] <mup> Bug #1615095 opened: storage: volumes not supported <landscape> <juju-core:New> <https://launchpad.net/bugs/1615095>
[19:54] <sinzui> natefinch: He is. you were working in the winows machines do not come up when we deoploy a windows charm. That is difficult to fix when the azure provider is broken and metadata generate-tools is broken
[19:55] <natefinch> sinzui: for what it's worth, the bug with TLS is not the problem with that. the machine downloads the tools from the controller just fine.  Andrew submitted a fix for some other bug that I saw on the machine later.  Ihoped that would fix the last of the azure bugs.
[19:57] <natefinch> sinzui: and I *think* the makefile is installing go 1.6?  I can't tell if that's actually what it's using to build, though.  And given that it's failing to find tls ciphersuites that exist in 1.6 but not in 1.2, I'd say it's probably not using 1.6 to compile.
[19:57] <natefinch> I should make a canary file to tell us when someone tries to compile with an old version of go
[19:57] <sinzui> natefinch: I wish you had said that earlier. I agree with you
[19:57] <sinzui> natefinch: http://reports.vapour.ws/releases/4278/job/azure-arm-deploy-windows-amd64/attempt/100
[19:58] <sinzui> natefinch: ^ I see the windows charms were deployed and they did exchange tokens
[19:58] <sinzui> natefinch: The failue is just azure is slow. I bet this test would pass if I added 10 minutes
[19:59] <natefinch> oh yeah, I saw Ian say that azure slowed even further with their latest update because everything is serialized now
[20:00] <natefinch> redir: gave you a ship it... didn't ultimately have time to run the tests, but I trust you did, and the code is simple enough.
[20:00] <natefinch> I gotta run early today, prepping for daughter's birthday party tomorrow
[20:01] <redir> natefinch: yeah and still running, if it doesn't trigger by my EoD I'll merge. I was able to repro pretty easily -- and repeatedly before fixing.
[20:02] <natefinch> cool
[20:25] <cmars> i'm confused why this didn't land: https://github.com/juju/juju/pull/6043
[20:25] <cmars> specifically http://juju-ci.vapour.ws:8080/job/github-merge-juju/8854/
[20:26] <mup> Bug #1615106 opened: actionSuite.SetUpTest: forcibly closed <ci> <intermittent-failure> <mongodb> <test-failure> <unit-tests> <windows> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1615106>
[20:26] <mup> Bug #1615108 opened: ConstraintsMerge arch problems <arm64> <ci> <jujuqa> <ppc64el> <s390x> <test-failure> <unit-tests> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1615108>
[20:26] <mup> Bug #1615112 opened: EnableHASuite.SetUpTest: forcibly closed <intermittent-failure> <jujuqa> <mongodb> <test-failure> <unit-tests> <windows> <juju-core:Triaged by rharding> <https://launchpad.net/bugs/1615112>
[20:29] <perrito666> cmars: flaky test
[20:30] <cmars> perrito666, should i wait for it to be fixed? or just keep trying?
[20:30] <perrito666> cmars: retry, it has been like that for a while
[20:36]  * perrito666 runs slow tests
[20:36] <perrito666> cmars: if its a known flaky test (as is the case with that agent one) I believe that your magic number is 3, if same failure hits you 3 times you have broken it a bit more than it already was
[20:38] <cmars> perrito666, uh-oh, this is the third try.. D:
[20:42] <perrito666> same failure?
[20:42] <cmars> perrito666, running now
[20:42] <perrito666> cmars: you might want to run that isolated test on your machine
[20:59]  * rick_h_ runs, have a good weekend folks
[21:06] <mup> Bug #1615118 opened: clientSuite.TearDownTest: mongodb has exited without being killed <ci> <intermittent-failure> <jujuqa> <mongodb> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.25:Triaged by rharding> <https://launchpad.net/bugs/1615118>
[21:06] <mup> Bug #1615121 opened: SettingsSuite.SetUpSuite "no reachable servers" <ci> <intermittent-failure> <jujuqa> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core kpi-metrics:Triaged> <https://launchpad.net/bugs/1615121>
[21:27] <redir> taking a break, bbiab