Libelektra: cache: système d'exportation kdb

Bien sûr pourquoi pas? Il exporte également la version et d'autres éléments inutiles pour l'importation. Vous pouvez ajouter --without-elektra pour éviter d'exporter ces pièces.

Pour l'enregistreur shell, je m'attendrais également à ce que seule la partie donnée soit sauvegardée et restaurée.

Bien sûr pourquoi pas?

Est-ce que kdbSet supprime d'une manière ou d'une autre? Il semble erroné de sérialiser ces clés, quand elles sont codées en dur via une partie spéciale du plugin get functions ...

Pour les informations de version, kdbSet vérifie s'ils sont identiques et ignore kdbSet s'ils le sont. Sinon, une erreur est générée.

Pour les modules (iirc), il n'y a pas de kdbSet, donc les clés à définir sont simplement ignorées. Iirc le plugin "constantes" a le même comportement Il est généralement monté system / info / elektra donc pas dans system / elektra. Peut-être devrions-nous changer cela pour rendre --without-elektra plus utile?

Mais quoi qu'il en soit: les deux comportements (ignorer et vérifier les clés identiques) ne devraient pas nuire à une importation.

Donc, pour la situation actuelle de l'Elektra assez instable, cela prend tout son sens: les importations de système / elektra sont rejetées à moins que la version ne soit identique. Pour éviter cette erreur, --without-elektra peut être passé.

Après la version 1.0, nous pouvons en fait être plus détendus et accepter les importations depuis les versions 1.0 ou supérieures d'Elektra. ( @mpranj qu'en pensez-vous?)

Le texte doit alors être adapté, actuellement c'est:

kdb import system < sys
Sorry, module kdb issued the error C01320:
Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version/constants/KDB_VERSION_MICRO (expected system/elektra/version/constants/KDB_VERSION_MICRO) was tried to be modified to '1' (expected '2')

Quoi qu'il en soit, votre question donne un aperçu de la façon dont nous pouvons améliorer la documentation de --without-elektra . L'idée de --without-elektra dans le contexte de l'import / export est que soit:

1. tous les internas d'Elektra sont exportés mais nous avons également le contrôle de version pour ne pas gâcher Elektra.
2. vous n'importez / exportez pas les internas d'Elektra, donc la version d'Elektra n'a pas d'importance (seule la version du plugin de stockage fait)

Après 1.0, nous pouvons en fait être plus détendus

Je suis d'accord avec les suggestions.

Comme @kodebach l'a mentionné, il est en quelque sorte étrange que cela apparaisse tout à l'heure dans # 3115 et n'apparaisse pas auparavant. Bien que l'ajout de --without-elektra aurait probablement dû être là en premier lieu pour la sauvegarde et la restauration, il semble toujours que le PR ait changé un certain comportement.

@kodebach avez-vous réactivé le cache pour ces tests? J'aimerais attendre que le reste du PR soit terminé pour que je puisse réparer mmapstorage et le cache. J'ai vu des erreurs telles / similaires ( Postcondition of backend was violated: drop key [...] not belonging to [...] ) alors que le cache n'était pas implémenté correctement.

avez-vous réactivé le cache pour ces tests?

Oui, le cache est entièrement activé.

pour que je puisse réparer mmapstorage et cache

mmapstorage fonctionne déjà. Il s'avère que j'avais un key au lieu de ukey quelque part.

Le cache semble également fonctionner, mis à part le problème du test de démontage global. La dernière fois que j'ai vérifié, l'erreur ne s'est pas produite lorsque le cache n'est pas compilé.

J'ai changé des parties de kdbGet , elektraCacheGet et des fonctions associées. Il est probable que j'ai cassé quelque chose, mais comme les choses que j'ai changées doivent probablement être modifiées à nouveau après le # 2969, je ne pense pas que vous ayez besoin de jeter un coup d'œil maintenant.

D'accord. Je suggère que si le cache + mmapstorage cause des problèmes, vous le gardez simplement désactivé jusqu'à la toute fin et nous l'activons, nous l'adaptons ensuite.

Le PR est un changement assez fondamental, donc ce sera beaucoup plus facile si vous ne restez pas bloqué à cause d'un comportement de cache cassé. Quand il est pratiquement prêt, activez à nouveau le cache et envoyez-moi un ping pour que je puisse jeter un coup d'œil et réparer les restes.

@mpranj : Je vous ai assigné car c'est lié au cache.

