The nocloud-net data source requires a folder like string forcing 2 seperate requests to hard coded locations

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1886846

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2020-07-08T16:15:58.694961+00:00
date_fix_committed = None
date_fix_released = None
id = 1886846
importance = wishlist
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1886846
milestone = None
owner = rustyscottweber
owner_name = Russell Weber
private = False
status = triaged
submitter = rustyscottweber
submitter_name = Russell Weber
tags = []
duplicates = []

Launchpad user Russell Weber(rustyscottweber) wrote on 2020-07-08T16:15:58.694961+00:00

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.