Add Feature Flags e.g. for instance configurations #3

New Issue

2026-03-27T14:10:08Z

simon commented

2026-03-27 14:10:08 +00:00

We want to be able to group certain configs, even if they don't belong to a specific recipe or depend on the existence of a specific recipe.

Usacase:

Our current default instance config looks like this:

authentik:
    env:
        APPLICATIONS: 
            Calendar: https://nextcloud.example.com/apps/calendar/
            BBB: https://nextcloud.example.com/apps/bbb
        EXTRA_ICONS:
            Calendar: ~/.abra/recipes/authentik/icons/calendar.svg
            BBB: ~/.abra/recipes/authentik/icons/bbb.png
    initial-hooks:
      - local import_user managed-kolli/<VM-Folder>/demo.kollicloud.de.users.csv
wekan:
nextcloud:
      initial-hooks:
        - app install_bbb
onlyoffice:
collabora:
wordpress:
vikunja:
matrix-synapse:
element-web:
rallly:
outline:
zammad:
hedgedoc:
kimai:
pretix:
vaultwarden:

There are no apps "bbb" or "calendar" - but it would be nice if we could enable these features just as easy as all the other ones, with a certain default config and without the need to override this in all instances.

Those features could work in a similar way as the combine.yml in the alakazam repo.
e.g.:

FEATURES:
  calendar:
  bbb:
authentik:
nextcloud:
...

copied over from https://git.local-it.org/KolliCloud-intern/development/issues/295

We want to be able to group certain configs, even if they don't belong to a specific recipe or depend on the existence of a specific recipe. ## Usacase: Our current default instance config looks like this: ``` authentik: env: APPLICATIONS: Calendar: https://nextcloud.example.com/apps/calendar/ BBB: https://nextcloud.example.com/apps/bbb EXTRA_ICONS: Calendar: ~/.abra/recipes/authentik/icons/calendar.svg BBB: ~/.abra/recipes/authentik/icons/bbb.png initial-hooks: - local import_user managed-kolli/<VM-Folder>/demo.kollicloud.de.users.csv wekan: nextcloud: initial-hooks: - app install_bbb onlyoffice: collabora: wordpress: vikunja: matrix-synapse: element-web: rallly: outline: zammad: hedgedoc: kimai: pretix: vaultwarden: ``` There are no apps "bbb" or "calendar" - but it would be nice if we could enable these features just as easy as all the other ones, with a certain default config and without the need to override this in all instances. Those features could work in a similar way as the combine.yml in the alakazam repo. e.g.: ``` FEATURES: calendar: bbb: authentik: nextcloud: ... ``` --- *copied over from https://git.local-it.org/KolliCloud-intern/development/issues/295*

👀 1

simon referenced this issue from toolshed/abra

2026-04-09 07:34:52 +00:00

interface for abra app config #818

dannygroenewegen commented

2026-05-21 09:01:06 +00:00

Yes, this would prevent a bunch of duplication. So a feature is a set of configs (env, *-hooks, secrets) that, when activated, is applied to one or more recipes. Would there also be a use case to share these features (a bit analogous to recipe-specific features that could be implemented as an abra.sh function), or would most features be a specific choice for the set of deployments you're offering?

We could start with a features.yml file somewhere in the root path and decide later whether it makes sense to share features in this repo or in an alakazam-features repo?

Taking bbb as an example: you would create a features.yml in your root path:

FEATURES:
  bbb:
    authentik:
       env:
         APPLICATIONS:
           BBB: https://nextcloud.example.com/apps/bbb
     nextcloud:
       initial-hooks
         - app install_bbb
  calendar:
    ...

And then the instance config becomes:

FEATURES:
  bbb:
  calendar:
authentik:
nextcloud:
...

(I don't think this example actually works, the calendar feature would probably overwrite the APPLICATIONS env that was set by the bbb feature. So instead, for the authentik part it should probably call add_single_application in initial-hooks?)

I am wondering whether features is the most suitable name for this. Could you consider this a feature of the instance deployment? Or might CONFIG-SETS and config-sets.yml be a more generic name for what this does, applying a set of configs to the instance?

And what about disabling it: Enabling the feature in alaka.yml of some grouped instance dir as a default, and then disabling it by setting bbb: false in an instance specific file?

Yes, this would prevent a bunch of duplication. So a feature is a set of configs (env, *-hooks, secrets) that, when activated, is applied to one or more recipes. Would there also be a use case to share these features (a bit analogous to recipe-specific features that could be implemented as an abra.sh function), or would most features be a specific choice for the set of deployments you're offering? We could start with a `features.yml` file somewhere in the root path and decide later whether it makes sense to share features in this repo or in an alakazam-features repo? Taking bbb as an example: you would create a `features.yml` in your root path: ``` FEATURES: bbb: authentik: env: APPLICATIONS: BBB: https://nextcloud.example.com/apps/bbb nextcloud: initial-hooks - app install_bbb calendar: ... ``` And then the instance config becomes: ``` FEATURES: bbb: calendar: authentik: nextcloud: ... ``` (I don't think this example actually works, the calendar feature would probably overwrite the APPLICATIONS env that was set by the bbb feature. So instead, for the authentik part it should probably call add_single_application in initial-hooks?) I am wondering whether features is the most suitable name for this. Could you consider this a feature of the instance deployment? Or might CONFIG-SETS and `config-sets.yml` be a more generic name for what this does, applying a set of configs to the instance? And what about disabling it: Enabling the feature in alaka.yml of some grouped instance dir as a default, and then disabling it by setting `bbb: false` in an instance specific file?

❤️ 3

simon commented

2026-05-21 15:35:07 +00:00

Yes to all of this! 😍

moritz commented

2026-05-26 15:21:40 +00:00

I also like all these ideas!

(I don't think this example actually works, the calendar feature would probably overwrite the APPLICATIONS env that was set by the bbb feature. So instead, for the authentik part it should probably call add_single_application in initial-hooks?)

This is an unfortunately undocumented feature of alakazam: if the value of an env is a dict (like APPLICATIONS) , in the first step the dict will be merged and then it will be converted into a json. Therefore the APPLICATIONS env won't be overwritten.

I also like all these ideas! > (I don't think this example actually works, the calendar feature would probably overwrite the APPLICATIONS env that was set by the bbb feature. So instead, for the authentik part it should probably call add_single_application in initial-hooks?) This is an unfortunately undocumented feature of alakazam: if the value of an env is a dict (like `APPLICATIONS`) , in the first step the dict will be merged and then it will be converted into a json. Therefore the `APPLICATIONS` env won't be overwritten.

dannygroenewegen referenced this issue

2026-05-28 10:05:33 +00:00

feat: add config-sets support #8

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/alakazam#3