$darkmode
Elektra 0.9.12
|
We are proud to release Elektra 0.9.12.
Elektra serves as a universal and secure framework to access configuration settings in a global, hierarchical key database. For more information, visit https://libelektra.org.
You can also read the news on our website.
You can try out the latest Elektra release using our docker image elektra/elektra. This is the quickest way to get started with Elektra without compiling and other obstacles, simply run:
The entire logic for backends has been rewritten, to allow for more flexibility und an unlimited number of plugins. Instead of calling plugins directly, libelektra-kdb
now only calls so-called backend plugins and special hook plugins. There is a contract between libelektra-kdb
and the backend plugins. All backend plugins must adhere to this contract. To achieve this goal, most backend plugins will call other plugins (like libelektra-kdb
did previously).
The logic previously implemented in libelektra-kdb
was moved to the new default backend plugin backend
. It works like the old system, but now also allows an unlimited number of plugins in positions where that makes sense. For example, you can have unlimited postgetstorage
plugins, but only a single getresolver
.
There have also been slight changes to kdbGet
and kdbSet
. Please read their API docs to find out, if you rely on any behavior that has been altered. You can also read the new low-level docs to find out all the intricate details.
The structure of system:/elektra/mountpoints
changed as well. Take a look at the new docs, if you need to know details.
The mountpoint configuration format contains breaking changes and a manual upgrade process is needed. Follow these steps to upgrade the old mountpoint configuration to the new format:
Warning: BACK UP YOUR CONFIG FILES BEFORE UPDATING! We recommend making a backup of the file printed by
kdb file system:/elektra/mountpoints
before updating your installation. In the unlikely case that the migration script fails, you can still use the information from the backup to manually recreate your mountpoints.
To update your existing system:/elektra/mountpoints
data you can use the migration script.
Note: To run the script you must have Elektra, Python (>= 3.7) and the Python binding installed. The script uses the Python binding to manipulate
Key
s andKeySet
s, but it does not use thekdb
CLI tool, or theKDB
API. It is safe to run this script before, or after you update your Elektra installation.
By default, the script loads the file /etc/kdb/elektra.ecf
. If you changed where system:/elektra/mountpoints
is stored, you can provide an alternative path:
Note: Because the script does not use the
KDB
API it only works, if the mountpoints config file uses the defaultdump
format.If your mountpoints config file is not using the
dump
format, you may still be able to use the migration script. However, in that case, you will have to use the script before updating your Elektra installation:
- Run
kdb export system:/elektra/mountpoints dump
to get a copy of your mountpoints config indump
format- Write this data to a file and run the migration script on the file.
- To get the data back in your original format you can use
./migrate-mountpoints.py /path/to/file/from/step2 | kdb convert dump your-format > /path/to/converted/file
- Run
kdb file system:/elektra/mountpoints
to find out where your mountpoint config is stored. Make sure to back up this file, before upgrading your installation.- Now upgrade your Elektra installation.
- Copy the file
/path/to/converted/file
from step 3 to the location you got in step 4.
The script will read the old mountpoint configuration from the given file. It will convert the configuration and print the new version to stdout
.
You can inspect the output to make sure, everything is in order. When you are ready to commit the changes, you can manually edit the config file, or use:
system:/elektra/mountpoints
to new format. _()_Thanks to _(Maximilian Irlinger )_ our Key
and KeySet
datastructures are now fully copy-on-write! This means noticeably reduced memory usage for cases where keys and keysets are copied and/or duplicated!
We ran some very promising benchmarks, each were performed with 400,000 keys. All benchmarks were executed using valgrind --tool=massif --time-unit=B --max-snapshots=200 --threshold=0.1
.
Benchmark | Old Implementation | Copy-on-Write | Size Reduction | Remarks |
---|---|---|---|---|
createkeys.c | 5.3 MiB | 6.5 MiB | -22 % | |
deepdup.c | 10.5 MiB | 8.2 MiB | 22 % | |
large.c | 18.9 MiB | 15.3 MiB | 19 % | |
kdb.c | 23.5 MiB | 17.8 MiB | 24 % | |
kdbget.c | 11.0 MiB | 8.8 MiB | 20 % | |
kdbmodify.c | 11.0 MiB | 8.8 MiB | 20 % | Same results as kdbget.c |
First, it should be noted that a single key, without counting payload, is about 50% larger with the copy-on-write implementation. This explains why the createkeys.c
benchmark yields a negative reduction result. This benchmark only allocates keys, so not much improvement can be expected there. Still, as other stuff also uses heap memory, the overall memory consumption only increased by 22%, which is far less than 50%.
All other benchmarks saw meaningful reductions of heap memory used. One interesting observation is that kdbget.c
and kdbmodify.c
used exactly the same memory. This can most likely be explained by internal caching within the memory allocator of glibc
.
We also performed runtime tests on the same benchmarks using perf stat --repeat 13
to ensure no major performance regressions occur.
Benchmark | Old Implementation | Deviation | Copy-on-Write | Deviation | Runtime Increase |
---|---|---|---|---|---|
createkeys.c | 0.209572 s | 0.36 % | 0.21987 s | 0.77 % | 4.9 % |
deepdup.c | 0.23025 s | 0.47 % | 0.231804 s | 0.32 % | 0.6 % |
large.c | 1.14038 s | 0.21 % | 1.14837 s | 0.21 % | 0.7 % |
kdb.c | 1.9270 s | 2.63 % | 1.93354 s | 0.17 % | 0.3 % |
kdbget.c | 0.145663 s | 0.17 % | 0.15763 s | 0.70 % | 8.2 % |
kdbmodify.c | 0.146506 s | 0.19 % | 0.156347 s | 0.15 % | 6.7 % |
Overall, the runtime performance hit is less than 10%. The more a program does, the less the additional overhead of the copy-on-write algorithms matter. One interesting detail is that keyCopy
and keyDup
have become quite a bit faster. This can be seen by comparing the differences between createkeys.c
and deepdup.c
. The differences are 21 ms for the old implementation and 12 ms for the copy-on-write implementation.
A Free/Libre and Open Source Software (FLOSS) Initiative couldn't survive with many small contributions fixing annoying problems. This release also contains all contributions done via one term of the FLOSS course. The success was tremendous, as shown in the rest of the release notes.
A big thanks to the students for their contributions!
The following text lists news about the plugins we updated in this release.
list
plugin. _(Maximilian Irlinger )_ (Was only needed for global plugins, which are now replaced by hooks.)The text below summarizes updates to the C (and C++)-based libraries of Elektra.
keyCopy
now only allocates additional memory if KEY_CP_META
or KEY_CP_ALL
is used. _(Maximilian Irlinger )_elektraIoFdSetFlags
: file flags must be exactly one of: read only, write only or read write. _(Richard Stöckl )_elektraMergeGetConflictingKeys
and elektraMergeIsKeyConflicting
to check which keys were causing a merge conflict. _(Maximilian Irlinger )_Bindings allow you to utilize Elektra using various programming languages. This section keeps you up-to-date with the multi-language support provided by Elektra.
KDB_MAX_PATH_LENGTH
for better portability. _(Markus Raab)_memleak
. _(@0x6178656c)_global-mount
and global-umount
commands. _(Maximilian Irlinger )_kdb find
without argument. _(Christian Jonak-Moechel )_egrep
by grep -E
. _(@0x6178656c and )_elektra-granularity.md
. _()_doc/dev/error-\*
. _()_check_doc.sh
to work for contrib, dev and tutorials. _()_elektra
to libelektra
package. _()_Code
. _()_code
blocks to prevent Markdown from falsy rendering LaTeX. _()_, _()_libelektra-core
. _()_keyIsBelow
and new keyGetNextPart
functions. _()_ronn-ng
to 0.10.1.pre3. _(Mihael Pranjić )_memleak
label to test_getenv
. _(@0x6178656c)_--rerun-failed
from run_*
scripts. _()_backend
plugin to components of libelektra package. _(Mihael Pranjić )_--stacktrace
to gradle for the JNA builds. _(Maximilian Irlinger )_libpcrec++-dev
to libpcrecpp0v5
in Debian Sid. _(Richard Stöckl )_openjdk-17-jdk
in Debian Sid. _(Maximilian Irlinger )_pip3
due to upstream debian changes. _(Mihael Pranjić )_java-library.gradle
to use archiveClassifier
_(Maximilian Irlinger )_ctest --rerun-failed
to Jenkins CI. _()_macos_instance
reference, upgrade to macOS Ventura (by default), use Python 3.11 and Ruby 3.x. _(Mihael Pranjić )_testmod_dbus*
tests on macOS. _()_testmod_dbus*
tests on macOS. _()_The website is generated from the repository, so all information about plugins, bindings and tools are always up-to-date. Furthermore, we changed:
/pythongen
link on homepage. _()_TESTING.md
file. _()_, _()_We are currently working on following topics:
We closed about 150 issues for this release.
About 28 authors changed 960 files with 29400 insertions(+) and 20927 deletions(-) in 1421 commits.
Thanks to all authors for making this release possible!
We welcome new contributors! Read here about how to get started.
As first step, you could give us feedback about these release notes. Contact us via our issue tracker.
You can download the release from
The hashsums are:
The release tarball is also available signed using GnuPG from
The following GPG Key was used to sign this release: 12CC44541E1B8AD9B66AFAD55262E7353324914A
Already built API documentation can be found
Subscribe to the RSS feed to always get the release notifications.
If you also want to participate, or for any questions and comments, please contact us via our issue tracker on GitHub.
For more information, see https://libelektra.org.
Best regards, Elektra Initiative