(Maas 2.6.2) Maas always seems to do a “apt-get dist-upgrade” as part of deploying a machine, which is a major problem for us as we use an internal aptly snapshot of upstream that “lags” behind upstream by a certain amount of time (so that all machines can be patched to a CONSISTENT source). The problem is that maas won’t allow me to direct it at our static snapshot as its “ubuntu mirror”, because the snapshotting/aptly process ends up changing some fields in the InRelease/Release files which causes cloud-init in the ephemeral image to choke on and immediately abort, so I’m forced to leave maas configured to point at upstream, the problem being when maas deploys a machine, some hidden compiled in step within curtin/maas does an “apt-get upgrade” to the box while pointing to the upstream mirrors which results in pulling down packages NEWER than our delayed snapshot. This results in sporadic APT failures AFTER deployment when the machine is pointed back at our static snapshots that are now “behind” (by design). i.e. apt-get upgrade during deploy updates libc, and a process on some VM’s after deployment needs to install libc6-dev which now pointing at our static snapshot is behind the libc that got updated (unwantedly by maas) which results in an apt failure and a manual forced-downgrade of libc is necessary to resolve the situation.
We build our images to be CONSISTENT and mass’s blind “apt-get upgrade” during deployment completely breaks that.
Looking for one of the following:
A way to turn off apt-get upgrade by maas during the deployment process (via api call or gui)
Or some magic flags to cloud-init that I can feed via curtin to make it ignore the fields in InRelease/Release that cause it to complain when in the ephemeral (We have no issues with all of our machines that point to it today, its somehting specifically in cloud-init’s apt handler than chokes on it)