Je ne peux rien reproduire de similaire sur le master actuel. Je ne peux pas faire grand-chose là-bas à moins que quelqu'un sache comment le reproduire là-bas, mais je soupçonne qu'il n'est pas présent sur le master.

Sur la branche de # 3115, j'obtiens les erreurs comme décrit. @kodebach dois-je y aller et essayer de réparer les éléments liés au cache en plus de vos modifications ou est-il trop tôt pour travailler dessus? À quel point est-il difficile de rebaser la branche du maître actuellement (plugin pré-backend)?

Je pense que cela ne vaut pas la peine de travailler sur le # 3115 jusqu'à ce que le # 2969 et les PR associés soient fusionnés. Après cela, je vais rebaser et essayer de terminer le PR. Je voudrais rebaser le moins possible, car vous devez essentiellement vérifier tous les commits pour tout ce qui repose sur la syntaxe des noms de clés pour assurer un rebase correct.

Si vous le souhaitez, vous pouvez bien sûr rechercher le bogue dans la version actuelle du PR. Cependant, pour autant que je me souvienne, j'ai essayé ceci sur master avant de créer le problème, donc peut-être qu'il a été corrigé entre-temps.

Je pense que cela ne vaut pas la peine de travailler sur le # 3115 jusqu'à ce que le # 2969 et les PR associés soient fusionnés.

D'accord merci! Alors attendons et vérifions ce problème après la fusion des PR associés!

Est-il possible de marquer d'une manière ou d'une autre les problèmes qu'ils attendent de certains PR? J'ai changé le titre pour l'instant.

J'ai réussi à reproduire cela sur master aujourd'hui. Plus précisément, j'ai construit scripts/docker/fedora/32/Dockerfile (techniquement à partir de # 3447 et non à partir de master , mais le fichier est le même et complètement autonome). J'ai ensuite commencé un conteneur avec

docker run -it -w /home/jenkins elektra-fedora-32:latest

et à l'intérieur du conteneur ont couru les lignes suivantes:

git clone https://github.com/ElektraInitiative/libelektra
cd libelektra && mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DKDB_DB_SPEC="$PWD/config/spec" -DKDB_DB_SYSTEM="$PWD/config/system" -DKDB_DB_USER="cdbg-1/.config" -DCMAKE_INSTALL_PREFIX="$PWD/install" -DINSTALL_SYSTEM_FILES=OFF -DENABLE_DEBUG=ON -DENABLE_LOGGER=ON -DCMAKE_EXPORT_COMPILE_COMMANDS=TRUE -DPLUGINS="ALL;-lua;-ccode;-tcl" -DBINDINGS="ALL" -DCOMMON_FLAGS="-Werror"
make -j 24
bin/kdb export system toml

Le résultat de la dernière commande était:

