[00:13] * thumper dogwalk [01:11] * perrito666 returns [01:20] ahasenack: thanks for the update on the bug... I was going to post something similar. Sorry for the initial misunderstanding. [01:33] wallyworld: sorry I missed standup, was in 1:1. FYI yesterday I put up a branch that adds scheduling/retries/status for filesystems in the storage provisioner; another branch with tests for retries/status; and then fixed that error reporting issue in maltese-falcon [01:34] axw: no worries, i'm currently reviewing some stuff on rb, will get to yours soon [01:34] wallyworld: thanks [01:37] axw: actually, i can't see yours, must have already landed? [01:37] wallyworld: RB hates me: https://github.com/juju/juju/pull/3177 [01:37] yay rb [01:43] thumper: I have a PR for the new juju/os package [01:43] i'm on call reviewer [01:44] which is a problem [01:44] do you want to take a look ? [01:49] thumper: https://github.com/juju/juju/pull/3193 [01:56] davechen1y: ack [02:38] cu all [02:38] bye perrito666 [02:59] davechen1y: it seems that while I've been reviewing this it has gone from diff version 1 to 4 [03:01] yes [03:01] git --force is magical [03:02] the delta between diffs is smal [03:02] just renamed a few imports from coreos to jujuos, 'cos we don't need the hassle [03:02] the key parts are version/ and juju/os/ [03:02] the rest are just mechanical translation [03:03] the rest are just mechanical translations [03:04] I saw the change [03:04] I actually recommended s/coreos/jujuos/g [03:04] just a few other questions and some comments, but pretty happy overall [03:08] cool, i'm just fixing a few tests that wont compile due to the move of the constants from version to juju/os [03:08] will push another proposal v soon [03:09] i'd like to try to get this landed today [03:09] so I can take a run at deleting version.Binary.OS [03:11] wallyworld: I'm going out for a while, school carnival [03:11] sure, have fun [03:11] axw: school carnivals r fun :) enjoy! [03:11] axw: especially if there is cotton candy... [03:18] thumper: thanks for the review [03:19] i've responded to all the points [03:19] PTAL [03:21] kk [03:23] thumper: http://reviews.vapour.ws/r/2559/ [03:23] just gave this the thumbs down [03:24] I said the same on the gitub review [03:24] bzzt [03:34] Bug #1491688 opened: all-machine logging stopped, x509: certificate signed by unknown authority

[03:40] ^^ that'll be ntp [03:59] davechen1y: ubuntu should have a feature that smacks you if you mess with the clock [04:03] menn0: does the db log pruner worker run for each environment? [04:15] anastasiamac: didn't see cotton candy, but they had a coffee van... very professional [04:16] axw: 2nd bets thing! [04:16] best [04:18] natefinch, fance a side bet that this was a MAAS install ? [04:35] cd .. [04:35] oops :) [04:35] heh [04:36] thumper: just checking who is watching :D [04:53] anastasiamac: least it wasn't your passwod [05:11] thumper: no it's a global thing [05:12] thumper: sorry didn't notice your msg [08:35] axw: if you have time, i finally got school pick up and dinner out the way http://reviews.vapour.ws/r/2573/ [08:36] wallyworld: sure [08:36] ta [08:52] wallyworld: done. one problem with clearing the UpdateStatusRequired field, but otherwise looking good [09:02] axw: i relied [09:03] replied [09:03] thnaks for looking [09:05] wallyworld: me too [09:06] axw: fair point, i'll tweak it [09:06] wallyworld: thanks [09:07] wallyworld: I'd just add a StatusVersion like ConfigVersion, should be straight forward [09:07] yup [09:08] need to help kid with homework, so might not do it immediately [09:08] nps [09:12] wallyworld, ping? [09:12] mattyw: hey [09:12] wallyworld, hey - so are you ok with runhook being left as is for now? [09:13] mattyw: yeah, the tests still bother me (started and installed inconsistent), but we can fix later [09:13] wallyworld, that's sort of the point, they're inconsistent because they're testing change [09:14] wallyworld, the other option is I could select on the hooks that would run if installed = true [09:14] mattyw: sur, but the reader will look and go "wtf" why is installed false when start is true [09:14] wallyworld, so I can try to catch all states - to make sure the output is always at least consistent in itself [09:14] but i agree it's not urgent before merging [09:15] if I get time today I'll make that change and ping you et al to take a look [09:15] mattyw: yeah, selecting is what i suggested, but i wouldn't hold up merging for it [09:15] wallyworld, in the meantime - bed time again [09:15] mattyw: of more importance - i think you assigned yourself to do some doc? [09:15] ttyl [09:16] wallyworld, I started a flowchart yeah [09:16] wallyworld, I need to put leadership etc on there [09:16] wallyworld, and it doesn't include the realtion hooks yet [09:16] wallyworld, but I think we'd agreed that it could happen after mergning [09:16] mattyw: people are whining there's been no sprint summary email. i told them we'd wait for doc and code to be done :-) neither is done yet [09:16] + [09:16] 1 [09:17] wallyworld, ok - I'll talk to casey tomorrow, we'll put together some press statement before we propose the branch :) [09:17] we can help too, maybe if a draft were done on google docs we could all hack on it [09:17] sounds great [09:18] wallyworld, nighty night [09:18] see ya [09:25] axw: actually, the watcher has to reset remotestate.updatestatus to false, otherwise when each snapshot is taken, it will remain true. it needs to go to true and straight back to false. a one shot trigger. if the resolver needs to ensure it acts on it, it can if it wishes record something in local state when the channel fires. [09:26] wallyworld: hence a version, something that only goes forwards [09:26] ok [09:27] seems "wrong" to call it a version when it's a trigger, but it will work [09:27] wallyworld: Snapshot() is meant to describe the goal state, and we should not be encoding the logic of ignoring state changes in the state watcher [09:27] it's not ignoring - the resolver will pick it up [09:28] whether it acts on it is still up to the resolver [09:28] but i'll change it to be consistent [09:31] wallyworld: it boils down to "UpdateStatusNeeded" not really being a goal state. the idea of having a version is to say that the local state is out of date if its version is less than that of the remote state's [09:31] yes, agreed. it's not a goal state, just an advisotry [09:31] advisory [09:31] wallyworld: so yes, the idea is to convert a trigger into something that is not a trigger, but a goal [09:31] wallyworld: and I'm saying that's up for the client to decide [09:32] i agree, just differ on the implementation. but it'scool, i'll change [12:50] dimitern: Good morning dimitern o/ [12:50] lazyPower, morning :) [12:51] dimitern: Can i call your attention to this bug briefly while its still fresh in my mind? https://bugs.launchpad.net/juju-core/+bug/1491592 [12:51] Bug #1491592: local provider uses the wrong interface

[12:51] lazyPower, sure, let me have a look [12:52] lazyPower, hmm so it's local + kvm? [12:52] yeah [12:53] I riffed briefly with nate yesterday about the referenced bug - where a fix was provided to filter lxc bridges, but that seems fairly brittle since we're growing our SDN providers, and most of them create bridge devices. This just happens to be the docker0 bridge thats causing the trouble this time :/ [12:55] lazyPower, well, we're only filtering whatever lxc_bridge is in agent config [12:55] lazyPower, I bet it's lxcbr0 or (for kvm) virbr0 [12:56] lazyPower, there's a potential workaround you could try [12:57] lazyPower, ignore-machine-addresses: true in environments.yaml (I'll double check the setting name) [12:58] morning all [12:59] lazyPower, that's it - is it possible to give that setting a try and re-bootstrap (or ask the customer)? [12:59] perrito666, o/ [12:59] dimitern: we sure can [13:01] Thanks for talking a look dimitern [13:01] lazyPower, no worries, I hope it might help [14:03] wwitzel3: standup [14:38] natefinch: bug 1486553 is now targetted for 1.25.0, so please do you work there first and forward-port to 1.26 [14:38] Bug #1486553: i/o timeout errors can cause non-atomic service deploys

[14:42] katco: ok, thanks [14:56] katco, alexisb: FYI, the cloudsigma provider is now no longer provisional in 1.25 (I'll forward-port shortly) [14:56] ericsnow: awesome! ty for picking that up. alexisb ^^^ [15:04] ty ericsnow ! [15:05] katco, alexisb: np :) === xwwt_ is now known as xwwt [15:41] ericsnow, wwitzel3: either of you want to trade 1:1 times with me? We have a guest coming to the house at 3, which is when my 1:1 is with katco. [15:41] natefinch: I can [15:41] ericsnow: cool, when's yours? [15:41] natefinch: 4 eastern [15:42] that's better than 3 for me... though earlier would be better. wwitzel3 - how about you? [15:43] natefinch: I'm in mine right now and it is over in 17 minutes [15:43] wwitzel3: haha ok [15:45] fwereade: ping [15:48] Bug #1415517 changed: juju bootstrap on armhf/keystone hangs

[15:59] katco: so, mind if ericsnow and I switch 1:1 times? [16:00] natefinch: ericsnow: not at all... sorry [16:00] katco: cool [16:01] natefinch: thanks [16:01] katco: ^^^ [16:01] ericsnow: any time ;) [16:02] I think katco should talk to ericsnow about natefinch and natefinch about ericsnow in that case [16:03] mgz: that's what we already do [16:03] :) [16:03] master is block btw, ftb on windows [16:09] Bug #1491923 opened: FTB on windows - ReadOSRelease undefined

