ubuntu-desktop-provision

Bug #2055077
Comment #6

Comment 6 for bug 2055077

Revision history for this message

Chad Smith (chad.smith) wrote on 2024-03-01:

Reflecting this context to the bug instead of IRC messages.

There are a number of issues at play here:

1. edubuntu images do not provide /var/lib/cloud/seed/nocloud/user-data or meta-data files which allow cloud-init in Ubuntu Desktop images to detect cloud-init's NoCloud datasource.

2. /usr/lib/cloud-init/ds-identify is used to quickly limit any viable datasources on a system during systemd generator timeframe. inability to find any datasources will leave cloud-init with a disabled status.

3. subiquity (and live desktop images) make a call to cloud-init status to block on cloud-init completion: either disabled or enabled with user-data

4. subiquity calls cloud-init's stages.Init() function to query for any actionable `autoinstall` key in user-data presented in #cloud-config provided to the machine at boot.

The problem appears due to cloud-init being disabled/inert due to step #2.
Subiquity's subsequent waiting on cloud-init status doesn't consider `disabled` state of cloud-init in #3 and invokes stages.Init() directly in step #4 when there really isn't any possible way we'd have user-data.

The side-effect of cloud-init's stages.Init() call is: if no detected datasources are present, stages.Init() is trying to be helpful and try discovering datasources for you at runtime. Since ds-identify never found any datasource, it didn't limit the list of all potential datasources in /etc/cloud/cloud.cfg.d/90_dpkg.cfg. So, stages.Init() happily walks through all costly detection/discover logic for 31 datasource.

Short-term we could tidy up the edubuntu image flavor to ensure cloud-init can minimally detect an empty nocloud datasource by providing empty files at /var/lib/cloud/seed/nocloud/user-data and /var/lib/cloud/seed/nocloud/meta-data. That'll leave cloud-init in an enabled state that current subiquity code can invoke stages.Init() without side-effects.

long-term:
- subiquity should probably double check cloud-init disabled status and avoid calling stages.Init() if cloud-init is "disabled"

Reflecting this context to the bug instead of IRC messages.

There are a number of issues at play here:

1. edubuntu images do not provide /var/lib/cloud/seed/nocloud/user-data or meta-data files which allow cloud-init in Ubuntu Desktop images to detect cloud-init's NoCloud datasource.

3. subiquity (and live desktop images) make a call to cloud-init status to block on cloud-init completion: either disabled or enabled with user-data

4. subiquity calls cloud-init's stages.Init() function to query for any actionable `autoinstall` key in user-data presented in #cloud-config provided to the machine at boot.

The side-effect of cloud-init's stages.Init() call is:  if no detected datasources are present, stages.Init() is trying to be helpful and try discovering datasources for you at runtime. Since ds-identify never found any datasource, it didn't limit the list of all potential datasources in /etc/cloud/cloud.cfg.d/90_dpkg.cfg. So, stages.Init() happily walks through all costly detection/discover logic for 31 datasource.

Short-term we could tidy up the edubuntu image flavor to ensure cloud-init can minimally detect an empty nocloud datasource by providing empty files at /var/lib/cloud/seed/nocloud/user-data  and /var/lib/cloud/seed/nocloud/meta-data. That'll leave cloud-init in an enabled state that current subiquity code can invoke stages.Init() without side-effects.

long-term:
 - subiquity should probably double check cloud-init disabled status and avoid calling stages.Init() if cloud-init is "disabled"