elektra.modules.cache = "cache plugin waits for your orders"
elektra.modules.cache.exports = ""
elektra.modules.cache.exports.close = "(binary)"
elektra.modules.cache.exports.get = "(binary)"
elektra.modules.cache.exports.open = "(binary)"
elektra.modules.cache.exports.set = "(binary)"
elektra.modules.cache.infos = "Information about the cache plugin is in keys below"
elektra.modules.cache.infos.author = "Mihael Pranjic <[email protected]>"
elektra.modules.cache.infos.licence = "BSD"
elektra.modules.cache.infos.metadata = ""
elektra.modules.cache.infos.needs = ""
elektra.modules.cache.infos.placements = "pregetcache postgetcache"
elektra.modules.cache.infos.provides = ""
elektra.modules.cache.infos.recommends = ""
elektra.modules.cache.infos.status = "maintained unittest shelltest specific global"
elektra.modules.cache.infos.version = 1
elektra.modules.dump = "dump plugin waits for your orders"
elektra.modules.dump.config.needs.fcrypt.textmode = 0
elektra.modules.dump.exports = ""
elektra.modules.dump.exports.get = "(binary)"
elektra.modules.dump.exports.serialise = "(binary)"
elektra.modules.dump.exports.set = "(binary)"
elektra.modules.dump.exports.unserialise = "(binary)"
elektra.modules.dump.infos = "Information about the dump plugin is in keys below"
elektra.modules.dump.infos.author = "Markus Raab <[email protected]>"
elektra.modules.dump.infos.licence = "BSD"
elektra.modules.dump.infos.metadata = ""
elektra.modules.dump.infos.needs = ""
elektra.modules.dump.infos.placements = "getstorage setstorage"
elektra.modules.dump.infos.provides = "storage/dump storage dump"
elektra.modules.dump.infos.recommends = ""
elektra.modules.dump.infos.status = "productive maintained conformant unittest tested nodep -1000 default"
elektra.modules.dump.infos.version = 1
elektra.modules.list = "list plugin waits for your orders"
elektra.modules.list.exports = ""
elektra.modules.list.exports.addPlugin = "(binary)"
elektra.modules.list.exports.close = "(binary)"
elektra.modules.list.exports.deferredCall = "(binary)"
elektra.modules.list.exports.editPlugin = "(binary)"
elektra.modules.list.exports.error = "(binary)"
elektra.modules.list.exports.findplugin = "(binary)"
elektra.modules.list.exports.get = "(binary)"
elektra.modules.list.exports.mountplugin = "(binary)"
elektra.modules.list.exports.open = "(binary)"
elektra.modules.list.exports.set = "(binary)"
elektra.modules.list.exports.unmountplugin = "(binary)"
elektra.modules.list.infos = "Information about the list plugin is in keys below"
elektra.modules.list.infos.author = "Thomas Waser <[email protected]>"
elektra.modules.list.infos.licence = "BSD"
elektra.modules.list.infos.needs = ""
elektra.modules.list.infos.placements = "pregetstorage procgetstorage postgetstorage postgetcleanup presetstorage presetcleanup precommit postcommit prerollback postrollback"
elektra.modules.list.infos.provides = ""
elektra.modules.list.infos.status = "unittest nodep libc configurable global"
elektra.modules.list.infos.version = 1
elektra.modules.resolver_fm_hpu_b = "resolver_fm_hpu_b plugin waits for your orders"
elektra.modules.resolver_fm_hpu_b.constants = ""
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_BASE = "fm"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_SYSTEM = "b"
elektra.modules.resolver_fm_hpu_b.constants.ELEKTRA_VARIANT_USER = "hpu"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_DIR = ".dir"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_HOME = "/home"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SPEC = "/home/jenkins/libelektra/build/config/spec"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_SYSTEM = "/home/jenkins/libelektra/build/config/system"
elektra.modules.resolver_fm_hpu_b.constants.KDB_DB_USER = "cdbg-1/.config"
elektra.modules.resolver_fm_hpu_b.exports = ""
elektra.modules.resolver_fm_hpu_b.exports.checkfile = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.close = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.commit = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.error = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.filename = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.freeHandle = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.get = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.open = "(binary)"
elektra.modules.resolver_fm_hpu_b.exports.set = "(binary)"
elektra.modules.resolver_fm_hpu_b.infos = "All information you want to know is in keys below"
elektra.modules.resolver_fm_hpu_b.infos.author = "Markus Raab <[email protected]>"
elektra.modules.resolver_fm_hpu_b.infos.licence = "BSD"
elektra.modules.resolver_fm_hpu_b.infos.needs = ""
elektra.modules.resolver_fm_hpu_b.infos.placements = "rollback getresolver setresolver commit"
elektra.modules.resolver_fm_hpu_b.infos.provides = "resolver"
elektra.modules.resolver_fm_hpu_b.infos.status = "productive maintained specific unittest tested libc nodep configurable default"
elektra.modules.resolver_fm_hpu_b.infos.version = 1
elektra.version = "Below are version information of the Elektra Library you are currently using"
elektra.version.constants = ""
elektra.version.constants.KDB_VERSION = "0.9.2"
elektra.version.constants.KDB_VERSION_MAJOR = 0
elektra.version.constants.KDB_VERSION_MINOR = 9
elektra.version.constants.KDB_VERSION_PATCH = 2
elektra.version.constants.SO_VERSION = 4
elektra.version.infos = "All information you want to know"
elektra.version.infos.author = "Markus Raab <[email protected]>"
elektra.version.infos.description = "Information of your Elektra Installation"
elektra.version.infos.licence = "BSD"
elektra.version.infos.version = 1

