Libelektra: cache: sistem ekspor kdb

Dibuat pada 28 Nov 2019  ·  29Komentar  ·  Sumber: ElektraInitiative/libelektra

Di # 3115 saya perhatikan bahwa kdb export system ( kdb export system:/ di PR), juga mengekspor semuanya di system/elektra/modules . Apakah ini dimaksudkan?

Untuk keadaan spesifik, lihat https://github.com/ElektraInitiative/libelektra/pull/3115#issuecomment -559576223

bug

Komentar yang paling membantu

AFAIK yang satu ini dan komentar berikutnya (yaitu masalah asli) masih belum terselesaikan: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Semua 29 komentar

Tentu saja kenapa tidak? Itu juga mengekspor versi dan hal-hal lain yang tidak berguna untuk impor. Anda dapat menambahkan --without-elektra untuk menghindari mengekspor bagian ini.

Untuk perekam shell saya juga berharap bahwa hanya bagian yang diberikan yang dicadangkan dan dipulihkan.

Tentu saja kenapa tidak?

Apakah kdbSet entah bagaimana menghapusnya? Tampaknya salah untuk membuat serial kunci ini, ketika mereka dikodekan dengan keras melalui bagian khusus dari fungsi plugin get ...

Untuk informasi versi kdbSet memeriksa apakah mereka identik dan mengabaikan kdbSet jika mereka identik. Jika tidak, kesalahan akan dihasilkan.

Untuk modul (iirc) tidak ada kdbSet, jadi kunci yang akan disetel diabaikan begitu saja. Plugin Iirc yang “konstanta” memiliki tingkah laku yang sama yaitu biasanya dipasang system / info / elektra jadi bukan di system / elektra. Mungkin kita harus mengubahnya agar --without-elektra lebih berguna?

Tapi bagaimanapun: Kedua perilaku tersebut (mengabaikan dan memeriksa kunci yang identik) seharusnya tidak mengganggu impor.

Jadi untuk situasi Elektra yang cukup tidak stabil saat ini, masuk akal: impor sistem / elektra ditolak kecuali versinya identik. Untuk menghindari kesalahan ini, --without-elektra dapat dikirimkan.

Setelah 1.0 kita sebenarnya bisa lebih santai dan menerima impor dari Elektra versi 1.0 atau lebih tinggi. ( @mpranj bagaimana menurutmu?)

Teks tersebut perlu diadaptasi, saat ini menjadi:

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')

Bagaimanapun, pertanyaan Anda memberikan wawasan tentang bagaimana kami dapat meningkatkan dokumentasi --without-elektra . Ide --without-elektra dalam konteks impor / ekspor adalah:

  1. semua internas Elektra diekspor tetapi kemudian kami juga memiliki pemeriksaan versi untuk tidak mengacaukan Elektra.
  2. Anda tidak mengimpor / mengekspor internas dari Elektra, jadi versi Elektra tidak masalah (hanya versi plugin penyimpanan yang melakukannya)

Setelah 1.0 kita sebenarnya bisa lebih rileks

Saya setuju dengan sarannya.

Seperti yang disebutkan @kodebach , agak aneh bahwa ini muncul sekarang di # 3115 dan tidak muncul sebelumnya. Saat menambahkan --without-elektra mungkin seharusnya ada di tempat pertama untuk backup-and-restore, tampaknya PR mengubah beberapa perilaku.

@ Kodebach apakah Anda mengaktifkan cache lagi untuk pengujian tersebut? Saya ingin menunggu PR lainnya selesai sehingga saya dapat memperbaiki penyimpanan dan cache. Saya telah melihat kesalahan seperti / serupa ( Postcondition of backend was violated: drop key [...] not belonging to [...] ) sementara cache tidak diimplementasikan dengan benar.

apakah Anda mengaktifkan cache lagi untuk tes tersebut?

Ya, cache sepenuhnya diaktifkan.

jadi saya bisa memperbaiki mmapstorage dan cache

mmapstorage sudah berfungsi. Ternyata saya punya key bukan ukey suatu tempat.

Cache juga tampaknya berfungsi, selain masalah dengan pengujian unmount global. Terakhir saya periksa, kesalahan tidak terjadi saat cache tidak dikompilasi.

