During deployment it's possible to define additional files with a configuration like the following, which when using cloud-init results in default behavior to overwrite any existing files
The behavior with format: ignition however is different and any attempt to overwrite an existing file will fail during the OS firstboot:
[ 17.691712] worker-0 ignition[1180]: Ignition failed: failed to create files: failed to create files: error creating /sysroot/etc/motd: error creating file "/sysroot/etc/motd": A file exists there already and overwrite is false
What did you expect to happen:
The behavior between cloud-init and ignition should be consistent from the perspective of the user of the RKE2 provider API, even if the default behavior of the underlying tool may be different.
I think we can likely adapt the configuration during the translation from cloud-init to butane/ignition so that we set the overwrite flag to true.
How to reproduce it:
Deploy with a similar configuration described above and format: ignition
Environment:
I reproduced using Leap Micro 6.0 with CAPM3.
What happened:
During deployment it's possible to define additional files with a configuration like the following, which when using cloud-init results in default behavior to overwrite any existing files
The behavior with
format: ignition
however is different and any attempt to overwrite an existing file will fail during the OS firstboot:What did you expect to happen: The behavior between cloud-init and ignition should be consistent from the perspective of the user of the RKE2 provider API, even if the default behavior of the underlying tool may be different.
I think we can likely adapt the configuration during the translation from cloud-init to butane/ignition so that we set the overwrite flag to true.
How to reproduce it: Deploy with a similar configuration described above and
format: ignition
Environment: I reproduced using Leap Micro 6.0 with CAPM3.