(REMARQUE: j'ai supprimé les clés .description de la sortie, car elles contiennent la chaîne ``` et cassent donc le formatage Markdown de Github)

IMO, la sortie doit être vide, car toutes les clés sont dérivées de l'installation spécifique d'Elektra et ne doivent jamais être importées dans une KDB. L'exportation des clés version.constants pourrait avoir du sens, si kdb import ignore correctement (les autres clés version ne devraient pas non plus être exportées).

~ Les problèmes Postcondition of backend was violated: drop key system:/elektra/modules/cache/infos/licence not belonging to "system:/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint se produisent uniquement dans # 3447 et uniquement pour le plugin cache . Il y a donc toujours un bogue dans # 3447. Cependant, la résolution de ce problème kdb export éliminerait également le problème. ~

CORRECTION: Les problèmes de postcondition se produisent également dans le conteneur Docker.

Dans le conteneur d'en haut, j'ai couru (directement après les autres trucs):

ctest -R kdb_global_umount --output-on-failure

Après cela, toute commande kdb qui essaie d'accéder à la KDB rapporte beaucoup d'avertissements postcondition , par exemple kdb ls system .

De plus, si j'essaye d'exécuter kdb rm -r system , j'obtiens:

Interface: Read only plugin, 'kdbSet' not supported but the key system/elektra/version (value Below are version information of the Elektra Library you are currently using) tried to be removed

Cet échec de kdb rm -r system est intentionnel. Qu'est-ce que vous attendiez?

Je dois admettre, cependant, que le message d'erreur est assez mauvais (même grammaticalement et sémantiquement: l'utilisateur a essayé quelque chose, pas la clé).

Qu'est-ce que vous attendiez?

Pour être juste, oui kdb rm -r system n'a pas beaucoup de sens dans un vrai système. Sur une configuration de développement, cela peut être utile (mais la suppression manuelle des fichiers n'est pas non plus difficile).

Je dois admettre, cependant, que le message d'erreur est assez mauvais

Je pense que c'est ce qui m'a le plus dérouté. Si le message disait quelque chose comme "suppression ... non autorisée", j'aurais compris que j'ai fait quelque chose de mal. De plus AFAIK nous avons défini Interface Errors comme une erreur dans le code et non comme quelque chose de causé par l'utilisateur.

En ce qui concerne le plugin version et les plugins en lecture seule en général: je pense qu'il devrait y avoir un moyen d'ignorer ces erreurs des plugins en lecture seule lors de l'appel de kdb rm (peut-être kdb rm -rf ).
À un certain niveau, "supprimer" les clés en lecture seule a du sens, du moins lorsque nous supprimons tout ce qui se trouve sous le point de montage en lecture seule en même temps. kdb rm -r some/mountpoint devrait supprimer tout le fichier de configuration sous-jacent pour some/mountpoint , c'est-à-dire que la post-condition est qu'il n'y a pas de fichier de configuration. Puisque les plugins en lecture seule (au moins ceux qui fonctionnent comme version ) n'ont pas de fichiers de configuration, la post-condition est automatiquement satisfaite.

Sur une configuration de développement, cela pourrait être utile

Pour le développement, il y a kdb reset .

Si le message disait quelque chose comme "suppression ... non autorisée"

Je suis complètement d'accord! Qu'en est-il du # 3498?

peut-être kdb rm -rf

Je trouve -f déroutant, car vous ne pouvez pas le forcer mais seulement l'ignorer, donc --without-elektra serait-il mieux adapté?

devrait supprimer tout le fichier de configuration sous-jacent pour

Oui, c'est le cas et le résolveur s'en charge.

la post-condition est automatiquement satisfaite.

Naja, il y a aussi la post-condition qu'après kdb rm key kdb get key retourne une clé introuvable. Cette post-condition ne serait pas remplie.

Changer le message d'erreur devrait suffire

Y a-t-il maintenant des bogues restants décrits dans ce problème?

AFAIK celui-ci et le prochain commentaire (c'est-à-dire le problème d'origine) ne sont toujours pas résolus: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Désolé, il semble que j'ai mal compris ce problème au début. Permettez-moi de récapituler pour voir si je comprends bien maintenant.

Du point de vue du cache, nous voulons réutiliser les fichiers mmap autant que possible. Ainsi, si quelqu'un appelle kdbGet sur "system/this" et que le point de montage est en fait "system" , nous persisterons complètement "system" . Quand quelqu'un appelle ensuite kdbGet sur "system/other" , le cache est déjà présent, ce qui accélère un peu les choses. Nous créons essentiellement un fichier de cache mmap par point de montage, mais nous stockons TOUTES les clés sous le point de montage.

Si je comprends bien le problème maintenant, votre point est que la mise en cache "system/elektra/modules" et similaires est à la fois:

1. erroné et
2. non pertinent, car la récupération de ces clés est de toute façon rapide.

EDIT: Actuellement, obtenir le cache évite complètement ksAppend et d'autres opérations. Ainsi, nous préservons l'OPMPHM et tout. Si nous commençons ksAppend-ing "system/elektra/modules" au reste du point de montage du système, nous perdrons certainement des performances. Ce n'est peut-être pas pertinent pour l'espace de noms système, mais cela nuirait certainement aux performances si nous avons des cas extrêmes comme celui-ci partout.

Remarque: j'ai marqué les commentaires concernant les éléments kdb rm system comme résolus, ils sont donc masqués par Github. Cela devrait rendre ce problème un peu plus clair.

Si je comprends bien le problème maintenant, votre point est que la mise en cache "system/elektra/modules" et similaires est à la fois:

1. erroné et
2. non pertinent, car la récupération de ces clés est de toute façon rapide.

Le simple fait de les mettre en cache est erroné, oui, mais nous pourrions toujours les mettre en cache, tant qu'il y a une logique pour détecter que les clés ont changé. Je ne peux pas faire de commentaire sur la vitesse, mais l'utilisation du cache peut être encore plus rapide. Comme vous l'avez dit, cela évite ksAppend et évite également de nombreux appels aux plugins.

Le problème d'origine concerne simplement le comportement de kdb export . Sa sortie ne doit system/elektra/modules ou system/elektra/version , car elles sont spécifiques à l'installation d'Elektra et ne doivent pas être importées dans une autre KDB.

Je n'ai pas enquêté sur l'origine de ces clés, donc je ne suis pas sûr que le plugin cache soit réellement impliqué ici. La meilleure solution pourrait être de toujours ksCut ces parties en kdb export . De cette façon, le problème ne peut pas réapparaître si quelque chose change.

Il y a aussi le problème «La postcondition du backend a été violée». D'après ce que je comprends jusqu'à présent, ce problème est causé par kdb export produisant des clés dans system/elektra/modules , mais je suis sûr à 100%:

Si vous suivez les étapes de https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469, puis exécutez

ctest -R kdb_global_umount --output-on-failure

bin/kdb ls system

