)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":3009,"name":"Vladimir Kozhukalov","email":"kozhukalov@gmail.com","username":"kozhukalov"},"change_message_id":"a2ac1a9e5045791a5d4897db7a03c812b38cab91","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7109b50a_5a3f4966","updated":"2025-04-28 18:52:36.000000000","message":"The service cleaner script tracks the service\u0027s status which is updated periodically and services are considered down after service_down_time which 60 seconds by default. And the script even sleeps another 60 seconds to avoid cleaning up false down services. So when you redeploy nova services (helm upgrade), they won\u0027t be cleaned immediately. This cron job is mostly needed because of the dynamic nature of k8s env to cleanup service records when k8s reschedules pods on other hosts. \n\nIf you need services to be cleaned up early then you can change the cron schedule https://opendev.org/openstack/openstack-helm/src/branch/master/nova/values.yaml#L111","commit_id":"dde3676d44d397d786fbb1151dbf62319d35df70"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"2de1d8776e43e3f73d30bc271b9fbba5559385b1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"58447c73_95d37d6f","in_reply_to":"444f6779_db14089e","updated":"2025-08-06 06:24:50.000000000","message":"For components like schedulers its better to use statefulsets rather than deployments. In this case name will be deterministic and will change only when number of replicas is changed. This applies to other components like conductors/heat engines etc. But statefulset usage added additional nuances.","commit_id":"dde3676d44d397d786fbb1151dbf62319d35df70"},{"author":{"_account_id":35674,"name":"ChungWon Lee","display_name":"cw0306-lee","email":"cw0306.lee@samsung.com","username":"cw0306-lee"},"change_message_id":"e6ed8c7bb52b6d50c87446e556b657e7c0655b44","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7f77912c_a426885c","in_reply_to":"7109b50a_5a3f4966","updated":"2025-05-02 09:05:50.000000000","message":"Hi, Vladimir Kozhukalov! Thanks for kind comment and sorry for late reply.\nI think I used wrong expression.\nI wanted to say that remove old services when they become down(not immediately and new services work well).\nChange cron job schedule can solve this, too but it can affect performance if we use cronjob frequently.\nThat is why I wanted to add this job.\nMaybe, I can complement this job by adding init container to compare enabled service number and pod number.","commit_id":"dde3676d44d397d786fbb1151dbf62319d35df70"},{"author":{"_account_id":14525,"name":"Vasyl Saienko","email":"vsaienko@mirantis.com","username":"vsaienko"},"change_message_id":"6d73d02959b729252d8a90907cf01a9607a91dec","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ff821228_37f0f9d0","in_reply_to":"7f77912c_a426885c","updated":"2025-08-05 08:18:26.000000000","message":"IMO service removal should be done by external tooling, as for example when node has hardware failure it may take days/weeks to recover it, during that time service will be down but should not be removed from database, as we know it will appear when hardware is fixed. \n\nCronjob on other hand makes sense if we don\u0027t care and want to remove down services immidiately when cron is started (not sure if pipeline has options like min number of time service is in down state before removing it) otherwise changin schedule is just a random.\n\nFor manual removal, we should directly call openstack API from external tooling.","commit_id":"dde3676d44d397d786fbb1151dbf62319d35df70"},{"author":{"_account_id":35674,"name":"ChungWon Lee","display_name":"cw0306-lee","email":"cw0306.lee@samsung.com","username":"cw0306-lee"},"change_message_id":"39f3ade2072f090a886bfc253b7e00fc760d3c30","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"444f6779_db14089e","in_reply_to":"ff821228_37f0f9d0","updated":"2025-08-06 02:06:27.000000000","message":"Thank you for your opinion. I thought about how can I know which scheduler should be removed(not because of error) and when should I remove it(should run job after all scheduler updated but hard to know it finished well). Therefore, I think delete by api that you said is right. Thank you!","commit_id":"dde3676d44d397d786fbb1151dbf62319d35df70"}]}