[00:00] that's a stock juju bug [00:01] wallyworld: ha, i clunged to "remote" :) [00:01] :-) [00:57] wallyworld: do u recall if interactive bootstrap should work with builtin or personal clouds as well? I thought there was a limitation where we supported public clouds only... [00:57] hmmm, not sure [00:58] i didn't know of such a limitation [00:58] wallyworld: well, considering it doesn't work right now, we probably have a bug [00:59] could be, the work was sort of half finished [00:59] wallyworld: i mean it works with both public and personal but not builtin.. i *think* i know where the problem is... will propose soon... [01:06] anastasiamac: wallyworld yea the rest of interactive bootstrap was meant to tie into the add-cloud work [01:06] The next step was to tie add-credential to the end of add-cloud and then update bootstrap to tie into add-cloud [01:07] one day..... [01:08] Best laid plans... [01:22] wallyworld: quick review? https://github.com/juju/juju/pull/7037 [01:22] sure [01:23] wallyworld: thanks [01:24] lgtm [01:28] wallyworld: cool cool [02:32] Bug #1667419 changed: Juju 1.25.10 non-HA cpu/ram usage spike (can't apply changes to env)

[02:41] Bug #1663633 changed: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure [02:50] Bug #1663633 opened: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure [02:51] thumper: no joy replicating with juju 1.25.6 and mongo 2.4 [02:59] Bug #1663633 changed: Juju 1.25.10: Conversation scope is missing sometimes - causes relation hook failure [03:03] menn0: hmm... [03:04] thumper: yes? [03:04] menn0: more the no joy [03:04] thumper: I've been poking at it a bit more but I'm not seeing the problem [03:04] not an interested hmm [03:04] yeha [03:04] yeah [03:04] it sucks [03:16] menn0: thumper: is it possible that there was no env-uuid when the charm was deployed? so when it was upgraded, some transacations got *lost*? since there was no envuuid we could group them by?... [03:16] no, there was clearly an env-uuid [03:17] anastasiamac: I don't *think* so. transactions aren't being lost, just the txn-revno field [03:33] menn0: joining us? === jam1 is now known as jam [04:10] anastasiamac: Could you review https://github.com/juju/juju/pull/7038 plz? [04:11] axw: PTAL https://github.com/juju/juju/pull/7039 [04:11] babbageclunk: sure \o/ [04:11] babbageclunk: or we can swap :D and u could PTAL mine too... [04:13] babbageclunk: u make me swoon - u even updated a bug \o/ [04:13] anastasiamac: I'm looking at yours now! [04:15] anastasiamac: reviewed [04:15] babbageclunk: axwawesome \o/ [04:15] * babbageclunk is too slow [04:17] veebers: to run CI, do I still need an environments.yaml for juju 2.x? seems like it, just wondering if I'm missing something [04:18] babbageclunk: u could break a tie - do u think that the method name should b the same as the other pkg but with different behavior... m not fussed either way :) [04:19] anastasiamac: I see where you're coming from, but the "Any" qualifier is pretty meaningless. If it were meaningful I'd have no problem with it [04:20] axw this is with a juju-ci-tools test? [04:20] veebers: yup [04:20] axw: yeah you'll want to use cloud city and set JUJU_HOME to it's path [04:22] veebers: ok, thanks. seems unnecessary [04:23] axw it's how we enable being able to test 1.25.* and 2.* across any cloud using the same test code [04:23] (it's grown out from testing just 1.25 and evolved from there) [04:25] anastasiamac: I think I'm with axw - the Any- prefix suggests some randomness or nondeterminism to me. CloudByName is better in this case. [04:27] axw: is there (good) docs re: the difference between storage-unit, volume and filesystem? [04:28] babbageclunk: where is our new proxy funcs? [04:31] thumper: where is your new proxy funcs more like [04:31] uh, I mean it lives in juju/juju/utils/proxy [04:33] thumper: with stuff to update the settings in proxyupdater and installing it as the default proxy in juju/juju/cmd/jujud/main.go [04:33] looking at utils/proxy stuff now [04:33] thumper: not juju/utils/proxy though. [04:34] right [04:34] thumper: I have seen some complaining about juju/juju/utils/proxy vs juju/utils/proxy and I am not unsympathetic to those complaints. [04:35] babbageclunk: is there a reason we aren't moving one to the other [04:35] ? [04:36] thumper: It didn't occur to me - it seems like the j/j/u/p stuff is specific to juju, while the j/u/p bit isn't? But maybe I should have just put everything in j/u/p? [04:37] * thumper shrugs... [04:41] veebers: sorry was afk. I don't think so [04:42] axw: nw, are you able to one-liner the difference? You did mention yesterday but obviously it didn't gel for me :-( [04:45] veebers: storage-instance is an instance of a charm-declared store. a volume is just a disk/logical volume, and a filesystem is... a filesystem. a storage instance will have an associated volume and/or a filesystem [04:45] veebers: so a storage instance is the association between a volume/filesystem and an unit (or application, when we have shared storage) [04:48] axw: ack, thanks :-) [06:15] axw: PR for auth type in add credential: https://github.com/juju/juju/pull/7040 PTAL :D [06:20] anastasiamac: I think we should probably call cloud.CredentialSchema.Finalize on the input? there are other things in there that we should validate too [06:21] anastasiamac: Finalize will interpret the file attrs and replace them tho, so don't want that bit... [06:21] axw: oooh. k. did not know wbaout that :) i'll check after school pickup :D tyvm! [06:21] anastasiamac: maybe introduce a Validate method to CredentialSchema, which does what Finalize does from Coerce up [06:22] axw: that'd b neat coz it'll answer validation in other places too! great idea. i'll look into it further [09:23] axw: any chance you could review https://github.com/juju/juju/pull/7034 [09:23] jam: looking [09:24] its not particularly small [09:52] jam: if I have subnet 10.0.0.0/8, can I have a static route for source=10.0.0.0/16? [09:52] jam: in MAAS I mean [09:53] jam: just wondering about the bit that looks up static routes based on the interface's subnet CIDR [09:53] axw: I believe so. [09:53] axw: that's actually how ante-et-al are using it [09:53] ceph-data is the 10.100.0.0/16 group of subnets [09:53] and each rack gets, say 10.100.1.0/24 [09:54] and has a static route that says [09:54] "for anything in 10.100.0.0/16 use 10.100.1.1" [09:55] jam: so how does this work then? https://github.com/juju/juju/pull/7034/files#diff-e48e1166d15f27c5c7356ca4ee7000c0R282 [09:56] axw: so a given device will be in a registered subnet, which may have static routes pointing at other listed subnets [09:56] but there isn't anything that says subnets don't overlap [09:56] axw: https://github.com/juju/juju/pull/7034/files#diff-9f2d224cfe3d5b5450772b51d95b625aR2176 is where we build up the map by listing all of the register static routes [09:57] each one has a "Source" subnet that states where it should apply [09:58] jam: but won't that end up with a key of 10.100.0.0/16, and the NIC is in subnet 10.100.0.0/24? [09:58] axw: so that's not how it works. In the config for Subnet 10.100.0.0/24 you set a destination of 10.100.0.0/16 [09:59] and a magic gateway [09:59] axw: you always exactly match a 'local' subnet in the config [09:59] axw: IOW, you can't say "all machines in 10.100.0.0/16 use gateway 10.100.1.1" because not all of them have direct routes *to* that machine [09:59] so *each* /24 subnet needs to be told the preferred (generally the local) gateway to get to the rest of /16 [09:59] axw: does that make sense? [10:00] 10.100.1.0/24 probably points to 10.100.1.1, 10.100.2.0/24 points to 10.100.2.1, etc. [10:00] jam: it makes sense, but that seems to be the opposite of jam: if I have subnet 10.0.0.0/8, can I have a static route for source=10.0.0.0/16? [10:01] jam: so multiple static routes: one per source subnet, each going to the same destination CIDR but via different gateways [10:01] axw: if you want to *reach* 10.0.0.0/8 you can create a static route with source=10.0.0.0/16 [10:01] destination=10.0.0.0/8 but the gateway IP needs to be in your source range (I believe) [10:02] jam: sorry, I had that back to front :) [10:02] ok, all good [10:02] source is 'who I am' and destination is "who I want to talk to" and gateway "who do I send my letter to that will deliver it" [10:03] yeah, I just had my CIDRs back to front in my question [10:05] axw: if you can think of ways that I can document things to make it easier to pick up. I did add comments to network.Route https://github.com/juju/juju/pull/7034/files#diff-24ce41f044a5d947051b85bb10734d91R264 [10:05] but if I can tweak that to make it more understandable, I'm certainly willing to. [10:06] jam: it's pretty clear. I think it might be helpful to add a comment that for the static routes coming back from MAAS, source is expected to exactly match the subnet on the device [10:50] axw: thanks for the review [10:50] np === tinwood is now known as tinwood_swap === gsamfira_ is now known as gsamfira [20:28] babbageclunk: ping-a-ling https://hangouts.google.com/hangouts/_/canonical.com/websocket-mania [20:28] babbageclunk: can you join us please [20:28] ? [20:28] thumper: sure [20:30] sinzui: thanks for pushing up a new bug [20:30] It seems the MAAS 2.0 *docs* say it supports an API that isn't actually there. [20:30] jam: oops [20:31] sinzui: oddly enough axw caught that I would have treated static-routes missing as being ok, and thought it would be poor to suppress the error [20:31] sinzui: seems I was right to be paranoid the first time. [20:32] sinzui: btw, I hopefully stopped my merge of 2.1 into develop cleanly, but I haven't clicked the "X" very often in case anything bad happens when you do it [20:40] sinzui: I'd like to add a targetted error trap for that error, is it possible to get access to the 2.0 MAAS so I can confirm the error code, etc? [20:51] jam: I will send you the ssh info. You may already have info for finfolk. but I have additional for the maas 2.0 itself [20:54] sinzui: thx [20:54] sinzui: I don't think I need to actually start anything, I just want to track the error messages, etc. [20:54] redir: ping [20:55] redir: Looking at your libvirt changes for KVM containers, it looks like we are trying to set guest device names for network interfaces. Did you see that actually working? Because my quick Xenial + Juju 2.2 test doesn't show it working. [20:57] redir: is there some place we can see the XML that was used to launch the container? [21:13] sinzui: I need to go to sleep (1am here). Any chance you could check if https://github.com/juju/juju/pull/7045 fixes this? [21:13] I think it will, but I don't really want to land it without testing it. [21:14] jam: I will follow the merrge [21:14] jam: are you ok with me merging 2.1 into develop now? [21:15] jam: or have you got something in flight that you want to include? [21:15] babbageclunk: actually its something we don't want to merge. [21:15] babbageclunk: my latest patch has a regression against maas 2.0. The above patch should fix that regression and then we'd be good to merge up. [21:16] babbageclunk: there is also a conflict in dependencies.tsv because of different gomaasapi versions, use the one in 2.1 [21:16] * jam sleeps [21:16] jam: yeah, I guessed that one - was going to check on the commit to be sure. So, I should hold off until 7045 lands? [21:17] babbageclunk: I'll merge up once 7045 lands, but if curtis approve it and it lands while I'm asleep, you're welcome to merge up [21:21] jam, ok cool - night! [22:02] jam pong HO? [22:02] do misse dyou [22:02] we cna HO tomorrow jam [23:18] easy review: https://github.com/juju/juju/pull/7035 [23:18] PTAL [23:23] * anastasiamac looking [23:36] tx anastasiamac