Do we also need to bump the chart version, or is this being batched with other recent changes prior to proposing upstream to the GH repo?
lgtm - although in future we should perhaps consider an upstream change to make the location of the j2 templates more consistent - it's a bit weird atm since some end up in /tmp and others in…
My point is until now this wasn't copied into the image at all (we had an unused file but it's not COPY'd in the Dockerfile)
With this change it is copied, but AFAICS the [script won't…
This reverts the fix I made for https://gitlab.com/sylva-projects/sylva-core/-/issues/2147 but I think it's probably OK since the uefi bootloader is now access via file:// instead of the vmedia webserver
This may reintroduce the spurious restart I fixed in https://build.opensuse.org/package/rdiff/isv:SUSE:Edge:Metal3:Ironic:2024.2/ironic-image?linkrev=base&rev=10 - at the time I couldn't reproduce the same issue with the upstream environment but it would probably be reasonable to push the change upstream anyway?
As mentioned in #200 - we can't remove this as it's required to allow Ironic to accept the nmstate network-data format instead of enforcing the openstack schema
Yes it's necessary to keep this, as it allows us to part nmstate format for the preprovisioningNetworkData and networkData - without the empty schema Ironic won't allow this as it doesn't match…
This copies runironic-exporter which AFAICS was not previously copied, and looks like it won't work due to missing dependencies - since we don't currently test/support it I'd suggest we just remove it and skip copying it from upstream until/unless there is a requirement for it?
Note this empty schema file doesn't exist upstream, it might be a good candidate for an upstream PR with some variable to enable the related Ironic config (disabled by default upstream) - I think it could be justified as other community members may well be interested in enabling other user-data payloads which don't conform to the openstack schema