Comment 16 for bug 1991261

Good news! Adding dsmode: local to meta-data appears to fix things nicely. A couple of questions spring to mind though, particularly since I can't seem to find much documented about "dsmode" in the cloud-init documentation -- there're several places that mention it, but all are cloud-specific sources, none of which I'm using (e.g. [1]). The instance meta-data chapter [2] shows it in an example but otherwise doesn't describe it.

[1]: https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html?highlight=dsmode#keys-and-values

[2]: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html?highlight=dsmode#using-instance-data

Anyway, onto the questions. Will this break anyone who is tweaking their kernel command line to use a networked seed?

Context: on occasion in the past, I've set up a quick http server and tweaked the kernel command on a freshly flashed image (editing cmdline.txt on the boot partition) to point to that server as a seed. Will setting dsmode to "local" prevent someone from using a seed in this way without removing that from meta-data? (my guess on this is "yes", in which case I ought to document that in release notes)

Also, should dsmode actually be dsmode="net" in the case we're using NoCloud as the only data source?

Context: I note there's also NoCloudNet in the code for that datasource (although it doesn't appear to be documented). I would've guessed that NoCloud would set dsmode="local" implicitly, but NoCloudNet would use dsmode="net"? Is that a bug in its own right, or am I barking up the wrong tree with this? (looking at the other uses of dsmode, it seems to be a configuration option of a data-source)