)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"c61acde8170b4dd4702023fe4033112a5d16c91f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c28f0386_863194e6","updated":"2026-04-21 00:05:40.000000000","message":"recheck new images","commit_id":"4c14ae7f34fd72350db4b5406e4ebf63be6b5e9d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"98d8172db9a62173270328430ad5c96aad0083ec","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"e08a1648_deddf92b","updated":"2026-05-14 18:15:00.000000000","message":"recheck new chain","commit_id":"91c684b438f96522e9bb1acfc651163b3c6b3263"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"b45f1b48b222a4263c142717244ecf4d4f16a085","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"c0ab7bd2_8a4ba989","updated":"2026-05-15 10:55:04.000000000","message":"recheck new images","commit_id":"14137f9f5acf32627c1d677f98cb520bba75eb0c"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"6f46090b343b75f93f0a84e51a9359dbfd6cb04a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":14,"id":"f39d77c8_dbd36498","updated":"2026-05-15 14:37:59.000000000","message":"Actually I believe the direction should be the opposite - stop managing permissions in Kolla and start managing them more in Kolla-Ansible","commit_id":"716380c0198414db19254e57951d514f786f6208"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"9fb453dc75f495dae81cb0856ecc354715ce6451","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":14,"id":"01b3eb48_1e907f81","updated":"2026-05-15 20:49:15.000000000","message":"recheck not related barbican fail","commit_id":"716380c0198414db19254e57951d514f786f6208"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"fc02b023608aef03d289a11afce2e96e85b64e5e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":14,"id":"f8c2a9d7_d83aa12b","in_reply_to":"f39d77c8_dbd36498","updated":"2026-05-15 20:48:59.000000000","message":"I understand your concern, you would prefer the Kolla container image to provide a mechanism for setting permissions, creating log files, directories, and similar things ...basically some form of API. Then k-a would provide the configuration, or in other words, call the container API and configure things.\n\nHowever, what is the value of having such a feature in Kolla Ansible if the user cannot change config.json ? from the k-a code perspective? It is predefined - it is not like a config override. This is my first argument in favor of the solution I presented here.\n\nAnother argument is this - let’s say the user wants to use httpd for Ironic from Rocky, and for LE from Ubuntu. Whatever the custom setup is, the Kolla Ansible orchestrator will generate config.json for both with the apache user, while in another image it is www-data. ( this can be fixed in image ...what OS i am running - that user will be owner...on start)\n\nIn my opinion, Kolla Ansible should not deal with permissions and users. httpd/apache is only one example, there are more cases like this, even if not many. On the end /var/log/kolla is created in images already - https://github.com/openstack/kolla/blob/129e88848d511ebdac4e42124e1192bc5c38d4b5/docker/base/Dockerfile.j2#L322-L333 . Also, users are already created in images.\n\nI think Kolla Ansible should handle:\n\n- providing templates for service configuration\n- handling complex playbooks for restarts, starts, upgrades, and cluster initialization\n- backups, restores, operations, whatever\n\nWhy to not handle permissions then ? \n\nWhat I mean is ..we should not be afraid to hide things inside the container where it makes sense. You may remember the Python 3.12 vs Python 3.10 (or whatever versions it was) case and the complex templating in Kolla Ansible - that was solved by a layer in the images for example by creating a symlink.\n\nIn my opinion, our users do not want to run Cinder as user superman, nor do they want to arbitrarily change permissions and paths. I think they want one thing:\n\n- to know which config file they can provide via override\n- to know what can be configured\n- not to deal with permissions\n- not to deal with differences between images from different distributions\n- They want Kolla-Ansible to be faster, not to have one task create the path, another set permissions, another do a check, and so on.\n\n\nAnd in the end, you\u0027re not saying that Kolla-Ansible should do it directly, you\u0027re saying that k-a should provide an immutable config that gets passed into the container, and then the container itself performs the final actions.\n\nIf those things are immutable, then what is the point of the Kolla-Ansible config.json step?\n\nThe only real advantage, I have to admit, is that config.json makes it visible what the container will do internally. On the contrary, it may encourage someone to modify it manually and simply restart the container, when in image - not that easy ....\n\nWDYT ?","commit_id":"716380c0198414db19254e57951d514f786f6208"}]}