Saya memang mengubah bagian dari kdbGet , elektraCacheGet dan fungsi terkait. Sepertinya saya merusak sesuatu, tetapi karena hal-hal yang saya ubah mungkin harus diubah lagi setelah # 2969, saya rasa Anda tidak perlu melihatnya sekarang.

Baik. Saya sarankan jika cache + mmapstorage menyebabkan masalah, Anda tetap menonaktifkannya sampai akhir dan kami mengaktifkannya kemudian menyesuaikannya.

PR adalah perubahan yang cukup mendasar sehingga akan lebih mudah jika Anda tidak terjebak karena beberapa perilaku cache yang rusak. Ketika pada dasarnya sudah siap, cukup aktifkan cache lagi dan ping saya sehingga saya dapat melihat dan memperbaiki sisanya.

@mpranj : Saya menugaskan Anda karena ini berhubungan dengan cache.

Saya tidak dapat mereproduksi hal serupa pada master saat ini. Saya tidak bisa berbuat banyak di sana kecuali seseorang tahu bagaimana mereproduksinya di sana, tapi saya curiga itu tidak ada pada master.

Di cabang dari # 3115 saya mendapatkan kesalahan seperti yang dijelaskan. @kodebach haruskah saya masuk ke sana dan mencoba memperbaiki hal-hal terkait cache di atas perubahan Anda atau terlalu dini untuk bekerja di atasnya? Seberapa merepotkan untuk me-rebase cabang dari master saat ini (plugin pra-backend)?

Saya pikir tidak ada gunanya mengerjakan # 3115 sampai # 2969 dan PR terkait digabungkan. Setelah itu saya akan melakukan rebase dan mencoba menyelesaikan PR. Saya ingin melakukan rebase sesedikit mungkin, karena pada dasarnya Anda harus memeriksa semua commit untuk apa pun yang bergantung pada sintaks keynames untuk memastikan rebase yang tepat.

Jika Anda mau, tentunya Anda bisa mencari bug di versi PR saat ini. Namun, sejauh yang saya ingat, saya mencoba ini pada master sebelum membuat masalah, jadi mungkin masalah tersebut telah diperbaiki untuk sementara waktu.

Saya pikir tidak ada gunanya mengerjakan # 3115 sampai # 2969 dan PR terkait digabungkan.

Oke terima kasih! Kemudian mari kita tunggu dan periksa masalah ini setelah PR terkait digabungkan!

Apakah mungkin untuk menandai masalah entah bagaimana mereka menunggu beberapa PR? Saya mengubah judul untuk saat ini.

