[02:23] <cherylj> hey wallyworld, looks like there's a windows unit test failure on master from the new xdg home dir work:  http://reports.vapour.ws/releases/3580/job/run-unit-tests-win2012-amd64/attempt/1891#highlight
[02:34] <wallyworld> cherylj: ok, will look. we really need to gate on windows unit tests. not sure why we don't yet
[02:34] <cherylj> yeah, would be nice
[02:34] <wallyworld> we have been talking about it for months and months
[02:35] <cherylj> just hasn't made it to the top of their list of priorities, I guess
[02:36] <wallyworld> yeah. seems like a small change for a big win though
[02:56] <wallyworld> axw: a small tweak to fix windows unit tests http://reviews.vapour.ws/r/3763/
[02:57] <axw> wallyworld: are we trying to use XDG things on Windows? :/
[02:58] <wallyworld> axw: no, there's a separate func to get the right location, but the tests have always been linux specific
[02:58] <axw> ok
[02:59] <wallyworld> axw: on windows, it's %APPDATA%/juju
[02:59] <axw> wallyworld: done
[02:59] <wallyworld> ty
[02:59] <axw> wallyworld: ok, thanks
[04:10] <cherylj> oh god, so many test failures.  My eyes!  MY EYES!!
[04:11] <cherylj> wallyworld, perrito666, so did the new juju home stuff break out JUJU_HOME into JUJU_DATA and something else?
[04:11] <cherylj> because it looks like CI wasn't
[04:29] <wallyworld> cherylj: JUJU_DATA replaces JUJU_HOME, but it will default to something sensible. if CI uses JUJU_HOME, then i'll need to back out that change
[04:31] <wallyworld> or i might set JUJU_DATA to JUJU_HOME till CI is updated
[04:31] <cherylj> wallyworld: that sounds like a good compromise.  I'll bring it up to the QA guys in the morning
[04:31] <wallyworld> ok. i'll do that now
[04:31] <cherylj> thanks, wallyworld!
[04:32] <wallyworld> sure, sorry about the breakage
[04:44] <wallyworld> axw: another small one http://reviews.vapour.ws/r/3764/
[04:45] <axw> wallyworld: done
[04:45] <wallyworld> ty
[04:47] <axw> wallyworld: whenever you're ready: http://reviews.vapour.ws/r/3765/
[04:47] <wallyworld> sure
[04:57] <wallyworld> axw: how much smaller is asn encoding vs json?
[04:57] <wallyworld> did it make much of a difference?
[05:04] <axw> wallyworld: it was reasonably significant. I can't recall the overhead exactly. I can measure again if you like
[05:04] <wallyworld> no need, just curious
[05:21] <wallyworld> axw: a couple of small things
[05:33] <wallyworld> axw: when you are free, another trivial http://reviews.vapour.ws/r/3767/
[06:09] <davecheney> what's changed now ? https://bugs.launchpad.net/juju-core/+bug/1542985
[06:09] <mup> Bug #1542985: Juju won't switch environments <juju-core:New> <https://launchpad.net/bugs/1542985>
[06:13] <davecheney> axw: wallyworld what has juju switch been renamed to ?
[06:13] <wallyworld> davecheney: that one stays the same
[06:13] <wallyworld> let me double check
[06:13] <davecheney> see linked bug
[06:14] <wallyworld> yup, stays as switch
[06:14] <davecheney> why can't I change to ap-southeast-2 anymore
[06:14] <wallyworld> hmmm, haven't see that bug till now
[06:15] <davecheney> it's there in juju/environemnts.yam
[06:15] <davecheney> it's there in juju/environemnts.yam
[06:15] <davecheney> it's there in juju/environemnts.yaml
[06:15] <wallyworld> it's supposed to work
[06:15] <wallyworld> something broke :-(
[06:16] <davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug
[06:16] <davecheney> 2016-02-08 06:15:41 INFO juju.cmd supercommand.go:59 running juju [2.0-alpha2 gc devel +fa5e547 Sun Feb 7 03:18:28 2016 +0000]
[06:16] <davecheney> 2016-02-08 06:15:41 ERROR cmd supercommand.go:448 the name of the model must be specified
[06:16] <davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug ap-southeast-2
[06:16] <davecheney> we really hate our users
[06:16] <davecheney> error: unrecognized args: ["ap-southeast-2"]
[06:16] <davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap -v --debug -m dev
[06:16] <davecheney> 2016-02-08 06:16:36 INFO juju.cmd supercommand.go:59 running juju [2.0-alpha2 gc devel +fa5e547 Sun Feb 7 03:18:28 2016 +0000]
[06:16] <davecheney> 2016-02-08 06:16:36 ERROR cmd supercommand.go:448 open /home/dfc/.local/share/juju/environments.yaml: no such file or directory
[06:17] <wallyworld> juju home has changed
[06:17] <wallyworld> i'm in the process of updating release notes
[06:17] <wallyworld> it only landed on the weekend i think
[06:17] <axw> davecheney: FYI, in the near future we will completely ignore environments.yaml
[06:17] <wallyworld> just copy ~/.juju to ~/.local/share/juju
[06:18] <axw> more info later
[06:18] <davecheney> lucky(~/.local/share) % ls -al . | grep juju
[06:18] <davecheney> lrwxrwxrwx  1 dfc dfc    15 Feb  8 17:18 juju -> /home/dfc/.juju
[06:18] <davecheney> problem solved
[06:18] <wallyworld> ~/.juju will be ignored in a day or so
[06:19] <wallyworld> as soon as CI is updated
[06:19] <wallyworld> then it will be ~/.local/share/juju
[06:19] <davecheney> looks like it's being ignore now
[06:19] <wallyworld> i landed a change maybe 2 hours ago to temporarily use it
[06:19] <wallyworld> until CI is fixed
[06:20] <wallyworld> so just copy stuff to ~/.local/share/juju to be future proof
[06:20] <davecheney> commit fd9cd4bc60d55571ce2db8562462703ed3baa228
[06:20] <davecheney> Author: Ian Booth <ian.booth@canonical.com>
[06:20] <davecheney> Date:   Mon Feb 8 14:41:59 2016 +1000
[06:20] <davecheney> Fall back to JUJU_HOME if JUJU_DATA not set
[06:20] <davecheney> yup, i have that rev
[06:20] <wallyworld> you need $JUJU_HOME set
[06:20] <wallyworld> that's what it falls back to
[06:20] <davecheney> 2016-02-08 06:20:42 DEBUG juju.provider.common bootstrap.go:318 connection attempt for 54.79.164.245 failed: Warning: Permanently added '54.79.164.245' (ECDSA) to the list of known hosts.
[06:21] <davecheney> /var/lib/juju/nonce.txt does not exist
[06:21] <davecheney> 2016-02-08 06:20:48 DEBUG juju.provider.common bootstrap.go:318 connection attempt for 54.79.164.245 failed: /var/lib/juju/nonce.txt does not exist
[06:21] <davecheney> ^ these won't exist
[06:21] <davecheney> my user has no permission to write to those locations
[06:21] <wallyworld> right, but that's not what we're taling about
[06:21] <wallyworld> it's the XDG data home
[06:22] <davecheney> ok
[06:22] <wallyworld> as opposed to XDG config home
[06:22] <wallyworld> or XDG runtime home etc
[06:22] <mup> Bug #1542985 opened: Juju won't switch environments <juju-core:New> <https://launchpad.net/bugs/1542985>
[06:22] <mup> Bug #1542988 opened: bootstrap tries to write to /var/lib/juju on local machine <juju-core:New> <https://launchpad.net/bugs/1542988>
[06:22] <wallyworld> oh yuk
[06:22] <wallyworld> really?
[06:22] <wallyworld> what provider
[06:23] <davecheney> ec2
[06:24] <wallyworld> the nonce.txt is written by cloud init i believe
[06:24] <wallyworld> the bootstrap client has never used that file
[06:24] <axw> yes, written by cloud-init. bootstrap looks for it to check that cloud-init has finished
[06:24] <wallyworld> how the fark it is getting written locally i'm not sure
[06:24] <davecheney> maybe that error is leaking through from the remote side
[06:27] <axw> wallyworld: PTAL
[06:27] <wallyworld> sure
[06:30] <wallyworld> axw: lgtm. we need to double check that a newly added user on a controller only has access to the models they create or are shared with them. i can't recall whether in the initial poc done with the initial jes work all users had admin access on the controller or not
[06:52] <mup> Bug #1542990 opened: tools version checker restarts every 3 seconds <juju-core:New> <https://launchpad.net/bugs/1542990>
[06:52] <mup> Bug #1542992 opened: ec2: destroy-controller causes rate limiting failure <juju-core:New> <https://launchpad.net/bugs/1542992>
[07:16] <axw> wallyworld: yep. I did test, but not very rigorously, and it appeared to be checking access
[07:17] <wallyworld> axw: ok, we'll need to ensure going forward it works as we hope
[07:37] <wallyworld> axw: if you get a chance at some point, could you take a another pass at http://reviews.vapour.ws/r/3737/ now that it's been updated?
[07:37] <axw> wallyworld: yup, was about to, just fixing my branch
[07:38] <wallyworld> awesome ty
[08:02] <axw> wallyworld: what would you call the combination of controllers.yaml, accounts.yaml, models.yaml (sic), etc.? currently called "Cache" in that branch, but it doesn't sit well with me
[08:02] <axw> wallyworld: only the model info is really a cache
[08:02] <wallyworld> axw: agreed
[08:02] <wallyworld> um
[08:04] <wallyworld> LocalControllerState  ?
[08:05] <wallyworld> it's local to that machine, it's related to controllers (and accounts for those), and it's state cached in memory or on disk
[08:05] <wallyworld> naming is hard :-)
[08:06] <axw> wallyworld: a bit better, but I'm not completely sold on that either. I'll think about it for a bit.
[08:06] <wallyworld> yeah, i wasn't that happy with that suggestion
[08:09] <axw> wallyworld: I'm thinking ControllerStore, NewFileControllerStore, NewMemControllerStore, DefaultControllerStore
[08:09] <wallyworld> hmmm, that works
[08:09] <axw> wallyworld: along the lines of existing configstore
[08:09] <wallyworld> it's similar to what's there
[08:09] <wallyworld> yup
[08:28] <anastasiamac_> wallyworld: axw: my problem with "store" is that its prime meaning is not "storehouse, warehouse" but actually is closer related to "retail"
[08:28] <anastasiamac_> apart from that - i'm phased at all.. whatever
[08:28] <wallyworld> disagree :-)
[08:28] <wallyworld> in computer terms, store ahas a well defined meaning
[08:30] <anastasiamac_> m not*
[08:31] <dimitern> wallyworld, hey there
[08:31] <wallyworld> hey
[08:31] <dimitern> wallyworld, re that juju home 2.0 change
[08:31] <wallyworld> should i brace?
[08:31] <dimitern> wallyworld, how is going to work with non-public clouds - i.e. maas ?
[08:31] <dimitern> wallyworld, juju bootstrap mymaas maas/?
[08:32] <dimitern> assuming the lack of environments.yaml
[08:32] <axw> dimitern: there's a new clouds.yaml for private clouds
[08:32] <wallyworld> dimitern: hop onto #juju
[08:32] <dimitern> omw
[08:52] <frobware> dimitern, morning!
[08:53] <frobware> dimitern, are merging master -> maas-spaces?  I started but need to decide whether I should continue.
[08:54] <dimitern> frobware, morning
[08:54] <dimitern> frobware, yeah, I think it's good to do it often until we can merge
[08:55] <frobware> dimitern, I didn't finish resolving all the conflicts
[08:55] <dimitern> frobware, the bigger merge landed on friday
[08:55] <dimitern> frobware, so this morning it was much easier - only 1 test to fix
[08:55] <frobware> dimitern, ah - that's the one I'm talking about. I started on Friday, but didn't complete.
[08:56] <dimitern> frobware, I've run make check after the merge on friday and did a quick live test to be sure
[08:57] <frobware> dimitern, and that's now landed in maas-spaces?
[08:57] <dimitern> frobware, this morning's merge is landing now
[08:57] <dimitern> frobware, and the friday's one is already in
[08:58] <dimitern> frobware, I have a few tasks planned to unblock maas-spaces merging into master
[08:58] <dimitern> frobware, so we can then concentrate on the remaining tasks
[09:32] <voidspace> frobware: we had a CI run on Friday, on maas-spaces, that never completed
[09:32] <voidspace> frobware: http://reports.vapour.ws/releases/3578
[09:32] <voidspace> frobware: but there was a xenial unit test failure which isn't good - featuretests
[09:34] <voidspace> frobware: that maybe looks space discovery related, which is unexpected
[09:34] <dimitern> voidspace, 2 of those attempts where due to issues with the cloud archive getting the wrong package
[09:34] <voidspace> frobware: however they pass locally
[09:35] <voidspace> dimitern: ah right, infrastructure problem then?
[09:35] <voidspace> dimitern: the featuretests pass locally for me (wily), but I get a cmd/status failure
[09:35] <dimitern> voidspace, and the last one is flaky due to the controller space not getting handled
[09:35] <voidspace> yeah, we're still expecting that to fail
[09:35] <voidspace> I believe
[09:41] <voidspace> cmd/juju/status fails consistently for me
[09:41] <voidspace> checking master
[09:41] <dimitern> voidspace, how does it fail?
[09:42] <voidspace> dimitern: six failures, unexpected number of machines in some of them
[09:43] <voidspace> dimitern: same failure for me on master
[09:43] <voidspace> dimitern: huuuuge amounts of logging so hard to summarise the failures, I'll pick one of the tests and investigate
[09:43] <voidspace> dimitern: it could be an oddity with my machine
[09:44] <voidspace> hah, latest run of master on CI failed to build
[09:45] <voidspace> Wily unit tests passed on Friday on CI though
[09:48] <dimitern> voidspace, I see both master and maas-spaces-merge-master-7* pass here, although I did see the LoginsDuringUpgrade test failing once
[09:48] <voidspace> dimitern: how did it fail?
[09:54] <dimitern> voidspace, something like can login as machine expected IsTrue, got false
[09:54] <voidspace> ah
[09:56] <voidspace> with status test, I'm getting five machines when only one was expected
[09:56] <voidspace> digging into it
[10:50] <voidspace> dimitern: http://pastebin.ubuntu.com/14992568/
[12:19] <wallyworld> dimitern: here's a trivial one line fix for a failing windows unit test (i hope), can you take a quick look? http://reviews.vapour.ws/r/3771/
[12:20] <dimitern> wallyworld, looking
[12:20] <wallyworld> ty
[12:21] <dimitern> wallyworld, LGTM
[12:21] <wallyworld> tyvm
[12:21] <dimitern> wallyworld, and I assume a better fix will be done there once possible, right?
[12:21] <wallyworld> dimitern: that whole line will be deleted
[12:22] <wallyworld> since JUJU_HOME won't be supported and the fallback in the code will be gome
[12:22] <wallyworld> but CI scripts need to be updated
[12:22] <dimitern> wallyworld, right
[12:22] <wallyworld> the test fails because of a temporary fallback in the code
[12:29] <voidspace> wallyworld: hey, you know anything about status tests?
[12:29] <wallyworld> a littlw
[12:30] <wallyworld> i do know i hate them
[12:30] <voidspace> wallyworld: there's a few that fail consistently on my machine (but not anywhere else)
[12:30] <voidspace> wallyworld: here's one http://pastebin.ubuntu.com/14992568/
[12:30] <wallyworld> looking
[12:30] <voidspace> wallyworld: the test is trying to limit status to an exposed service but gets five machines instead of one
[12:31] <voidspace> wallyworld: that's running just that test with the preceding tests in the loop removed (so line numbers won't match yours) to eradicate state leakage between tests as a cause
[12:31] <wallyworld> and it's intermittent?
[12:31] <wallyworld> not on your machine
[12:32] <voidspace> wallyworld: consistent on my machine, not seen elsewhere yet I believe
[12:32] <voidspace> wallyworld: but in means I can't do a full unit test run without failures on my machine - so I'd like to find out the cause
[12:33] <wallyworld> indeed
[12:33] <wallyworld> i get mongo failures quite regularly :-(
[12:36] <wallyworld> voidspace: i don't see anything obvious, how long has it been doing this?
[12:39] <voidspace> wallyworld: new today
[12:39] <voidspace> wallyworld: thanks for looking anyway
[12:40] <wallyworld> voidspace: i do notice what appears to be old agent-state values in the yaml output. those are gone from master. you could try rebasing
[12:41] <voidspace> wallyworld: I've just had a thought - I copied environments.yaml from CI
[12:41] <voidspace> I wonder if that is screwing with things
[12:41] <voidspace> wallyworld: I'm on current master head
[12:41] <wallyworld> probably not, but yoy could try without, i'd have to see what's in it i guess
[12:42] <wallyworld> shouldn't affect the tests
[12:44] <voidspace> nah, doesn't affect it - still 6 failures
[12:56] <wallyworld> hmmm, there must be something unique to your setup, but i can't think of what
[13:12] <voidspace> updated version of go as well, no difference
[13:12] <dimitern> voidspace, check if you have cache.yaml in ~/.juju/environments/
[13:12] <dimitern> voidspace, and delete it if it's there before retrying
[13:12] <voidspace> dimitern: I blew away .juju and did a fresh init
[13:13] <dimitern> voidspace, hmm - well, then check ~/.local/share/juju ?
[13:13] <voidspace> dimitern: I blew that away before the init too :-)
[13:13] <voidspace> I'll check though
[13:13] <voidspace> just reinstalling lxc to fix (hopefuly) another test failure on my machine
[13:14] <voidspace> dimitern: no cache.yaml there
[13:17] <dimitern> voidspace, what do you have in ~/.local/share/juju ? I only have ssh/ with juju_id_rsa + juju_id_rsa.pub
[13:17] <voidspace> dimitern: I have an environments.yaml too
[13:17] <voidspace> dimitern: which was created by juju init
[13:18] <dimitern> voidspace, in ~/.local/share/juju/ ?
[13:18] <dimitern> voidspace, I don't have this fwiw
[13:19] <voidspace> yep
[13:19] <voidspace> this is a fresh build with go 1.5, no preexisting juju home directory, then juju init
[13:19] <voidspace> which created environments.yaml
[13:19] <voidspace> it's just the boilerplate one
[13:21] <dimitern> voidspace, juju init shouldn't be necessary anymore AIUI
[13:21] <voidspace> dimitern: it certainly shouldn't cause tests to fail though!
[13:22] <voidspace> I'll get rid of the environments.yaml and see
[13:22] <dimitern> voidspace, yeah
[13:22] <voidspace> go rid of canonistack and ec2 credentials from my environment - that didn't fix it either
[13:23] <voidspace> removing environments.yaml didn't help
[13:25] <dimitern> voidspace, try rm -fr $GOPATH/pkg/ followed by go install github.com/juju/juju/... ?
[13:25] <voidspace> dimitern: heh, ok
[13:27] <voidspace> I just updated go version which I think did the same thing
[13:27] <voidspace> (effectively)
[13:28] <voidspace> nope, same problem
[13:28] <voidspace> back to digging into the code
[13:31] <dimitern> voidspace, hmm ok, I hope you find it
[14:37] <bdx> hey whats going on everyone??? Can someone give an example of provisioning storage using the openstack provider? Thanks!
[15:16] <natefinch> ericsnow: ready when you are.
[15:50] <mup> Bug #1543178 opened: TestBlankJujuXDGDataHomeEnvVar fails because widows isn't looking at xdg location <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1543178>
[16:20] <mup> Bug #1543189 opened: testing_test.go: fakeHome declared and not used <ci> <go1.5> <go1.6> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543189>
[16:20] <mup> Bug #1543193 opened: TestConfig fails on windows because of wrong dir <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1543193>
[16:32] <mup> Bug #1542992 changed: ec2: destroy-controller causes rate limiting failure <juju-core:New> <https://launchpad.net/bugs/1542992>
[16:56] <dimitern> voidspace, any luck with those test failures btw?
[17:02] <frobware> voidspace, dooferlad: sync with rick
[17:03] <mup> Bug #1542990 changed: tools version checker restarts every 3 seconds <juju-core:New> <https://launchpad.net/bugs/1542990>
[17:04] <cherylj> fwereade: did you see waigani's email about moving the state workers to use the dependency engine?
[17:07] <voidspace> frobware: omw
[17:07] <voidspace> dimitern: buried in predicate matchers in the apiserver at the moment :-)
[17:08] <voidspace> frobware: can't join
[17:08] <dimitern> voidspace, right, np
[17:08] <voidspace> worked
[17:12] <mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
[17:24] <mup> Bug #1543216 changed: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
[17:25] <fwereade> cherylj, dammit, I did, it looked broadly sensible/correct but I haven't done it properly yet
[17:33] <mup> Bug #1543216 opened: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
[17:33] <mup> Bug #1543223 opened: kill-controller fails on missing volume <ci> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
[17:39] <mup> Bug #1543223 changed: kill-controller fails on missing volume <ci> <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
[17:42] <mup> Bug #1543223 opened: kill-controller fails on missing volume <ci> <juju-release-support> <kill-controller> <juju-core:Triaged> <https://launchpad.net/bugs/1543223>
[17:51] <voidspace> unitMatchSubnet returns true for match when it gets an error!
[17:51] <voidspace> which seems very odd
[17:52] <voidspace> however, if there's an error - match shouldn't be checked
[17:52] <voidspace> I think we've got a double-nil error here - the error is != nil but errors.Trace is still returning nil
[17:52] <voidspace> something like this
[17:53] <voidspace> no, not the problem
[18:01] <tych0> cherylj: looks like i finally got #4314 to work :)
[18:02] <voidspace> dimitern: frobware: ah, it's matching on the subnet - now to work out why
[18:03] <mup> Bug #1543235 opened: UniterSuite.TestUniterRelations again fails <ci> <i386> <intermittent-failure> <ppc64el> <regression> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1543235>
[18:04] <voidspace> dimitern: frobware: it's fucking BT dns
[18:04] <frobware> voidspace, been there.
[18:04] <voidspace> dimitern: frobware: BT causes net.ResolveIPAddr("started") to work...
[18:04] <voidspace> fsking bollox
[18:04] <voidspace> ok, at least I found it
[18:04] <frobware> voidspace, this is the problem I had with "testing.invalid"
[18:04] <voidspace> now to see if I can fix it
[18:05] <voidspace> frobware: yeah, I will have that problem too...
[18:05] <voidspace> so matchSubnet returns true for the "started" status filter
[18:05] <voidspace> hah!
[18:11] <dimitern> voidspace, wow! that really sucks for BT :)
[18:14] <cherylj> tych0: yay!!
[18:15] <cherylj> tych0: CI should pick up your branch to run now since you've updated it.
[18:17] <cherylj> tych0: I see unit test failures, though, now that it's gotten through the build.
[18:18] <cherylj> tych0: http://juju-ci.vapour.ws:8080/job/github-merge-juju/6271/console
[18:18] <tych0> cherylj: i think that's the last build
[18:18] <tych0> er
[18:18] <tych0> the n-1th build
[18:19] <tych0> i fixed those and the jujubot actually merged it
[18:19] <cherylj> ah!
[18:19] <cherylj> ok :)
[18:20] <tych0> cherylj: what i don't remember is how to go to the fancy web page you sent me to
[18:20] <tych0> cherylj: and if jujubot merged that, are the additonal tests that are going to be run now that i need to check that fancy web page for, or not?
[18:22] <cherylj> tych0: http://reports.vapour.ws/releases#lxd-container-type
[18:22] <cherylj> tych0: there are also reports emailed out from CI with summaries.
[18:22] <tych0> ah, reports.vapour.ws :)
[18:23] <cherylj> tych0: I can keep an eye out for yours and let you know if there are any failures seen there that are unique to your branch.
[18:23] <tych0> cherylj: oh, that would be swell, thanks!
[18:23] <cherylj> np!
[18:23] <tych0> cherylj: is there anything else you need from me right now? (modulo any fixes, of course)
[18:24] <cherylj> tych0: nope, not until your branch runs through CI
[18:24] <tych0> cherylj: ok, cool. thanks!
[18:33] <mup> Bug #1542985 changed: Juju won't switch environments <juju-core:Invalid> <https://launchpad.net/bugs/1542985>
[18:36] <natefinch> ericsnow: trivial review?
[18:36] <natefinch> http://reviews.vapour.ws/r/3772/
[18:38] <dimitern> voidspace, dooferlad, frobware, http://reviews.vapour.ws/r/3773/ please have a look when you can
[18:40] <natefinch> ericsnow: should I just remove the existing show-charm-resources command (currently called "resources")?  It conflicts with the card I'm working on that wants list-resources to have an alias of "resources"
[18:40] <ericsnow> natefinch: sure
[18:40] <ericsnow> natefinch: I'll be removing it in my patch as well
[18:40] <natefinch> ericsnow: figured.
[18:40] <natefinch> ericsnow: cool
[18:50] <natefinch> rick_h__ or rick_h___: we have a task to change push-resource to only accept a single resource at a time, in anticipation of adding a --comment flag... in that case, does it make sense to keep the format push-resource service name=file, or should we just make it push-resource service name file  (i.e. drop the equals and make the name and file separate arguments)?
[19:06] <mup> Bug #1538241 opened: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
[19:12] <mup> Bug #1538241 changed: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
[19:15] <mup> Bug #1538241 opened: 2.0-alpha2 stabilization <blocker> <juju-core:Triaged> <https://launchpad.net/bugs/1538241>
[19:42] <natefinch> ericsnow: any idea whay this PR didn't get a review on reviewboard?
[19:42] <natefinch> ericsnow: https://github.com/juju/juju/pull/4332
[19:42]  * ericsnow takes a look
[19:43] <ericsnow> natefinch: also, be sure to take a look at the tasks for that card (there's more to it than the rename)
[19:44] <natefinch> ericsnow: ahh, I missed the tasks, thanks
[19:47] <ericsnow> natefinch: it looks like you already have a review request up for revision 968fb37
[19:47] <ericsnow> natefinch: perhaps you have a draft up? an old PR?
[19:48] <ericsnow> natefinch: in either case you have to completely delete (rather than discard) the old review request
[19:48] <mup> Bug #1356500 changed: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
[19:48] <mup> Bug #1433336 changed: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
[19:48] <mup> Bug #1543262 opened: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
[19:49] <thumper> morning peeps
[19:52] <natefinch> ericsnow: weird
[19:54] <mup> Bug #1543262 changed: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
[19:54] <mup> Bug #1356500 opened: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
[19:54] <mup> Bug #1433336 opened: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
[19:54] <natefinch> ericsnow: yeah, there's a draft up.... no idea how that got there.  it has no contents, though.
[19:55] <natefinch> ericsnow: how do I delete it?
[19:55] <ericsnow> natefinch: under the "Close" tab click on "Delete Permanently"
[19:55] <natefinch> ericsnow: I don't have that, must be admin only?
[19:56] <ericsnow> natefinch: weird, I thought you could do that for your own requests
[19:56] <ericsnow> natefinch: I'll clean it up
[19:56] <natefinch> ericsnow: thanks
[19:57] <ericsnow> natefinch: what's the URL to the request
[19:57] <ericsnow> ?
[19:58] <natefinch> http://reviews.vapour.ws/r/3774/
[20:06] <mup> Bug #1356500 changed: Lost relation data after juju killing upgrader/uniter on state connection lost. <sts> <juju-core:Invalid> <https://launchpad.net/bugs/1356500>
[20:06] <mup> Bug #1433336 changed: juju deploy tags are persistent accross juju deploys <juju-core:Invalid> <https://launchpad.net/bugs/1433336>
[20:06] <mup> Bug #1543262 opened: keystone V3 support needed <uosci> <Go OpenStack Exchange:New> <juju-core:New> <https://launchpad.net/bugs/1543262>
[20:30] <ericsnow> natefinch: kill that PR and and try again
[20:33] <natefinch> ericsnow: worked, thanks
[20:34] <natefinch> ericsnow: I have a couple of merges going.  Gotta go snowblow again.  I'll finished up the tasks on that show-service-resources patch when I get back in... I should be able to get that and the change to push-resource done tonight
[20:34] <ericsnow> natefinch: cool
[21:09] <mup> Bug #1543283 opened: [Joyent] 4k ssh key can not be used: "cannot create credentials: An error occurred while parsing the key: asn1: structure error: length too large" <juju-core:New> <https://launchpad.net/bugs/1543283>
[21:28] <rick_h___> natefinch-afk: I think name=file is worthwhile as it's explicit.
[21:51] <rick_h___> wallyworld: can you bump that until after your standup please?
[22:01] <wallyworld> rick_h___: the cli meeting?
[22:02] <rick_h___> wallyworld: yes please. I'm flying back in that window but will in a layover after your standup
[22:02] <rick_h___> wallyworld: or do you want to chat now?
[22:02] <wallyworld> rick_h___: if alexisb is free we could
[22:03] <wallyworld> rick_h___: ah, but she has monday off, that's right, so i'll bump
[22:03] <rick_h___> wallyworld: ah right, she's on holiday today
[22:03] <wallyworld> it tuesday here so i forgot what day it was
[22:03] <wallyworld> over there
[22:03] <rick_h___> heh
[22:06] <rick_h___> ty wallyworld
[22:07] <wallyworld> np. you sre a busy, busy man
[22:07] <wallyworld> are
[22:09] <rick_h___> wallyworld: wheeeee
[22:09] <rick_h___> wallyworld: "livin the dream"
[22:09] <wallyworld> living the dream :-D
[22:09] <rick_h___> :P
[22:09] <wallyworld> yup :-)
[22:09] <wallyworld> me too!
[22:10] <rick_h___> wallyworld is my role model
[22:11] <wallyworld> for some value of "role model"
[22:11] <wallyworld> the mind boggles
[22:11] <wallyworld> i am good at livin the dream :-)
[22:16] <rick_h___> wallyworld: ooh, can I ask a favor? I'm trying to figure out something.
[22:16] <wallyworld> sure
[22:16] <rick_h___> wallyworld: if an ubuntu user isn't on a guest ubuntu image, does juju create one?
[22:16] <rick_h___> wallyworld: someone thinks this is true but unsure how to check it out
[22:17] <wallyworld> afair, we expect an ubuntu user on our public cloud images, i think we create one for manual provider
[22:17] <wallyworld> i'd have to check to be sure
[22:18] <wallyworld> thumper: can you recall?
[22:18] <rick_h___> wallyworld: if you get a sec can you dbl check? We're talking about providing images for someone and they want a non-ubuntu user ootb and I'm worrked about charms not working if there's no ubuntu user
[22:18] <thumper> eh?
[22:18] <rick_h___> wallyworld: or hint me on how to dbl check
[22:18] <wallyworld> thumper: do you know for sure or not if we create an ubuntu user if one doesn't exist?
[22:18] <thumper> I think we do now
[22:18] <thumper> not for sure, but 85%
[22:19] <wallyworld> rick_h___: i'll find out and get back to you
[22:19] <rick_h___> wallyworld: ty
[22:19] <rick_h___> I'd like to tell them "no" but wanted to make sure I had grounds first :)
[22:20] <wallyworld> ok, maybe you can say yes :-)
[22:21] <rick_h___> no, I'm not good at giving people what they want. I like it my way :P
[22:24] <wallyworld> rick_h___:
[22:25] <wallyworld> / SetUbuntuUser creates an "ubuntu" use for unix systems so the juju client
[22:25] <wallyworld> / can access the machine using ssh with the configuration we expect.
[22:25] <wallyworld> so we create the ubuntu user in cloud init
[22:25] <rick_h___> ah ok coolio ty
[22:29] <davechen1y> https://github.com/juju/juju/pull/4335
[22:29] <davechen1y> can I get a review pls
[22:31] <davechen1y> oh dear
[22:31] <davechen1y> i have a horrible feeling about the api server
[22:31] <thumper> davechen1y: shipit
[22:32] <thumper> what is this feeling?
[22:32] <davechen1y> every api server "conection" is a http conneciton
[22:32] <davechen1y> which is pooled on the client
[22:32] <davechen1y> there is no "session for a client"
[22:32] <davechen1y> it's just a bag of http connections
[22:32] <davechen1y> so "counting the number of outstanding connections" is complicated
[22:33] <davechen1y> do we want the number of http requests in fly
[22:33] <davechen1y> the number of http connections connectde (but possibly inactive)
[22:33] <davechen1y> etc
[22:33] <thumper> hmm...
[22:33] <thumper> tricky
[22:33] <davechen1y> i think the safest thing is always send Connection: closed after every API request
[22:33] <davechen1y> disabling pooling on the client
[22:34] <davechen1y> althought, this probably isn't the root issue that Cheryl is chasing
[22:35] <davechen1y> hmm
[22:36] <davechen1y> althgouth
[22:36] <davechen1y> isnt it web sockets over http ?
[22:36] <davechen1y> so actaully there _is_ a long lived connection
[22:36] <davechen1y> why did it have to be web sockets
[22:36] <davechen1y> ?!?
[22:36] <davechen1y> ok, so back in the day we had the gui
[22:36] <davechen1y> but now we have more clients that are _not_ browsers
[23:07] <davechen1y>                         modelUUID := req.URL.Query().Get(":modeluuid")
[23:07] <davechen1y>                         logger.Tracef("got a request for model %q", modelUUID)
[23:07] <davechen1y> ^ left over debugging ?
[23:15] <wallyworld> anastasiamac_: axw: a minute late
[23:15] <anastasiamac_> wallyworld: k. let us know when
[23:16] <wallyworld> here now
[23:23] <davechen1y> cherylj: what was the issue # we talked about at standup ?
[23:24] <davechen1y> thumper: i think I figured out a way around it
[23:32] <cherylj> davechen1y: https://bugs.launchpad.net/juju-core/+bug/1543216
[23:32] <mup> Bug #1543216: EOF uploading charm <charm> <ci> <deploy> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1543216>
[23:37] <mup> Bug #1543362 opened: juju debug-log returns error if run too early in bootstrap <juju-core:New> <https://launchpad.net/bugs/1543362>
[23:37] <davechen1y> ta