Comment 3 for bug 1819033

Thank you for working on this, figuring out the root cause and proposing the fix for 16.04.

I'd like to question though whether an SRU is really appropriate in this case. It seems to me that this kind of change risks unintended consequences more so than usual, that the number of users affected is small and a better general solution is possible.

I wondered how it is that a package upgrade takes ten minutes, and realised that based on Cicatrice's description, this is only happening because of the use of a "baked" image that is missing the latest updates, doesn't install them before entering production, and does get them all during the first unattended-upgrades run which will take place the first night after deployment.

This seems like a poor approach to me, exactly because the instance is being put into production in a way that is set to immediately change overnight, and additionally because the instance is being put into production with outstanding security updates. Better would be to ask cloud-init to automatically upgrade on first boot, perhaps limiting it to security updates only if that is required. I think that would be a more sensible way of doing it regardless of this particular issue, and one consequence of doing this would be that this issue would then be moot, because unattended-upgrades would be expected to run much faster when it doesn't ever have more than a day of security updates catchup to perform.

Apart from this very specific use case, I'm not sure that this issue is likely to impact any others. Given my solution above appears to be better for everyone, I'm soft-declining this SRU, pending further discussion, to minimise regression risk to existing unaffected users. If you disagree, please do discuss that here, and we can reconsider. Otherwise, I'll mark this "Won't Fix" for php7.0 and reject from the queue when I next see this again after a couple of weeks.

Separately, I think this scenario is a trap for those deploying like Cicatrice did. Ubuntu images should do the right thing by default. I think cloud-init might be the right place to fix this, and filed bug 1827204 to track the "it should do the right thing by default" problem.