00:22:19 ERROR juju.cmd.juju.commands bootstrap.go:885 failed to bootstrap model: cannot start bootstrap instance in availability zone “lxdhostmachine”: no matching image found
Does lxc launch ubuntu:20.04 work from the same terminal as running the juju bootstrap command?
I have a vanilla ubuntu 23.04 machine which I have used juju on yet and I’m unable to reproduce the issue today. There have been some intermittent issues with availability of cloud images.
±------±-------------±-------±--------------------------------------------±-------------±----------±---------±------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
±------±-------------±-------±--------------------------------------------±-------------±----------±---------±------------------------------+
| | 3f04ed906801 | no | ubuntu 20.04 LTS amd64 (daily) (20230612) | x86_64 | CONTAINER | 436.65MB | Jun 13, 2023 at 12:02pm (UTC) |
±------±-------------±-------±--------------------------------------------±-------------±----------±---------±------------------------------+
| | 884a62161ef5 | no | ubuntu 20.04 LTS amd64 (release) (20230606) | x86_64 | CONTAINER | 436.66MB | Jun 14, 2023 at 6:40pm (UTC) |
±------±-------------±-------±--------------------------------------------±-------------±----------±---------±------------------------------+
I am also having trouble with lxd and “no matching image found” but my jujud is able to find and deploy kvm images just fine. I’m behind a firewall as well.
I am also able to deploy locally with lxc and I can reach the cloud image URLs with wget.
I am using these proxy settings in config.yaml:
snap-http-proxy: http://squid:3128/
snap-https-proxy: same
apt-http-proxy: same
apt-https-proxy: same
http-proxy: same
https-proxy: same (discourse only allows 2 links)
Note - if I try to use juju-http-proxy and juju-https-proxy, then juju itself won’t deploy due to the firewall.
Is there anywhere I can look to see what it is actually doing to match these images? I looked at the jujud go code and there isn’t a lot of debugging info to enable. Re-building the snap (and the 250MB-sized jujud :P) doesn’t look like fun but I might have to go down that road.
This makes sense. Everything should be using the proxy, but I used tcpdump on the hardware node and saw that there were attempts to directly connect to images.linuxcontainers.org and https-services.aerodent.canonical.com (presumably this is cloud-images).
I tried the proxy setting command:
lxc config set core.proxy_https http://squid:3128
But it doesn’t seem to make a difference, and the setting reverts to an empty string after reboot anyway. I’ll post an update if/when I figure this part out.
I can’t seem to find a way to make the maas/juju version of lxd use a proxy. The snap over-writes any local settings and all the configs are auto-generated.
The lxc config proxy setting is ignored by lxd.
Is there any way to tell juju to set the lxd proxy? I’m going to have to hack my own lxd snap to make this work. It would be even better to find a deb way to deploy this, snaps are a disaster.
When you say MAAS/Juju version of LXD do you mean when you deploy to a container on a juju managed machine (i.e. with juju deploy --to 0/lxd/1 or something similar)? If thats the case it looks like we may have some hardcoded URLs in Juju.
images.linuxcontainers.org is given here, and it is used in here which is used by the CreateContainer method of the container provisioner.
I’m not very familiar with this part of the code so am still trying to figure it out too. But I can’t see a way to change that URL.
In my particular case, using "juju deploy --to 0/lxd/1’ (for example) results in failure (matching image not found). Using lxc launch works just fine. (juju 3.5.4)
