yahoo-eng-team team mailing list archive

[Russell Weber <1886846@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: cloud-init
     Importance: Undecided
         Status: New

-- 
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 forcing 2 seperate web
  requests to hard coded files

Status in cloud-init:
  New

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