[00:04] Bug #1346597 opened: cannot get replset config: not authorized for query on local.system.replset

[00:04] Bug #1575895 opened: juju loses apt-http/s-proxy information if a model is deleted and a new one created

[00:20] axw mostly just a question, when I `juju add-model --region us-east-1 foo` from a controller boostrapped in `us-west-1`, does anything actually happen in `us-east-1`? or is that all stored on the controller and nothing happens in us-east-1 until I `juju deploy something`? [00:21] axw: I was under the impression from my convo with wallyworld that I should see something come up when I add a model to another region, but it makes sense that it wouldn't, too. [00:34] axw: rubber stamp pls http://reviews.vapour.ws/r/5467/ [00:36] menn0, axw, wallyworld: thoughts ? http://reviews.vapour.ws/r/5468/ [00:37] output looks nice [00:38] thumper: +1 the output and args are nice [00:44] thumper: ship it [00:48] redir: atm, nothing happens. we may change it soon so that the model's security group gets created when you add the model [01:01] axw tx [01:16] gtg. Until tomorrow, #juju-dev [01:26] cmars: yo [01:27] cmars: you and roger really need to talk more, or you need to read his email :-D [02:03] axw or anyone else.... trying to run juju on windows, but it seems to die mysteriously right away? http://pastebin.ubuntu.com/23066001/ [02:03] natefinch: probably https://bugs.launchpad.net/juju-core/+bug/1612836 [02:03] Bug #1612836: Cannot bring up hosted model machines in azure

[02:04] natefinch: one mo, I have a small patch you can apply to test [02:04] natefinch: http://paste.ubuntu.com/23066004/ [02:06] axw: will give it a go [02:06] axw: thanks [02:33] natefinch: if you have a moment to review, the fix is in a PR now: http://reviews.vapour.ws/r/5469/ [02:33] axw: sure [02:39] axw: doh - axw/juju-tools/main.go:45: cannot use buildToolsCommand literal (type *buildToolsCommand) as type modelcmd.ModelCommand [02:39] axw: bah,. it's because gnuflag moved [02:39] natefinch: ah, I'll update it in a moment [02:41] natefinch: pushed [02:43] axw: cool [02:43] I really love that go install has no middle man between git push and me getting and installing the code. [02:44] like, no npm repository to update or anything. Just get the code from git and build it. [02:46] I wish kill controller had a --jfdi that would just kill the machines via the provider... waiting for azure to nicely close everything down is so slow... [02:46] Bug #1614329 opened: Cannot deploy charm to new lxd container on machine: permissions error

[02:46] Bug #1614330 opened: agree command uses 'less' for a pager, fails on windows

[02:54] natefinch: I often just "azure group delete -q --nowait", then "juju unregister -y " [02:58] axw: nice [02:59] natefinch: groups are quite neat - only one thing to delete, and your model or controller is cleaned out [03:00] the time they take to delete is just a bit painful [03:04] pretty awesome suffix git put on commit 0806e96e6e79b530161cbb40f54bd8b338e0bad1 [03:06] axw: where will I find the code that stores storage-pool settings? [03:10] think I've found it [03:12] thumper: sorry went afk, sorted? [03:12] yeah [03:15] wallyworld: if we start making API calls in list-controllers, then one bad controller is going to hang the whole command. can we isolate the access to show-controller at least? [03:16] that becomes rather inconvenient for a user to see at a glance what they have access to [03:16] but you are right about a bad controller [03:17] maybe it has to be show controller [03:37] axw: will there ever be storage pools for pools that aren't defined on volumes or filesystems? [03:38] thumper: non capisco. do you mean "will there ever be storage pools that aren't referred to by volumes or filesystems"? [03:38] kinda [03:39] will there be pool settings for pools not currently refered to [03:39] thumper: if so, yes. e.g. when you bootstrap ec2, you get a storage pool out of the box called "ebs-ssd" [03:39] how do I know all the pool names? [03:39] thumper: storage/poolmanager.PoolManager.List [03:40] name is part of the config returned [03:40] actually, I could just iterate through all settings looking for "pool#" prefix [03:41] I have all the settings read [03:41] or that [03:41] perhaps that :) [03:46] Bug #1614345 opened: add-subnet subcommand references absent create-subnet command

[04:16] axw: i did it for show controllers, but also added a tabular option to show controllers to make the output nice if needed [04:17] wallyworld: sounds good [04:17] i'll now move on to list-models and list-users [04:23] wallyworld: re: --build-agent, can it use just a binary in path (i.e. for jujud) or does it need to build from source? [04:24] veebers: it uses a binary in the path if build-agent is not specified [04:24] build-agent means build [04:26] wallyworld: hmm ok. Is it still possible to pass something in to upgrade-juju to get the build number bumped (as I was trying with --upload-tools). Does that require --build-agent? [04:26] no need, the build number is bumped regardless [04:28] wallyworld: ok cool, thanks :-) [04:28] if you find an issue, let me know [04:28] will do :-) [04:39] menn0: http://reviews.vapour.ws/r/5472/ [04:39] thumper: about to do a kid pickup. will review after. [04:40] np [04:49] Bug #1614364 opened: manual provider lxc units are behind NAT, fail by default

[04:51] wallyworld: I have reviewed http://reviews.vapour.ws/r/5471/, would appreciate if you would also take a look later, after anastasiamac has responded to comments [04:52] axw: np, just popping out to get kid from camp, bbiab [04:52] wallyworld: there's lots of changes, but there's a bunch of discrete changes in separate commits on github [04:52] thanks, later [05:19] Bug #1604474 changed: Juju 2.0-beta12 userdata execution fails on Windows

[05:20] axw: hmm... part of the reason of using the database implementation to get at the storage pools is that is exactly what the migration import and export code does, it does low level database stuff, which is why the entire setting collection is read at once [05:20] all the migration code has deep knowledge of implementation details [05:20] that is how it works [05:21] I'm happy enough changing the core description definition [05:21] thumper: I guess that's fine, changing core description would be enough then [05:21] to make it slightly less hacky [05:21] thumper: though I thought importing didn't involve inserting docs? [05:21] thumper: but using AddMachine, etc. [05:21] haha, no [05:21] no? [05:21] ok [05:21] not at all [05:22] much hacky doc op foo [05:22] fu [05:22] thumper: yeah that wouldn't work, not sure what I was thinking :) very well then [05:22] most of the AddMachine etc high level function try to apply checks we don't want [05:22] * axw nods [05:22] Bug #1604474 opened: Juju 2.0-beta12 userdata execution fails on Windows

[05:23] I'll tweak the description :) [05:23] hmm.. why has review board stopped updating with some changes? [05:24] https://github.com/juju/juju/pull/6025 [05:24] phew... romulas command branch finally landed [05:25] weird, because it found http://reviews.vapour.ws/r/5474/ [05:28] Bug #1604474 changed: Juju 2.0-beta12 userdata execution fails on Windows

[05:37] thumper: ship it on the loggo one [05:37] menn0: I'm just updating the storage pools [05:37] which loggo one? [05:37] thumper: the small one which changes the default writer [05:37] the cmd one? [05:38] I see it :) [05:38] I hope it lands due to deps [05:38] if not, I'll poke veebers :) [05:39] menn0: https://github.com/juju/juju/pull/6025 [05:40] thumper: RB now working? [05:40] menn0: didn't pick up that one [05:40] no idea why [05:43] thumper: LGTM, with one query [05:44] * menn0 wants this stuff to land so he can see what it looks like [05:44] menn0: it is different due to loggo.Level vs. string key [05:44] debug-log sends but string representations of the level [05:44] thumper: ah right. makes sense. [05:44] thumper: all good. [05:45] thumper: Hey I'm about to EOD, did you want me to take a look at something? [05:45] perhaps [05:45] gimmie two ticks [05:46] veebers: nope, all good [05:46] thumper: sweet :-) [05:56] thumper: VALIDATION phase done... pushing now [05:56] sweet [06:08] heh [06:08] hmm [06:08] I have two branches [06:08] and was getting confused [06:08] color-debug-log [06:08] and debug-log-color [06:08] was editing wrong one [06:10] Hi folks; anyone know if there has ever been any attempt to deploy juju environments in a fully disconnected environment? i.e. no streams available, no charm store, no external repos [06:13] not something I do personally [06:13] blahdeblah: some of the folk with orange boxes do I think [06:13] thumper: OK, interesting; any suggestion who to talk to? [06:14] try scott [06:14] * thumper looks for nick [06:14] txspud [06:14] Scott Croft [06:14] I think he has [06:21] thanks thumper === akhavr1 is now known as akhavr === frankban|afk is now known as frankban [09:07] frobware: ping [09:07] voidspace: hi [09:07] frobware: hey, hi [09:08] frobware: I'm looking at a 1.25 port of the fix for bug 1602716 [09:08] Bug #1602716: MAAS provider bridge script doesn't handle alias interfaces IP <2.0>

