[FLOSS H1] First impressions

[0x6178656c]

After playing around with Elektra a bit I think I understand some of the key features.

Clear

• Elektra provides an interface to configuration management and exposes configuration as a key-value store.
• There are different namespaces with different purposes.
  • For instance, for cascading lookups (for keys without the namespace specified) the namespaces are traversed in a specific order.
• Files can be mounted to act as the parent node of a hierarchy.
• Elektra advocates a specific naming convention for naming of keys.

Resources

The main resource which helped me understand Elektra was reading the first four of the tutorials.

Unclear

Significance of namespaces

Although I had glimpses of understanding their significance, I still feel that I am missing some concrete examples which highlight the power of the namespace feature.

Syncing of configuration files

One configuration use case I would be interested in, but could not find any documentation on is keeping configuration files in sync.

Say there are two programs, Program A and Program B, with configuration files config_a.ini and config_b.ini and that the configuration of some values need to be the same for both programs (e.g. IP addresses, port numbers) .

Is there a way in Elektra to keep those two programs' configuration in sync? Note that I am crucially thinking of the case where Program A and Program B both know nothing about Elektra.

[kodebach]

Significance of namespaces

Yes, namespaces could be explained better. Technically, everything is there. Namespaces are separate hierarchies and a cascading lookup checks namespaces in a certain order. What I think is missing is the relation to the resolver.

When you ask Elektra for a key like user:/foo. There is something called a resolver that decides what file (*) needs to be loaded to get the key. This process in part maps the key to the file used during mounting. However, when mounting we normally don't use absolute paths. Instead we use just a filename (or a relative path). So we need to combine this filename (or relative path) with a directory. This directory is determined by the namespace. For example, the default directories for the system:/, user:/ and dir:/ namespaces are /etc/kdb, $HOME/.config and $PWD/.dir.

(*) In future other links like databases could be used instead of files, but it's easier to explain with files. If the backend doesn't use files, replace "file" with an appropriate term for the storage unit, e.g. database table.

Some namespaces also have special properties, meta:/ is used for metadata associated with keys, spec:/ is used for specifications, proc:/ is for process specific keys that aren't stored and default:/ is for default keys derived from specifications.

Syncing of configuration files

AFAIK there is no mechanism to do this right now.

[markus2330]

@0x6178656c Thank you, very valuable input!

Although I had glimpses of understanding their significance, I still feel that I am missing some concrete examples which highlight the power of the namespace feature.

Yes, I agree (more) examples are very welcome. We can keep the issue open for this (or you create a new one) if you want to work on it (later when it becomes more clear what the namespaces are). I would appreciate it.

One configuration use case I would be interested in, but could not find any documentation on is keeping configuration files in sync.

Are these configuration files on the same computer (nodes) or on different ones?

• If there are on different ones, CM tools or network file systems are ways to do it.
• If it is one computer, you probably don't want to copy but to use override/fallback links.

What doesn't exist at the moment:

• A tool that does a two-way-sync on one computer by copying changes around wouldn't be hard to write. Currently we are doing many changes in the notification system though, see [decision] Change Tracking #4554
• Another approach would be providing a --bind mount with a plugin that creates override/fallback links on every key for you. Is probably more difficult than it seems as the plugin system is currently not really designed to do this.

[kodebach]

• If it is one computer, you probably don't want to copy but to use override/fallback links.

I think you missed this part of the question:

Note that I am crucially thinking of the case where Program A and Program B both know nothing about Elektra.

The application(s) not knowing about Elektra makes things significantly more complicated.

A tool that does a two-way-sync on one computer by copying changes around wouldn't be hard to write.

I wouldn't say that. Handling conflicts between files and doing merging can always be hard. The notification and recording system deals with some of that, but not all of it.

[markus2330]

know nothing about Elektra.

It still is possible via https://www.libelektra.org/bindings/intercept_fs

The application(s) not knowing about Elektra makes things significantly more complicated.

👍

Handling conflicts between files and doing merging can always be hard.

With Elektra it is much easier, as the merging is done on key/values. And we have a 3-way merge:
https://www.libelektra.org/tutorials/merge-configuration