Comment 9 for bug 1957101

+1 for having more options with this behavior.

We have automated Ubuntu VM image building since U14, and up until U20, a full build for multiple distros in parallel took less than ten minutes front to back, including automated quality control checks. The unattended-upgrades step -- even with local mirrors, caching proxies, incredibly bare bones installs, etc., -- adds several minutes to build jobs, sometimes enough to cause a build to fail because the build worker spends too much time waiting for it to finish updating.

I think there's a balance to be struck here: when these images are deployed within our cloud, we have other tools and mechanisms in place to keep them up-to-date, and a given image may be used for a month or longer depending on circumstances, so all that time spent upgrading during the original image build is subject to rapidly diminishing returns. Disabling networking as a way to prevent this from happening is a complete non-starter, because every piece of all of our provisioning toolchains have explicit dependencies on other services on our internal network.

I think it's great to be able to do this within the install environment, but it can be a real nuisance if you're working on tight schedules in already controlled environments; having the flexibility to decide when and what to upgrade during provisioning would be very helpful.