Currently the only way to set the snap store proxy is via custom cloud-init
and passing user_data to `maas machine deploy <system_id> user_data=
I guess that should be handled better first in cloud-init . I made a proposal around:
The preffered would be just to set assertions url in MAAS so the snap-store ID and assertions could ack’ed and configured automatically
There are few caveats to that:
- So far I see even if I set
snap:module and MAAS got built-in proxy turned on , my snippet will just ignored:
#cloud-config
snap:
commands:
00: bash -c 'snap ack <(curl -s https://snap-store-proxy.local/v2/auth/store/assertions
)'
01: snap set core proxy.store=\$(curl -s https://snap-store-proxy.local/v2/auth/store/assertions
|grep "^store:"| cut -f2 -d" ")
[ 601.074735] cloud-init[3330]: error: cannot install "lxd": Post "https://api.snapcraft.io/v2/snaps/refresh":
[ 601.075082] cloud-init[3330]: dial tcp: lookup api.snapcraft.io on 127.0.0.53:53: server misbehaving
When I disable built-in proxy the above just works
Why deployment fails ? We got specific case when deploy also vm-host with LXD in MAAS
(using register_vmhost=True)
And on the installation MAAS will try install lxd snap and that fails without snapstore
It would be possible circumvent when deploying with juju, if only juju was able to specify deploying on lxd vm insterad libvirt vm( --to kvm:0),
Yet currently the juju 3.x does not support it
4.x might support it in the future
See:
- Juju 4.0 support for LXD containers and VMs - juju - Charmhub
- https://documentation.ubuntu.com/juju/latest/releasenotes/juju_4.0.x/juju_4.0.0/
KVM provider: KVM support is removed; use LXD with virtual-machine constraint.