Tracked in Github Issues as https://github.com/canonical/cloud- init/issues/3759
** Bug watch added: github.com/canonical/cloud-init/issues #3759 https://github.com/canonical/cloud-init/issues/3759 ** 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/1886846 Title: The nocloud-net data source requires a folder like string forcing 2 seperate requests to hard coded locations Status in cloud-init: Expired Bug description: Consider the following IPXE boot script: set kernelparams root=/dev/ram0 ramdisk_size=1500000 ip=dhcp url=http://${MYIP}/tftp/ubuntu-20.04-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://${MYIP}/tftp/cloud-init-bios/ This will mean that the meta-data and user-data files will respectively be returned from "http://${MYIP}/tftp/cloud-init- bios/meta-data" and "http://${MYIP}/tftp/cloud-init-bios/user-data" However this is problematic in 2 ways. 1. If the end goal is to have a generated config be used, something like a .php script, then there isn't a clean way to do this since there is no way to append a .php file extension or provide get level variables so that what is actually queried and then returned looks more like the following: "http://${MYIP}/tftp/cloud-init-bios/user-data.php?ip=192.168.1.1&config=storage-node". This also means that the files cannot be in other languages or localized to a different languages because the file names "user-data" and meta-data are hard coded. (@meena) has suggested "set kernelparams root=/dev/ram0 ramdisk_size=1500000 ip=dhcp url=http://${MYIP}/tftp/ubuntu-20.04-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://${MYIP}/tftp/cloud-init-bios/config-generator.php?ip=192.168.1.1&version=20.04&type=storage&document=" This way, when the url is combined, 2 seperate queries are made to the config-generator.php; each with a different "document" variable set. Although this work around might work for my purposes, it isn't made abundantly clear in the documentation that this is an acceptable practice. It also demands that both generated documents use the exact same variables which means that it may not work for some one else's exact purposes. If there was a way to name the exact file names that will be appended onto the base directory for retrieval, this would solve all of these issues. Example: "set kernelparams root=/dev/ram0 ramdisk_size=1500000 ip=dhcp url=http://${MYIP}/tftp/ubuntu-20.04-live-server-amd64.iso autoinstall ds=nocloud-net;s=http://${MYIP}/tftp/cloud-init-bios/;u=user-data-generator.php?ip=192.168.1.1&version=20.04&type=storage;m=meta-data-generator.php?version=20.04&other=localization" In this example the meta-data would be retrieved using the full URL "http://${MYIP}/tftp/cloud-init-bios/meta-data-generator.php?version=20.04&other=localization" and the user data would be retrieved using the full URL "http://${MYIP}/tftp/cloud-init-bios/user-data-generator.php?ip=192.168.1.1&version=20.04&type=storage" The end result would be that "meta-data" and "user-data" are no longer hard coded values. 2. This forces 2 separate web-requests which is not as simple as making a single web request. It would be nice to get a combined file which has both the meta-data as well as the user-data combined together. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1886846/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp