Skip to content
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

[RFE] Define sysext level for Flatcar #643

Closed
pothos opened this issue Feb 28, 2022 · 0 comments · Fixed by flatcar/scripts#252
Closed

[RFE] Define sysext level for Flatcar #643

pothos opened this issue Feb 28, 2022 · 0 comments · Fixed by flatcar/scripts#252
Assignees
Labels
kind/feature A feature request

Comments

@pothos
Copy link
Member

pothos commented Feb 28, 2022

Current situation

Systemd-sysext images have a compatibility matching mechanism that searches for the matching OS version or custom sysext level setting. On Flatcar there is just the OS version set in /etc/os-release until now.

Impact

Sysext images can't easily be used together with autoupdates that change the OS version.

Ideal future situation

We define a Flatcar sysext level like 1.0 which the sysext images can match for instead of the OS version.
Since there is not backwards compatibility mechanism in the matching, e.g., to specify a minimum version, the long term plan for this setting is a bit unclear and we should work with upstream to get a more flexible mechanism. Also, matching for the architecture should be added.

Implementation options

1.0 (or actually 1.0-amd64 and 1.0-arm64 to forbid mixing architectures but I think we can address this upstream in parallel and start without baking it in)

Additional information

@pothos pothos added the kind/feature A feature request label Feb 28, 2022
pothos added a commit to flatcar/scripts that referenced this issue Mar 10, 2022
Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.

Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib/extension-release.d/extension-release.NAME
  ID=flatcar
  SYSEXT_LEVEL=1.0
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.

Closes: flatcar/Flatcar#643
pothos added a commit to flatcar/scripts that referenced this issue Mar 10, 2022
Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.

Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib/extension-release.d/extension-release.NAME
  ID=flatcar
  SYSEXT_LEVEL=1.0
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.

Closes: flatcar/Flatcar#643
pothos added a commit to flatcar/scripts that referenced this issue Mar 10, 2022
Sysext images have a compatibility matching mechanism that searches for
the matching OS version or custom sysext level setting. On Flatcar
there is just the OS version set in /etc/os-release until now which
means that sysext images can't easily be used together with autoupdates
that change the OS version.

Define a sysext level for Flatcar so that users can refer to it instead
of the OS version when they have images that don't rely on a particular
Flatcar version.
Here an example of the now possible metadata:
/etc/extensions/NAME/usr/lib64/extension-release.d/extension-release.NAME
  ID=flatcar
  SYSEXT_LEVEL=1.0
and a symlink /etc/extensions/NAME/usr/lib → /etc/extensions/NAME/usr/lib64
to work around the problem that using lib/ as path destroys Flatcar's
lib → lib64 symlink.
In the future the matching logic hopefully gets more flexible because
now it is just a string comparison. Also, the architecture is not
matched either for now - we should work with upstream to improve this.

Closes: flatcar/Flatcar#643
@t-lo t-lo moved this from Upcoming / Backlog to Done (move to Release Board) in Flatcar tactical, release planning, and roadmap Mar 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant