)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"f56b40f048657d1b9aab292572f05b58b62fd15e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":10,"id":"8412c21c_a5a2cab5","updated":"2026-04-24 05:49:16.000000000","message":"Why are we switching from non-sudo commands to sudo commands?\n\nI personally would prefer we don\u0027t introduce another script, especially with a wildcard in sudoers - a cleaner approach would be to add support for doing this to kolla_set_configs and manage these permissions in kolla-ansible config.json (or future config.yaml)","commit_id":"96dc9ddf2524e841c36b5b031d54f45904e4852d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"12bae49d38b15a6f97f249b6194728a85c87cdac","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":10,"id":"e3df41af_159e8369","in_reply_to":"3961cdf0_cfa105ac","updated":"2026-05-12 22:29:58.000000000","message":"Actually, now that I’m looking at it, it’s clear for me.\n\nGiven the previous reply, please take a look here: https://review.opendev.org/c/openstack/kolla-ansible/+/985402\n, where there is a proposal to remove this from config.json entirely - simply to avoid this mess and restore the original idea of fluentd:kolla + SGID, with the correct permissions being set in the image.\n\nAfter all, you know yourself that sometimes users fixed permissions and fluentd errors in the container image, sometimes in kolla-ansible via config.json. In either case, the SGID bit idea was broken in the vast majority of cases.\n\nI personally remember that we had problems with OVS logs, for example, and it always ended up being “fixed somehow.”\n\nAnd this is actually where it comes from: config.json was read by the kolla_set_configs Python script, which is executed via sudo from /usr/local/bin/kolla_start as:\n\nsudo -E kolla_set_configs\n\nSo, actually chowns, mkdirs, chmods were already executed as sudo..\n\nI discovered this while working on extending logging to rsyslog, and it felt correct to fix it properly from an architectural point of view. I have it tested as well.\n\nBut if this approach is never going to be acceptable, please tell me straight away so I don’t waste time fighting with it. I will still stand by the point that the current combination we have in Kolla/Kolla-Ansible is what introduces the mess here.\n\nStill leaving unresolved and wait for reply.","commit_id":"96dc9ddf2524e841c36b5b031d54f45904e4852d"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"97aa478f3347a29f71eb613e7b26dd7509ccebca","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":10,"id":"3961cdf0_cfa105ac","in_reply_to":"8412c21c_a5a2cab5","updated":"2026-05-12 22:11:24.000000000","message":"First, maybe I should explain why I started looking into this problem.\n\nI started investigating this because originally in Kolla, the idea was that /var/log/kolla would be owned by the fluentd user and the kolla group, including preserving the SGID bit. But later, Kolla-Ansible introduced the ability to modify file permissions via config.json, which disrupted the original design where the container was supposed to prepare its own permissions. That led to a mess with SGID, permissions set by extend_start scripts, combined with permissions being set by set_configs, or more specifically by config.json from Kolla-Ansible.\n\nRight now, I can’t quickly tell you exactly where I ran into issues, but I think it was with horizon, libvirt, and /var/log/kolla/ansible.log.\nTo answer your question properly, I need to reproduce it again without sudo and then respond.\n\nIn any case, it’s not entirely true that sudo was never used. Yes, in the vast majority of cases it wasn’t, but it was used in docker/fluentd/extend_start.sh for example. It’s possible that it’s only needed there - that\u0027s why in base sudoers\n\nBut when moving to this approach (which I personally think is the correct one), it’s also necessary to normalize the permissions that have historically been set via config.json ( maybe the second reason)\n\nIn any case, I’ll test it.\n\nLeaving this unresolved for now.","commit_id":"96dc9ddf2524e841c36b5b031d54f45904e4852d"}]}