[00:53] hello everyone, do anyone know how to enable `externalTrafficPolicy: Local` on ingress by juju deployment, i tried to enable on the service but i get >> `Service "default-http-backend-kubernetes-worker" is invalid: spec.externalTrafficPolicy: Invalid value: "Local": ExternalTrafficPolicy can only be set on NodePort and LoadBalancer service [00:53] not sure which service am I missing here? [00:59] Anyone enabled that setting before? [01:03] Have anyone at least worked around enabling ingress to see the real client ip? [01:03] or forward the real client ip? [07:02] achilleasa: can you shoot me that error message so I can tweak it in the cli doc please? [07:10] rick_h: current version: https://pastebin.canonical.com/p/rp9bS24hgX/ [07:11] achilleasa: ty === nmnde is now known as nammn_de [09:48] I think I may have broke juju or found a bug [09:49] It doesn't seem to let you destroy a controller if you've already removed its container. Is this a known bug? [09:50] How can I clean up controllers that have already had their containers removed? I can renstall juju if thats the only solution but I'd lie to know the proper way, if there is one [09:53] I have tried `juju destroy-controller -y --destroy-all-models --destroy-storage juju1` but it never completes, nor does it print any errors [09:53] It should be pretty much instant as it never actually got used [09:57] danboid: so you use juju unregister to remove the details of a controller from your local cache [09:57] danboid: if you go to the cloud and remove the VMs, then there's nothing for your juju cli tool to speak to handle the destroy process [09:57] danboid: so you just delete it from your local cache of controllers with unregister [09:58] danboid: juju doesn't auto do that because we can't tell a network outage vs a gone machine/etc. [09:58] rick_h, Sorted it. `juju kill-controller juju1` got rid with issue, I think [09:58] *without issue [09:59] There's no downside to using kill-controller ids there? [09:59] As I say, it was never used anyway so I'm just housekeepng [10:00] I presume kill-controller unregisters it too [10:01] I suppose I should tidy up in the cleanest way that works [10:03] The docs do say to use kill controller as a last resort, just wondering if there are any drawbacks? [10:04] rick_h, OK so juju unregister worked for me too. I should use that over kill-controller but what is the difference [10:05] danboid: kill-controller will try to reach out to the cloud and kill off any machines behind the controller's back [10:06] danboid: it doesn't promise to leave things in a clean state and such [10:06] danboid: unregister doesn't touch the cloud at all and just removes the yaml in your local cache [10:07] rick_h, but in my case where all my controllers never got used, it wouldn't make any difference [10:07] rick_h, Thanks for explaining [10:08] danboid: right [10:17] I've not been able to get juju register to work so that I can login to a controller from a remote machine [10:18] I get prompted for passwords and the controller name then it just waits and waits and eventually times out [10:20] So, the register code encodes what exactly? My controller is running in an LXD container on my MAAS controller so how is it trying to contact it? [10:21] I have disabled IPv6 on my MAAS/juju controller so that shouldn't be an issue now [10:23] Do I need to create some LXD proxy devices (port forwarding rules) to forward the juju api port from the MAAS controller/ LXD server to the container on the IP? [10:24] *to the container running the controller [10:28] Luckily I think I know how to do that but the docs should really give an example as I'm sure it's quite a common scenario [10:44] I expect juju bootstrap doesn't do any network config for the controller container. So after configuring the networking of the controller container (lets say we can SSH into it and port 17070 is open), at that point juju register should work without any LXD proxy devices? === exsdev0 is now known as exsdev === salmankhan1 is now known as salmankhan [11:05] Can IPv6 be disabled on the juju controller without disabling IPv6 entirely on the host machine via a kernel argument? [11:05] I did that and itseems to have broke MAAS [11:06] I tried disabling IPv6 in LXD but that didn't help [11:06] danboid: the issue is that the client needs to be able to contact the controller on its API port [11:06] danboid: so if you've got a controller in a lxd container, then the client running "juju register" should be able to telnet to the controller ip:port [11:07] if it can't you'll get a failure as you describe [11:07] danboid: no, juju just puts the controller on the lxd container. Since you bootstrap from the machine you're talking to lxd on they're normally routable [11:08] danboid: but from another machine you'll need to have a path from the root device that's hosting the lxd container from the outside [11:09] Do you know if MAAS requires IPv6? We aren't using v6 but after disabling it (to get juju controllers to stop using v6 addresses) I can no onger login to MAAS [11:10] I disabled it with a kernel argument [11:10] THe juju controlles were assigning 17017 to an IPv6 address otherwise [11:11] danboid: hmm, not sure. I think it would depend on what was setup on the network if ipv4 was setup correct or the like [11:11] but you don't know of any juju controlle config option to say "only use IPv4"? [11:12] danboid: on lxd juju throws an error if it's setup with ipv6 [11:12] danboid: so you shouldn't need a config for that [11:13] It hasn't done that for me [11:13] danboid: what Juju are you using? snap or deb and version? [11:14] snap. I've been using `juju bootstrap lxd Juju1` to create controller containers [11:14] 2.6.8 [11:14] Under 18.04 [11:15] Then if I shell into the container and run netstat, I see 17017 is using an IPv6 address, unless I disable IPv6 with a kernel arg [11:16] listening on a IPv6 port even [11:17] danboid: hmm, I wonder what's up with that. We threw an error suggesting you use lxd-configure or the like to set it up w/o ipv6 enabled. [11:19] I tried disabling ipv6 addressing and NAT but it didn't help. Is this documented? [11:19] Disabling it on the LXD networking level sorry [11:24] danboid: https://github.com/juju/docs/issues/2965 [11:24] danboid: basically when you run `lxd init` it walks you through the setup [11:29] rick_h, Yes, I saw that bug yesterday and did what it advises but it didn't fix it for me. Even after destroying my controllers and creating new ones with LXD IPv6 disabled beforehand [11:31] danboid: huh? do you disabled lxd ipv6 and still got an ipv6 address on containers brought up with juju? [11:31] Disabling IPv6 at te kernel level on the host DOES fix it but it seems that means I cannot run MAAS and LXD/juju controller on the same box [11:31] Yes, I'll show you my LXD network config [11:33] https://gist.github.com/danboid/96fddd9ae6b95c91f6afc1dce63cf686 [11:34] I went the extra step over what that bug advised by disabling ipv6 NAT too [11:34] With IPv6 disabled, I didn't get a port 17017 at all [11:35] Enable v6, and I get 17017 listening on v6 === nammn_de_ is now known as nammn_de === narindergupta is now known as narinderguptamac [15:23] danboid: did you manage to get things working? [15:24] babbageclunk, I solved my IPv6 problem by uninstalling lxd from the 18.04 repo and installing lxd from snap [15:25] danboid: oh great [15:25] It does seem that the MAAS web UI doesn't start without IPv6 [15:26] I didn't think to ask your lxd version, that would have been a good hint sorry === ISDADS\sgs548_ is now known as danboid [19:16] I've tried to bootstrap a controller with juju, and it hangs at the step 'Running machine configuration script'. After 2h, I cancelled the whole thing, and now juju won't return anything for juju status. Any idea how to fix juju?