| perrito666 | bbl dinner | 00:12 |
|---|---|---|
| wallyworld | axw: i've updated the pr when you are back | 00:22 |
| anastasiamac | I am OCR next Tuesday but am on holidays - anyone keen to swap? :D | 00:46 |
| axw | wallyworld: shipit | 01:15 |
| wallyworld | ty | 01:15 |
| axw | wallyworld: I think we should eventually tease out those model representations from api/uniter, and move them into the worker/uniter package itself, wrapping a flat API | 01:17 |
| axw | wallyworld: then we can think about auto-generating the API client code | 01:17 |
| axw | not today obviously, just thinking about things we can do to improve quality in future | 01:18 |
| wallyworld | yeah, there's room for improvement in that area. we need to rethink a few of our initial design deceisions | 01:18 |
| wallyworld | not that we are hitting these pain points | 01:18 |
| wallyworld | now | 01:18 |
| axw | wallyworld: well we are with testing. and writing API clients isn't *hard* but it's more work than necessary | 01:18 |
| axw | time better spent elsewhere | 01:19 |
| wallyworld | yep | 01:19 |
| davecheney | axw: I have a question about tools storage | 02:28 |
| davecheney | tools_test.go:331: c.Assert(url, gc.Equals, "https://0.1.2.3:1234/environment/my-uuid/tools/"+version.Current.String()) | 02:28 |
| davecheney | ... obtained string = "https://0.1.2.3:1234/environment/my-uuid/tools/1.26-alpha1-trusty-arm64" | 02:28 |
| davecheney | ... expected string = "https://0.1.2.3:1234/environment/my-uuid/tools/1.26-alpha1" | 02:28 |
| davecheney | i've been tinkering with something and have a test failure | 02:28 |
| davecheney | but I think the expected message is wrong | 02:28 |
| davecheney | why would the expected want tools withotu a series and an arch ? | 02:28 |
| axw | davecheney: sec, finding the code to refresh memory | 02:28 |
| davecheney | apiserver/common | 02:29 |
| axw | davecheney: yeah, it should be the binary string... version.Current is a verison.Binary in master, did you change its type? | 02:31 |
| davecheney | i did | 02:32 |
| axw | davecheney: show me your diff? | 02:32 |
| davecheney | it's very large | 02:33 |
| davecheney | so when you say binary string | 02:33 |
| davecheney | it should be the output of version.Binary.String() ? | 02:33 |
| axw | davecheney: yep | 02:33 |
| davecheney | m'kay | 02:33 |
| davecheney | thanks | 02:33 |
| thumper | menn0: got time to talk migrations? | 02:34 |
| menn0 | thumper: yep | 02:34 |
| davecheney | axw: i see the problem | 02:35 |
| davecheney | axw: https://github.com/juju/juju/compare/master...davecheney:remove-version-arch?expand=1 | 02:35 |
| davecheney | if you want to see the whole thing | 02:35 |
| * thumper peeks | 02:35 | |
| davecheney | axw: the error mesage above is back to front | 02:36 |
| davecheney | the expected is being constructed incorrect ... | 02:36 |
| davecheney | the expected is being constructed incorrectly ... | 02:36 |
| axw | davecheney: I think you just want to s/version.Current/current/ on the last line of TestToolsURLGetter | 02:38 |
| axw | davecheney: the URL returned *should* include arch/series | 02:38 |
| axw | it's a URL to download a specific tools archive | 02:39 |
| davecheney | yeah, i understand what is going on now | 02:39 |
| davecheney | hanks | 02:39 |
| davecheney | thanks | 02:39 |
| axw | nps | 02:39 |
| mup | Bug #1491226 opened: juju status hangs at 'connection established to' until jujud-machine-0 restarted <juju-core:New> <https://launchpad.net/bugs/1491226> | 04:30 |
| thumper | I'm just popping out again to take sad daughter with sadder laptop back down to repair person | 04:45 |
| thumper | bbs | 04:45 |
| thumper | back | 05:19 |
| thumper | dying hard disk | 05:19 |
| thumper | there goes another $150 | 05:19 |
| thumper | boo | 05:19 |
| davecheney | thumper: version.Binary.OS is _always_ derrived from version.Current.Series ... | 05:47 |
| davecheney | we don't need to put that on the struct | 05:47 |
| davecheney | we can recover it with a function | 05:47 |
| thumper | right, I don't know who did, or why exactly | 05:47 |
| thumper | perhaps look for the commit that added it and look at the review? | 05:47 |
| thumper | I'm guessing it was added as a "helper" | 05:47 |
| thumper | where a plain function would have been better | 05:48 |
| davecheney | having it on the value does have one advantage | 05:49 |
| davecheney | it's always known to be valid | 05:49 |
| davecheney | recovering it from version.Current.Series when needed does mean you have to handle the error there | 05:49 |
| davecheney | that doesn't look like too much of a problem | 05:50 |
| davecheney | and that means version.Binary goes back to being just Number, Series and Arch | 05:50 |
| davecheney | i think it's worth the cost | 05:50 |
| davecheney | _especially_ as most of the callers that use version.Binary.OS, are actually asking ... is this windows | 05:50 |
| davecheney | is this centos | 05:50 |
| davecheney | they don't want to switch on the versin | 05:50 |
| davecheney | just check if they shold enable something or not | 05:50 |
| davecheney | I have not found one case where we overwrite vesion.Current.OS | 05:50 |
| davecheney | I think i'll move the OS stuff out of version/ into juju/os | 05:51 |
| davecheney | like we have juju/arch | 05:51 |
| thumper | sounds good to me | 05:57 |
| thumper | also good to have explicit functions for checking OS | 05:58 |
| thumper | I'm getting called for dinner | 05:58 |
| thumper | chat tomorrow | 05:58 |
| === akhavr1 is now known as akhavr | ||
| mup | Bug #1491353 opened: workers ignore stop channel <juju-core:New> <https://launchpad.net/bugs/1491353> | 11:58 |
| === akhavr1 is now known as akhavr | ||
| mgz | bogdanteleaga: I have some bugs for you | 13:18 |
| mup | Bug #1491398 opened: RebootSuite test failures on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1491398> | 13:35 |
| mup | Bug #1491399 opened: TestInstallMongodServiceExists fails on precise <ci> <precise> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1491399> | 13:35 |
| niemeyer_ | natefinch, mgz: Can you please see if the IPv6 test is now working again? | 13:37 |
| mgz | niemeyer_: sure thing | 13:37 |
| niemeyer_ | mgz: Thanks! | 13:38 |
| wwitzel3 | ericsnow: what is the state of the workload plugins to libs? | 13:41 |
| mgz | niemeyer_: all good, <http://paste.ubuntu.com/12253283> | 13:41 |
| wwitzel3 | ericsnow: want me to pick it up? my resolve storage variables is being blocked by it | 13:41 |
| ericsnow | wwitzel3: basically all done | 13:41 |
| niemeyer_ | mgz: Sweet | 13:42 |
| ericsnow | wwitzel3: I split it up; first: http://reviews.vapour.ws/r/2541/ | 13:42 |
| niemeyer_ | mgz: Still need to do more for the full IPv6 address resolution story, but at least addresses are working properly again | 13:42 |
| mup | Bug #1491398 changed: RebootSuite test failures on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1491398> | 13:47 |
| mup | Bug #1491399 changed: TestInstallMongodServiceExists fails on precise <ci> <precise> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1491399> | 13:47 |
| mup | Bug #1491398 opened: RebootSuite test failures on windows <ci> <regression> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1491398> | 13:50 |
| mup | Bug #1491399 opened: TestInstallMongodServiceExists fails on precise <ci> <precise> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1491399> | 13:50 |
| mup | Bug #1491451 opened: [Juju 2.x] Remove command aliases <juju-core:New> <https://launchpad.net/bugs/1491451> | 14:53 |
| katco | ericsnow: wwitzel3: natefinch: new card on the board for removing the cloudsigma feature flag. if one of you could pick that up in the next few days, that'd be great | 15:09 |
| katco | ericsnow: wwitzel3 natefinch why is "massachusetts names" at the top of the spec? | 15:18 |
| natefinch | lol | 15:21 |
| natefinch | mistype sorry | 15:21 |
| wwitzel3 | hah | 15:22 |
| bogdanteleaga | can someone take a look at this? http://reviews.vapour.ws/r/2557/ | 15:30 |
| === natefinch is now known as natefinch-afk | ||
| benji | k/quit | 18:15 |
| mup | Bug #1491547 opened: [upgrade-juju] Poor user experience <juju-core:New> <https://launchpad.net/bugs/1491547> | 19:03 |
| mup | Bug #1491547 changed: [upgrade-juju] Poor user experience <juju-core:New> <https://launchpad.net/bugs/1491547> | 19:12 |
| alexisb | cherylj, ping | 19:15 |
| * alexisb looks at the calendar and sees cherylj is on vacation | 19:16 | |
| mup | Bug #1491547 opened: [upgrade-juju] Poor user experience <docteam> <juju-core:New> <https://launchpad.net/bugs/1491547> | 19:18 |
| === natefinch-afk is now known as natefinch | ||
| lazyPower | Greetings core hackers o/ I've run into an interesting scenario that appears to be a dupe of this bug: https://bugs.launchpad.net/juju-core/+bug/1416928 - juju has picked the wrong interface to atttempt to communicate with the state server | 20:03 |
| mup | Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Fix Released by dooferlad> <juju-core 1.21:Fix Released by dimitern> <juju-core 1.22:Fix Released by dooferlad> <https://launchpad.net/bugs/1416928> | 20:03 |
| lazyPower | in this particular case its the docker0 bridge interface, and none of the LXC interfaces. Is there a suggested work around? | 20:03 |
| natefinch | lazyPower: I presume you're on a version of juju that has the fixes to that bug? | 20:04 |
| mbruzek | natefinch: it is a customer who is encountered this and they are at 1.24.5.1 | 20:05 |
| lazyPower | natefinch: 1.25.1 to be exact. | 20:05 |
| lazyPower | er | 20:05 |
| lazyPower | sorry mbruzek is correct. 1.24.5.1 | 20:05 |
| natefinch | *nod* | 20:05 |
| mbruzek | natefinch http://paste.ubuntu.com/12256492/ | 20:07 |
| mbruzek | natefinch: I can see Juju dialing "wss://192.168.122.1:17070/environment | 20:07 |
| mbruzek | natefinch: then I see Juju trying to download https://172.17.42.1:17070/environment | 20:08 |
| natefinch | mbruzek, lazyPower: yeah, looking at the fix, the bugfix was very specifically targetted at lxc, so it wouldn't filter out other bridge adapters, like docker's. | 20:17 |
| lazyPower | natefinch: i can file a follow up bug if thats helpful | 20:18 |
| lazyPower | we have enough log output and i see what happened in the deployment well enough to outline whats happened. | 20:18 |
| mbruzek | natefinch: is that the right bug 1416928 ? | 20:18 |
| mup | Bug #1416928: juju agent using lxcbr0 address as apiaddress instead of juju-br0 breaks agents <api> <lxc> <network> <juju-core:Fix Released by dooferlad> <juju-core 1.21:Fix Released by dimitern> <juju-core 1.22:Fix Released by dooferlad> <https://launchpad.net/bugs/1416928> | 20:18 |
| mbruzek | Can I have them watch that one for a fix? Or where? | 20:19 |
| natefinch | lazyPower: yes please. I'm sure it's the exact same thing, just the fix explicitly just uses lxc-net to find the lxc bridge | 20:19 |
| natefinch | mbruzek: watch the new one lazyPower makes. And lazyPower, please link to that lxc bug. Hopefully we can find a more general solution that won't break whenever something else adds its own bridge | 20:20 |
| mup | Bug #1491578 opened: [wily] When adding a machine, can't find the juju-local metapackage <juju-core:New> <https://launchpad.net/bugs/1491578> | 20:30 |
| natefinch | katco: I just reread https://bugs.launchpad.net/juju-core/+bug/1486553 and only now noticed the linked bug at the bottom of the description that is a private bug.... it seems like there's no actual juju-core bug to reproduce. Yes, there's a network timeout when running deploy, but that's not a bug, that's the network being the network. | 20:30 |
| mup | Bug #1486553: i/o timeout errors can cause non-atomic service deploys <cisco> <landscape> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1486553> | 20:30 |
| natefinch | katco: It seems like that big is "theoretically, something bad could happen" not "something bad has actually happened" | 20:31 |
| natefinch | s/big/bug/ | 20:31 |
| katco | natefinch: we have customer sites that this is affecting | 20:31 |
| natefinch | katco: nothing in the bug says what problems they're having, other than a network timeout.... after which they look at the environment and the deploy succeeded. | 20:32 |
| katco | natefinch: let me find someone you can talk to | 20:32 |
| natefinch | katco: that would be helpful :) | 20:32 |
| katco | natefinch: talk to landscape/beret (dean) | 20:34 |
| natefinch | Beret: I'm looking into https://bugs.launchpad.net/juju-core/+bug/1486553 hoping you can help me understand how core can help. | 20:35 |
| mup | Bug #1486553: i/o timeout errors can cause non-atomic service deploys <cisco> <landscape> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1486553> | 20:35 |
| Beret | natefinch, bad stuff does indeed happen | 20:35 |
| Beret | and happens often | 20:35 |
| Beret | ahasenack, around? | 20:36 |
| Beret | natefinch, did you see Dimiter's comment? | 20:36 |
| natefinch | Beret: yes, but I'm not sure if that's the specific problem the customers are seeing. | 20:38 |
| dpb1_ | natefinch: wdyn | 20:40 |
| natefinch | dpb1_: the bug https://bugs.launchpad.net/juju-core/+bug/1486553 doesn't tell me what specific problem the customer is seeing, other than a network timeout, which is sorta out of my jurisdiction. | 20:41 |
| mup | Bug #1486553: i/o timeout errors can cause non-atomic service deploys <cisco> <landscape> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1486553> | 20:41 |
| ahasenack | natefinch: we had two occurances related to that timeout | 20:41 |
| ahasenack | natefinch: a) juju deploy returned a timeout, we retried it, it then said the service already exists | 20:42 |
| mup | Bug #1491578 changed: [wily] juju add-machine, can't find the juju-local metapackage <juju-core:New> <https://launchpad.net/bugs/1491578> | 20:42 |
| ahasenack | natefinch: b) juju deploy returned a timeout, service was deployed but without the configuration we asked (just its defaults) | 20:42 |
| ahasenack | natefinch: I'm a bit less clued in the (b) case, I know what was reported in the bug in that case | 20:42 |
| ahasenack | natefinch: but about (a), we see that rather often, as in a few times per week | 20:42 |
| ahasenack | natefinch: we found out the (b) case when we started handling the "service already exists" error for when we retry. We assumed it was all good, but later found out the service config options were not what we set | 20:43 |
| natefinch | ahasenack: b) is much more concerning to me. a) seems like the price we pay for an unreliable network... though perhaps there's some bug causing the timeout. b) is definitely just a bug that should be fixed (though I'm sure it'll be tricky). | 20:46 |
| ahasenack | natefinch: it's tricky to workaround as well, we would have to remove the service and deploy again to be sure | 20:47 |
| ahasenack | natefinch: it's when we hit (b) that the bug got escalated, since we have a workaround in place for (a) | 20:47 |
| ahasenack | "if it says service is already deployed, good, let's just move on" | 20:47 |
| ahasenack | natefinch: iirc the timeout was to localhost, | 20:47 |
| ahasenack | natefinch: not between us (client) and state server | 20:48 |
| ahasenack | natefinch: gotta run now | 20:48 |
| mup | Bug #1491578 opened: [wily] When adding a machine, can't find the juju-local metapackage <juju-core:New> <https://launchpad.net/bugs/1491578> | 20:48 |
| natefinch | a timeout to localhost is pretty bogus, for sure | 20:49 |
| ahasenack | back | 20:56 |
| ahasenack | natefinch: | 20:56 |
| ahasenack | Aug 7 20:45:06 job-handler-1 INFO Traceback (failure with no frames): <class 'canonical.juju.errors.RequestError'>: cannot add service "mongodb": read tcp 127.0.0.1:37017: i/o timeout | 20:56 |
| ahasenack | that's what I meant with timeout to localhost | 20:56 |
| ahasenack | job-handler is our juju client in this scenario | 20:57 |
| ahasenack | natefinch: so if true, it's not a networking issue, more like a local high load perhaps, short timeout, all threads occupied, etc, scenario | 20:57 |
| natefinch | ahasenack: yeah, I was going to say... what's the timeout? | 20:58 |
| natefinch | like length of time | 20:58 |
| ahasenack | ours? don't know, would have to check | 20:59 |
| natefinch | deploy *should* be quick, but it depends on if you're doing a deploy of a local charm, etc... | 20:59 |
| ahasenack | but that is to localhost, so it's on your end | 20:59 |
| ahasenack | that message, "read tcp 127.0.0.1:37017: i/o timeout", comes back from juju, no? | 21:00 |
| ahasenack | our connection is still up and fine | 21:00 |
| natefinch | ahasenack: ahh ok, sorry, was getting confused by the extra stuff on the beginning of the error. Yes, the 'cannot add service "foo" ' is our message. | 21:02 |
| natefinch | ahasenack: any more info you can put in that bug would help... like, the type of environments you've seen this in, etc. You shouldn't be connecting to localhost unless you're running local provider or running the client on the state machine | 21:03 |
| ahasenack | natefinch: for what is worth, we deploy a lot of containers, so disk i/o is intense | 21:03 |
| ahasenack | natefinch: we do not connect to localhost | 21:03 |
| natefinch | ahasenack: sorry, I mean that juju should not be connecting to localhost | 21:03 |
| ahasenack | landscape ---------> |17070:state server -> mongo:37017| | 21:03 |
| ahasenack | is that a fair diagram? | 21:04 |
| natefinch | ahasenack: oh, yes, duh, ok | 21:04 |
| natefinch | ahasenack: I gotta run, it's dinner time here.... I'll work on this some more tonight, see if I can reproduce, or induce a reproduction. | 21:04 |
| ahasenack | natefinch: cheers, thx | 21:04 |
| mup | Bug #1491592 opened: local provider uses the wrong interface <customer-support> <local-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1491592> | 21:18 |
| mbruzek | Hello juju-devs this bug that mup just referenced is from a customer. | 21:19 |
| mbruzek | I see that natefinch has already left https://bugs.launchpad.net/juju-core/+bug/1491592 | 21:19 |
| mup | Bug #1491592: local provider uses the wrong interface <customer-support> <local-provider> <networking> <juju-core:New> <https://launchpad.net/bugs/1491592> | 21:19 |
| mbruzek | It is a networking related problem with the local kvm provider | 21:20 |
| rogpeppe | wallyworld: i think you might have been involved in some of this code. perhaps you might want to review this fix? https://github.com/juju/utils/pull/148 | 21:58 |
| wallyworld | rogpeppe: sure thing, just have to finish a meting first | 21:59 |
| rogpeppe | wallyworld: thanks! | 22:00 |
| mup | Bug #1491608 opened: importing juju/utils should not side-effect http.DefaultTransport <juju-core:New> <https://launchpad.net/bugs/1491608> | 22:18 |
| alexisb | axw, I will be a few minutes late | 23:01 |
| axw | alexisb: np, ping when you're there please | 23:01 |
| alexisb | axw, I am on the hangout when you are ready | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!