Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3309
** Bug watch added: github.com/canonical/cloud-init/issues #3309 https://github.com/canonical/cloud-init/issues/3309 ** Changed in: cloud-init Status: Triaged => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1810859 Title: ds-identify runs too early Status in cloud-init: Expired Bug description: ds-identify is executed from a systemd generator [1]. Based on my understanding of the intention of both this creates a non resolvable timing conflict. Generators run very early in the boot process. The cloud-init generator runs ds-identify which in turn runs "blkid" to find filesystems with specific labels, "cidata" for the nocloud data source. However, it is possible to construct an environment where the filesystem with the "cidata" label is on an attached device and the generator runs prior to the attached device being known to the kernel and thus the return of blkid cannot reflect the proper status, meaning the "cidata" label cannot be found and thus the "nocloud" data source is not properly identified. This implies that the cloud- init.target unit will be disabled. Observed in a test environment with qemu and the data source on a separate virtual device. According to [1] we shouldn't add any sync points such as "udevadm settle", thus I am not certain how this could be resolved. Also given that we cannot control the timing of the execution of the generator it appears that this is going to be difficult to get under control. Would it make sense to give ds-identify the option to simply exit and leave things alone? In the present setup the generator target runs ds-identify which in turn will disable cloud-init.target if no data source can be identified. However, the Python code usually runs late enough that things that are no available in early boot are found and data sources are identified properly. If users that know they run in a specific environment could set a "ds=no-check" flag on the kernel command line then the timing issue could be prevented. I realize for the nocloud case a user can set "ds=nocloud" on the kernel command line to work around the timing issue described herein. Also a "ds=no-check" would circumvent the basic intention of the generator to allow cloud-init to be installed anywhere and simply detect quickly an environment where cloud-init Python code should not be executed and thus safe boot time. My point is that, IMHO, timing issues in general cannot be avoided by ds-identify due to the nature of when systemd executes the generators. Thus giving users the general ability to disable ds-identify maybe useful. I am happy if I can be proven incorrect and the timing issue can be resolved. [1] https://www.freedesktop.org/wiki/Software/systemd/Generators/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1810859/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
