Skip to content

updating poster - #35

Merged
Perry Skountrianos (perrysk-msft) merged 1 commit into
microsoft:masterfrom
BYHAM:Rick26
May 16, 2016
Merged

Perry Skountrianos (perrysk-msft) merged 1 commit into
microsoft:masterfrom
BYHAM:Rick26

Conversation

@BYHAM

Copy link
Copy Markdown
Contributor

No description provided.

@BYHAM

Copy link
Copy Markdown
Contributor Author

#sign-off

@perrysk-msft
Perry Skountrianos (perrysk-msft) merged commit e22ec9e into microsoft:master May 16, 2016
Umachandar Jayachandran (uc-msft) pushed a commit that referenced this pull request Aug 31, 2026
Azure SQL updates previously always blocked until the operation completed, so a
large estate was processed serially. They are now submitted with --no-wait and
reported as 'RequestSubmitted'; passing -WaitForCompletion omits the flag so the
CLI polls to a terminal state and the result is reported as 'Updated'. This
matches the Arc path, which has always used -NoWait, giving one consistent
default across resource types.

Two resource types cannot honour this and are documented rather than faked:
'az sql vm update' and Set-AzDataFactoryV2IntegrationRuntime expose no
--no-wait/-AsJob equivalent. A generic 'az resource update/patch' fallback does
not support --no-wait either, and a direct ARM PATCH on a SQL VM is rejected
with MissingPatchParameters (approved values: tags, additionalVmPatch), so the
license type cannot be set by a lightweight non-blocking call. Hand-rolling a
full PUT was judged worse than documenting the limitation.

The helper only appends --no-wait for commands that accept it, and tolerates the
empty response body those calls return.

Adds TESTPLAN cases #33-#35 and re-syncs the embedded copy.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants