[00:32] anastasiamac: ok, good to know. better just let curtis know. [00:33] menn0: i have emailed Curtis. There is a tiny possibility too that the master was taken from a commit that preceeds ur and my changes... hence our work was re-targeted to next milestone although it is in codebase.. [00:34] anastasiamac: could be, although the specific issue xtian and I were working on was one of the reasons for beta13 and I'm fairly certain it did make it [00:35] menn0: \o/ then it's just an oversight and will get cleared tonight [00:38] anastasiamac/thumper: quick review please: http://reviews.vapour.ws/r/5298/ [00:38] menn0: looking [02:12] axw: I have some questions around volumes when you have some time [02:14] axw: FWIW, re: https://bugs.launchpad.net/juju-core/+bug/1599503 I reverted the charm storage change which was exercising this bug. So the production urgency is gone from our perspective. [02:14] Bug #1599503: Cannot upgrade charm if storage is modified, even if the service doesn't use said storage

[02:17] blahdeblah: OK, thanks for letting me know. I was thinking that would be the fastest course of action. I'm on the case anyway, hope to have it fixed today or tomorrow in the 2.0 branch. [02:17] thumper: fire away [02:17] axw: probably best over hangout [02:18] axw: FWIW, we don't care about 2.0 for production envs. :-) [02:18] blahdeblah: yeah I just mean I'm fixing it there, then will back port :) [02:18] back port shouldn't be long behind [02:19] axw: https://hangouts.google.com/hangouts/_/canonical.com/volumes?authuser=1 [02:19] axw: cool - thanks [05:54] see ya tomorrow folks [08:00] * dimitern waves ;) [08:02] morning all [08:02] \o [08:11] morning [08:11] dimitern: welcome back; want to sync? [08:12] frobware: thanks! sure, just give me ~15m need to sort out the sprint stuff quickly first [08:13] dimitern: ok [08:35] frobware: hey, let's sync? joining the new "Standup" HO now.. [09:14] dimitern: welcome back! [09:15] babbageclunk: thanks! how's it going ? :) [09:15] babbageclunk: I see you'll be deserting our motley team for NZ :D [09:15] dimitern: pretty good, I think! How was gophercon? [09:16] dimitern: Yeah :( but :) [09:16] babbageclunk: awesome! lots of good talks and 2x as many people as 2014 [09:17] dimitern: how big is it? [09:17] babbageclunk: >1500 [09:17] dimitern: nice [09:18] babbageclunk: I'll prep a summary and send it some time this week [09:20] jam1: ping? [09:23] jam1: np, ignore that :) [09:33] fwereade_: ping? [09:37] dimitern: got a moment for some advice? [09:38] babbageclunk: sure [09:38] dimitern: I'm working on bug 1585878 [09:38] Bug #1585878: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <2.0>

[09:39] babbageclunk: yeah.. [09:39] Talking to Will it turns out to need a bit more structure than it first seemed from the bug. [09:39] babbageclunk: wanna HO or IRC is ok? [09:40] dimitern: Actually HO would be better, now that you say. [09:40] dimitern: In juju-sapphire? [09:40] babbageclunk: ok, joining the upcoming standup call - "core" I think it's called [09:40] I don't think I have that one anymore on my cal [09:41] ok, I still see sapphire. [09:41] how about that [09:41] ? [09:42] babbageclunk: I see it from last friday [09:52] babbageclunk, sorry! what can I do for you? [09:52] babbageclunk, dimitern: shall I join somewhere? [11:22] Bug #1605714 changed: juju2 beta11: LXD containers always pending on ppc64el systems

[11:22] Bug #1605747 changed: [ juju2 beta11 ] Maas system is deployed but agent remains pending

[11:22] Bug #1605756 changed: [ juju2 beta11 ] system show up in juju status as pending but there is no attempt to deploy in maas

[11:31] Bug #1605790 changed: Unable to initialize agent

[11:46] Bug #1605790 opened: Unable to initialize agent

[11:52] Bug #1605790 changed: Unable to initialize agent

[11:52] Bug #1605986 changed: Creating container: can't get info for image 'ubuntu-trusty'

[11:58] Bug #1605986 opened: Creating container: can't get info for image 'ubuntu-trusty'

[12:01] Bug #1605986 changed: Creating container: can't get info for image 'ubuntu-trusty'

[13:46] dimitern: apt-get update generally working for you atm? [13:47] frobware: I've been using apt update instead, for a while now [13:47] frobware: but apt-get update worked - just checked [13:48] dimitern: my network is flaky, possibly because I'm setting up IPv6, but lots of things seem to work, equally lots don't... [13:49] frobware: oh I see :/ [13:49] dimitern: I can generally do enough but any update eventually fails. some machines make lots of progress, others stop after 1 hit [13:52] frobware: maas-proxy could be messing some reqs? [13:58] fwereade_: can you make sure to have a card in kanban with the links and such for your PR: https://github.com/juju/juju/pull/5863 please? [14:01] dimitern: ping - standup [14:01] oops omw [14:02] dimitern: natefinch dooferlad ping for standups and such [14:02] dooferlad: ^^ [14:04] fwereade_: ping for standup ^ [14:13] Bug #1606256 opened: AWS failed to bootstrap environment refreshing addresses

[14:22] Bug #1606256 changed: AWS failed to bootstrap environment refreshing addresses

[14:28] Bug #1605756 opened: [ juju2 beta11 ] system show up in juju status as pending but there is no attempt to deploy in maas

[14:28] Bug #1606256 opened: AWS failed to bootstrap environment refreshing addresses

[14:29] fwereade_: hey, how did you come up with 100 for the batch size? i'm trying to find documentation for that flag [14:32] katco, "more pessimistic than the 1000 many reported success when using" [14:32] katco, I drew a blank on docs too, went entirely by empirical "does it still work" [14:32] fwereade_: ahh :) [14:33] fwereade_: yeah is this a flag on mongod? doesn't seem to be there [14:33] fwereade_: or looks like maybe mongorestore [14:33] katco, I have half a suspicion that a sufficiently-runaway txn-queue could make specific docs problematic in themselves, which is why I asked for a dump [14:33] katco, yeah, mongorestore [14:34] gtv [14:37] fwereade_: sorry got distracted. that sounds interesting (i.e. horrible)... what is a "run away txn-queue"? writes/s txns > reads/s txns? [14:38] katco, in particular, if you run transactions that *only* have asserts, the txn-queue fields in the affected documents never get cleaned up and grow without bound [14:39] katco, mgopurge fixes it; we have code we run on a timer to catch it; but it's a Thing That Can Happen [14:39] ew [14:39] katco, especially in older environments from before we discovered this [14:39] katco, well put ;) [14:40] everything about that is ew haha. the situation, our fix, ew [14:41] katco, indeed, we *should* better filter the txns so we don't even allow them to hit mgo/txn, to prevent the issue in the first place [14:41] fwereade_: ship it, with a request for just a little documentation [14:41] katco, ack, tyvm [14:55] fwereade_: I don't really understand the relationship between state/watchers and watcher/watchers. Can you explain? [14:55] a question for anyone: given that model names are relative to usernames, how can i switch to a model owned by someone else that has the same name as a model owned by me? [14:56] dooferlad: does this work on your network: wget -6 http://security.ubuntu.com/ubuntu/ [14:56] I *think* at the bottom everything ends up being a state watcher, right? [14:58] fwereade_: The admonitions in Boring Techniques against workers depending on state watchers is just a specific case of "workers should use the api rather than talking directly to state". [15:01] Bug #1606265 opened: Bogus upgrade in progress

[15:09] babbageclunk, hey, sorry [15:10] babbageclunk, it *is* a special case of that, yes; but more generally it's "don't use watchers that close their channels except where obliged to by reasons surrounding state" [15:10] fwereade_: Ok. [15:10] babbageclunk, the relationship is pretty much *just* that one closes its Changes chan and the other one doesn't [15:11] babbageclunk, and they have different types in a sort of attempt to encourage people to distinguish between them [15:11] fwereade_: So in my case, I'll add a state one, and then expose that in the API as a watcher/watcher and make a worker that uses that? [15:11] babbageclunk, watchers are basically all implemented either in state, or in api/watcher [15:12] babbageclunk, exactly, yeah [15:12] fwereade_: Also, I can't find an implementation of a notifywatcher that watches a whole collection (rather than a specific doc). [15:12] babbageclunk, hmm; cleanup watcher maybe? *checks* [15:13] fwereade_: Aha, thanks! [15:13] ok, cool. [15:14] babbageclunk, state.newNotifyCollWatcher? [15:14] babbageclunk, ah yes indeed [15:21] babbageclunk, (derail: I don't think there's anything stopping one from implementing a `watcher.WhateverWatcher` against whatever one chooses -- I think the watcher model is pretty useful -- but it is true that the vast majority, and perhaps all, of our live watcher.WhateverWatchers *are* backed by state.WhateverWatchers on a controller somewhere) [15:22] babbageclunk, (if one *doesn't* swap out the implementation when writing worker tests, one generally has an unpleasant time and ends up with slow and/or flaky tests) [15:23] fwereade_: Makes sense. [15:27] dimitern: ping - care to debug some ipv6 issues? Only if you have time... [15:28] frobware: I have some time before I go out at the top of the hour [15:29] dimitern: 1:1 HO? [15:29] frobware: omw [15:30] dimitern: oh, think I've deleted it. link? :) [15:30] frobware: me too :) [15:30] frobware: let's use the last one (standup) [15:31] Bug #1606278 opened: juju (2.0) deploy / fails [15:31] Bug #1606282 opened: juju (2.0) deploy fails as current working directory has a bundle [15:56] does the phrase "ABA problem" mean something to anyone? [15:57] ah... should have searched first: https://en.wikipedia.org/wiki/ABA_problem [15:59] liking swedish pop too much? [15:59] mgz: ha, the same joke occurred to me [16:05] uh, I arrived way too late for the joke [16:06] katco: interesting how they try to convey the issue in the name but just make it way more unrelated [16:06] perrito666: yeah [16:07] perrito666: i feel like it should have "race condition" somewhere in the name [16:07] "ABA race condition" at least hints at what's happening [16:08] Bug #1606300 opened: Race in github.com/altoros/gosigma

[16:08] Bug #1606302 opened: testsuite.TestWatchUnitAssignment got Next

[16:14] morning juju-dev [16:15] hey redir [16:30] frobware: sorry about the delay, yes, that works for me [16:31] * dooferlad goes back to running around like a crazy person [16:31] dooferlad: yep, things work from my router, not my clients. [16:31] frobware: ip -6 route ? [16:32] dooferlad: I've fiddled as this was mostly working before. :) [16:38] Bug # opened: 1606303, 1606308, 1606310, 1606313 [17:53] Bug #1606337 opened: Change single to multiple 'auto' stanzas in generated network configuration. === cory_fu is now known as cory_fu-vac [19:59] Bug #1606354 opened: Created user has no display-name === endo is now known as endomorphosis_ [20:05] Bug #1606354 changed: Created user has no display-name [20:06] does anyone know how to deal with this error message? [20:06] cmd supercommand.go:458 storing charm for URL "cs:juju-gui-130": cannot retrieve charm "cs:juju-gui-130": cannot get archive: Get https://api.jujucharms.com/charmstore/v5/juju-gui-130/archive?channel=stable: dial tcp 162.213.33.122:443: getsockopt: connection timed out [20:08] Bug #1606354 opened: Created user has no display-name [20:58] sinzui, thumper: do you know what kind of cert we're using for TLS on the juju server? i.e. RSA or ECDSA (or both if that's possible? I don't know). Working on https://bugs.launchpad.net/juju-core/+bug/1604474 [20:58] Bug #1604474: Juju 2.0-beta12 userdata execution fails on Windows

[20:59] natefinch: I don't know [21:00] gotta run for a while, but will be back later [21:00] sinzui: ok, np === natefinch is now known as natefinch-afk [21:59] Bug #1488245 changed: Recurring lxc issue: failed to retrieve the template to clone

[23:05] Bug #1605669 changed: grant-revoke User could not check status with read permission