mudler / mudler/luet

Avoid configuration duplication

Open
#283 1 comment 0 reactions 1 assignee View on GitHub

@mudler is already working on this.

Since Jan 8, 2022.

enhancement
Dominant language
Go
Stars
307
Forks
30
PR merge metrics
No merged PRs in 30d

Description

Is your feature request related to a problem? Please describe.

I try to share configurations between collections, in order to maintain the common parts in one place.

Describe the solution you'd like

Currently, templating is supported in build.yaml only.
Currently, to a collection can be added a collection of anchors to be reused across the collection, like:

Collection A collection.yaml file :

anchors:

- &layers-X
  category: "layers"
  name: "X"
  version: ">=0"

- &buildbase-X
  category: "buildbase"
  name: "X"
  version: ">=0"

packages:

- category: "apps"
  name: "app"
  version: "9999+20"

... (rest of the package definition omitted)  

  requires:
  - <<: *layers-X
  build_requires:
  - <<: *buildbase-X

If another collection needs the same anchors, would need to copy them there and maintain them in both places.

My proposed solution is to support templating for anchors:

/templates/anchors.yaml :

{{ define "anchors" }}

anchors:

- &layers-X
  category: "layers"
  name: "X"
  version: ">=0"

- &buildbase-X
  category: "buildbase"
  name: "X"
  version: ">=0"

{{ end }}

Collection A collection.yaml file :

{{ template "anchors" }}

packages:

- category: "apps"
  name: "app"
  version: "9999+20"

... (rest of the package definition omitted)  

  requires:
  - <<: *layers-X
  build_requires:
  - <<: *buildbase-X

Additionally, common scripts (that are usually referred by build.yaml), is productive to refer from any collection build.
They could be in a common place or even in templates directory, but accessible and referred somehow in the build.yaml file.
Either way, the structure could look like this (if technically possible):

\- Collection A
\-- build.yaml
\-- collection.yaml
\-- finalize.yaml
\- Collection B
\-- build.yaml
\-- collection.yaml
\-- finalize.yaml
\- templates
\-- build.yaml
\-- finalize.yaml
\-- script.sh

/Collection A/build.yaml could be:

{{ template "collection_build" . }}

... or more complex, according to the needs, using the templates defined in /templates.

By analogy, also /Collection A/finalize.yaml could be:

install:
{{ template "collection_finalize_install" .  }}

while /Collection B/finalize.yaml could be:

install:
{{ template "collection_finalize_install" .  }}
- source /etc/profile && env-update

where /templates/finalize.yaml could be:

{{ define "collection_finalize_install" }}

{{ range .Values.requires | uniq }}
  {{ if or (eq .name "X") (eq .name "gnome-common") (eq .name "gnome") }}
- glib-compile-schemas /usr/share/glib-2.0/schemas > /dev/null 2>&1
  {{ end }}
{{ end }}
- update-mime-database /usr/share/mime/
- ldconfig

{{ end }}

I am aware of the fact that finalizers would be generated and packed rather than run at install time, right?

Another question here is: could be possible to have a finalizer handling to run once a set of commands that each package would have? Currently, at the end of installation, when several packages are handled, their finalizers run each, so it comes to run repeatedly the same batch of commands again and again.

Describe alternatives you've considered

Additional context

This is just a draft, could be extended to regular definition.yaml too.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.