[16:16] the windows-public-clouds branch has been rolled back one rev [16:20] voidspace, sorry, pong [16:21] fwereade: I think we're about to tear-down, I'll ping you tomorrow [16:22] voidspace, ok, cheers [17:09] fwereade: hiya === rogpeppe2 is now known as rogpeppe [17:10] rogpeppe, o/ [17:11] rogpeppe, am just off actually :( [17:11] fwereade: oh... [17:11] fwereade: just wanted to ask what "workloads" were in charms [17:11] fwereade: and chew the fat a bit :) [17:11] fwereade: perhaps you could tell me who knows about them [17:11] rogpeppe, can do the first: things like the bunch of docker conntainers you're running and want to surface to the admin [17:12] rogpeppe, katco knows all [17:12] fwereade: cool [17:12] fwereade: just wanted to make a slightly better doc comment than https://github.com/juju/charm/pull/150/files [17:12] rogpeppe: haha, yes [17:13] rogpeppe: so actually, i'm not sure if that code will stay in there. wwitzel3 ericsnow natefinch do you recall? [17:13] katco: it would be great if someone could add a decent explanation of what workloads are to the charm package [17:13] brb [17:15] wwitzel3: think you could take a look at rogpeppe's request ^^^ [17:15] wwitzel3: I'd be glad to as well [17:16] ericsnow: weren't we talking about moving that out of the charm repo. because we won't be in metadata.yaml any longer? [17:17] katco, ericsnow: that would be ideal from my pov [17:18] katco: we were deliberating; on the one hand workloads.yaml is a certainly charm-level concern, but on the other hand it isn't a fully realized part of all the charm machinery such that it *has* to be in the charm repo [17:18] rogpeppe: it was in there originally because we were adding to metadata.yaml; now we'll have a separate file: workloads.yaml, but there may still be a reason to keep it in there... remembering something about needing to load the workloads.yaml at the same time as metadata.yaml [17:18] ericsnow: ah ok. we need to make that decision soon [17:19] katco: conceptually I think it still belongs in the charm repo but we should come to a concensus with the GUI/eco teams [18:10] ericsnow: now that we don [18:10] ericsnow: don't have plugins... do we really need type-options? [18:10] ericsnow: seems like that feature was mostly to give plugins an escape hatch [18:11] natefinch: we still need it [18:12] natefinch: it's not about executable vs. lib plugin [18:12] natefinch: it's about generic options vs. technology-specific options [18:15] ericsnow: right, but if the types are all hard coded, any type-specific option could just be in the main struct, and ignored by the types that don't use it. [18:18] ericsnow: sorry, just thinking out loud. I think type-options is fine, just less important now that we know at compile-time what all the possible options are. [18:20] natefinch: I'm not sure that having a struct with *all* possible options supports maintainability well [18:21] ericsnow: one option I thought of was to let the plugin provide the value to be serialized/deserialized. Then a plugin that wanted to extend the base struct could embed it and add its own fields. But that's a significant change, and somewhat less straight forward than just having an extra "other stuff" map. [18:22] natefinch: keep in mind that the struct is effectively exposed to charmers so we want to keep the focus on the language we're effectively establishing for dealing with workloads in Juju [18:24] natefinch: what you are suggesting would make more sense if we had a separate type used internally from the one exposed to charmers (which I would consider overkill) [18:25] ericsnow: well, what's exposed to charmers is a yaml file, right? Certainly we'd want 95% of that to be the same for all workload types. So the question is how you support the other 5% [18:26] natefinch: yeah [18:26] natefinch: this is a discussion we had a while back and the type-options approach was the one we settled on [18:59] ericsnow: will be just a few mins late [18:59] katco: np [19:30] Bug #1492000 opened: mongo: testEnsureNumaCtl fails when $TMPDIR is set [21:26] mattyw: scheme seems to do only checking I need conversion [21:26] * perrito666 is really hoping for mattyw to correct him [21:32] perrito666, I think it does conversion as well [21:32] perrito666, that's what the coerce calls are for [21:42] mattyw: I have not looked in detail but it seems to do the convversion just as a way to check types [22:01] wallyworld_: could you take a quick look at my fix for #1491923? http://reviews.vapour.ws/r/2587/ [22:01] Bug #1491923: FTB on windows - ReadOSRelease undefined

[22:01] wallyworld_: I'm going to test it locally under windows too [22:01] sure [22:01] wallyworld_: thanks [22:11] ericsnow: i think it looks ok :-) [22:12] wallyworld_: I can't remember my admin PW for my Windows VM lol [22:12] ha [22:12] windozesux maybe? [22:13] wallyworld_: yeah, that was it [22:24] davecheney: so can you explain how i broke freebsd/arm? [22:26] oooh [22:26] ok nevermind [22:36] davecheney: https://go-review.googlesource.com/#/c/14280/1 take 2 [22:36] davecheney: can you test on freebsd or nacl or android or something? [23:08] wtf google signing me off [23:10] Bug #1492058 opened: Deploy CentOS images with Juju KVM provider [23:55] Bug #1492066 opened: cloud-init fails when deploying CentOS with Juju.