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

plugins: add support for customizations #97

Merged
merged 1 commit into from
May 3, 2022
Merged

Conversation

gicmo
Copy link
Contributor

@gicmo gicmo commented May 2, 2022

The Cloud API supports passing in a variety of image customizations, like e.g. extra packages or pre-defining users.

Add a new command line option to the client --customizations which takes a path to a JSON file which contains the customziations; they will be passed via the existing opts argument to the hub.

Add support for customizations to the opts/options arguments to the hub plugin. No validation to the object is done. Instead we rely in Composer for the validation of the content.

Add support for customizations the image ComposeRequest in the builder plugin. All specified values are just passed through to composer as-is.

Add tests for the respective plugins.

@gicmo gicmo requested a review from ondrejbudai May 2, 2022 13:25

Verified

This commit was signed with the committer’s verified signature.
DanielaE Daniela Engert
The Cloud API supports passing in a variety of image customizations,
like e.g. extra packages or pre-defining users.

Add a new command line option to the client `--customizations` which
takes a path to a JSON file which contains the customziations; they
will be passed via the existing `opts` argument to the hub.

Add support for `customizations` to the `opts`/`options` arguments
to the hub plugin. No validation to the object is done. Instead we
rely in Composer for the validation of the content.

Add support for `customizations` the image `ComposeRequest` in the
builder plugin. All specified values are just passed through to
composer as-is.

Add tests for the respective plugins.
@gicmo gicmo force-pushed the customizations branch from 76c90e0 to 8ac9677 Compare May 2, 2022 13:31
@teg
Copy link
Member

teg commented May 2, 2022

What is our stance on passing things through our API layers unvalidated. At some point we said we would not do this (to avoid spaghetti code), but I'm very open to refining that stance (i.e., it makes sense in certain circumstances). It obviously is quite nice for fetatures just to appear higher up in the stack when they are enabled lower down, as long as we avoid any of the pitfalls.

Would we do something similar with composer <-> image builder?

@gicmo
Copy link
Contributor Author

gicmo commented May 2, 2022

What is our stance on passing things through our API layers unvalidated. At some point we said we would not do this (to avoid spaghetti code), but I'm very open to refining that stance (i.e., it makes sense in certain circumstances). It obviously is quite nice for fetatures just to appear higher up in the stack when they are enabled lower down, as long as we avoid any of the pitfalls.

I spoke with @ondrejbudai about this and we though for the customisation it makes sense to not validate it, since it is basically an object that is fully defined and owned by Composer and it can be explicitly validated there on the one hand and it is totally opaque to koji-osbuild (we don't need to know anything about it or fiddle with it).
This is in contrast to ostree params where we do substitution for the different arches in the ref.

But it is indeed a very grey area.

@teg
Copy link
Member

teg commented May 2, 2022

I guess the argument could be made that composer customisations are like osbuild manifests (scary thought), and hence opaque and well-defined blobs. No objections from me on this PR, this was just a general musing.

@ondrejbudai
Copy link
Member

Interesting though, Tom! There are certainly some trade-offs between passing through and translating. I would say that translating is more convenient for end users because you know that one koji-osbuild installation will work consistently across multiple composer servers because it can do different translation for each instance.

In reality, this is not needed though, one koji instance uses just one composer and I tbh don't expect the opposite. For this reason, I don't think we need to bother with translation and just do pass-through.

Copy link
Member

@ondrejbudai ondrejbudai left a comment

Choose a reason for hiding this comment

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

Looks good!

@gicmo gicmo merged commit 591a55a into osbuild:main May 3, 2022
@gicmo gicmo deleted the customizations branch May 3, 2022 10:28
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

3 participants