fix(grub_dpkg): Don't set grub install target by default #5292
Conversation
Related to LP: #2054103 BREAKING_CHANGE: Changes grub_dpkg.enabled to False by default.
|
fyi @BirknerAlex |
|
We'll want to patch this out of Mantic and below. |
|
Thanks for the heads up! We will add the flag to vendor data instead. |
There was a problem hiding this comment.
@kukrimate is aware of a couple of potential failure paths for non-cloud images where this grub config setup is still required and cloud_style_initialization=false. A potential approach we may want to consider is for cloud-init to check debconf settings cloud_sytle_initialization for a True value and maybe on Debian the presence of /etc/grub.d/enable_cloud to determine whether or not to NOOP.
| @@ -247,7 +247,7 @@ def test_handle( | |||
| """Test setting of correct debconf database entries""" | |||
| m_is_efi_booted.return_value = is_uefi | |||
| m_fetch_idevs.return_value = fetch_idevs_output | |||
| cfg = {"grub_dpkg": {}} | |||
| cfg = {"grub_dpkg": {"enabled": True}} | |||
There was a problem hiding this comment.
It appears that non-cloud livecd-rootfs images still rely on this cloud-init grub boot traget setup per-boot. This behavior should not land yet until we have sorted expected behavior in those environments.
There was a problem hiding this comment.
It appears that non-cloud livecd-rootfs images still rely on this cloud-init grub boot traget setup per-boot
Those are images, and therefore should be able to enable this as needed in cloud.cfg.d/.
Where is this conversation happening? @blackboxsw @kukrimate can we please continue the conversation in this PR?
This change should not be incompatible with those needs. They can opt in to using a configuration file in cloud.cfg.d if they still need this behavior. That said, wouldn't the same mis-detection issue exist there?
That could work but I'd still rather make this behavior a default opt-in rather than one that is dynamically decided at runtime. As we've observed, debconf is slow, and dynamic runtime behavior is more complex and error prone.
What creates this file? I'm missing some context about the significance of it and why cloud-init would want to use that to decide runtime behavior on debian. |
It's not externally visible, but to answer my own question it looks like the conversation took place here. |
|
Closing for now until we have confirmed that this is a safe change to make. |
Note: The impetus of this PR was correctness, but a side-effect is performance. This module sometimes takes absurd amounts of time to run, a recently launched Noble image took ~5s run this module (which is not uncommon). See the logs below.