)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d26279a4a0706ebbb5bc742bd8180687590ef9fa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bfc6cbde_e088c9ab","updated":"2026-01-11 03:24:04.000000000","message":"This almost lgtm but my suggestion is to expand this upgrade recommendation in doc and with testing.","commit_id":"ed83de46c61251420bafc33f31d193d0ba279f01"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7889a02c3f358389501179164bb1059ee2c77c02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"571ae75e_ad21805e","updated":"2026-01-14 20:51:50.000000000","message":"thanks for update and response. We are good on testing part. lgtm now.","commit_id":"f73a23b4d49cbcc0df772409f1881ff39fcdab3e"}],"releasenotes/notes/threading-by-default-sch-api-meta-d2534ce9c7b69d8a.yaml":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"d26279a4a0706ebbb5bc742bd8180687590ef9fa","unresolved":true,"context_lines":[{"line_number":12,"context_line":"    When you are upgrading to 2026.1 (Gazpacho) or newer the default"},{"line_number":13,"context_line":"    configuration of nova-scheduler, nova-api, and nova-metadata services"},{"line_number":14,"context_line":"    change to run these services with native threading mode by default"},{"line_number":15,"context_line":"    instead of the legacy eventlet mode. We recommend to decouple the"},{"line_number":16,"context_line":"    upgrade from the concurrency mode change to reduce the risk of issues."},{"line_number":17,"context_line":"    To do that either test the native threading mode of these services in"},{"line_number":18,"context_line":"    2025.2 (Flamingo) or ensure that your service configuration is explicitly"},{"line_number":19,"context_line":"    using the eventlet mode. Please read the"},{"line_number":20,"context_line":"    `concurrency \u003chttps://docs.openstack.org/nova/latest/admin/concurrency.html\u003e`__"},{"line_number":21,"context_line":"    guide for more details on how to configure the mode."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"1f013ee7_6d322a81","line":19,"range":{"start_line":15,"start_character":40,"end_line":19,"end_character":44},"updated":"2026-01-11 03:24:04.000000000","message":"I think this is important part for operators to upgrade.\n\nI have a few questions (from operator perspective) and those might need some more documentation/configuration:\n\n1. If anyone face issue for a single service in threading mode then how to run that particular service in eventlet mode but continue other service (which are ready for threading mode) in threading mode? Current OS_NOVA_DISABLE_EVENTLET_PATCHING env var either disable or enable the threading mode for all the services. Can we have per service config or env var? \n\n2. We are giving two option for upgrade strategy here 1. test threading mode before upgrade or keep service in eventlet mode. But in the later one, we are not saying switch to threading mode after upgrade.\n\n3. Doc: can we have a section in admin/concurrency.html about upgrade recommendation so that we can maintain as central and more discoverable doc for upgrade strategy? I know operator read releasenotes but having it in doc help to find this info more eaisly (via google search also).\n\n4. Testing. We do test the threading mode for sch and api service in nova-next job since F release so F-\u003eG upgrade are happening with threading mode. It is less likly that real deloyment will be enabling threading in F release or I will say upgrade might not happen in this way. Most of the upgrade will be happening via 2nd option which is switch to eventlet mode first, upgrade, switch to threading mode. So can we test that workflow in greande job? I know we discussed that greande testing in this threading switch is not needed as we recommend to doucple upgrade from threading switch but I feel in 2nd recommended option which is most likly will be the case should be tested.","commit_id":"ed83de46c61251420bafc33f31d193d0ba279f01"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c17b8c800dfa635f228cfb2d15312e6c24049d87","unresolved":true,"context_lines":[{"line_number":12,"context_line":"    When you are upgrading to 2026.1 (Gazpacho) or newer the default"},{"line_number":13,"context_line":"    configuration of nova-scheduler, nova-api, and nova-metadata services"},{"line_number":14,"context_line":"    change to run these services with native threading mode by default"},{"line_number":15,"context_line":"    instead of the legacy eventlet mode. We recommend to decouple the"},{"line_number":16,"context_line":"    upgrade from the concurrency mode change to reduce the risk of issues."},{"line_number":17,"context_line":"    To do that either test the native threading mode of these services in"},{"line_number":18,"context_line":"    2025.2 (Flamingo) or ensure that your service configuration is explicitly"},{"line_number":19,"context_line":"    using the eventlet mode. Please read the"},{"line_number":20,"context_line":"    `concurrency \u003chttps://docs.openstack.org/nova/latest/admin/concurrency.html\u003e`__"},{"line_number":21,"context_line":"    guide for more details on how to configure the mode."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"b2f4b9cf_57399472","line":19,"range":{"start_line":15,"start_character":40,"end_line":19,"end_character":44},"in_reply_to":"1f013ee7_6d322a81","updated":"2026-01-14 12:29:44.000000000","message":"\u003e I think this is important part for operators to upgrade.\n\u003e \n\u003e I have a few questions (from operator perspective) and those might need some more documentation/configuration:\n\u003e \n\u003e 1. If anyone face issue for a single service in threading mode then how to run that particular service in eventlet mode but continue other service (which are ready for threading mode) in threading mode? Current OS_NOVA_DISABLE_EVENTLET_PATCHING env var either disable or enable the threading mode for all the services. Can we have per service config or env var? \n\nThe env variable is used per service. See for example https://github.com/openstack/nova/blob/72d37f87a03dfffd19c7a7a9d9416604ebd963a6/.zuul.yaml#L518 \n\nSo the admin can decide to switch a single service type or a single service instance to a different concurrency mode by only passing a specific env variable to that service process.\n\n\u003e \n\u003e 2. We are giving two option for upgrade strategy here 1. test threading mode before upgrade or keep service in eventlet mode. But in the later one, we are not saying switch to threading mode after upgrade.\n\nI expanded the sentence now to clarify this.\n\n\u003e \n\u003e 3. Doc: can we have a section in admin/concurrency.html about upgrade recommendation so that we can maintain as central and more discoverable doc for upgrade strategy? I know operator read releasenotes but having it in doc help to find this info more eaisly (via google search also).\n\nI\u0027ve added a section in the doc. \n\n\u003e \n\u003e 4. Testing. We do test the threading mode for sch and api service in nova-next job since F release so F-\u003eG upgrade are happening with threading mode. It is less likly that real deloyment will be enabling threading in F release or I will say upgrade might not happen in this way. Most of the upgrade will be happening via 2nd option which is switch to eventlet mode first, upgrade, switch to threading mode. So can we test that workflow in greande job? I know we discussed that greande testing in this threading switch is not needed as we recommend to doucple upgrade from threading switch but I feel in 2nd recommended option which is most likly will be the case should be tested.\n\nAs far as I understand our current Grenade job  deploys F without any explicit concurrency configuration. In F every service still uses eventlet by default. Then Grenade upgrades to G where n-sch, n-api, n-metadata will change its default and start using native threading automatically. This is the most risky scenario as both upgrade and concurrency mode change happens at the same time. So I like the fact that we actually covering the most risky scenario. (scenario 1)\n\nTesting the recommended scenarios:\n2. switch on threading in F. This is partially covered by the nova-next job in F. But upgrading from F to G while using native threading already in F is not covered. We can do that but for that we would need a change the Grenade job to enables native threading in F already.\n3. forcing eventlet in F before the upgrade and keeping eventlet even in G. We can do that but for that we need to change the Grenade job to explicitly set eventlet in F. \n\nWe have one Grenade job today so we can use that to cover one of the 3 scenarios:\n1. switch mode during the upgrade\n2. switch before the upgrade\n3. do not switch during the upgrade (switch after the upgrade as a separate step)\n\nAnd if needed we can start duplicating the Grenade job to test all of these scenarios.\n\nNote that the real end to end case in the 3rd scenario cannot be covered with today\u0027s Grenade infra as there we would need:\n1. deploy F with explicit eventlet config\n2. upgrade and ensure G runs with eventlet and tests passes\n3. re-configure G to now use threading and re-test the deployment. AFAIK this step does not fit the Grenade model.","commit_id":"ed83de46c61251420bafc33f31d193d0ba279f01"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"7889a02c3f358389501179164bb1059ee2c77c02","unresolved":true,"context_lines":[{"line_number":12,"context_line":"    When you are upgrading to 2026.1 (Gazpacho) or newer the default"},{"line_number":13,"context_line":"    configuration of nova-scheduler, nova-api, and nova-metadata services"},{"line_number":14,"context_line":"    change to run these services with native threading mode by default"},{"line_number":15,"context_line":"    instead of the legacy eventlet mode. We recommend to decouple the"},{"line_number":16,"context_line":"    upgrade from the concurrency mode change to reduce the risk of issues."},{"line_number":17,"context_line":"    To do that either test the native threading mode of these services in"},{"line_number":18,"context_line":"    2025.2 (Flamingo) or ensure that your service configuration is explicitly"},{"line_number":19,"context_line":"    using the eventlet mode. Please read the"},{"line_number":20,"context_line":"    `concurrency \u003chttps://docs.openstack.org/nova/latest/admin/concurrency.html\u003e`__"},{"line_number":21,"context_line":"    guide for more details on how to configure the mode."}],"source_content_type":"text/x-yaml","patch_set":1,"id":"e2b93c2c_8c18e310","line":19,"range":{"start_line":15,"start_character":40,"end_line":19,"end_character":44},"in_reply_to":"b2f4b9cf_57399472","updated":"2026-01-14 20:51:50.000000000","message":"\u003e \u003e 1. If anyone face issue for a single service in threading mode then how to run that particular service in eventlet mode but continue other service (which are ready for threading mode) in threading mode? Current OS_NOVA_DISABLE_EVENTLET_PATCHING env var either disable or enable the threading mode for all the services. Can we have per service config or env var? \n\u003e \n\u003e The env variable is used per service. See for example https://github.com/openstack/nova/blob/72d37f87a03dfffd19c7a7a9d9416604ebd963a6/.zuul.yaml#L518 \n\u003e \n\u003e So the admin can decide to switch a single service type or a single service instance to a different concurrency mode by only passing a specific env variable to that service process.\n\nRight, I thought its global but now I get your point. Its up to admin how they set this env var per service and as per the service deployment model. All good now.\n\n\u003e \n\n\u003e \u003e \n\u003e \u003e 4. Testing. We do test the threading mode for sch and api service in nova-next job since F release so F-\u003eG upgrade are happening with threading mode. It is less likly that real deloyment will be enabling threading in F release or I will say upgrade might not happen in this way. Most of the upgrade will be happening via 2nd option which is switch to eventlet mode first, upgrade, switch to threading mode. So can we test that workflow in greande job? I know we discussed that greande testing in this threading switch is not needed as we recommend to doucple upgrade from threading switch but I feel in 2nd recommended option which is most likly will be the case should be tested.\n\u003e \n\u003e As far as I understand our current Grenade job  deploys F without any explicit concurrency configuration. In F every service still uses eventlet by default. Then Grenade upgrades to G where n-sch, n-api, n-metadata will change its default and start using native threading automatically. This is the most risky scenario as both upgrade and concurrency mode change happens at the same time. So I like the fact that we actually covering the most risky scenario. (scenario 1)\n\u003e \n\u003e Testing the recommended scenarios:\n\u003e 2. switch on threading in F. This is partially covered by the nova-next job in F. But upgrading from F to G while using native threading already in F is not covered. We can do that but for that we would need a change the Grenade job to enables native threading in F already.\n\u003e 3. forcing eventlet in F before the upgrade and keeping eventlet even in G. We can do that but for that we need to change the Grenade job to explicitly set eventlet in F. \n\u003e\n\nah, I missed the fact that in F, eventlet is default so F-\u003eG grenade job (current master) is testing the scenario I mentioned in my comment.  As you mentioned, that is more risky scenario and if that is working then switching mode explicitly will work so we do not need to test those separatly. \n\nI agree that rest all existing testing is enough. We have jobs testing both eventlet and threading mode in F and G code so we do not need to test the explicit 2nd and 3rd case in greande as that is implicit tested in normal jobs.\n\nFor future, when conductor and compute will become threading mode as default in H then grenade job in H (G-H) will test the same for conductor and compute service so we are good there too.\n\nThanks for clarifying, I am convienced on testing now.","commit_id":"ed83de46c61251420bafc33f31d193d0ba279f01"}]}