Saya benar-benar berhasil mereproduksi ini pada master hari ini. Secara khusus, saya membuat scripts/docker/fedora/32/Dockerfile (secara teknis dari # 3447 bukan dari master , tetapi filenya sama dan sepenuhnya berdiri sendiri). Saya kemudian memulai wadah dengan

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

dan di dalam wadah ada baris berikut:

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

Output dari perintah terakhir adalah:

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

(CATATAN: Saya menghapus kunci .description dari output, karena mengandung string ``` dan karena itu merusak pemformatan Markdown Github)

Output IMO seharusnya benar-benar kosong, karena semua kunci berasal dari instalasi Elektra tertentu dan tidak boleh diimpor ke KDB manapun. Mungkin mengekspor kunci version.constants bisa masuk akal, jika kdb import mengabaikannya dengan benar (kunci version juga tidak boleh diekspor).

~ Masalah 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 hanya terjadi di # 3447 dan hanya untuk plugin cache . Jadi masih ada bug di # 3447. Namun, memperbaiki masalah kdb export ini juga akan menghilangkan masalah. ~

KOREKSI: Masalah kondisi pasca benar-benar terjadi di kontainer buruh pelabuhan juga.

Di wadah dari atas, saya berlari (langsung setelah barang lain):

ctest -R kdb_global_umount --output-on-failure

Setelah itu setiap perintah kdb yang mencoba mengakses KDB melaporkan banyak peringatan postcondition , misalnya kdb ls system .

Selain itu, jika saya mencoba menjalankan kdb rm -r system , saya mendapatkan:

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

Kegagalan kdb rm -r system itu sengaja dilakukan. Apa yang kamu harapkan?

Saya harus mengakui, meskipun, bahwa pesan kesalahan cukup buruk (bahkan secara tata bahasa dan semantik: pengguna mencoba sesuatu, bukan kuncinya).

Apa yang kamu harapkan?

Agar adil, ya kdb rm -r system tidak masuk akal dalam sistem nyata. Pada pengaturan pengembangan, ini bisa berguna (tetapi menghapus file secara manual juga tidak sulit).

Namun, saya harus mengakui bahwa pesan kesalahannya cukup buruk

Saya pikir inilah yang paling membuat saya bingung. Jika pesan mengatakan sesuatu seperti "menghapus ... tidak diizinkan", saya akan mengerti bahwa saya melakukan sesuatu yang salah. Selain itu AFAIK kami mendefinisikan Interface Errors sebagai kesalahan dalam kode dan bukan sesuatu yang disebabkan oleh pengguna.

Mengenai plugin version dan plugin hanya-baca secara umum: Saya pikir seharusnya ada cara untuk mengabaikan kesalahan ini dari plugin hanya-baca saat memanggil kdb rm (mungkin kdb rm -rf ).
Pada tingkat tertentu, "menghapus" kunci hanya-baca masuk akal, setidaknya saat kami menghapus semua yang ada di bawah titik pemasangan hanya-baca sekaligus. kdb rm -r some/mountpoint harus menghapus seluruh file konfigurasi yang mendasari untuk some/mountpoint , yaitu kondisi akhir adalah tidak ada file konfigurasi. Karena plugin hanya-baca (setidaknya yang berfungsi seperti version ) tidak memiliki file konfigurasi, kondisi pasca secara otomatis terpenuhi.

Pada pengaturan pengembangan, ini bisa berguna

Untuk pengembangan ada kdb reset .

Jika pesan mengatakan sesuatu seperti "menghapus ... tidak diizinkan"

Saya sangat setuju! Bagaimana dengan # 3498?

mungkin kdb rm -rf

Saya menemukan -f membingungkan, karena Anda tidak dapat memaksanya tetapi hanya mengabaikannya, jadi --without-elektra akankah saya lebih cocok?

harus menghapus seluruh file konfigurasi untuk

Ya, ini masalahnya dan resolver akan menanganinya.

kondisi pasca secara otomatis terpenuhi.

Naja, ada juga kondisi pasca bahwa setelah kdb rm key kdb get key mengembalikan kunci yang tidak ditemukan. Kondisi pasca ini tidak akan terpenuhi.

Mengubah pesan kesalahan saja sudah cukup

Apakah sekarang ada bug yang tersisa yang dijelaskan dalam masalah ini?

AFAIK yang satu ini dan komentar berikutnya (yaitu masalah asli) masih belum terselesaikan: https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469

Maaf, sepertinya saya salah paham tentang masalah ini pada awalnya. Izinkan saya rekap untuk melihat apakah saya memahaminya dengan benar sekarang.

Dari perspektif cache kami ingin menggunakan kembali file mmap sebanyak mungkin. Jadi, jika seseorang memanggil kdbGet pada "system/this" dan mountpoint sebenarnya adalah "system" , kami akan mempertahankan "system" sepenuhnya. Ketika seseorang kemudian memanggil kdbGet pada "system/other" , cache sudah ada, yang mempercepat beberapa hal. Kami pada dasarnya membuat file cache mmap per mountpoint, tetapi kami menyimpan SEMUA kunci di bawah mountpoint.

Jika saya memahami masalahnya dengan benar sekarang, maksud Anda adalah bahwa cache "system/elektra/modules" dan yang serupa adalah keduanya:

  1. salah dan
  2. tidak relevan, karena mengambil kunci ini juga cepat.

EDIT: Saat ini, mendapatkan cache sepenuhnya menghindari ksAppend dan operasi lainnya. Demikian OPMPHM kita lestarikan dan sebagainya. Jika kita memulai ksAppend-ing "system/elektra/modules" ke sistem mountpoint lainnya, kita pasti akan kehilangan beberapa performa. Mungkin tidak relevan untuk namespace sistem tetapi pasti akan merusak kinerja jika kita memiliki kasus tepi seperti ini di mana-mana.

Catatan: Saya menandai komentar tentang barang kdb rm system sebagai terselesaikan, jadi mereka disembunyikan oleh Github. Itu seharusnya membuat masalah ini sedikit lebih jelas.

Jika saya memahami masalahnya dengan benar sekarang, maksud Anda adalah bahwa cache "system/elektra/modules" dan yang serupa adalah keduanya:

  1. salah dan
  2. tidak relevan, karena mengambil kunci ini juga cepat.

Men-cache-nya saja sudah salah ya, tetapi kita masih bisa men-cache-nya, selama ada logika untuk mendeteksi bahwa kunci-kunci tersebut berubah. Saya tidak bisa berkomentar tentang kecepatannya, tetapi menggunakan cache mungkin masih lebih cepat. Seperti yang Anda katakan, ini menghindari ksAppend dan juga menghindari banyak panggilan ke plugin.

Masalah aslinya hanya tentang perilaku kdb export . Keluarannya tidak boleh berisi kunci apa pun di bawah system/elektra/modules atau system/elektra/version , karena ini khusus untuk instalasi Elektra dan tidak boleh diimpor ke KDB lain.

Saya tidak menyelidiki dari mana kunci itu berasal, jadi saya tidak yakin plugin cache benar-benar terlibat di sini. Solusi terbaik mungkin selalu ksCut bagian-bagian ini dalam kdb export . Dengan begitu, masalah tidak dapat muncul kembali jika ada perubahan.


Ada juga masalah "Kondisi akhir backend telah dilanggar". Pemahaman saya sejauh ini adalah bahwa masalah ini disebabkan oleh kdb export menghasilkan kunci dalam system/elektra/modules , tetapi saya 100% yakin:

Jika Anda mengikuti langkah-langkah di https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469 dan kemudian jalankan

ctest -R kdb_global_umount --output-on-failure

bin/kdb ls system

(seperti yang saya katakan di komentar berikutnya), Anda akan mendapatkan banyak:

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

Ini sebenarnya satu-satunya referensi untuk plugin cache . AFAICT inilah yang terjadi di sini:

  • Prosedur "Cadangkan dan Pulihkan" dari pengujian ini menggunakan kdb export dan kdb import .
  • Entah bagaimana ini menghasilkan kunci dari system/elektra/modules/cache terus-menerus ditulis ke file elektra.ecf .
  • Ketika kami kemudian memanggil bentuk apa pun dari kdbGet melalui misalnya kdb ls system kami memiliki masalah.
  • Tidak yakin apa sebenarnya masalah ini, tetapi saya cukup yakin bahwa kunci system/elektra/modules/... tidak boleh ditulis ke disk.
  • Satu-satunya cara untuk memulihkan adalah _manually_ menghapus kunci system/elektra/modules/... dari elektra.ecf .

Mungkin ini harus diperbaiki di kdb import bukan di cache.

Terima kasih banyak telah melaporkan ini!

Cache pasti menyimpan Key (apa saja) ini jika mereka ada di KeySet yang dikembalikan dari kdbGet . Tidak ada pengecualian untuk cache. Namun, seperti yang Anda katakan, tidak masuk akal untuk mengizinkan kunci ini pada kdb import . Saya akan melihat apakah saya dapat mereproduksi ini dari deskripsi Anda dan memperbaikinya.

Jika masalah hanya terjadi saat menggunakan kdb import , saya cukup menjatuhkan kunci khusus ini saat impor.

Saya setuju dengan @mpranj bahwa cache harus mengembalikan semuanya sepenuhnya.

Keluarannya tidak boleh berisi kunci apa pun di bawah system / elektra / modules atau system / elektra / version karena ini khusus untuk instalasi Elektra dan tidak boleh diimpor ke KDB lain.

Mengekspor tidak hanya untuk mengimpor tetapi juga untuk menampilkan beberapa kunci / nilai untuk pengguna. Tidak ada yang salah dengan kdb export system/elektra/version/constants simpleini untuk melihat semua informasi versi.

Saya tidak menyelidiki dari mana kunci itu berasal, jadi saya tidak yakin plugin cache benar-benar terlibat di sini. Solusi terbaik mungkin selalu dengan ksCut bagian ini dalam ekspor kdb. Dengan begitu, masalah tidak dapat muncul kembali jika ada perubahan.

ksCut terjadi ketika Anda mengatakan --without-elektra . Apa yang bisa kita lakukan adalah mengubah default: mengecualikan elektra secara default, kecuali ketika secara eksplisit mengimpor / mengekspor / elektra atau mengatakan --with-elektra .

Kondisi akhir backend telah dilanggar

Ini sepertinya seperti bug yang tidak terkait. (Mungkin shellrecorder tidak menggunakan --without-elektra ). https://github.com/ElektraInitiative/libelektra/issues/3299#issuecomment -695814469, bagaimanapun, sepertinya memang begitu. (Saya tidak dapat mereproduksi, saya mendapatkan 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. )

Saya tidak bisa mereproduksi

Kami belum menerbitkan gambar ini ke hub buruh pelabuhan.

Prasyaratnya di sini adalah bahwa dia membangun gambar buruh pelabuhan dari scripts/docker/fedora/32/Dockerfile dan menandai bangunan tersebut dengan -t elektra-fedora-32:latest saat menjalankan docker build .

Sesuatu seperti:

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

Terima kasih, ya saya bisa mereproduksi masalah Postcondition of backend was violated sekarang di master (seperti yang dijelaskan oleh @kodebach di gambar buruh pelabuhan dan kemudian menggunakan perintah mount global):

 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

Masalahnya jelas tidak terkait dengan kdb export seperti yang juga terjadi, misalnya dengan kdb ls atau kdb cache clear .

Menariknya kdb cache clear tidak membantu tetapi masih bisa menjadi masalah cache (karena kdb tools pertama-tama gunakan KDB untuk mendapatkan konfigurasinya).

@mpranj apakah kamu punya ide?

Apa yang bisa kita lakukan adalah mengubah default: mengecualikan elektra secara default, kecuali ketika secara eksplisit mengimpor / mengekspor / elektra atau mengatakan --dengan-elektra.

Ya, itu pasti akan menjadi solusi yang lebih baik. Idealnya kita juga akan membedakan antara system/elektra/modules / system/elektra/version dan sisa system/elektra . Konfigurasi mountpoint dan konfigurasi plugin global jauh lebih berguna daripada modul dan kunci versi (yang dihasilkan saat runtime).

Masalahnya jelas tidak terkait dengan kdb export seperti yang juga terjadi, misalnya dengan kdb ls atau kdb cache clear .

Seperti yang saya nyatakan, hal-hal "Kondisi Akhir" kemungkinan besar adalah bug di kdb import .

Menariknya kdb cache clear tidak membantu

Mengapa demikian? Seperti saya katakan, masalahnya adalah bahwa system/elektra/modules kunci disimpan dalam elektra.ecf . Jika Anda mengikuti langkah-langkah saya di atas (secara khusus menggunakan opsi cmake ), Anda dapat melihatnya dengan menjalankan

cat config/system/elektra.ecf

dalam direktori build .

Seperti yang saya nyatakan, hal-hal "Kondisi Akhir" kemungkinan besar merupakan bug dalam impor kdb.

Karena kdb import tidak melakukan lebih dari membuat KeySet dan memanggil kdbSet Saya khawatir masalahnya ada di kdbSet . Perilaku yang benar dalam menyimpan apa pun di system/elektra/modules pasti merupakan kesalahan atau membuang, dan jelas tidak bertahan. Tapi jelas ini bukan perilakunya:

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

Jadi ketika plugin yang TIDAK DIBOLEHKAN dipasang, kami memiliki masalah seperti yang dijelaskan di sini. Jadi kita perlu kdbSet gagal dalam setiap upaya untuk menulis ke system/elektra/modules .

Sebenarnya kita perlu mendefinisikan semantik dari seluruh hierarki /elektra , yang mungkin merupakan tugas yang lebih besar ...

masalahnya adalah bahwa kunci sistem / elektra / modul disimpan di elektra.ecf

Maaf, saya tidak melihatnya ketika saya melompat-lompat di antara komentar mencoba mereproduksinya.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

markus2330 picture markus2330  ·  3Komentar

markus2330 picture markus2330  ·  4Komentar

sanssecours picture sanssecours  ·  3Komentar

markus2330 picture markus2330  ·  4Komentar

mpranj picture mpranj  ·  3Komentar