[11:48] <gollo> Hi, I think I might have run into a regression in cloud-init. We are using cloud-init in combination with Redhat Satellite to configure RHEL VMs provisioned via VMware templates.
[11:48] <gollo> Our config look like this:
[11:48] <gollo> # cat /etc/cloud/cloud.cfg.d/10_foreman.cfg
[11:48] <gollo> datasource_list: [NoCloud]
[11:48] <gollo> datasource:
[11:48] <gollo>   NoCloud:
[11:48] <gollo>     seedfrom: http://satellite:8000/userdata/
[11:48] <gollo> This works fine on RHEL 8, cloud-init version 22.1-8.el8_8.1
[11:48] <gollo> When we tried exactly the same config (plus the same rendered template) on RHEL 9.4, cloud-init version 23.4-7.el9_4, cloud-init does not use the seedfrom parameter to download the config. Instead we see the following error in cloud-init.log:
[11:48] <gollo> DataSourceNoCloud.py[DEBUG]: Seed from http://satellite:8000/userdata/ not supported by DataSourceNoCloud [seed=None][dsmode=net]
[11:48] <gollo> Does anybody know of changes to the NoCloud datasource code that could lead to this? Any ideas what to do are much appreciated.
[12:32] <minimal> gollo: that should work, I haven't tried it myself for maybe 1 year however
[12:33] <minimal> there were some changes in the past year regarding nocloud vs nocloud-net, perhaps it is a regression due to that
[12:36] <gollo> I am not sure if I understand the code changes between the version correctly, but from what I saw, it seems the seedfrom parameter is compared against a list of strings that it can begin with and only in nocloudnet, http and https are allowed schemata. However, I didn't find any documentation on what to change to enforce the other datasource type
[12:37] <minimal> the problem is the DataSourceNoCloud class is being used (which only permits seeds starting with "/" or "file://") rather than the DataSourceNoCloudNet class (which accepts "http://" and "https://")
[12:53] <gollo> That is what I also understood. The question now is can I adapt the config to make cloud-init use the correct class?
[12:58] <minimal> the config should not require any changes, I have used the same config myself in the past. That the log message you see mentions "[dsmode=net]" seems to imply that the seed URL should be accepted.
[12:59] <minimal> I will try and find some time later today to retest my own seedfrom-based VM to see if I can reproduce the problem
[18:37] <minimal> holmanb: I don't think there's any kernel document detailing which device use "pX" vs "X" for partition naming unfortunately
[18:39] <minimal> inside /sys a directory for a device may contain a "partition" file which has value of "1" if it represents a partitioned device, but that's the "wrong way around" from looking at a /sys directory for a parent device to work out how any partitions might be named
[18:53] <dbungert> pX vs X - not really documented to my knowledge but we reference: https://github.com/torvalds/linux/blob/0473719/block/partitions/core.c#L330
[19:01] <minimal> ok, that seems a simple enough rule, if device name ends with digit then use "p" before partition number
[19:17] <minimal> actually thinking about it, such partitioned device naming logic only applies to /dev/XYZ devices and not to /dev/disk/by-* devices
=== djhankb6 is now known as djhankb
=== fastidio1 is now known as fastidious