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

There should be only one framework image with the logic for all distros #1896

Closed
Tracked by #1914 ...
jimmykarily opened this issue Oct 9, 2023 · 6 comments · Fixed by #1929
Closed
Tracked by #1914 ...

There should be only one framework image with the logic for all distros #1896

jimmykarily opened this issue Oct 9, 2023 · 6 comments · Fixed by #1929
Assignees

Comments

@jimmykarily
Copy link
Contributor

jimmykarily commented Oct 9, 2023

Currently we are pushing different framework images as tags of quay.io/kairos/framework:XXX .
We want to move the installation of the framework bits from Earthly to the dockerfiles themselves. It makes it simpler if there is only one framework image and not one per flavor and our users also won't have to worry when creating their own derivatives, what image they should use.

It seems that this is possible but maybe there is some logic that need to be added to the framework bits.

Expected outcome:

There is only one framework image that works for all flavors.

Part of: #116

@jimmykarily jimmykarily converted this from a draft issue Oct 9, 2023
@jimmykarily jimmykarily moved this from Todo 🖊 to In Progress 🏃 in 🧙Issue tracking board Oct 9, 2023
@jimmykarily jimmykarily moved this from In Progress 🏃 to Todo 🖊 in 🧙Issue tracking board Oct 9, 2023
@Itxaka
Copy link
Member

Itxaka commented Oct 9, 2023

This is gonna be a bit more difficult not due to our config files but due to the install packages and dracut modules.

for example, tumbleweed needs the dracut-network-legacy package in the framework but almalinux uses dracut-network-legacy-compat and if I remember correctly they cannot be installed alongside

If we were able to merge them all then we would get at least 4 different frameworks:

  • generic
  • alpine
  • generic-fips
  • generic-fipts-static

so yeah..we can reduce but mostly they are all special xD

@jimmykarily
Copy link
Contributor Author

Can't the packages detect whether they should install something or not? E.g. merge dracut-network-legacy and dracut-network-legacy-compat and decide what to install based on whether it's almalinux or tumbleweed (or whatever the deciding factor is)?

@jimmykarily
Copy link
Contributor Author

actually, we have framework-profile to install different packages per distro. Can't we move these outside the framework image and define them there?

@Itxaka
Copy link
Member

Itxaka commented Oct 9, 2023

actually, we have framework-profile to install different packages per distro. Can't we move these outside the framework image and define them there?

but framework needs to be a complete package that you can install over "everything" adn you get all the bits and bops to have a kairos image no?

Framework should include those, for example, the network module should work out of the box for all flavors.

@Itxaka
Copy link
Member

Itxaka commented Oct 20, 2023

Work is almost done. I would say that a missing piece of this is to extract the framework stuff and put it in a different repo with its own cadence, and then we consume it in the Dockerfiles as a external artifact.

so instead of earthly doing it we just add a multi-stage layer on all dockerfiles that consume that framework image. One less thing for earthly to do, one more thing that we can add to the factory.

thought on this @mudler @jimmykarily @mauromorales ?

@jimmykarily
Copy link
Contributor Author

👍 framework images can be built on another repo. Probably with this code too: https://github.com/kairos-io/kairos/tree/master/profile-build .

@github-project-automation github-project-automation bot moved this from Under review 🔍 to Done ✅ in 🧙Issue tracking board Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants