)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15197,"name":"Pierre Riteau","email":"pierre@stackhpc.com","username":"priteau","status":"StackHPC"},"change_message_id":"46c8231aacfe273da7cbf5882d663e74987fc2f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e6b1890c_faf81ba2","updated":"2025-01-14 12:05:56.000000000","message":"Marked as work in progress as this might break deployments not using Vserver scoping (I don\u0027t have a way to test this).","commit_id":"1a0b7cf3cd1787a5f9e15ced09b55fe7d1004773"},{"author":{"_account_id":38864,"name":"Sridhar Kumar Ettkepalli","display_name":"Sridhar","email":"sridharkumar.ettkepalli@windriver.com","username":"settkepa"},"change_message_id":"c77831a9d25889a681e2c3840f03c44ae42125a8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"4e6270d6_a2ff4516","updated":"2026-09-04 19:19:33.000000000","message":"We hit the same Vserver-scoped startup failure this change targets and wanted to share findings, since the change has been idle for a while -- hoping to help move it forward.\n\nIssue(tunneling header): setting enable_tunneling\u003dFalse on _get_volume_by_args and get_operational_lif_addresses fixes those two calls, but other send_request() call sites still default to enable_tunneling\u003dTrue and hit SVM-namespaced endpoints, so an SVM-scoped account can still receive X-Dot-SVM-Name elsewhere and get rejected (error 2621712). Rather than disabling tunneling call-by-call, would detecting the account scope once at init -- e.g. GET /api/svm/svms returning a single record \u003d\u003e SVM-scoped -- and suppressing the header centrally in _build_headers() be more robust? That covers all call sites while leaving cluster-scoped behavior unchanged. Filed as bug #2166532 with this detail.\n\nIssue(perf-counter fallback): changing the _init_counter_info fallback from `except netapp_api.NaApiError` to `except exception.NotFound` handles the REST path, but the ZAPI path raises NaApiError for the same missing/empty counter, so the narrowed except would no longer catch the ZAPI case -- a possible regression for legacy clients. An alternative that covers both paths: fix it at the source in client_cmode_rest.get_performance_counter_info, which currently translates NaApiError into exception.NotFound; re-raising the original NaApiError there lets the existing fallback handle REST and ZAPI consistently, and _init_counter_info wouldn\u0027t need to change.","commit_id":"77fa09cd105a43e902ca2c398601d862337e6846"}],"cinder/volume/drivers/netapp/dataontap/performance/perf_cmode.py":[{"author":{"_account_id":38059,"name":"Anoop Kumar Shukla","display_name":"Anoop Shukla","email":"anoop.shukla@netapp.com","username":"anoop2","status":"NetApp"},"change_message_id":"bb579ef0970ebace99eaf69d14515b67b871b0f8","unresolved":true,"context_lines":[{"line_number":50,"context_line":"                self.avg_processor_busy_base_counter_name \u003d ("},{"line_number":51,"context_line":"                    self._get_base_counter_name(\u0027system\u0027,"},{"line_number":52,"context_line":"                                                \u0027avg_processor_busy\u0027))"},{"line_number":53,"context_line":"        except exception.NotFound:"},{"line_number":54,"context_line":"            if self.zapi_client.features.SYSTEM_CONSTITUENT_METRICS:"},{"line_number":55,"context_line":"                self.avg_processor_busy_base_counter_name \u003d \u0027cpu_elapsed_time\u0027"},{"line_number":56,"context_line":"            else:"}],"source_content_type":"text/x-python","patch_set":2,"id":"899da093_6f408374","line":53,"updated":"2026-09-24 05:05:47.000000000","message":"ZAPI still raises NaApiError when the API call fails. If the fallback only catches NotFound, the previously working ZAPI path starts failing on those errors.\n\nPlease look at https://review.opendev.org/c/openstack/cinder/+/1004868 which is the right fix for this issue.","commit_id":"77fa09cd105a43e902ca2c398601d862337e6846"}]}