[00:00] did you initialize vault? [00:01] I ran into this when testing the new 20.05 stable bundle [00:01] there are 2 sets of instructions that I needed to get things moving forward [00:02] https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-vault.html [00:02] first initialize and install vault [00:02] https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-certificate-management.html [00:02] second retrieve and sign the csr [01:00] thumper: i give up, 2.7 landing is broken, here's a forward port of the 2.7 PR directly to 2.8-rc3 (with legacy lease stuff removed) https://github.com/juju/juju/pull/11641 [01:06] or hpidcock or kelvinliu ^^^^^ [01:06] kust got to get 2.8-rc unblocked [01:07] looking [01:10] approved since the original one has been approved already wallyworld [01:10] ty [01:11] nws [01:58] I'm receiving a "no matching agent binaries available" message when deploying a focal workload to AWS [02:04] juju version? [02:05] this is JAAS (2.6.10), client is Juju 2.8-rc2 [02:05] timClicks: jaas doesn't know about focal [02:05] that is 2.7 [02:05] wallyworld: where are we at with the landings? [02:06] gave up on 2.7 and forward ported the last PR directly to 2.8-rc, waiting for CI now [02:06] wallyworld: can I try to merge my 2.8 branch? [02:07] sure, i'm just landing a 2.8rc->2.8 port and then i was going to merge yours [02:07] all good, if you want to do the mergy thing then that's all good [02:08] i can [02:08] looks like I'll be helping with a customer issue [02:09] what juju version? [02:09] don't know yet [03:02] forward port to develop https://github.com/juju/juju/pull/11642 [03:03] hi Guys, [03:05] hpidcock: did you pick up the just landed pr from tim? [03:06] wallyworld: let me check [03:07] hpidcock: also, GetByHardwareAddress isn't used [03:07] i suspect it's been replaced by Filter whichis whwere the conflict was [03:10] GetByHardwareAddress was only added 10 days ago [03:14] hpidcock: ah, i suspect it's for the work to filter out machine local addresses, and there's a PR which will use it [03:15] wallyworld: yep, can always delete it later. I'd rather not break manadart's WIP if he has any using it [03:15] yup [03:18] hpidcock: the changes look as expected to me based on working with the other branches of late [03:19] wallyworld: awesome thanks, just waiting for a green run then I'll merge [03:19] i was 1/2 way thriugh doing it myself then i saw your pr :-) [03:19] wallyworld: ahah [03:20] was looking at the nic conflict [03:20] sorry [03:20] all good, you saved me a lot6 of typing [04:17] https://github.com/juju/juju/pull/11644 [04:18] the last of the uniter package level loggers [04:18] phew [04:25] wallyworld, hpidcock: GetByHardwareAddress was indeed a utility added for a patch in progress. [04:26] wallyworld: This is the fix for network_get and local-machine addresses: https://github.com/juju/juju/pull/11638 [04:26] Just have to put together some QA. [04:27] gr8 ty [04:29] tychicus: he got some handful of keys [04:29] i think he did [05:30] * thumper sighs [05:30] more problems [05:30] but yay, users?? [05:35] thumper: anything serious? [05:35] wallyworld: nothing blocking [05:35] but enough that we'll want to include a patch in 2.7.7 [05:35] got a bug? [05:36] https://bugs.launchpad.net/juju/+bug/1881242 [05:36] Bug #1881242: Missing error check results in panic - apiserver [05:36] the fix for this bug is trivial... add an error handling [05:36] the other problem, for which we are also getting a bug, is how did it get into this status [05:36] state [05:37] sigh [05:39] wallyworld: did you see my PR above? [05:40] wallyworld: nm, hpidcock reviewed it for me [05:40] thanks hpidcock [05:40] that's why i didn't look :-) [05:40] already +1 [05:41] hey... https://jenkins.juju.canonical.com/job/github-make-check-juju/5933/consoleText [05:42] look for "oops" [05:42] api/uniter fails [05:42] but I don't see a filure in the output? [05:45] thumper: might be teardown failure? [05:46] succeeds locally [05:46] and I only see 118 passed and 1 skipped [05:46] hpidcock: could be [05:50] wallyworld: I see the email you just forwarded to me [05:50] but I don't see the original [05:50] thumper: yeah, go figure, maybe the email lists are stuck [05:50] could be [06:34] wallyworld: you message to the list has come through now [06:35] so it has [09:00] hey, quick bit of help needed hopefully. i've got a controller running on lxd locally, but juju has somehow got the wrong idea about what its ip addresses are (maybe the container got restarted?). how can I get it to learn the right ones? [09:15] (made a topic on discourse) [09:17] Laney: you can point the cli to the right IP by editing the endpoint values in ~/.local/share/juju/controllers.yaml for your controller (as always backup first before editing ;-) [09:18] achilleasa: wtf, that has the right addresses in it [09:18] uh [09:18] there's some duplication here, how did that happen [09:20] Laney: you mean you have the same IP twice in the endpoint list? Not sure how that could happen but it should not have any impact in connection attempts [09:20] no I had the same controller in there twice, once right and once wrong [09:20] but deleted the wrong one now and 'juju status' works again [09:21] 'juju ssh' doesn't though, it seems to be trying to connect to my public IP instead of the container's IP ... [09:24] works with --proxy but not without [11:39] manadart: can you take a look at https://github.com/juju/juju/pull/11645? [11:45] achilleasa: Approved it. [12:04] manadart: do we rewrite the agent config files when upgrading? [12:05] achilleasa: Yes, we have to in order to set the version. [12:14] hi [19:14] with the nova-cloud-controller charm, is there bit of additional config that needs to be performed to get console-access-protocol to use TLS? [19:15] I ensured that the vault relation is there juju add-relation nova-cloud-controller:certificates vault:certificates [19:17] but openssl s_client -connect shows that TLS is not enabled [19:18] If I switch from https to http the page renders with an error "Something went wrong, connection is closed " [19:19] tychicus, are you talking about the dashboard? [19:20] yes, the console in the dashboard [19:20] dashboard loads with https no problem [19:22] in previous releases to enable ssl you had to supply a console-ssl-cert to nova-cloud-controller [19:23] but console-ssl-cert was removed in the 19.07 charm release [19:24] Please use ssl_cert configuration option or the vault certificates relation [19:25] tychicus, where do you see that? [19:26] https://jaas.ai/nova-cloud-controller/345#charm-config-console-ssl-cert [19:33] tychicus, thanks [19:34] pmatulis: np, just trying to figure out if I missed something trivial in my config [19:35] tychicus, what about the value of 'console-access-protocol'? [19:35] pmatulis: uju config nova-cloud-controller console-access-protocol=novnc [19:36] s /uju/juju [19:36] tychicus, k [19:37] tychicus, well, based on what you've said you've done and based on the documentation it should work. can you open a bug on nova-cloud-controller? [19:37] sure [20:31] tychicus, did you try logging out and back in to the dashboard after having made that config change (to 'novnc')? [20:32] I did [20:33] k [20:34] well, like i recommend: https://bugs.launchpad.net/charm-nova-cloud-controller/+filebug [20:34] I'm working on the bug report now, but I need to do a little more digging [20:35] it looks like novnc is not proxied by apache, all of the stuff proxied by apache is fine [21:13] looks like the issue is that there is an issue with the nova.console.websocketproxy