(comme je l'ai dit dans le prochain commentaire), vous obtiendrez beaucoup de:

Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "(null)" with name "(null)" because it is hidden by other mountpoint

C'est en fait la seule référence au plugin cache . AFAICT voici ce qui se passe ici:

• La procédure "Sauvegarde et restauration" du test utilise kdb export et kdb import .
• D'une manière ou d'une autre, cela entraîne l'écriture persistante des clés de system/elektra/modules/cache dans le fichier elektra.ecf .
• Lorsque nous appelons ensuite une forme quelconque de kdbGet via par exemple kdb ls system nous avons le problème.
• Je ne sais pas exactement quel est ce problème, mais je suis tout à fait certain qu'une clé system/elektra/modules/... ne devrait jamais être écrite sur le disque.
• La seule façon de récupérer est de supprimer _manuellement_ les clés system/elektra/modules/... de elektra.ecf .

Peut-être que cela doit être corrigé dans kdb import pas dans le cache.

Merci beaucoup d'avoir signalé cela!

Le cache stocke définitivement ces (toutes) clés si elles sont présentes dans le KeySet retourné à partir de kdbGet . Il n'y a aucune exception pour le cache. Cependant, comme vous l'avez dit, cela n'a aucun sens d'autoriser ces clés sur kdb import . Je vais voir si je peux reproduire cela à partir de votre description et résoudre le problème.

Si le problème se produit uniquement lors de l'utilisation de kdb import , je supprimerais simplement ces clés spéciales lors de l'importation.

Je suis d'accord avec @mpranj pour

Sa sortie ne doit jamais contenir de clés sous system / elektra / modules ou system / elektra / version car elles sont spécifiques à l'installation d'Elektra et ne doivent pas être importées dans une autre KDB.

L'exportation n'est pas seulement pour l'importation, mais aussi pour afficher plusieurs clés / valeurs pour un utilisateur. Il n'y a rien de mal avec kdb export system/elektra/version/constants simpleini pour voir toutes les informations de version.

Je n'ai pas enquêté sur l'origine de ces clés, donc je ne suis pas sûr que le plugin de cache soit réellement impliqué ici. La meilleure solution pourrait être de toujours ksCut ces parties dans l'exportation kdb. De cette façon, le problème ne peut pas réapparaître si quelque chose change.

Un tel ksCut se produit lorsque vous dites --without-elektra . Ce que nous pourrions faire, c'est changer la valeur par défaut: exclure elektra par défaut, sauf lors de l'importation / exportation explicite / elektra ou en disant --with-elektra .

La postcondition du backend a été violée

Cela semble être un bug sans rapport. (Peut-être que shellrecorder n'utilise pas --without-elektra ). https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 semble cependant devoir l'être. (Je ne peux pas reproduire, j'obtiens Error response from daemon: pull access denied for elektra-fedora-32, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. )

Je ne peux pas reproduire

Nous n'avons pas publié cette image sur Docker Hub.

La condition préalable ici est qu'il construise l'image docker à partir de scripts/docker/fedora/32/Dockerfile et qu'il ait tagué la construction avec -t elektra-fedora-32:latest lors de l'exécution de docker build .

Quelque chose comme:

cd scripts/docker/fedora/32/
docker build -t elektra-fedora-32:latest -f ./Dockerfile .

Merci, oui je peux reproduire les problèmes Postcondition of backend was violated maintenant sur master (comme décrit par @kodebach dans l'image docker puis en utilisant les commandes de montage globales):

 Sorry, 17 warnings were issued ;(
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/close not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/get not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/open not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/exports/set not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/author not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/description not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/licence not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/metadata not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/needs not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/placements not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/provides not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/recommends not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/status not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint
        Sorry, module kdb issued the warning C01320:
        Interface: Postcondition of backend was violated: drop key system/elektra/modules/cache/infos/version not belonging to "system/elektra/modules/cache" with name "modules" but instead to "" with name "default" because it is hidden by other mountpoint

Le problème n'est clairement pas lié à kdb export car il se produit également, par exemple avec kdb ls ou kdb cache clear .

Il est intéressant kdb cache clear noter que kdb utilisent d'abord KDB pour obtenir leur configuration).

@mpranj avez-vous une idée?

Ce que nous pourrions faire, c'est changer la valeur par défaut: exclure elektra par défaut, sauf lorsque vous importez / exportez / elektra explicitement ou en disant --with-elektra.

Oui, ce serait certainement une meilleure solution. Idéalement, nous ferions également la différence entre system/elektra/modules / system/elektra/version et le reste de system/elektra . La configuration du point de montage et la configuration globale du plugin sont beaucoup plus utiles que les modules et les clés de version (qui sont générés lors de l'exécution).

Le problème n'est clairement pas lié à kdb export car il se produit également, par exemple avec kdb ls ou kdb cache clear .

Comme je l'ai dit, le truc "Postcondition" est probablement un bogue dans kdb import .

Fait intéressant, kdb cache clear n'aide pas

Pourquoi le ferait-il? Comme je l'ai dit, le problème est que les clés system/elektra/modules sont stockées dans elektra.ecf . Si vous avez suivi mes étapes ci-dessus (spécifiquement utilisé les mêmes options cmake ), vous pouvez le voir en exécutant

cat config/system/elektra.ecf

dans le répertoire build .

Comme je l'ai dit, le truc "Postcondition" est probablement un bogue dans l'importation kdb.

Comme kdb import ne fait pas beaucoup plus que créer un KeySet et appeler kdbSet je crains que le problème se situe quelque part dans kdbSet . Le comportement correct de stocker quoi que ce soit dans system/elektra/modules doit être une erreur ou un rejet, et certainement pas persistant. Mais évidemment ce n'est pas le comportement:

kdb set system/elektra/modules/NOTALLOWED
kdb ls system/elektra/modules
#> system/elektra/modules/NOTALLOWED
#> system/elektra/modules/cache
...

Ainsi, lorsqu'un plugin NOTALLOWED est monté, nous avons le problème décrit ici. Nous avons donc besoin de kdbSet pour échouer sur toute tentative d'écriture dans system/elektra/modules .

En fait, nous devons définir la sémantique de toute la hiérarchie /elektra , ce qui est probablement une tâche plus importante ...

le problème est que les clés système / elektra / modules sont stockées dans elektra.ecf

Désolé, je ne l'ai pas vu quand je sautais entre les commentaires pour essayer de le reproduire.