Evaluation of reclass and possible inventory alternatives

[MatteoVoges]

Hello, I want to share my thoughts about the current inventory solution with reclass, pro's and con's of it and other inventory alternatives and the introduction of a pluggable inventory system.

Current Solution with reclass

Advantages ✔️

• good structure (targets and classes) by default
• meta information for targets

Disadvantages ❌

• old code (legacy python2) --> hard to extend and maintain
• currently no support for default values and interpolation with relative paths (but upcoming)
• no python package, reclass as submodule isn't that nice

Your opinion

Now your opinion and ideas are needed:
What do you like about reclass? What features are missing to improve your workflows? What else could be added to my list above?

Inventory alternatives

OmegaConf

Advantages ✔️

• is actively maintained, regularly released
• many users (if it's used, then it has to be good )
• support of relative paths and default values
• support of custom resolvers --> opportunity to define our own tags
• easy to extend due open-source and possible collaborations
• python package

Disadvantages ❌

• no structure by default, but easy to adapt the structure of reclass, or think of a new structure!
• some mismatches in syntax to reclass, but easy to fix with a migration-script (no disadvantage at all)

There are several more options, but OmegaConf seems really easy to use, easy to integrate into kapitan and its actively maintained.

All type of feedback is welcome, so ask questions, share your thoughts with us and let us also know, which features you want to have in your inventory in general!

Other

• figgy: Cloud bases config with secret management and own version control
  • not suitable for kapitan as we need local yaml config
• yamlpath: yaml library that supports loading and merging nodes, but no interpolation
• hiyapyco: yaml config
  • supports loading and merging nodes
  • interpolation only with jinja2
  • uses GNU-3.0 License

---

References

• Reclass: Repository, Documentation
• OmegaConf: Repository, Documentation
• Provide an alternative backend for the inventory #990
• feat(inventory): introduce OmegaConf as optional inventory backend #995
• refactor: prepare support for optional inventory backends #1003
• Slack Post

[ademariag]

Thank you @MatteoVoges, great work. Is there a branch with a working setup that we could test?

[MatteoVoges]

I'm currently working on a migration script that turns reclass inventories into omegaConf compatible inventories. Then I could apply this to our example inventory and publish a finished version on a branch in the kapitan repo, so that you don't have to checkout the nexenio fork. The core features of the inventory are already available, but some flags (like compose-node-name and such) have to be done.

[MatteoVoges]

Is there a branch with a working setup that we could test?

You can test now the new features regarding omegaconf:

Installation and setup

Docker

Create a new Dockerfile and paste the following contents in there:

Dockerfile:

FROM python:3.10-slim AS python-builder

USER root

RUN apt-get update \
    && apt-get install --no-install-recommends -y \
    curl \
    build-essential \
    git \
    ssh-client \
    libmagic1 \
    gnupg \
    ca-certificates \
    gosu

RUN git clone \
    --recurse-submodules -j8 \
    --branch pluggable-inventory \
    https://github.com/neXenio/kapitan.git /kapitan

WORKDIR /kapitan

# build kapitan
RUN pip install -e .

# Install Helm
RUN curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
  && chmod 700 get_helm.sh \
  && HELM_INSTALL_DIR=/usr/local/bin ./get_helm.sh \
  && rm get_helm.sh

RUN apt-get install -y default-jre

# install omegaconf
RUN make pull_oc

ENTRYPOINT ["kapitan"]

Build the image with docker build <path> -t kapitan:dev. Now replace your image in your ./kapitan script.

Manual (Dev Mode)

1. Create a new virtual enviroment: python -m venv omegaconfenv
2. activate your environment source omegaconf/bin/activate
3. Install kapitan

• git clone --branch pluggable-inventory https://github.com/nexenio/kapitan.git
• cd kapitan
• git submodule update --init
• poetry install

4. Install Omegaconf: make pull_oc

Usage

First I highly recommend you to backup your inventory or creating a test inventory, in case something works not as expected.
To activate the feature you have to enable the flag: --omegaconf. When you run this the first time you also have to specify --migrate, to replace the yaml paths in the references.

So run kapitan compile --omegaconf --migrate. The inventory speed could be slower than it was before with reclass, but there are lots of performance boosters planned.

If you installed the project in dev mode, you are able to experiment with costum resolvers. At the moment there are several resolvers already enabled. Here are some highlights:

• ${env:PATH}: access environment variables
• ${select:<yaml_path>, default} : interpolation with default value, if the path doesn't exist
• ${key:}: get the name of the key
• ${fullkey:}: get the full name of the key

You can extend these resolvers or implement your own in kapitan/omegaconf_inv.py . Starting at line 148 you can modify the existing resolver dep and define any python object you can imagine. Note that you can input several input arguments and treat a resolver as a regular python function.

---

If you have problems with setup or questions in general, please leave them here and I'm happy to answer them.

[uberspot]

How much effort would it be to port reclass to python3 and compile it as a package do you think? VS migrating everyone's inventories and semantics. Cause even with OmegaConf it seems like you'll still need a translation later from inventory yaml to omegaconf constructs?

[MatteoVoges]

The effort for migration and the difference in syntax will be as small as possible. At the moment the only thing is, that the paths in the interpolations will use . instead of :, because they are the official yaml-path-notation. This happens in a migration step, so you don't have to touch thousands of files.
The main benefit from using omegaconf is targetwise-loading (future speedup potential) and the use of custom resolvers. They work like a generator for the inventory and can create large configurations with very less specification.
I will be presenting my results at the workgroup-meetings, so please join, if you want to see some examples or if you have more questions.

[ademariag]

@uberspot the reasons are not just to do with python3 port, but in general to do with the inability to easily extend and improve on reclass. Plan is to maintain compatibilty with reclass, so this would be an addition for people that want to move to use it.