[09:08] frobware: even with the new code in place, 1.25 doesn't bridge the alias [09:08] frobware: is this because 1.25 does a lot less bridging than 2.0? [09:08] voidspace: yes [09:09] voidspace: we only brindge the default route [09:09] frobware: so I'll leave the code in place, but mark the specific bug as wontfix for 1.25 (again) [09:09] voidspace: is there harm it being there? in general I think the bridge script should be identical between 1.25 and 2.0 [09:10] frobware: I've put the code in there - but there was a card to handle it linked to the LP bug [09:10] frobware: so I'm landing the code but it doesn't actually fix the bug... I was just checking this was expected. [09:11] frobware: which you've confirmed. So thanks. [09:11] voidspace: this is not expected. why doesn't it fix the bug? [09:11] frobware: on 1.25 it doesn't fix the bug because we don't bridge the alias (which was the bug) [09:11] frobware: surely? [09:12] voidspace: hmm. can you create an alias for the default route (MAAS UI) and validate that we bridge the alias [09:13] voidspace: you'll need an alias for this to make sense [09:14] voidspace: I have an alias for eth0, eth0 is bridged but eth0:1 isn't - as expected [09:14] frobware: I have an alias for eth0, eth0 is bridged but eth0:1 isn't - as expected [09:14] frobware: if I now disable eth0 should that make the alias the default route, or should I do something else? [09:16] voidspace: can you PB your original ENI [09:17] frobware: http://pastebin.ubuntu.com/23066815/ [09:18] frobware: that's before and after [09:19] frobware: the gateway is specified on the bond, should I create an alias for that? [09:20] voidspace: looking at the PB [09:21] re-bootstrapping with an alias to the bond as well and grabbing coffee [09:23] voidspace: the script seems broken [09:25] voidspace: I take that back. apologies. [09:26] voidspace: you can do this without rebooting - just run the script on the original eni, observing the output depending on what you pass to --interface-to-bridge [09:29] frobware: so what should I test for 1.25? [09:29] voidspace: still looking and understanding... [09:29] frobware: ok [09:29] voidspace: do you have an ENI where bond0 has an alias? [09:29] frobware: this is the branch https://github.com/juju/juju/pull/6013 [09:30] frobware: I just did that - bond0 is still active though [09:30] frobware: juju-br0 is created but the bond alias is left in place, no additional bridge is created [09:31] frobware: if we only bridge the interface with the gateway (which I assume is the default route) then that is still expected I think [09:32] voidspace: if you're running the script by hand, you can ignore the gateway bit. the arguments --interface-to-bridge and --bridge-name control what gets bridged [09:32] voidspace: on 2.0 we don't use those arguments so everything (appropriate) gets bridged [09:34] frobware: so it won't fix the specific bug for 1.25 (unless the alias is the default route) but it's nice to have the code the same in both 1.25 / 2.0 for maintenance [09:35] voidspace: yes, for the latter. but you can have an alias so we should check what it would do [09:35] voidspace: just a little confused about what its doing for the 2.0 case atm [09:35] frobware: ok [09:36] frobware: dimitern and I have both tested this branch with deploys and it seems to work fine [09:36] frobware: http://reviews.vapour.ws/r/5460/ [09:36] voidspace: deploys that involve an alias on 1.25? [09:36] frobware: you can see what dimitern used in his comment on the review [09:37] voidspace: and an alias on the interface that is the default route? [09:37] I'm just looking now [09:37] ah no, not an alias [09:37] frobware: no aliases [09:37] voidspace: isn't that a different PR? [09:37] is it broken with them? [09:38] voidspace: that PR is about the MTU [09:38] frobware: yeah, but I rolled the code into that [09:38] frobware: so no, that's the right PR [09:38] ??? [09:38] why [09:38] frobware: I did one PR with all the new code [09:38] voidspace: why not separate PRs? [09:39] voidspace: that makes no sense to me. if we ever had to revert the MTU for example we just added/created more work [09:39] frobware: because the patches didn't apply cleanly - so it would have been a lot more work to do as separate patches [09:39] voidspace: why not separate patches? [09:39] frobware: we created "possibly more work" - doing them separately now would be "definitely more work" [09:39] voidspace: disagree. we should do discrete things. [09:39] frobware: because the patches don't apply cleanly as separate patches [09:40] voidspace: but we can fix the patches per PR [09:41] frobware: I understand your disagreement. This patch is really "bring 1.25 up to using the same code for bridging as 2.0" which is a discrete thing. [09:41] voidspace: fwiw, I think this is the wrong approach. patches should be discrete so that they can be reverted if necessary. seems like we have conflated things. [09:42] frobware: I understand and I don't think it is worth the extra effort. If this patch introduces regressions it can be reverted. [10:05] voidspace: so i think the script is broken for the single use case, where single use means we explicitly pass the interface name to be bridged [10:05] * frobware was trying to look at yakkety... and wonders how much more of this fun and games is to come in netplan [10:18] voidspace, dimitern: https://bugs.launchpad.net/juju-core/+bug/1614471 [10:18] Bug #1614471: MAAS bridge script doesn't bridge aliases correctly where --interface-to-bridge is specified [10:19] frobware: ok [10:19] frobware: what do you think the right fix is for 1.25, or will that need some thinking about? [10:20] voidspace: just going to try it [10:20] voidspace: not a fix, just to understand the current behaviour [10:20] frobware: I can look at breaking the patch into pieces and talk to Rick about it. I have a critical bug I'm assigned to in the meantime (although that should be easy). [10:20] frobware: sure [10:21] voidspace: take a look at the critical patch - was going to try the alias stuff [10:21] frobware: I can't create an alias that is the default route on my maas setup, but it can be done by directly calling the script [10:21] voidspace: even if that means I'm just doing some additional QA [10:21] frobware: ok [10:22] voidspace: I'm wondering if the alias stuff would have worked if we had landed 395cd8d812c004e8c9a8783c47fcfc22ded9de2e some time earlier. [10:23] voidspace: or more conveniently https://github.com/juju/juju/pull/5792 [10:23] axw: could you please take a look at http://reviews.vapour.ws/r/5475/ ? [10:29] My ssd died. :( [10:32] Bug #1614471 opened: MAAS bridge script doesn't bridge aliases correctly where --interface-to-bridge is specified [10:48] dimitern, voidspace, frobware: my ssd died. Setting up on a loaner machine now (my ansible script has mostly worked!). [11:02] * dimitern is back; catching up [11:08] babbageclunk: oh bugger :/ any notable losses? [11:09] babbageclunk: :-( but glad you're getting set back up [11:09] frobware: re bug 1614471 [11:09] Bug #1614471: MAAS bridge script doesn't bridge aliases correctly where --interface-to-bridge is specified [11:09] frobware: I'm not sure we should create juju-br0:1 in that case [11:10] dimitern: because? [11:10] frobware: how will that be useful? [11:11] frobware: juju-br0 will work with its primary IP coming from eth0, which will be on the default route as well [11:11] dimitern: so... this is what I'm trying to understand. why was it broken and would the presence of an auto stanza have fixed the initial bug report [11:11] frobware: eth0:1 will also work, if you need for some reason not to go through juju-br0 [11:12] or perhaps it won't actually.. [11:12] * dimitern gives it a quick test [11:24] dimitern: Lost a couple of days work. :( Really wish I'd pushed yesterday afternoon. [11:25] babbageclunk: oh man :( sorry! [11:25] yeah, pushing at EOD is a good rule of thumb [11:26] frobware: so if we're bridging aliases as well, what happens if the alias is on a different subnet? [11:26] frobware: that would imply a separate bridge, not just moving the alias address over to the bridge [11:30] so, I am without power where I'm staying, and am rather stuck with cafes if I want internet [11:33] I'll be catching up on mail and reviews and stuff while I'm here, but if anyone wants my advice/company/whatever, they should talk to me while I'm here [11:44] fwereade: are you in the uk? [12:02] dimitern, yeah [12:02] fwereade: so brexit reached the power companies? :) [12:03] dimitern, haha [12:03] dimitern, not yet, that I'm aware of ;p [12:03] fwereade: ;) too early [12:03] dimitern, trouble in the building, people are working on it [12:04] fwereade: is your bandwidth wide enough for a HO, if you have some time as well? [12:04] dimitern, HO probably not great, there's background noise [12:04] fwereade: I'd like to chat about the ipam story and how it fits in core [12:05] fwereade: right, ok - irc then :) [12:26] frobware: I think you're right - with auto the interface would have come up and the fact that it wasn't bridged would only have mattered for containers [12:26] frobware: so for 1.25 just ensuring the auto is there is enough [12:27] frobware: *unless* it's an ipv6 specific thing [12:27] frobware: can you effectively have two default routes, one for ipv6 and one for ipv4? [12:27] frobware: the alias in the original bug report was ipv6 [12:38] frobware, voidspace: I've tested with eth0 bridged to juju-br0 and eth0:1 not, deployed 3 lxc containers - works fine [12:42] frobware: ah no, in the original bug report the alias does have auto in the generated /e/n/i [12:42] dimitern: cool [12:43] voidspace: yeah, I don't know how ipv6 creeped into that [12:48] voidspace: I think you raise a good point about containers - should aliases be bridged for containers? [12:48] dimitern: ^^ [12:49] voidspace, dimitern: can we HO re: aliases? [12:49] frobware: ok with me [12:50] frobware: in 1.25 we only alias the default route, we don't provide multi-nic support - which probably means no ipv6 support if that's on a separate interface/alias [12:50] frobware: sure [12:50] frobware: which is probably fine as we're doing it in 2.0 [12:50] frobware: HO channel? [12:50] voidspace: standup [12:51] kk [12:51] omw [12:52] me2 [12:58] mgz: ping? [12:58] mgz: ping [12:58] voidspace: dibs [12:58] mgz: do you still want a review from me? you were going to create some PRs [12:59] fwereade, ping [13:00] babbageclunk: haha, good luck with that... [13:00] niedbalski, pong [13:00] niedbalski, what can I do for you? [13:00] voidspace: I'm pretty sure etiquette dictates that he talk to me first. [13:01] babbageclunk: yo [13:01] voidspace: alyo [13:02] fwereade, hey William :) , Could you check this https://pastebin.canonical.com/163030/? this is preventing to start the units. I think is related to LP: #1534103 [13:02] Bug #1534103: "unknown operation kind run-action" (1.26alpha3) <2.0-count>

