-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add backward compatibility #23
Conversation
1d6538e
to
6fbb138
Compare
5f8164e
to
5285546
Compare
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
and these two need to be ported: 4b3c0f9 3e27c2e Edit: the handling of ext4 OEM entries is now done in the translator instead of trying to mount all supported filesystems one by one |
this commit ID pulls the following PR: * flatcar/ignition#23 it mainly brings V3 support on top of V2 support for Ignition and ensure backward compatibility with existing integration. Signed-off-by: Mathieu Tortuyaux <[email protected]>
a1a1b20
to
ce6fd58
Compare
05073ce
to
2d1ca66
Compare
2d1ca66
to
390754d
Compare
3a0410f
to
d8e5d3b
Compare
4fe7d2c
to
114ff89
Compare
The ign-converter uses the files under Edit: Plan is to keep the current flatcar-master state around as |
8bc3d56
to
6de40b2
Compare
6de40b2
to
dcd27a7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are good now with the kola tests passing?
Signed-off-by: Mathieu Tortuyaux <[email protected]>
Signed-off-by: Mathieu Tortuyaux <[email protected]>
Signed-off-by: Mathieu Tortuyaux <[email protected]>
if the version of ignition is 2.x we convert it to 3.1 using ign-converter. it shoud support any 2.x version (or at the least the last 2 releases) Signed-off-by: Mathieu Tortuyaux <[email protected]>
this patch provides backward compatiblity for various config key Signed-off-by: Mathieu Tortuyaux <[email protected]>
we support both CoreOS and Flatcar fw_cfg path to ensure compatiblity Signed-off-by: Mathieu Tortuyaux <[email protected]>
Signed-off-by: Mathieu Tortuyaux <[email protected]>
As soon as the OEM partition's filesystem format changes, all users that have file entries for the OEM partition (e.g., for kernel parameters), need to also switch to the new format, otherwise Ignition will bootloop due to the encountered mismatch error. If users have set the wipeFilesystem option there is no change in behavior and the user would create the desired filesystem on each Ignition run. To spare the users the migration due to an internal detail of the OEM partition, allow the OEM filesystem format to mismatch and just reuse the existing OEM partition. The user can still enable the wipeFilesystem to reformat regardless what content the partition has. Signed-off-by: Mathieu Tortuyaux <[email protected]>
The decision whether to use ignition.config.data or coreos.config.data was based on their presence in ovfenv. If this was missing, coreos.config.data would always be used. Also, if the retrieval of the guestinfo would have an error, the value from ovfenv would not be used even though it was supposed to be a fallback. Thus, refactor the logic to get variables from the ovfenv as fallback while preferring the direct guestinfo variables. With this new function, fix the logic of falling back to coreos.config.data but preferring ignition.config.data. The OVF metadata for CoreOS specified guestinfo.coreos.config.url but that was never used to fetch the Ignition config. Thus, use guestinfo.*.config.url as fallback if no guestinfo.*.config.data variables are set.
version 2 should be able to translate configuration version 1 but the `GetConfigVersion` was not able to detect version 1 configuration since for this particular version the `Version` is an int held into `ignitionVersion` field. Signed-off-by: Mathieu Tortuyaux <[email protected]>
we detect if the config is not an ignition one (script/cloudinit) and we return an ErrEmpty which will make Ignition to ignore this user config. Signed-off-by: Mathieu Tortuyaux <[email protected]>
This reverts commit 0c088d6.
When btrfs is used to fit more content into the partition, mounting fails because ext4 was hardcoded. When mounting ext4 fails, try mounting as btrfs.
The "udevadm settle" command used to wait for udev to process the disk changes and recreate the entries under /dev was still prone to races where udev didn't get notified yet of the final event to wait for. This caused the boot with a btrfs root filesystem created by Ignition to fail almost every time on certain hardware. Issue tagged events and wait for them to be processed by udev. This is actually meanigful in all stages not only for the other parts of the initramfs which may be surprised by sudden device nodes disappearing shortly like the case was with systemd's fsck service but also for the inter-stage dependencies which currently are using the waiter for systemd device units but that doesn't really prevent from races with udev device node recreation. Thus, these changes are complementary to the existing waiter which mainly has the purpose to wait for unmodified devices. For newly created RAIDs we can wait for the new node to be available as udev will not recreate it. Note: This is a port for Ignition 0.35 while for 2.2 this also should be done for LUKS.
dcd27a7
to
858ba5f
Compare
@pothos ok then - I started a new CI this morning using flatcar/mantle#301. If it's good, I'll go ahead and merge this one. |
In this PR, we provide backward compatibility between v1, v2 and v3 of Ignition's config.
We use a forked
ign-converter
to ensure the conversion (https://github.com/flatcar-linux/ign-converter) - once the config loaded,ignition
will check the version:3.x
: it behaves as usual2.x
: it tries to first parse withv2_4
parser (which fallbacks to1.x
if required) then it converts to3.x
high level changes:
oem://
file URLs, special handling of the OEM partition, CoreOS/Flatcar Container Linux config locations, translation of v1 and v2 configs to v3Testing done
hostname
one)systemd.journald.max_level_console=debug console=ttyS0
to get Ignition logs if it bootloops)Note for reviewers
main
to be the default branch and backupflatcar-master
tospec2x
to follow the upstream logic