)]}'
{"id":"openstack%2Fopenstack-helm~999462","triplet_id":"openstack%2Fopenstack-helm~master~I5f53e887f739bc511a2077e2b82f5b776bed01f3","project":"openstack/openstack-helm","branch":"master","attention_set":{},"removed_from_attention_set":{"3009":{"account":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"last_update":"2026-08-04 19:48:29.000000000","reason":"Change was submitted"}},"hashtags":[],"change_id":"I5f53e887f739bc511a2077e2b82f5b776bed01f3","subject":"Fix the mariadb-operator values overrides","status":"MERGED","created":"2026-07-31 21:11:29.000000000","updated":"2026-08-04 19:50:26.000000000","submitted":"2026-08-04 19:48:29.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":0,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"999462","meta_rev_id":"375ec97938c0c69a04ecdff2d2ef93d5d61c2c5b","_number":999462,"virtual_id_number":999462,"owner":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"value":0,"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},{"value":0,"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},{"tag":"autogenerated:zuul:gate","value":2,"date":"2026-08-04 19:48:29.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","default_value":0,"optional":true},"Code-Review":{"approved":{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},"all":[{"value":2,"date":"2026-08-04 18:02:15.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},{"value":2,"date":"2026-08-04 18:24:05.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"approved":{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},"all":[{"value":0,"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},{"value":1,"date":"2026-08-04 18:24:05.000000000","permitted_voting_range":{"min":1,"max":1},"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2026-07-31 22:40:39.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2026-08-04 18:02:15.000000000","updated_by":{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},"reviewer":{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},"state":"REVIEWER"},{"updated":"2026-08-04 18:24:05.000000000","updated_by":{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},"reviewer":{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},"state":"REVIEWER"}],"messages":[{"id":"835d7d678ec7e00a0c227bf5abff7a0dd9e96835","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-07-31 21:11:29.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"0a9151405791ec054c6a0e4993b2c67a058cec84","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-07-31 21:12:27.000000000","message":"Uploaded patch set 2: Commit message was updated.","accounts_in_message":[],"_revision_number":2},{"id":"cfb413d50ee1e28f97fdd8ec479c18c4e6e0f6d3","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-07-31 21:55:50.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"9217ac57ebc5b0d62a3c34ff535760db5ec27ad0","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-07-31 22:40:39.000000000","message":"Patch Set 3: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/f8b6ef2120704156965488364bf9f17a\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/ddd6826682e842a4b31349fac33cbd7b : SUCCESS in 3m 32s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/363cea80622a4719819c901b4ee22213 : SUCCESS in 3m 33s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/4058053a4f6a446fafa373b1424de793 : SUCCESS in 3m 21s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/ad3f2d39d71c4ed988e5b017d89c35ec : FAILURE in 38m 57s","accounts_in_message":[],"_revision_number":3},{"id":"2f8020b264ed14f8dd49990f377793593c206e9b","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-07-31 23:07:59.000000000","message":"Uploaded patch set 4.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":4},{"id":"c6eaccc11f59e7572f8ab8830bdf986835cea0e1","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-07-31 23:29:27.000000000","message":"Patch Set 4: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/c4d1634a82b9493d9a6101f94baade08\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/e6d7f92690fd47aba200d20762c65dcc : SUCCESS in 3m 13s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/d6872420fd504355a2dc46467c38f319 : SUCCESS in 3m 31s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/c14d401896174db497d47b7e25e0926d : SUCCESS in 3m 02s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/d00c07ffb4ff4e19b51dc914a3b8149d : FAILURE in 16m 05s","accounts_in_message":[],"_revision_number":4},{"id":"8b801edca867204cafb5a764424d30782ddab9d7","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-07-31 23:45:38.000000000","message":"Uploaded patch set 5.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":5},{"id":"b11b158f7ae8d3759ac9e2295804a34bbc0176da","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 00:31:55.000000000","message":"Patch Set 5: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/2af3105e39c24e1b9c2a3f24ec4aec01\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/5d268561cdda406e882d7732739e0c94 : SUCCESS in 2m 20s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/74c538c45c8047c5aba28179bf54e66c : SUCCESS in 3m 43s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/527594fa722c4e27868077fa70a95b3c : SUCCESS in 2m 38s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/defc5be8c5e548278efafd856c7ce2ba : FAILURE in 40m 39s","accounts_in_message":[],"_revision_number":5},{"id":"dcf430e26d33598d3ba46318aca274b21faa402e","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 00:42:45.000000000","message":"Uploaded patch set 6.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":6},{"id":"833463ac9ec017a9ae2d15dd89bcbb6b330792b1","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 01:04:36.000000000","message":"Patch Set 6: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/efb251d3417745d6806356866a2395ef\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/7ae710972ec740eebc6854b88cb41712 : SUCCESS in 3m 37s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/384cbbce85b6470eaf23a8b957800ce2 : SUCCESS in 3m 52s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/96bd1b1556fd42a4aed2d78e972b9a8a : SUCCESS in 2m 54s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/919bf70f8b3d41b9993dea90a50cdc89 : FAILURE in 17m 30s","accounts_in_message":[],"_revision_number":6},{"id":"0cba4e5b792bbdb801d7e8b74ca7f6ff7004a215","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 01:54:47.000000000","message":"Uploaded patch set 7.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":7},{"id":"c6338e45ce67a73a64ff9f7adcc7444fad8a2441","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 02:16:50.000000000","message":"Patch Set 7: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/a8cf0f5df6044eec8e053b06c96ac5c5\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/d75486c2cd9a4979bf19b0acc6c9cb43 : SUCCESS in 4m 35s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/e0a6d85f83ce4c41938cd0858e6eafc7 : SUCCESS in 2m 25s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/23bd09d25176409f91f92febd533c3c2 : SUCCESS in 2m 15s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/99f7cf6c89364a138234a24fd03b57a2 : FAILURE in 16m 25s","accounts_in_message":[],"_revision_number":7},{"id":"1214ba466981d168c562b442810ea43836e1ce96","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 03:12:16.000000000","message":"Uploaded patch set 8.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":8},{"id":"774743c984107459e628f0f780bbacb5f0437fde","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 03:44:40.000000000","message":"Patch Set 8: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/7bcdd004063c4702be0665a6419e2d26\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/20b9a2c1bd904918812dd5d0c904e37f : SUCCESS in 2m 50s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/b690f9eaf40d49c2bce4925fe67f6aac : SUCCESS in 3m 27s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/47a3bb55c62140bfbf4343bb1cf45be2 : SUCCESS in 1m 52s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/3d5fa263f7c041969ab71a67256a080e : FAILURE in 26m 43s","accounts_in_message":[],"_revision_number":8},{"id":"61ff1f3535a7f850d047d5f738d8959f545f5ee3","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 04:54:31.000000000","message":"Uploaded patch set 9.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":9},{"id":"2efbdd29f0889be88ae8cdf6a84d410f1f65f5f4","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 05:11:36.000000000","message":"Patch Set 9: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttps://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing\nand https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures\n\nhttps://zuul.opendev.org/t/openstack/buildset/864b5fe2764f413e8b2e9e9ea1b133d7\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/6ca6103869e345648ef9ef81371b4434 : SUCCESS in 3m 15s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/b4f8c633bda146018b80e4fb5c3900b3 : SUCCESS in 1m 56s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/fab957d18d2e43cc9201a220a82c706c : SUCCESS in 2m 04s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/f3084007fc5f4dd4ae6874362b4c4fd6 : FAILURE in 14m 46s","accounts_in_message":[],"_revision_number":9},{"id":"87d279c2d5eab2eb02646204a4d388d38e8214b4","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 05:14:21.000000000","message":"Uploaded patch set 10.\n\nOutdated Votes:\n* Verified-1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":10},{"id":"e7b936b6a29f6b41b42d44018bb0f84fb823390b","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-01 06:39:46.000000000","message":"Patch Set 10: Verified+1\n\nBuild succeeded (check pipeline).\nhttps://zuul.opendev.org/t/openstack/buildset/7121dc898dc34f60bf970f2046c514c0\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/4af028e8d1764954a73665bf3779142d : SUCCESS in 2m 31s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/5467843c81274aedbfb55b60627b65f9 : SUCCESS in 2m 22s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/7ac1cea7a3f24479ab3719577261c453 : SUCCESS in 2m 10s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/e0ca07d454af41fbb787e8fb57f697ab : SUCCESS in 1h 18m 05s","accounts_in_message":[],"_revision_number":10},{"id":"ea0df7cf22ecadaf263e5e5b0cfb52386b7dff80","tag":"autogenerated:gerrit:newWipPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-01 23:47:02.000000000","message":"Uploaded patch set 11.\n\nOutdated Votes:\n* Verified+1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":11},{"id":"b50be24f4483605c605341007bbc35be66eb1bdf","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-02 01:11:26.000000000","message":"Patch Set 11: Verified+1\n\nBuild succeeded (check pipeline).\nhttps://zuul.opendev.org/t/openstack/buildset/0e28feb07d0443438b93b29e8c0161dc\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/be15cf385c984fdcaaeeaeb3f9ce482c : SUCCESS in 2m 17s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/7d8bd086dc0545a487cf9a221a3fe5bc : SUCCESS in 3m 15s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/82974c7e6ca5460e89368cbf3557dced : SUCCESS in 1m 43s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/c6df5010d2474219ad4b3128eed48ab4 : SUCCESS in 1h 18m 06s","accounts_in_message":[],"_revision_number":11},{"id":"11e196eba5daaaed8e214cb6dd86042588643c20","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-02 01:43:34.000000000","message":"Uploaded patch set 12: Commit message was updated.\n\nOutdated Votes:\n* Verified+1 (copy condition: \"NEVER\")\n","accounts_in_message":[],"_revision_number":12},{"id":"91f03333a20a4a2dfb7b9274579ff0dabfecdca5","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-02 01:45:51.000000000","message":"Uploaded patch set 13: Commit message was updated.","accounts_in_message":[],"_revision_number":13},{"id":"454791769d3bf1f8884181a58ca4e2d42a19249f","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"date":"2026-08-02 01:48:05.000000000","message":"Uploaded patch set 14.","accounts_in_message":[],"_revision_number":14},{"id":"9382c7e38bb6ca4bfbc20b107b435306522c2245","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-02 03:17:31.000000000","message":"Patch Set 14: Verified+1\n\nBuild succeeded (check pipeline).\nhttps://zuul.opendev.org/t/openstack/buildset/4a081d5e06b54f46a9202be376aac471\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/726b30cbab2c44f992473c5d82971689 : SUCCESS in 3m 31s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/c84d154572064d9ba75e98f0c52279a7 : SUCCESS in 3m 44s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/c8ec2013407444eea1636ffa226a82a3 : SUCCESS in 3m 32s\n- openstack-helm-pre-commit https://zuul.opendev.org/t/openstack/build/670bb2fecd4e471c8d5d0022659a8a86 : SUCCESS in 5m 57s\n- openstack-helm-build-charts https://zuul.opendev.org/t/openstack/build/882bab28f1b14414a57dc52b7ec3bc3f : SUCCESS in 2m 40s\n- openstack-helm-cinder-2025-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/0659a89d6e0c45cf85dfcd277fa90dd2 : SUCCESS in 47m 07s\n- openstack-helm-compute-kit-2025-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/9e12a9439b7a431b8b7c5058e8675ea6 : SUCCESS in 1h 14m 13s\n- openstack-helm-cinder-2025-2-ubuntu_noble https://zuul.opendev.org/t/openstack/build/adb8ace95ad54c649ce702731af3e84f : SUCCESS in 30m 44s\n- openstack-helm-compute-kit-2025-2-ubuntu_noble https://zuul.opendev.org/t/openstack/build/23ac590eedc54cc5b4accbbadb28768b : SUCCESS in 1h 15m 58s\n- openstack-helm-cinder-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/30049b8be5af45cbba86420e7014868b : SUCCESS in 50m 06s\n- openstack-helm-compute-kit-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/80ecbc047a3d40fb82caa9b21ac3c227 : SUCCESS in 1h 23m 20s\n- openstack-helm-mariadb-operator-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/6688b82a7bd447d0ab00606180cbf666 : SUCCESS in 1h 13m 42s\n- openstack-helm-tls-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/36f4fd9a39804d11b83a28c1fd9d781a : SUCCESS in 1h 19m 05s\n- openstack-helm-compute-kit-ovn-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/8500c91d03bb4018909f4660be154b61 : SUCCESS in 1h 12m 01s\n- openstack-helm-compute-kit-dpdk-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/db435b3145d1489fb393734b1ddf1e48 : SUCCESS in 55m 46s\n- openstack-helm-octavia-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/a55cbec9222e41f8959d8903bcb2967c : SUCCESS in 1h 09m 35s\n- openstack-helm-logging https://zuul.opendev.org/t/openstack/build/9497e2e79808427092790ad0062522a9 : SUCCESS in 24m 03s\n- openstack-helm-monitoring https://zuul.opendev.org/t/openstack/build/c3e5ca57a0ae4e3ea75b65c22ec350a5 : SUCCESS in 30m 02s","accounts_in_message":[],"_revision_number":14},{"id":"f368c014b5b99bca76e9414fc919432ed68f55c1","author":{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"},"date":"2026-08-04 18:02:15.000000000","message":"Patch Set 14: Code-Review+2","accounts_in_message":[],"_revision_number":14},{"id":"36a54646c86ac23418d80a0a2c4161fc6a5e80c9","author":{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"},"date":"2026-08-04 18:24:05.000000000","message":"Patch Set 14: Code-Review+2 Workflow+1","accounts_in_message":[],"_revision_number":14},{"id":"231f9b0f823144d60687b90025e0abbb9b9927e9","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-04 18:25:10.000000000","message":"Patch Set 14: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":14},{"id":"c608817a9a72817c260f4e2bff79dbe3c86fa819","tag":"autogenerated:zuul:gate","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-04 19:48:29.000000000","message":"Patch Set 14: Verified+2\n\nBuild succeeded (gate pipeline).\nhttps://zuul.opendev.org/t/openstack/buildset/cd4d6a02e21a4a4c9cf8ce28d8f1d68d\n\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/941e899cbf294ec1b6e277b5f88f2893 : SUCCESS in 3m 33s\n- build-openstack-releasenotes https://zuul.opendev.org/t/openstack/build/abaff3d446844da187f05a67cde6f1c8 : SUCCESS in 3m 34s\n- openstack-helm-linter https://zuul.opendev.org/t/openstack/build/33e72261a66d4fbca805162e41951bdf : SUCCESS in 1m 52s\n- openstack-helm-cinder-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/f3d75701aa974703ada2931c73976268 : SUCCESS in 46m 16s\n- openstack-helm-compute-kit-2026-1-ubuntu_noble https://zuul.opendev.org/t/openstack/build/4363cada1c964d4cbdcdc24ccae6e0a9 : SUCCESS in 1h 17m 09s\n- openstack-helm-logging https://zuul.opendev.org/t/openstack/build/6c6b4c4f7da945c4a47f522db15624af : SUCCESS in 21m 37s\n- openstack-helm-monitoring https://zuul.opendev.org/t/openstack/build/4da826eb82954781bc505481d619b70b : SUCCESS in 23m 01s","accounts_in_message":[],"_revision_number":14},{"id":"213680b7892c799544c3a220f9227efc7c717eb8","tag":"autogenerated:gerrit:merged","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-04 19:48:29.000000000","message":"Change has been successfully merged","accounts_in_message":[],"_revision_number":14},{"id":"375ec97938c0c69a04ecdff2d2ef93d5d61c2c5b","tag":"autogenerated:zuul:promote","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2026-08-04 19:50:26.000000000","message":"Patch Set 14:\n\nBuild succeeded (promote pipeline).\nhttps://zuul.opendev.org/t/openstack/buildset/30b6b24031c9494faa8485691c36f3b0\n\n- promote-openstack-tox-docs https://zuul.opendev.org/t/openstack/build/ecb29172e8ed4ba7bb064f3cad6c2780 : SUCCESS in 44s","accounts_in_message":[],"_revision_number":14}],"current_revision_number":14,"current_revision":"91697aa73e86bab174f7c1b5629f1642314ea5d1","revisions":{"1c5b3f538ae9e183904480f6a45c5b0228dde0d2":{"kind":"REWORK","_number":1,"created":"2026-07-31 21:11:29.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/1"}}},"commit":{"parents":[{"commit":"50c697fc3cb4307d7f8e278a1ad7366e5f7260a7","subject":"Merge \"Terminate API TLS with nginx sidecars\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/50c697fc3cb4307d7f8e278a1ad7366e5f7260a7"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:28.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files, which\nprovision a chart\u0027s database with mariadb-operator instead of the chart\u0027s\ndb-init job, could not work as written. None of them failed loudly: helm\ntemplate succeeded, yamllint passed, and the result was a service running\nwith no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts read\n   .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was inert. With the\n   generated connection string suppressed at the same time, the fallback path\n   in the workload templates mounts an emptyDir and the service starts with no\n   database configuration rather than refusing to start. Some component keys\n   did not exist either -- nova_api_ospi for nova_api_osapi, placement_api for\n   placement, neutron_api for neutron_server/neutron_rpc_server -- so the\n   block would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload that\n   reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded: they\n   have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object,\n   \"- secret: {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection references is\n   not created by any chart, so the user was never created, every Grant then\n   failed with \"Can\u0027t find any matching row in the user table\", and the\n   connection secret was never written. The overrides now create it from\n   endpoints.\u003coslo_db endpoint\u003e.auth.\u003cuser\u003e.password, the same value the\n   chart\u0027s own database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go placeholders\n   in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret holding a\n   useless URI. The placeholders are now escaped so tpl reproduces them\n   verbatim. {{ .Release.Namespace }}, which does have to be evaluated, is\n   left alone -- a single tpl pass cannot serve both kinds of placeholder,\n   which is why this belongs in escaped form rather than plain.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for, and metadata.name is nova-api / nova-cell0.\n* nova\u0027s api Connection pointed at database \"nova\" instead of \"nova_api\", so\n  the [api_database] snippet would have addressed the wrong schema.\n* nova disabled secret_db_api and secret_db_cell0, but job-db-sync injects\n  DB_CONNECTION and DB_CONNECTION_CELL0 from those secrets, so the db-sync\n  pod could not start. Both are left enabled.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant are\n  now declared -- previously job_db_init_session was disabled with nothing\n  taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section (storage:sqlalchemy and\n  taskflow); the snippet now carries both sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its db-init\n  job, but declared no resources for the octavia_persistence database. It now\n  gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum, masakari,\nmistral, rally, tacker, trove and watcher -- have no pod.etcSources support at\nall: no workload template mounts a config snippet directory, so the operator\u0027s\nconnection secret cannot reach the service. Their overrides declare the custom\nresources and leave the chart\u0027s generated connection string in place, which\nresolves to the same user, password and database the operator provisions.\nAdding etcSources support to those charts is a separate change; each override\nrecords what to null and project once it lands.\n\nVerified for all twenty-six charts: helm template and helm lint succeed with\nthe override, no \"\u003cno value\u003e\" in the output, the placeholders survive tpl\nintact, every referenced password secret is created, every object name is a\nvalid DNS-1123 subdomain, every projected source is an object, every nulled\nconfig option is written back by a Connection snippet, no generated database\nURI is left in the etc secret, and the secretTemplate keys within a chart are\ndistinct so the projected volume cannot collide.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/1c5b3f538ae9e183904480f6a45c5b0228dde0d2"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/1c5b3f538ae9e183904480f6a45c5b0228dde0d2"}]},"branch":"refs/heads/master"},"b01018a54e6dba40dd064f5ac6a7ff362f51867d":{"kind":"NO_CODE_CHANGE","_number":2,"created":"2026-07-31 21:12:27.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/2"}}},"commit":{"parents":[{"commit":"50c697fc3cb4307d7f8e278a1ad7366e5f7260a7","subject":"Merge \"Terminate API TLS with nginx sidecars\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/50c697fc3cb4307d7f8e278a1ad7366e5f7260a7"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:12:19.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for, and metadata.name is nova-api / nova-cell0.\n* nova\u0027s api Connection pointed at database \"nova\" instead of\n  \"nova_api\", so the [api_database] snippet would have addressed the\n  wrong schema.\n* nova disabled secret_db_api and secret_db_cell0, but job-db-sync\n  injects DB_CONNECTION and DB_CONNECTION_CELL0 from those secrets, so\n  the db-sync pod could not start. Both are left enabled.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/b01018a54e6dba40dd064f5ac6a7ff362f51867d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/b01018a54e6dba40dd064f5ac6a7ff362f51867d"}]},"branch":"refs/heads/master"},"3e8aa6ce4b259bbaffaecd539a976aef474af38b":{"kind":"REWORK","_number":3,"created":"2026-07-31 21:55:50.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/3"}}},"commit":{"parents":[{"commit":"50c697fc3cb4307d7f8e278a1ad7366e5f7260a7","subject":"Merge \"Terminate API TLS with nginx sidecars\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/50c697fc3cb4307d7f8e278a1ad7366e5f7260a7"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:55:48.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for, and metadata.name is nova-api / nova-cell0.\n* nova\u0027s api Connection pointed at database \"nova\" instead of\n  \"nova_api\", so the [api_database] snippet would have addressed the\n  wrong schema.\n* nova disabled secret_db_api and secret_db_cell0, but job-db-sync\n  injects DB_CONNECTION and DB_CONNECTION_CELL0 from those secrets, so\n  the db-sync pod could not start. Both are left enabled.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/3e8aa6ce4b259bbaffaecd539a976aef474af38b"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/3e8aa6ce4b259bbaffaecd539a976aef474af38b"}]},"branch":"refs/heads/master"},"0cd0f02cd76361e3499d07b33ed2606dfa84337e":{"kind":"REWORK","_number":4,"created":"2026-07-31 23:07:59.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/4"}}},"commit":{"parents":[{"commit":"50c697fc3cb4307d7f8e278a1ad7366e5f7260a7","subject":"Merge \"Terminate API TLS with nginx sidecars\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/50c697fc3cb4307d7f8e278a1ad7366e5f7260a7"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 23:07:52.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for, and metadata.name is nova-api / nova-cell0.\n* nova\u0027s api Connection pointed at database \"nova\" instead of\n  \"nova_api\", so the [api_database] snippet would have addressed the\n  wrong schema.\n* nova disabled secret_db_api and secret_db_cell0, but job-db-sync\n  injects DB_CONNECTION and DB_CONNECTION_CELL0 from those secrets, so\n  the db-sync pod could not start. Both are left enabled.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/0cd0f02cd76361e3499d07b33ed2606dfa84337e"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/0cd0f02cd76361e3499d07b33ed2606dfa84337e"}]},"branch":"refs/heads/master"},"20095d78777348199fb59a5a99376506326be914":{"kind":"REWORK","_number":5,"created":"2026-07-31 23:45:38.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/5"}}},"commit":{"parents":[{"commit":"50c697fc3cb4307d7f8e278a1ad7366e5f7260a7","subject":"Merge \"Terminate API TLS with nginx sidecars\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/50c697fc3cb4307d7f8e278a1ad7366e5f7260a7"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 23:45:36.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for, and metadata.name is nova-api / nova-cell0.\n* nova\u0027s api Connection pointed at database \"nova\" instead of\n  \"nova_api\", so the [api_database] snippet would have addressed the\n  wrong schema.\n* nova disabled secret_db_api and secret_db_cell0, but job-db-sync\n  injects DB_CONNECTION and DB_CONNECTION_CELL0 from those secrets, so\n  the db-sync pod could not start. Both are left enabled.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook waits for the client Service and for it to have a ready\nendpoint, rather than asserting once. The Ready condition on the MariaDB\nresource does not imply the operator has finished creating that Service:\non one run it appeared a second after Ready and the check failed, on\nanother it was already there. Every chart resolves its oslo_db endpoint\nto that Service and kubernetes-entrypoint blocks on its endpoints, so it\nis worth waiting for explicitly instead of letting the first chart\u0027s\ninit container hang.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/20095d78777348199fb59a5a99376506326be914"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/20095d78777348199fb59a5a99376506326be914"}]},"branch":"refs/heads/master"},"425e56b6eb59b2046fbaffa39947b833353d7939":{"kind":"REWORK","_number":6,"created":"2026-08-01 00:42:45.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/6"}}},"commit":{"parents":[{"commit":"533a2a5f0bf7b7f8a20bce538c6db4dd92703efb","subject":"Merge \"nova: source db-sync cell mapping values from nova.conf\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/533a2a5f0bf7b7f8a20bce538c6db4dd92703efb"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 00:42:42.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook waits for the client Service and for it to have a ready\nendpoint, rather than asserting once. The Ready condition on the MariaDB\nresource does not imply the operator has finished creating that Service:\non one run it appeared a second after Ready and the check failed, on\nanother it was already there. Every chart resolves its oslo_db endpoint\nto that Service and kubernetes-entrypoint blocks on its endpoints, so it\nis worth waiting for explicitly instead of letting the first chart\u0027s\ninit container hang.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/425e56b6eb59b2046fbaffa39947b833353d7939"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/425e56b6eb59b2046fbaffa39947b833353d7939"}]},"branch":"refs/heads/master"},"67b605464d8f1aee77b3798c9f5f3fcd6c6cf789":{"kind":"REWORK","_number":7,"created":"2026-08-01 01:54:47.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/7"}}},"commit":{"parents":[{"commit":"533a2a5f0bf7b7f8a20bce538c6db4dd92703efb","subject":"Merge \"nova: source db-sync cell mapping values from nova.conf\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/533a2a5f0bf7b7f8a20bce538c6db4dd92703efb"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 01:54:45.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nstorage.size is set even though the storage is ephemeral. It is\ndocumented as required whenever a volumeClaimTemplate does not supply\nit, and without it the operator\u0027s storage reconciler fails with \"invalid\nexisting storage size\" on every pass and never gets as far as creating\nthe Services -- while still reporting the MariaDB itself as Ready,\nbecause that condition is derived from the StatefulSet. Whether any\nService appeared before the reconcile wedged turned out to depend on\nwhich phase won the race, which is why two of the runs deploying this\nlooked fine and two did not.\n\nSo the playbook waits for the client Service and for it to have a ready\nendpoint, rather than trusting the Ready condition. Every chart resolves\nits oslo_db endpoint to that Service and kubernetes-entrypoint blocks on\nits endpoints, so waiting here beats letting the first chart\u0027s init\ncontainer hang. If it never turns up, the playbook prints the MariaDB\nresource, what the operator did create, and the last errors from the\noperator\u0027s own log before failing -- diagnosing this from the archived\nlogs of a finished job cost a full run.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/67b605464d8f1aee77b3798c9f5f3fcd6c6cf789"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/67b605464d8f1aee77b3798c9f5f3fcd6c6cf789"}]},"branch":"refs/heads/master"},"20af6cae608a1728ea558f71072e155fdcb9e4f6":{"kind":"REWORK","_number":8,"created":"2026-08-01 03:12:16.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/8","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/8","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/8"}}},"commit":{"parents":[{"commit":"533a2a5f0bf7b7f8a20bce538c6db4dd92703efb","subject":"Merge \"nova: source db-sync cell mapping values from nova.conf\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/533a2a5f0bf7b7f8a20bce538c6db4dd92703efb"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 03:12:14.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook provisions the storage itself: a StorageClass with no\nprovisioner and one host-path PersistentVolume for the operator\u0027s PVC to\nbind to. The deploy-env cluster has no storage class, which is why the\nmariadb chart writes to a host path too; one replica and disposable data\ndo not justify a provisioner.\n\nspec.storage.ephemeral would avoid that, but it is not usable with this\noperator. On its own the storage reconciler rejects it with \"invalid\nexisting storage size\" on every pass and never reaches the phase that\ncreates the Services -- while the MariaDB still reports Ready, because\nthat condition is derived from the StatefulSet. Whether a Service\nappeared before the reconcile wedged depended on which phase won, which\nis why two runs of this looked fine and two did not. Adding the size the\nreconciler wants is refused by the validating webhook: \"Either ephemeral\nor regular storage must be provided\".\n\nSo the playbook waits for the client Service and for it to have a ready\nendpoint, rather than trusting the Ready condition. Every chart resolves\nits oslo_db endpoint to that Service and kubernetes-entrypoint blocks on\nits endpoints, so waiting here beats letting the first chart\u0027s init\ncontainer hang. If it never turns up, the playbook prints the MariaDB\nresource, what the operator did create, and the last errors from the\noperator\u0027s own log before failing -- diagnosing this from the archived\nlogs of a finished job cost a full run.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/20af6cae608a1728ea558f71072e155fdcb9e4f6"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/20af6cae608a1728ea558f71072e155fdcb9e4f6"}]},"branch":"refs/heads/master"},"0ac4ed8662dba2a8f09d7622374f2357d7f901a0":{"kind":"REWORK","_number":9,"created":"2026-08-01 04:54:31.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/9","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/9","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/9"}}},"commit":{"parents":[{"commit":"533a2a5f0bf7b7f8a20bce538c6db4dd92703efb","subject":"Merge \"nova: source db-sync cell mapping values from nova.conf\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/533a2a5f0bf7b7f8a20bce538c6db4dd92703efb"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 04:54:28.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook provisions the storage itself: a StorageClass with no\nprovisioner and one host-path PersistentVolume for the operator\u0027s PVC to\nbind to. The deploy-env cluster has no storage class, which is why the\nmariadb chart writes to a host path too; one replica and disposable data\ndo not justify a provisioner. The directory is created on every node\nfirst, world-writable, because kubelet would otherwise create it as\nroot:root 0755 and the operator runs mariadbd as a non-root user, which\naborts with \u0027Can\u0027t create/write to file ... (Errcode: 13 \"Permission\ndenied\")\u0027. fsGroup is no help: Kubernetes does not manage ownership for\nhostPath volumes.\n\nspec.storage.ephemeral would avoid that, but it is not usable with this\noperator. On its own the storage reconciler rejects it with \"invalid\nexisting storage size\" on every pass and never reaches the phase that\ncreates the Services -- while the MariaDB still reports Ready, because\nthat condition is derived from the StatefulSet. Whether a Service\nappeared before the reconcile wedged depended on which phase won, which\nis why two runs of this looked fine and two did not. Adding the size the\nreconciler wants is refused by the validating webhook: \"Either ephemeral\nor regular storage must be provided\".\n\nSo the playbook waits for the client Service and for it to have a ready\nendpoint, rather than trusting the Ready condition. Every chart resolves\nits oslo_db endpoint to that Service and kubernetes-entrypoint blocks on\nits endpoints, so waiting here beats letting the first chart\u0027s init\ncontainer hang. If it never turns up, the playbook prints the MariaDB\nresource, what the operator did create, and the last errors from the\noperator\u0027s own log before failing -- diagnosing this from the archived\nlogs of a finished job cost a full run.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/0ac4ed8662dba2a8f09d7622374f2357d7f901a0"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/0ac4ed8662dba2a8f09d7622374f2357d7f901a0"}]},"branch":"refs/heads/master"},"ec80003ba27284e6b3b2e2eaf8f9d36d9b1ec170":{"kind":"REWORK","_number":10,"created":"2026-08-01 05:14:21.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/10","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/10","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/10"}}},"commit":{"parents":[{"commit":"533a2a5f0bf7b7f8a20bce538c6db4dd92703efb","subject":"Merge \"nova: source db-sync cell mapping values from nova.conf\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/533a2a5f0bf7b7f8a20bce538c6db4dd92703efb"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 05:14:18.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nextraObjects is therefore now a map in all 36 gateway.yaml and all 26\nmariadb-operator.yaml overrides. No chart change is needed: the shared\nextra-manifests.yaml iterates with \"range .Values.extraObjects\", and Go\ntemplates range over a map\u0027s values just as they do over a list\u0027s\nelements. Helm does log \u0027skipped value for \u003cchart\u003e.extraObjects: Not a\ntable\u0027 when the map merges over the chart\u0027s empty-list default; it is\ncosmetic, and changing 79 chart defaults to {} is left for later. The\nremaining list-form overrides -- tls-gateway-and-sidecar.yaml and\ngateway-tls.yaml -- are each the only extraObjects source in the job\nthat uses them, so they still work; converting them is a follow-up.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook provisions the storage itself: a StorageClass with no\nprovisioner and one host-path PersistentVolume for the operator\u0027s PVC to\nbind to. The deploy-env cluster has no storage class, which is why the\nmariadb chart writes to a host path too; one replica and disposable data\ndo not justify a provisioner. The directory is created on every node\nfirst, world-writable, because kubelet would otherwise create it as\nroot:root 0755 and the operator runs mariadbd as a non-root user, which\naborts with \u0027Can\u0027t create/write to file ... (Errcode: 13 \"Permission\ndenied\")\u0027. fsGroup is no help: Kubernetes does not manage ownership for\nhostPath volumes.\n\nspec.storage.ephemeral would avoid that, but it is not usable with this\noperator. On its own the storage reconciler rejects it with \"invalid\nexisting storage size\" on every pass and never reaches the phase that\ncreates the Services -- while the MariaDB still reports Ready, because\nthat condition is derived from the StatefulSet. Whether a Service\nappeared before the reconcile wedged depended on which phase won, which\nis why two runs of this looked fine and two did not. Adding the size the\nreconciler wants is refused by the validating webhook: \"Either ephemeral\nor regular storage must be provided\".\n\nBringing the operator up needs more than helm --wait, too. Both that and\nwait-for-pods are satisfied as soon as its deployments report available\nreplicas, which is before the cert-controller has issued the webhook\u0027s\nserving certificate and patched the CA bundle into the webhook\nconfigurations; creating a MariaDB in that window fails with \u0027failed\ncalling webhook \"mmariadb.kb.io\": context deadline exceeded\u0027. So the\nplaybook waits for all three deployments to roll out and for the CA\nbundle to appear, and retries the create -- but only while the webhook is\nunreachable, so a real rejection still fails at once.\n\nSo the playbook waits for the client Service and for it to have a ready\nendpoint, rather than trusting the Ready condition. Every chart resolves\nits oslo_db endpoint to that Service and kubernetes-entrypoint blocks on\nits endpoints, so waiting here beats letting the first chart\u0027s init\ncontainer hang. If it never turns up, the playbook prints the MariaDB\nresource, what the operator did create, and the last errors from the\noperator\u0027s own log before failing -- diagnosing this from the archived\nlogs of a finished job cost a full run.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune. The\nlist-to-map conversion is behaviour-neutral: for all 62 converted files\nthe rendered object set is identical, ignoring the uuidv4 and\nmemcache_secret_key values a chart regenerates on every render.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/ec80003ba27284e6b3b2e2eaf8f9d36d9b1ec170"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/ec80003ba27284e6b3b2e2eaf8f9d36d9b1ec170"}]},"branch":"refs/heads/master"},"034e3f65e8922eefd29544bddf79b71e234ad1c7":{"kind":"REWORK","_number":11,"created":"2026-08-01 23:47:02.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/11","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/11","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/11"}}},"commit":{"parents":[{"commit":"d91658aba8f58ac7620e02b774b7f7cb7292ab22","subject":"Make extraObjects default to a map","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/d91658aba8f58ac7620e02b774b7f7cb7292ab22"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-01 23:46:44.000000000","tz":-300},"subject":"[WIP] Fix the mariadb-operator values overrides","message":"[WIP] Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. None of them failed\nloudly: helm template succeeded, yamllint passed, and the result was a\nservice running with no [database] section at all.\n\nFour defects, all fixed here:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert. With the generated connection string suppressed at the same\n   time, the fallback path in the workload templates mounts an emptyDir\n   and the service starts with no database configuration rather than\n   refusing to start. Some component keys did not exist either --\n   nova_api_ospi for nova_api_osapi, placement_api for placement,\n   neutron_api for neutron_server/neutron_rpc_server -- so the block\n   would still have missed its target after being moved. Component sets\n   now come from each chart\u0027s own values.yaml and cover every workload\n   that reads the database, not just the API and db-sync. nova_compute,\n   nova_compute_ironic and the neutron agents are deliberately excluded:\n   they have no database access.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object, \"- secret:\n   {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from endpoints.\u003coslo_db\n   endpoint\u003e.auth.\u003cuser\u003e.password, the same value the chart\u0027s own\n   database secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   mariadb-operator would have written a syntactically valid secret\n   holding a useless URI. The placeholders are now escaped so tpl\n   reproduces them verbatim. {{ .Release.Namespace }}, which does have\n   to be evaluated, is left alone -- a single tpl pass cannot serve both\n   kinds of placeholder, which is why this belongs in escaped form.\n\nFurther errors found while fixing the above:\n\n* nova asked for Database objects named nova_api and nova_cell0. An\n  underscore is not valid in a Kubernetes object name, so the API server\n  rejects them. spec.name now carries the database name, which is what\n  DatabaseSpec.name is for; metadata.name is nova-cell0 / nova-cell1.\n* nova\u0027s databases were wrong twice over. The override predates the\n  current endpoint layout, in which api_database comes from oslo_db\n  (database \"nova\") and database from oslo_db_cell1 (database\n  \"nova_cell1\"); there is no oslo_db_api endpoint and no cell0_database\n  config section any more. nova_cell0 is reached only as the\n  DB_CONNECTION_CELL0 environment variable job-db-sync takes from the\n  chart\u0027s own secret_db_cell0, so it gets a Database and a Grant but no\n  Connection, and secret_db_cell0 stays enabled -- the override used to\n  disable it, which would have stopped db-sync from starting.\n* grafana disabled secret_db_session, which job-db-session-sync reads as\n  DB_CONNECTION. Left enabled, and the session database, user and grant\n  are now declared -- previously job_db_init_session was disabled with\n  nothing taking over.\n* placement nulled conf.placement.placement_database.connection but the\n  snippet wrote a [database] section.\n* designate and masakari null a second config section\n  (storage:sqlalchemy and taskflow); the snippet now carries both\n  sections in one file.\n* octavia nulled task_flow.persistence_connection and disabled its\n  db-init job, but declared no resources for the octavia_persistence\n  database. It now gets its own Database, Grant and Connection.\n* The Connection objects had no metadata.namespace while the other kinds\n  did.\n* nova-db-cell0-conn named a secret nova-cell0-db-conn.\n\ntools/deployment/common/verify-mariadb-tls.sh required the connection\nstring before deciding whether there was any TLS to verify, and read it\nonly from the service config -- which these overrides null on purpose.\nIt now falls back to the operator\u0027s connection secret (CONN_SECRET,\nCONN_FILE) and requires a connection string only after the tls.oslo_db\ngate, so with TLS off it reports \"nothing to verify\" instead of exiting\n2.\n\nTwelve charts -- blazar, cyborg, freezer, gnocchi, grafana, magnum,\nmasakari, mistral, rally, tacker, trove and watcher -- have no\npod.etcSources support at all: no workload template mounts a config\nsnippet directory, so the operator\u0027s connection secret cannot reach the\nservice. Their overrides declare the custom resources and leave the\nchart\u0027s generated connection string in place, which resolves to the same\nuser, password and database the operator provisions. Adding etcSources\nsupport to those charts is a separate change; each override records what\nto null and project once it lands.\n\nA fifth defect, which only the test job could expose: extraObjects was a\nlist in both gateway.yaml and mariadb-operator.yaml. Helm merges maps\nacross -f files but *replaces* lists, so passing both to one chart\nsilently dropped whichever came first. The job\u0027s first run deployed the\ndatabases correctly and then failed with a 404 from the Envoy Gateway,\nbecause keystone\u0027s HTTPRoute had been replaced by the custom resources.\n\nThat one is fixed by the parent change, which makes extraObjects a map\neverywhere -- in the chart defaults and in every overrides file. This\nchange therefore depends on it, and the mariadb-operator overrides here\nare written in the map form it establishes.\n\nA test job exercises the result:\nopenstack-helm-mariadb-operator-2026-1-ubuntu_noble runs deploy-env,\nthen a new playbooks/deploy-mariadb-operator.yaml, then the existing\ndeploy-compute-kit playbook with mariadb-operator.yaml in\nosh_values_overrides. The new playbook installs mariadb-operator and\ncreates one MariaDB instance -- one server, no Galera -- on ephemeral\nstorage so the job needs no storage class. The instance is named\n\"mariadb\", which is both the mariaDbRef the overrides use and the\nendpoints.oslo_db.hosts.default every OpenStack chart already ships, so\nno endpoint overrides are needed anywhere. deploy-compute-kit skips the\nmariadb chart when mariadb_operator_enabled is set.\n\nThe operator chart version is pinned in the deploy-charts role defaults.\nIt matters twice: the API group was renamed from mariadb.mmontes.io to\nk8s.mariadb.com after 0.25.0 and the overrides target the latter, and\nthe CRDs were split into a separate chart in 0.35.0, so bumping past\n0.34.0 needs a second install. The mariadb-cluster chart is not used:\nits MariaDB resource still targets the retired mariadb.mmontes.io group,\nand updating it is separate work.\n\nThe playbook provisions the storage itself: a StorageClass with no\nprovisioner and one host-path PersistentVolume for the operator\u0027s PVC to\nbind to. The deploy-env cluster has no storage class, which is why the\nmariadb chart writes to a host path too; one replica and disposable data\ndo not justify a provisioner. The directory is created on every node\nfirst, world-writable, because kubelet would otherwise create it as\nroot:root 0755 and the operator runs mariadbd as a non-root user, which\naborts with \u0027Can\u0027t create/write to file ... (Errcode: 13 \"Permission\ndenied\")\u0027. fsGroup is no help: Kubernetes does not manage ownership for\nhostPath volumes.\n\nspec.storage.ephemeral would avoid that, but it is not usable with this\noperator. On its own the storage reconciler rejects it with \"invalid\nexisting storage size\" on every pass and never reaches the phase that\ncreates the Services -- while the MariaDB still reports Ready, because\nthat condition is derived from the StatefulSet. Whether a Service\nappeared before the reconcile wedged depended on which phase won, which\nis why two runs of this looked fine and two did not. Adding the size the\nreconciler wants is refused by the validating webhook: \"Either ephemeral\nor regular storage must be provided\".\n\nBringing the operator up needs more than helm --wait, too. Both that and\nwait-for-pods are satisfied as soon as its deployments report available\nreplicas, which is before the cert-controller has issued the webhook\u0027s\nserving certificate and patched the CA bundle into the webhook\nconfigurations; creating a MariaDB in that window fails with \u0027failed\ncalling webhook \"mmariadb.kb.io\": context deadline exceeded\u0027. So the\nplaybook waits for all three deployments to roll out and for the CA\nbundle to appear, and retries the create -- but only while the webhook is\nunreachable, so a real rejection still fails at once.\n\nSo the playbook waits for the client Service and for it to have a ready\nendpoint, rather than trusting the Ready condition. Every chart resolves\nits oslo_db endpoint to that Service and kubernetes-entrypoint blocks on\nits endpoints, so waiting here beats letting the first chart\u0027s init\ncontainer hang. If it never turns up, the playbook prints the MariaDB\nresource, what the operator did create, and the last errors from the\noperator\u0027s own log before failing -- diagnosing this from the archived\nlogs of a finished job cost a full run.\n\nThe check pipeline is trimmed to the linter and this one job, inside\ngrep-able DNM(mariadb-operator) markers, so iterating on it does not\nspend the whole node budget. The gate pipeline is untouched and still\nruns the full cinder and compute-kit jobs. Restore the block before\nmerging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print nothing.\n\nVerified for all twenty-six charts: helm template and helm lint succeed\nwith the override, no \"\u003cno value\u003e\" in the output, the placeholders\nsurvive tpl intact, every referenced password secret is created, every\nobject name is a valid DNS-1123 subdomain, every projected source is an\nobject, every nulled config option is written back by a Connection\nsnippet, no generated database URI is left in the etc secret, and the\nsecretTemplate keys within a chart are distinct so the projected volume\ncannot collide. All 116 rendered custom resources, and the MariaDB\nresource the new playbook applies, validate against the pinned\noperator\u0027s CRD schemas with no field the API server would prune.\n\nThe declarative database path itself is already confirmed working by\nthat first job run: keystone-api reported \"MountVolume.SetUp failed ...\nsecret keystone-db-conn not found\" five times and then started, and\nkeystone-db-sync succeeded -- so the operator did create the database,\nthe user and the grant from these custom resources, and did write the\nconnection secret, and kubelet held the pods until it appeared.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/034e3f65e8922eefd29544bddf79b71e234ad1c7"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/034e3f65e8922eefd29544bddf79b71e234ad1c7"}]},"branch":"refs/heads/master"},"b5d97da14b36a8cc0dae400d3d455cdeecd3469a":{"kind":"NO_CODE_CHANGE","_number":12,"created":"2026-08-02 01:43:34.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/12","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/12","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/12"}}},"commit":{"parents":[{"commit":"d91658aba8f58ac7620e02b774b7f7cb7292ab22","subject":"Make extraObjects default to a map","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/d91658aba8f58ac7620e02b774b7f7cb7292ab22"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-02 01:43:18.000000000","tz":-300},"subject":"Fix the mariadb-operator values overrides","message":"Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. Nothing failed loudly:\nhelm template succeeded, yamllint passed, and the result was a service\nrunning with no [database] section at all.\n\nFour defects:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert, and some of the component keys did not exist either. The\n   component sets now come from each chart\u0027s own values.yaml and cover\n   every workload that reads the database.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object,\n   \"- secret: {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from the same value the chart\u0027s own database\n   secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   They are now escaped so tpl reproduces them verbatim.\n   {{ .Release.Namespace }}, which does have to be evaluated, is left\n   alone.\n\nA number of smaller errors in the individual overrides are fixed along\nthe way. Twelve charts have no pod.etcSources support at all, so their\noverrides declare the custom resources and leave the chart\u0027s generated\nconnection string in place; adding that support is a separate change.\n\nA new job, openstack-helm-mariadb-operator-2026-1-ubuntu_noble,\nexercises the result: it installs mariadb-operator, creates a single\nMariaDB instance on ephemeral host-path storage and runs the compute kit\nagainst it.\n\nThe check pipeline is temporarily trimmed to the linter and that one\njob, inside grep-able markers, so iterating on it does not spend the\nwhole node budget. The gate pipeline is untouched. Restore the block\nbefore merging: grep -rn \u0027DNM(mariadb-operator)\u0027 zuul.d/ must print\nnothing.\n\nThis depends on the parent change making extraObjects a map. Helm\nreplaces lists when it merges -f files, so a list here silently dropped\nthe objects declared by gateway.yaml passed alongside it.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/b5d97da14b36a8cc0dae400d3d455cdeecd3469a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/b5d97da14b36a8cc0dae400d3d455cdeecd3469a"}]},"branch":"refs/heads/master"},"9a5f9a10dc7acdf66dc025d973f9431585e8118e":{"kind":"NO_CODE_CHANGE","_number":13,"created":"2026-08-02 01:45:51.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/13","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/13","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/13"}}},"commit":{"parents":[{"commit":"d91658aba8f58ac7620e02b774b7f7cb7292ab22","subject":"Make extraObjects default to a map","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/d91658aba8f58ac7620e02b774b7f7cb7292ab22"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-02 01:45:42.000000000","tz":-300},"subject":"Fix the mariadb-operator values overrides","message":"Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. Nothing failed loudly:\nhelm template succeeded, yamllint passed, and the result was a service\nrunning with no [database] section at all.\n\nFour defects:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert, and some of the component keys did not exist either. The\n   component sets now come from each chart\u0027s own values.yaml and cover\n   every workload that reads the database.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object,\n   \"- secret: {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from the same value the chart\u0027s own database\n   secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   They are now escaped so tpl reproduces them verbatim.\n   {{ .Release.Namespace }}, which does have to be evaluated, is left\n   alone.\n\nA new job, openstack-helm-mariadb-operator-2026-1-ubuntu_noble,\nexercises the result: it installs mariadb-operator, creates a single\nMariaDB instance on ephemeral host-path storage and runs the compute kit\nagainst it.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/9a5f9a10dc7acdf66dc025d973f9431585e8118e"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/9a5f9a10dc7acdf66dc025d973f9431585e8118e"}]},"branch":"refs/heads/master"},"91697aa73e86bab174f7c1b5629f1642314ea5d1":{"kind":"REWORK","_number":14,"created":"2026-08-02 01:48:05.000000000","uploader":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"ref":"refs/changes/62/999462/14","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/openstack-helm","ref":"refs/changes/62/999462/14","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/openstack-helm refs/changes/62/999462/14"}}},"commit":{"parents":[{"commit":"d91658aba8f58ac7620e02b774b7f7cb7292ab22","subject":"Make extraObjects default to a map","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/d91658aba8f58ac7620e02b774b7f7cb7292ab22"}]}],"author":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-07-31 21:11:23.000000000","tz":-300},"committer":{"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","date":"2026-08-02 01:47:59.000000000","tz":-300},"subject":"Fix the mariadb-operator values overrides","message":"Fix the mariadb-operator values overrides\n\nThe twenty-six values_overrides/\u003cchart\u003e/mariadb-operator.yaml files,\nwhich provision a chart\u0027s database with mariadb-operator instead of the\nchart\u0027s db-init job, could not work as written. Nothing failed loudly:\nhelm template succeeded, yamllint passed, and the result was a service\nrunning with no [database] section at all.\n\nFour defects:\n\n1. etcSources was set at the top level of the values tree. The charts\n   read .Values.pod.etcSources.\u003ccomponent\u003e, so the whole block was\n   inert, and some of the component keys did not exist either. The\n   component sets now come from each chart\u0027s own values.yaml and cover\n   every workload that reads the database.\n\n2. The sources were bare strings. $etcSources is toYaml\u0027d straight into\n   projected.sources, so each item has to be a source object,\n   \"- secret: {name: \u003csvc\u003e-db-conn}\".\n\n3. The \u003cuser\u003e-db-password secret that every User and Connection\n   references is not created by any chart, so the user was never\n   created, every Grant then failed with \"Can\u0027t find any matching row in\n   the user table\", and the connection secret was never written. The\n   overrides now create it from the same value the chart\u0027s own database\n   secrets are built from.\n\n4. extraObjects is rendered through tpl, which evaluated the Go\n   placeholders in secretTemplate.format and replaced them with nothing:\n\n     connection \u003d mysql+pymysql://:@:/\n\n   They are now escaped so tpl reproduces them verbatim.\n   {{ .Release.Namespace }}, which does have to be evaluated, is left\n   alone.\n\nA new job, openstack-helm-mariadb-operator-2026-1-ubuntu_noble,\nexercises the result: it installs mariadb-operator, creates a single\nMariaDB instance on ephemeral host-path storage and runs the compute kit\nagainst it.\n\nSigned-off-by: Vladimir Kozhukalov \u003ckozhukalov@gmail.com\u003e\nChange-Id: I5f53e887f739bc511a2077e2b82f5b776bed01f3\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/91697aa73e86bab174f7c1b5629f1642314ea5d1"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/openstack-helm/commit/91697aa73e86bab174f7c1b5629f1642314ea5d1"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[{"rule_name":"gerrit~DefaultSubmitRule","status":"CLOSED","labels":[{"label":"Verified","status":"MAY","applied_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]}},{"label":"Code-Review","status":"MAY","applied_by":{"_account_id":29974,"name":"Stephen Taylor","email":"stephen.taylor.1@att.com","username":"st053q"}},{"label":"Workflow","status":"MAY","applied_by":{"_account_id":34520,"name":"Sergiy Markin","email":"smarkin@mirantis.com","username":"sm515x"}}]}],"submit_requirements":[{"name":"Verified","description":"Verified in gate by CI","status":"SATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Verified\u003dMAX AND -label:Verified\u003dMIN","fulfilled":true,"status":"PASS","passing_atoms":["label:Verified\u003dMAX"],"failing_atoms":["label:Verified\u003dMIN"],"atom_explanations":{"label:Verified\u003dMAX":"","label:Verified\u003dMIN":""}}},{"name":"Code-Review","description":"Code reviewed by core reviewer","status":"SATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Code-Review\u003dMAX AND -label:Code-Review\u003dMIN","fulfilled":true,"status":"PASS","passing_atoms":["label:Code-Review\u003dMAX"],"failing_atoms":["label:Code-Review\u003dMIN"],"atom_explanations":{"label:Code-Review\u003dMAX":"","label:Code-Review\u003dMIN":""}}},{"name":"Workflow","description":"Approved for gate by core reviewer","status":"SATISFIED","is_legacy":false,"submittability_expression_result":{"expression":"label:Workflow\u003dMAX AND -label:Workflow\u003dMIN","fulfilled":true,"status":"PASS","passing_atoms":["label:Workflow\u003dMAX"],"failing_atoms":["label:Workflow\u003dMIN"],"atom_explanations":{"label:Workflow\u003dMAX":"","label:Workflow\u003dMIN":""}}}]}