)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"60e8acc0df7ba7c22fc3da20289666460db02476","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ba269f79_45064a4e","updated":"2026-03-06 18:20:50.000000000","message":"Since these are suppose to be stable it seems like the right approach is that they should be StatefulSets instead no? Cause what\u0027s gonna happen with this when I scale up the number of conductors or schedulers past 1?","commit_id":"3afbf5fd9732ecfe8dd8a90b25e6fe772a0a21d0"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"d8ba909a55e1c13c30b455c9ce4074dacd2e2470","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"183ef739_473acc2e","updated":"2026-03-12 21:38:00.000000000","message":"The implementation the PS suggests seems to have multiple issues\n\n- Usually we do such things in init containers that put custom snippets to /tmp/pod-shared/ and then the application container uses this snippet. See for example [1] and [2].\n- When you create such snippet /tmp/nova-conductor-host.conf in runtime then the health check script doesn\u0027t know about this and it is going to use the wrong message queue and the health check is gonna fail.\n- As @cardoe@cardoe.com mentioned earlier the suggested values structure is not going to work for more that 1 replica.\n\nSo, the statefulset suits best for this case. But those nova services conductor and scheduler are stateless in their nature and this dynamic nova service registration wasn\u0027t implemented for nothing and it works quite well. So at this point it is not quite clear for me what is the overall motivation for this change. Probably some inventory or debugging use cases can benefit. If you don\u0027t mind can you please give more details in the commit message why it is important to fix this?\n\nI am not against re-implementing conductor/scheduler as statefulsets because for this specific case it is not going to be too much disruptive. During the upgrade we can just deploy the new statefulset next to old deployment and then delete the old deployment and wait till the cleanup job comes and removes the stale records. However I would also like to hear from some other folks regarding this.  \n\n\n[1] https://opendev.org/openstack/openstack-helm/src/branch/master/nova/templates/bin/_nova-compute-init.sh.tpl#L53-L56\n[2] https://opendev.org/openstack/openstack-helm/src/branch/master/nova/templates/bin/_nova-compute.sh.tpl#L24-L26","commit_id":"3afbf5fd9732ecfe8dd8a90b25e6fe772a0a21d0"},{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"2e321e85fba09b69f23611ff6e1f72c0b4651282","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ac83d5a0_07048cc3","updated":"2026-03-17 01:53:41.000000000","message":"recheck","commit_id":"9d69fd8c36c6cd5055781c9514d03b197197489c"}]}