Fix 2253: Surface x-ms-* headers and ODataV4 errors on Azure failures - #2344
Draft
zunyangc wants to merge 2 commits into
Draft
Fix 2253: Surface x-ms-* headers and ODataV4 errors on Azure failures#2344zunyangc wants to merge 2 commits into
zunyangc wants to merge 2 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
SUMMARY
Fix #2253.
azure_rm_resource_infonow surfaces Azure'sx-ms-request-id,x-ms-correlation-request-id, the full response-header dict, and the ODataV4 error body (code,message,target,details,innererror) on failure. A newfail_azurehelper onAzureRMModuleBaseprovides the same structured failure payload for every module, and the previously-nonfunctionallog_modeandlog_pathmodule arguments now attach a rotating, mode-0o600 debug log atlog_pathwith a per-invocationcorrelation_id.ISSUE TYPE
COMPONENT NAME
ADDITIONAL INFORMATION
azure_rm_resource_infofailures now includecorrelation_id,response_metadata.{status_code,reason,request_id,correlation_request_id,http_headers}, anderror.{code,message,target,details,innererror}(cited:azure.core.exceptions.HttpResponseErrorandODataV4Formatpublic shape inAzure/azure-sdk-for-python).AzureRMModuleBase.fail_azure(exception, msg=None, **kwargs)is available for every module to routeazure.core.exceptions.HttpResponseError(and 8000AzureError) into a structured failure payload with redacted sensitive headers.GenericRestClient.on_errorfallback now raisesazure.core.exceptions.HttpResponseError(response=response)instead ofSendRequestException, preserving theHttpResponseobject so headers survive to the caller; the unreferencedSendRequestExceptionclass is removed.log_modegains real semantics:normal(default, unchanged behavior),file(attaches aSecureRotatingFileHandleratlog_path— mode 0o600, 10 MB × 5 backups), anddebug(raises theazure.azcollectionlogger level to DEBUG). Auto-elevates to DEBUG when Ansible is invoked with-vvvor whenAZURE_LOG_LEVELis set to a standard level.correlation_idthat appears in the log file and infail_azurefailure payloads for cross-record traceability.AzureRMModuleBase.log()andAzureRMAuth.log()now emit through theazure.azcollectionnamed logger in addition to Ansible's debug channel, so existingself.log(...)sites automatically populate the new log file whenlog_mode: fileis set.plugins/doc_fragments/azure.pyreplaces the stale"Parent argument."descriptions forlog_modeandlog_pathwith real behavior documentation and distinguishes them from Ansible-core'sANSIBLE_LOG_PATH.REFERENCE