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

buildextend-live: add coreos-installer config directives to feature map #3083

Merged
merged 2 commits into from
Sep 9, 2022
Merged

buildextend-live: add coreos-installer config directives to feature map #3083

merged 2 commits into from
Sep 9, 2022

Conversation

bgilbert
Copy link
Contributor

@bgilbert bgilbert commented Sep 7, 2022

On a coreos-installer new enough to ship example-config.yaml (coreos/coreos-installer#976), parse that file from the image and convert it to a map of supported directives in features.json. coreos-installer iso/pxe customize can use this to decide whether it can safely use a directive, without us having to manually add a new feature flag every time.

While we're here, drop checks for older features and assume they always exist now.

Drop checks for older features and assume they always exist now.
On a coreos-installer new enough to ship example-config.yaml, parse that
file from the image and convert it to a map of supported directives in
features.json.  coreos-installer iso/pxe customize can use this to decide
whether it can safely use a directive, without us having to manually add a
new feature flag every time.

xref coreos/coreos-installer@ae860c53
Copy link
Member

@mike-nguyen mike-nguyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

features['installer-config-directives'] = {
k: True for k in yaml.safe_load(f)
}
except subprocess.CalledProcessError as e:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker at all but I'd note with the ostree API we can actually more properly distinguish "ENOENT" from "something else went wrong". Kind of tempting to add cat --allow-noent which returns no output or something.

This is much like https://users.rust-lang.org/t/why-i-use-anyhow-error-even-in-libraries/68592

@bgilbert bgilbert merged commit e4f39c8 into coreos:main Sep 9, 2022
@bgilbert bgilbert deleted the features branch September 9, 2022 03:22
Copy link
Member

@dustymabe dustymabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (late)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants