/srv/irclogs.ubuntu.com/2016/07/25/#juju-dev.txt

menn0anastasiamac: ok, good to know. better just let curtis know.00:32
anastasiamacmenn0: 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:33
menn0anastasiamac: 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 it00:34
anastasiamacmenn0: \o/ then it's just an oversight and will get cleared tonight00:35
menn0anastasiamac/thumper: quick review please: http://reviews.vapour.ws/r/5298/00:38
anastasiamacmenn0: looking00:38
thumperaxw: I have some questions around volumes when you have some time02:12
blahdeblahaxw: 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
mupBug #1599503: Cannot upgrade charm if storage is modified, even if the service doesn't use said storage <juju-core:In Progress by axwalk> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1599503>02:14
axwblahdeblah: 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
axwthumper: fire away02:17
thumperaxw: probably best over hangout02:17
blahdeblahaxw: FWIW, we don't care about 2.0 for production envs. :-)02:18
axwblahdeblah: yeah I just mean I'm fixing it there, then will back port :)02:18
axwback port shouldn't be long behind02:18
thumperaxw: https://hangouts.google.com/hangouts/_/canonical.com/volumes?authuser=102:19
blahdeblahaxw: cool - thanks02:19
thumpersee ya tomorrow folks05:54
* dimitern waves ;)08:00
dimiternmorning all08:02
macgreagoir\o08:02
hoenirmorning08:11
frobwaredimitern: welcome back; want to sync?08:11
dimiternfrobware: thanks! sure, just give me ~15m need to sort out the sprint stuff quickly first08:12
frobwaredimitern: ok08:13
dimiternfrobware: hey, let's sync? joining the new "Standup" HO now..08:35
babbageclunkdimitern: welcome back!09:14
dimiternbabbageclunk: thanks! how's it going ? :)09:15
dimiternbabbageclunk: I see you'll be deserting our motley team for NZ :D09:15
babbageclunkdimitern: pretty good, I think! How was gophercon?09:15
babbageclunkdimitern: Yeah :( but :)09:16
dimiternbabbageclunk: awesome! lots of good talks and 2x as many people as 201409:16
babbageclunkdimitern: how big is it?09:17
dimiternbabbageclunk: >150009:17
babbageclunkdimitern: nice09:17
dimiternbabbageclunk: I'll prep a summary and send it some time this week09:18
dimiternjam1: ping?09:20
dimiternjam1: np, ignore that :)09:23
babbageclunkfwereade_: ping?09:33
babbageclunkdimitern: got a moment for some advice?09:37
dimiternbabbageclunk: sure09:38
babbageclunkdimitern: I'm working on bug 158587809:38
mupBug #1585878: Removing a container does not remove the underlying MAAS device representing the container unless the host is also removed. <2.0> <hours> <maas-provider> <network> <reliability> <juju-core:Triaged by 2-xtian> <https://launchpad.net/bugs/1585878>09:38
dimiternbabbageclunk: yeah..09:39
babbageclunkTalking to Will it turns out to need a bit more structure than it first seemed from the bug.09:39
dimiternbabbageclunk: wanna HO or IRC is ok?09:39
babbageclunkdimitern: Actually HO would be better, now that you say.09:40
babbageclunkdimitern: In juju-sapphire?09:40
dimiternbabbageclunk: ok, joining the upcoming standup call - "core" I think it's called09:40
dimiternI don't think I have that one anymore on my cal09:40
babbageclunkok, I still see sapphire.09:41
babbageclunkhow about that09:41
babbageclunk?09:41
dimiternbabbageclunk: I see it from last friday09:42
fwereade_babbageclunk, sorry! what can I do for you?09:52
fwereade_babbageclunk, dimitern: shall I join somewhere?09:52
mupBug #1605714 changed: juju2 beta11: LXD containers always pending on ppc64el systems <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1605714>11:22
mupBug #1605747 changed: [ juju2 beta11 ] Maas system is deployed but agent remains pending <oil> <oil-2.0> <juju-core:Invalid> <https://launchpad.net/bugs/1605747>11:22
mupBug #1605756 changed: [ juju2 beta11 ] system show up in juju status as pending but there is no attempt to deploy in maas <oil> <oil-2.0> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1605756>11:22
mupBug #1605790 changed: Unable to initialize agent <vpil> <juju-core:New> <https://launchpad.net/bugs/1605790>11:31
mupBug #1605790 opened: Unable to initialize agent <vpil> <juju-core:New> <https://launchpad.net/bugs/1605790>11:46
mupBug #1605790 changed: Unable to initialize agent <vpil> <juju-core:New> <https://launchpad.net/bugs/1605790>11:52
mupBug #1605986 changed: Creating container: can't get info for image 'ubuntu-trusty' <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1605986>11:52
mupBug #1605986 opened: Creating container: can't get info for image 'ubuntu-trusty' <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1605986>11:58
mupBug #1605986 changed: Creating container: can't get info for image 'ubuntu-trusty' <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1605986>12:01
frobwaredimitern: apt-get update generally working for you atm?13:46
dimiternfrobware: I've been using apt update instead, for a while now13:47
dimiternfrobware: but apt-get update worked - just checked13:47
frobwaredimitern: my network is flaky, possibly because I'm setting up IPv6, but lots of things seem to work, equally lots don't...13:48
dimiternfrobware: oh I see :/13:49
frobwaredimitern: I can generally do enough but any update eventually fails. some machines make lots of progress, others stop after 1 hit13:49
dimiternfrobware: maas-proxy could be messing some reqs?13:52
rick_h_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?13:58
frobwaredimitern: ping - standup14:01
dimiternoops omw14:01
rick_h_dimitern: natefinch dooferlad ping for standups and such14:02
frobwaredooferlad: ^^14:02
rick_h_fwereade_: ping for standup ^14:04
mupBug #1606256 opened: AWS failed to bootstrap environment refreshing addresses <bootstrap> <ci> <ec2-provider> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1606256>14:13
mupBug #1606256 changed: AWS failed to bootstrap environment refreshing addresses <bootstrap> <ci> <ec2-provider> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1606256>14:22
mupBug #1605756 opened: [ juju2 beta11 ] system show up in juju status as pending but there is no attempt to deploy in maas <oil> <oil-2.0> <juju-core:New> <MAAS:Invalid> <https://launchpad.net/bugs/1605756>14:28
mupBug #1606256 opened: AWS failed to bootstrap environment refreshing addresses <bootstrap> <ci> <ec2-provider> <reliability> <retry> <juju-core:Triaged> <https://launchpad.net/bugs/1606256>14:28
katcofwereade_: hey, how did you come up with 100 for the batch size? i'm trying to find documentation for that flag14:29
fwereade_katco, "more pessimistic than the 1000 many reported success when using"14:32
fwereade_katco, I drew a blank on docs too, went entirely by empirical "does it still work"14:32
katcofwereade_: ahh :)14:32
katcofwereade_: yeah is this a flag on mongod? doesn't seem to be there14:33
katcofwereade_: or looks like maybe mongorestore14:33
fwereade_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 dump14:33
fwereade_katco, yeah, mongorestore14:33
dimiterngtv14:34
katcofwereade_: sorry got distracted. that sounds interesting (i.e. horrible)... what is a "run away txn-queue"? writes/s txns > reads/s txns?14:37
fwereade_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 bound14:38
fwereade_katco, mgopurge fixes it; we have code we run on a timer to catch it; but it's a Thing That Can Happen14:39
katcoew14:39
fwereade_katco, especially in older environments from before we discovered this14:39
fwereade_katco, well put ;)14:39
katcoeverything about that is ew haha. the situation, our fix, ew14:40
fwereade_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 place14:41
katcofwereade_: ship it, with a request for just a little documentation14:41
fwereade_katco, ack, tyvm14:41
babbageclunkfwereade_: I don't really understand the relationship between state/watchers and watcher/watchers. Can you explain?14:55
rogpeppe1a 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:55
frobwaredooferlad: does this work on your network: wget -6 http://security.ubuntu.com/ubuntu/14:56
babbageclunkI *think* at the bottom everything ends up being a state watcher, right?14:56
babbageclunkfwereade_: 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".14:58
mupBug #1606265 opened: Bogus upgrade in progress <ci> <list-controllers> <regression> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1606265>15:01
fwereade_babbageclunk, hey, sorry15:09
fwereade_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
babbageclunkfwereade_: Ok.15:10
fwereade_babbageclunk, the relationship is pretty much *just* that one closes its Changes chan and the other one doesn't15:10
fwereade_babbageclunk, and they have different types in a sort of attempt to encourage people to distinguish between them15:11
babbageclunkfwereade_: 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
fwereade_babbageclunk, watchers are basically all implemented either in state, or in api/watcher15:11
fwereade_babbageclunk, exactly, yeah15:12
babbageclunkfwereade_: Also, I can't find an implementation of a notifywatcher that watches a whole collection (rather than a specific doc).15:12
fwereade_babbageclunk, hmm; cleanup watcher maybe? *checks*15:12
babbageclunkfwereade_: Aha, thanks!15:13
babbageclunkok, cool.15:13
fwereade_babbageclunk, state.newNotifyCollWatcher?15:14
fwereade_babbageclunk, ah yes indeed15:14
fwereade_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:21
fwereade_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:22
babbageclunkfwereade_: Makes sense.15:23
frobwaredimitern: ping - care to debug some ipv6 issues? Only if you have time...15:27
dimiternfrobware: I have some time before I go out at the top of the hour15:28
frobwaredimitern: 1:1 HO?15:29
dimiternfrobware: omw15:29
frobwaredimitern: oh, think I've deleted it. link? :)15:30
dimiternfrobware: me too :)15:30
dimiternfrobware: let's use the last one (standup)15:30
mupBug #1606278 opened: juju (2.0) deploy <charm-name>/<revision#> fails <juju-core:New> <https://launchpad.net/bugs/1606278>15:31
mupBug #1606282 opened: juju (2.0) deploy <bundle-name> fails as current working directory has a bundle <juju-core:New> <https://launchpad.net/bugs/1606282>15:31
katcodoes the phrase "ABA problem" mean something to anyone?15:56
katcoah... should have searched first: https://en.wikipedia.org/wiki/ABA_problem15:57
mgzliking swedish pop too much?15:59
katcomgz: ha, the same joke occurred to me15:59
perrito666uh, I arrived way too late for the joke16:05
perrito666katco: interesting how they try to convey the issue in the name but just make it way more unrelated16:06
katcoperrito666: yeah16:06
katcoperrito666: i feel like it should have "race condition" somewhere in the name16:07
katco"ABA race condition" at least hints at what's happening16:07
mupBug #1606300 opened: Race in github.com/altoros/gosigma <cloudsigma-provider> <intermittent-failure> <race-condition> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1606300>16:08
mupBug #1606302 opened: testsuite.TestWatchUnitAssignment got Next <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1606302>16:08
redirmorning juju-dev16:14
katcohey redir16:15
dooferladfrobware: sorry about the delay, yes, that works for me16:30
* dooferlad goes back to running around like a crazy person16:31
frobwaredooferlad: yep, things work from my router, not my clients.16:31
dooferladfrobware: ip -6 route ?16:31
frobwaredooferlad: I've fiddled as this was mostly working before. :)16:32
mupBug # opened: 1606303, 1606308, 1606310, 160631316:38
mupBug #1606337 opened: Change single to multiple 'auto' stanzas in generated network configuration. <juju-core:New> <https://launchpad.net/bugs/1606337>17:53
=== cory_fu is now known as cory_fu-vac
mupBug #1606354 opened: Created user has no display-name <juju-core:Triaged> <https://launchpad.net/bugs/1606354>19:59
=== endo is now known as endomorphosis_
mupBug #1606354 changed: Created user has no display-name <juju-core:Triaged> <https://launchpad.net/bugs/1606354>20:05
endomorphosis_does anyone know how to deal with this error message?20:06
endomorphosis_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 out20:06
mupBug #1606354 opened: Created user has no display-name <juju-core:Triaged> <https://launchpad.net/bugs/1606354>20:08
natefinchsinzui, 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/160447420:58
mupBug #1604474: Juju 2.0-beta12  userdata execution fails on Windows <azure-provider> <juju2.0> <oil> <oil-2.0> <windows> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1604474>20:58
sinzuinatefinch: I don't know20:59
natefinchgotta run for a while, but will be back later21:00
natefinchsinzui: ok, np21:00
=== natefinch is now known as natefinch-afk
mupBug #1488245 changed: Recurring lxc issue: failed to retrieve the template to clone  <canonical-bootstack> <landscape> <lxc> <oil> <juju-core:Invalid> <https://launchpad.net/bugs/1488245>21:59
mupBug #1605669 changed: grant-revoke User could not check status with read permission <ci> <grant> <regression> <juju-core:Fix Released by gz> <https://launchpad.net/bugs/1605669>23:05

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!