[13:02] mgz: Hey, the mgo fix is in upstream, so we no longer need to apply the nasty patch in our build. [13:02] fwereade, here is the current action list on the database (I've a full mongo dump) http://pastebin.ubuntu.com/23067364/ [13:02] mgz: If I land a change to remove the .diff file, juju/juju/patches is probably going to disappear (since there's nothing else in it). [13:03] niedbalski, that just looks like... utterly broken uniter code [13:03] mgz: Is that going to break your script that applies the patch? [13:03] niedbalski, looking further [13:04] mgz: Or, I could leave a readme file in patches to keep the dir alive in the repo. Would your script cope with that? [13:05] babbageclunk: a readme sounds good to me [13:07] babbageclunk: it does not at present but that should change I think [13:08] voidspace: I shall link you my prs, onesec [13:08] mgz: cool, thanks [13:08] mgz: I guess the alternative is a null patch, but if you're happy to change the script that's probably less obtuse. [13:08] babbageclunk: pthbthpthbthpt [13:08] babbageclunk: so, options, delete the dir, add note to general hacking docs somewhere [13:08] babbageclunk: or add dummy file for git in patches dir, make sure that lands after I update the script [13:08] voidspace: don't care, he responded to me first. I'll allow multiplexing. [13:09] babbageclunk: I refer the honourable gentleman to my previous comment (pthbthpthbthpt) [13:09] voidspace: https://code.launchpad.net/~gz/juju-ci-tools/jujupy_ssh_keys [13:09] voidspace: https://code.launchpad.net/~gz/juju-ci-tools/assess_ssh_keys [13:09] mgz: looking [13:10] voidspace: I'll bug a qa guy as well, so don't worry too much about juju-ci-tools specifics, but feedback on approach/code welcome [13:10] niedbalski, and, yeah, that bug looks like completely broken uniter code as well [13:10]