text:
JCore brownfield alerts - fix query for AVD Agent Health

Overview/Summary
This fixes a noted issue with the alert "AVD-HP-VM-HlthChkFailure-(hostpoolname)" in which the Session Host Name was not populating due to the query having an extra space in the parse line for the Resource Id.
Noted space is after the quotes before '/providers' and removed for both the BICEP and ARM template.
| parse ....... SessionHostRG " /providers/Microsoft.Compute/virtualMachines/" SessionHostName
vs
| parse ....... SessionHostRG "/providers/Microsoft.Compute/virtualMachines/" SessionHostName
This PR fixes/adds/changes/removes

Query for the AVD-HP-VM-HlthChkFailure alert to ensure the Session Host Name is returned in the results
Adjusted threshold for Azure Files availability from 99 to 99.99 due to degradation noted prior to hitting the threshold which is too low.

Breaking Changes

N/A

Testing Evidence
Tested query in Log Analytics to verify issue was resolved and was noted while reviewing for another customer.
As part of this Pull Request I have

[X] Read the Contribution Guide and ensured this PR is compliant with the guide
[X] Ensured the resource API versions in .bicep file/s I am adding/editing are using the latest API version possible
[X] Checked for duplicate Pull Requests
[X] Associated it with relevant GitHub Issues
[X] (AVD LZA Team Only) Associated it with relevant ADO Items
[X] Ensured my code/branch is up-to-date with the latest changes in the main branch
[X] Performed testing and provided evidence.
[X] Updated relevant and associated documentation (e.g. Contribution Guide, Module READMEs, Docs etc.)

@JCoreMS thanks for your contribution

authors: JCoreMS danycontre

repo: Azure/avdaccelerator


text:
[Datadog] Release new CLI with stable api version

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[x] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[x] Have you run python scripts/ci/test_index.py -q locally?

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

Datadog

source: gharchive/pull-request

authors: limingu yonzhan

repo: Azure/azure-cli-extensions

license: MIT

license_type: permissive

license_source: github-api


text:
{AKS} Update unit test pipeline to fix coverage report issue

This checklist is used to make sure that common guidelines for a pull request are followed.
Update unit test pipeline to fix coverage report issue.
General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally?

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

AKS

authors: FumingZhang yonzhan


text:
ADAL to MSAL move for cli>=2.30.0

This checklist is used to make sure that common guidelines for a pull request are followed.
General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally?

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

connectedK8S

@sirireddy12 Could you sync code from the remote main branch, so that this PR can skip the test issues of other modules

@sirireddy12 Could you sync code from the remote main branch, so that this PR can skip the test issues of other modules

done, thanks

Not related to this PR but I observed we have added all error messages and summary in code itself. Does we need to consider localization of those messages? If so, we should move all messages to separate file and load from there. We can have work item to track this work separately.

Could you add some test cases for those changes?

Could you add some test cases for those changes?

We are tracking a separate WI to author test cases. We will be increasing the test coverage with that. Can we go ahead with this PR?

We are tracking a separate WI to author test cases. We will be increasing the test coverage with that. Can we go ahead with this PR?

OK

authors: krdhruva sirireddy12 yonzhan zhoxing-ms


text:
Changes for the new api version 2023-08-01 and migrating to aaz

This checklist is used to make sure that common guidelines for a pull request are followed.
Related command

General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[ ] Have you run python scripts/ci/test_index.py -q locally?

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.


text:
Issues with the update option for vpn-gateway in Python and JS

The arguments for the two are very different. Python provides a generic way to specify objects but JS doesnt have this capability. As a result, in JS, there is no way to set BGP settings
Python doesnt have settings for SKU
Why does Python have address-prefixes param? It is not there in powershell. It is not needed
Both versions should have params for BGP and other settings. Just specifying an object is not enough

Issues with Xplat (Node) should be filed separately here: https://github.com/Azure/azure-xplat-cli

@aanandr
By #2 do you mean that capacity is not exposed? Is there ever an instance where name and tier would not be the same?
IRT #3 address-prefixes is present, according to the help, because it is a prerequisite for uploading certificates. Is this not the case?

Our action items:

[ ] Add BGP peering settings to create and update (just like with local-gateway)
[ ] Add SKU capacity
[ ] Add missing UltraPerformance SKU type

source: gharchive/issue

authors: aanandr tjprescott

repo: Azure/azure-cli


text:
WebApp:az webapp plan show` returns exit code 0 for non-existing resource

This is autogenerated. Please review and update as needed.
Describe the bug
az webapp plan show` returns exit code 0 for non-existing resource.  Other commands return a non-zero return code.
This behavior of "show" needs to be consistent across the CLI or script writing/maintenance is going to become unmanageable having to remember which commands bahave one way vs another.
Possibly a similar issue to #14572
Command Name
az appservice plan show
Errors:
Returns 0 if app service plan does not exist.
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az appservice plan show -n {"non-existant-plan-name"} -g {"existing-RG"}

Expected Behavior
returns non-zero result
Environment Summary
Windows-10-10.0.19041-SP0
Python 3.6.8
Installer: MSI

azure-cli 2.17.1

Extensions:
application-insights 0.1.13

Additional Context

webapp

webapp

Able to repro the issue.Will look into this

Is there any workaround in the meantime?

My workaround was to check the contents of the returned json.   It is $null when the plan does not exist where specified (including incorrect RG) however this forces me to check I have the correctly named RG first.
BTW, my original title was wrong - the command uses "appservice plan" not "webapp plan".  i.e. az appservice plan show -n ... -g ...

I ended up going for:
plan_name="my-plan"

if [[ $(az appservice plan list --query "[?name=='${plan_name}'].name" -o tsv | wc -l) -gt 0 ]]; then
  # App Service plan already exists
fi

It is quite annoying coming across these inconsistencies in the Azure CLI from time to time. I get it's vast, with a lot of commands, but the structure is consistent, and so it feels like consistency of behaviour should be achievable - @ThejaChoudary have you (as in the Az CLI team 😄) looked into the possibility of creating some kind of linter/analyser? Idea is you feed it rules (like "any show command should return non-zero if resource not found").

Duplicate of #17424

I'd argue 17424 is a duplicate of this.

Yeah I will agree with you @MarkAtAgilliance. I have given fix for #17424 and later on I have figure out there is an issue already logged for it. So thought of making this issue as duplicate as I cannot change the Fix history for #17424. Sorry for marked this as a duplicate. Hope you convince :)

authors: Kotasudhakarreddy MarkAtAgilliance ThejaChoudary cocowalla yonzhan


text:
Warn users when newer extension versions are masked by an older Azure CLI version

Is your feature request related to a problem? Please describe.
I've been seeing a lot of issues with customers who have a version of aks-preview that's too old for what they're trying to do, but when they do az extension update -n aks-preview it doesn't update them because the newer versions have a min_version higher than their Azure CLI version.
As an example, let's say I need an AKS feature that depends on aks-preview >= 0.5.49. If I have Azure CLI 2.25.0 installed, this is the result of adding the extension:
$ az version
{
  "azure-cli": "2.25.0",
  "azure-cli-core": "2.25.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {}
}

$ az extension add -n aks-preview
The installed extension 'aks-preview' is in preview.

$ az extension update -n aks-preview
No updates available for 'aks-preview'. Use --debug for more information.

$ az version
{
  "azure-cli": "2.25.0",
  "azure-cli-core": "2.25.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "aks-preview": "0.5.41"
  }
}

Nowhere was I told that there's a newer aks-preview available if I update Azure CLI:
$ az version
{
  "azure-cli": "2.32.0",
  "azure-cli-core": "2.32.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "aks-preview": "0.5.51",
    "fzf": "1.0.2"
  }
}

Describe the solution you'd like

Add warning text during az extension add and az extension update if there are newer extension versions that aren't eligible candidates because their minimum version is higher than the currently installed version.
Describe alternatives you've considered

Error during adding/updating if they can't get the newest version, thus preventing them from any version. This seems much less user friendly.

Additional context

I have seen this on at least four or five issues or ICMs just in the last two weeks. It's a common problem.

Core

Hi，
Thank you for your suggesting, we will improve it .
Best wishes.

authors: YuanyuanNi phealy yonzhan


text:
I cannot run az login

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az login
Errors:
The command failed with an unexpected error. Here is the traceback:
0. The ID token is not yet valid. Current epoch = 1646833256.  The id_token was: {
  "aud": "04b07795-8ddb-461a-bbee-02f9e1bf7b46",
  "iss": "https://login.microsoftonline.com/f8cdef31-a31e-4b4a-93e4-5f571e91255a/v2.0",
  "iat": 1646833661,
  "nbf": 1646833661,
  "exp": 1646837561,
  "aio": "AWQAm/8TAAAA/b8cM1fPkdw/bqP9xGyvSFjJZJ2fVFGSndqpMRI9LMAy1Pt5IA9ovlpvmYbhiO9d0040UIdxrNpzC2DZ7xellHSiL3t43uX39aMHX0mLRYEDILYfJtwUM0oEQLbv/V1D",
  "idp": "https://sts.windows.net/9188040d-6c67-4c5b-b112-36a304b66dad/",
  "nonce": "08af78634ee4e854643123f228f0a99de385db9d4922111c80214ee970fd8498",
  "preferred_username": "rattana_feline@hotmail.com",
  "rh": "0.AVUAMe_N-B6jSkuT5F9XHpElWpV3sATbjRpGu-4C-eG_e0YBAGQ.",
  "sub": "8rob_8RKb3D6xjv_S2FlenJIB1G2onfiY9gQMjXerpg",
  "tid": "f8cdef31-a31e-4b4a-93e4-5f571e91255a",
  "uti": "Jl3RS4AcMkKW9Yc4xkJZAA",
  "ver": "2.0"
}
Traceback (most recent call last):
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 231, in invoke
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 658, in execute
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 721, in _run_jobs_serially
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 692, in _run_job
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 328, in __call__
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/profile/custom.py", line 139, in login
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/_profile.py", line 155, in login
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/auth/identity.py", line 171, in login_with_auth_code
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/application.py", line 1546, in acquire_token_interactive
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oidc.py", line 280, in obtain_token_by_browser
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oauth2.py", line 640, in obtain_token_by_browser
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oauth2.py", line 678, in _obtain_token_by_browser
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/application.py", line 135, in obtain_token_by_auth_code_flow
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oidc.py", line 204, in obtain_token_by_auth_code_flow
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oauth2.py", line 548, in obtain_token_by_auth_code_flow
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oauth2.py", line 732, in _obtain_token_by_authorization_code
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oidc.py", line 115, in _obtain_token
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oauth2.py", line 789, in _obtain_token
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/application.py", line 581, in <lambda>
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/token_cache.py", line 307, in add
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/token_cache.py", line 113, in add
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/token_cache.py", line 152, in __add
  File "D:\a\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\msal/oauth2cli/oidc.py", line 76, in decode_id_token
RuntimeError: 0. The ID token is not yet valid. Current epoch = 1646833256.  The id_token was: {
  "aud": "04b07795-8ddb-461a-bbee-02f9e1bf7b46",
  "iss": "https://login.microsoftonline.com/f8cdef31-a31e-4b4a-93e4-5f571e91255a/v2.0",
  "iat": 1646833661,
  "nbf": 1646833661,
  "exp": 1646837561,
  "aio": "AWQAm/8TAAAA/b8cM1fPkdw/bqP9xGyvSFjJZJ2fVFGSndqpMRI9LMAy1Pt5IA9ovlpvmYbhiO9d0040UIdxrNpzC2DZ7xellHSiL3t43uX39aMHX0mLRYEDILYfJtwUM0oEQLbv/V1D",
  "idp": "https://sts.windows.net/9188040d-6c67-4c5b-b112-36a304b66dad/",
  "nonce": "08af78634ee4e854643123f228f0a99de385db9d4922111c80214ee970fd8498",
  "preferred_username": "rattana_feline@hotmail.com",
  "rh": "0.AVUAMe_N-B6jSkuT5F9XHpElWpV3sATbjRpGu-4C-eG_e0YBAGQ.",
  "sub": "8rob_8RKb3D6xjv_S2FlenJIB1G2onfiY9gQMjXerpg",
  "tid": "f8cdef31-a31e-4b4a-93e4-5f571e91255a",
  "uti": "Jl3RS4AcMkKW9Yc4xkJZAA",
  "ver": "2.0"
}

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az login

Expected Behavior
Environment Summary
Windows-10-10.0.19041-SP0
Python 3.8.9
Installer: MSI

azure-cli 2.34.1

Additional Context

Duplicate of #20388

authors: felinekk jiasli


text:
Cosmos DB --network-acl-bypass-resource-ids need to be validated further

Related command
az cosmosdb update --name MyCosmosDBDatabaseAccount--resource-group MyResourceGroup--network-acl-bypass AzureServices --network-acl-bypass-resource-ids "/subscriptions/subId/resourceGroups/rgName/providers/Microsoft.Synapse/workspaces/wsName"
Describe the bug
It's possible to input resource id without leading '/' in URI, and this cause Cosmos DB Analytical Store to be unable to identify the mentioned resources and by-pass on network acl checking.
Without the leading '/' in resource URI, CLI execution won't report any errors or indicate it's actually an invalid format.
Cosmos DB can still store the invalid URI at last, but no help to allow querying from Synapse.
To Reproduce
az cosmosdb update --name MyCosmosDBDatabaseAccount--resource-group MyResourceGroup--network-acl-bypass AzureServices --network-acl-bypass-resource-ids "subscriptions/subId/resourceGroups/rgName/providers/Microsoft.Synapse/workspaces/wsName"
Expected behavior
Please validate the input values of --network-acl-bypass-resource-ids, to ensure customer configuring their resource correctly.
Environment Summary
Linux-5.4.0-1091-azure-x86_64-with-glibc2.35 (Cloud Shell), CBL-Mariner/Linux
Python 3.9.13
Installer: RPM

azure-cli 2.40.0

Extensions:
kusto 0.4.0
cosmosdb-preview 0.17.0
ai-examples 0.2.5
ml 2.7.1
ssh 1.1.2

Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.1.0b1

Additional Context

route to CXP team

@chshihMSFT Thanks for reaching out to us and reporting this issue. We are looking into this issue and we will provide an update.

@chshihMSFT The above PR has been filed to address this issue. It is currently under review. If you have any pending concerns in the meantime, please let me know.

Hi @navba-MSFT, @evelyn-ys,
Thanks for the PR merge.
I've executed command az upgrade to get latest update for CLI modules but looks like the issue still exists; I can still input the resourceId (URI) without leading '/', then leads ill-format configuration in Cosmos DB account.
{
  "azure-cli": "2.41.0",
  "azure-cli-core": "2.41.0",
  "azure-cli-telemetry": "1.0.8",
  "extensions": {
    "ai-examples": "0.2.5",
    "cosmosdb-preview": "0.20.0",
    "kusto": "0.5.0",
    "ml": "2.10.0",
    "ssh": "1.1.2"
  }
}

@chshihMSFT The PR was merged a while ago. The fix is part of this milestone Targeted for 2022-11-01 and not yet released. https://github.com/Azure/azure-cli/milestone/123 .

Thanks! Looking forward to it.

A bit unrelated, but my search always end up here.

How can I reset a value on --network-acl-bypass-resource-ids  ?
For the --network-acl-bypass  it works by setting to None,   but I have found no value that resets the ids

authors: chshihMSFT claus18 navba-MSFT yonzhan


text:
az bicep upgrade failure

This is autogenerated. Please review and update as needed.
I ran "az bicep upgrade" and now this is what happens.
I'm using the latest version of az cli (2.44.1), I have tried rolling back to a previous version of bicep (13.1) but i get the same issue
Looks similar to this
https://github.com/Azure/azure-cli/issues/24482
Command Name
az bicep version
Errors:
The command failed with an unexpected error. Here is the traceback:
[WinError 193] %1 is not a valid Win32 application
Traceback (most recent call last):
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 663, in execute
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 697, in _run_job
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 333, in __call__
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/custom.py", line 3708, in show_bicep_cli_version
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/_bicep.py", line 75, in run_bicep_command
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/_bicep.py", line 203, in _get_bicep_installed_version
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/resource/_bicep.py", line 241, in _run_command
  File "subprocess.py", line 503, in run
  File "subprocess.py", line 971, in __init__
  File "subprocess.py", line 1440, in _execute_child
OSError: [WinError 193] %1 is not a valid Win32 application

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az bicep version

Expected Behavior
Environment Summary
Windows-10-10.0.19045-SP0
Python 3.10.8
Installer: MSI

azure-cli 2.44.1

Extensions:
account 0.2.5
automation 0.2.1
front-door 1.0.17
virtual-wan 0.2.15

Dependencies:
msal 1.20.0
azure-mgmt-resource 21.1.0b1

Additional Context

route to CXP team

@kmkelly2015 Thanks for reaching out to us and reporting this issue. Could you please follow the below action plan in order and let me know if that helps ?
Plan 1:
Could you try running %USERPROFILE.azure\bin\bicep.exe --version and see if it works?
Plan 2:
If the above plan doesn't help, Please clean up the %USERPROFILE.azure\bin folder and run az bicep install to reinstall Bicep for Azure CLI.
Hope this helps.

@navba-MSFT This has fixed the issue.
Thank you

authors: kmkelly2015 navba-MSFT yonzhan


text:
{Core} Vendor subscription SDK in azure-cli-core

Description
Vendor subscription SDK in azure-cli-core so that it doesn't have dependency on azure-mgmt-resource, which is required by resource command module.
In this way, azure-cli-core can start using Track 2 azure-mgmt-resource SDK before resource finishes the migration.
To switch back to using public SDK, simply change _USE_VENDEROED_SUBSCRIPTION_SDK to False.

Core

authors: jiasli yonzhan


text:
[Fish Shell Auto Completions]

Description
This adds Fish Shell auto completions with descriptions of sub commands and flags from the Azure CLI. There has been no changes to the actual code or functionality of the Azure CLI.
Testing Guide
Since this will not affect the build or release of the Azure CLI. No testing is required.
History Notes
[create-fish-complete.py] create fish complete statements

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

Fish Shell Auto Completions

The demo is awesome.

is there any progress with it guys ?

authors: borqosky mattpasco-microsoft qwordy yonzhan


text:
{appservice} Fix #24822: Fix 'az webapp delete -h' the help message f…

…or name parameter
Fixes https://github.com/Azure/azure-cli/issues/24822
Related command

Description

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

appservice

authors: RakeshMohanMSFT yonzhan


text:
{packaging} Update argcomplete to 3.0.8

Closes #26375
argcomplete added full zsh support in 3.0.0
Related command

Description

Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

packaging

@microsoft-github-policy-service agree company="Microsoft"

Thanks for your contribution. I'll check this update does not break anything later.
I will give this a low priority:

2.0 still the latest version in Fedora, we update it in #24903 because older versions of argcomplete are no longer available.
Current version works on Zsh. In 3.0 Fully support zsh. Argcomplete now supports completion descriptions and global completion in zsh.

Close as https://github.com/Azure/azure-cli/pull/26684 is merged

authors: bebound thehappydinoa yonzhan


text:
Allow Linter to run on VM module for CI

View a preview at https://prompt.ws/r/Azure/azure-cli/6132
This is an experimental preview for @microsoft users.

authors: promptws williexu


text:
How to use network policy

For network policy feature, are we required to enable the network policy feature when creating the aks cluster: https://docs.microsoft.com/en-us/azure/aks/use-network-policies
I created the aks cluster using portal, and I couldn't find a way to enable network policies. I applied the plugin using: https://github.com/Azure/azure-container-networking/blob/master/docs/npm.md
kubectl apply -f https://raw.githubusercontent.com/Azure/azure-container-networking/master/npm/azure-npm.yaml

But after applying a policy, I couldn't see any effect.

As far as I can tell you are required to have the networkPolicy and networkPlugin options set to azure, per the docs you linked to:
az aks create \
    ...
    --network-plugin azure \
    ...
    --network-policy azure

Or equivalent if using ARM templates

Hi @anujgeek , you have to explicitly declare --network-policy azure for AKS. @RossBarnie thanks for the reply!

Closing the issue as it is well documented on  https://docs.microsoft.com/en-us/azure/aks/use-network-policies

authors: RossBarnie anujgeek saiyan86

repo: Azure/azure-container-networking


text:
[backport] CI/CD changes to PR and CNI Release Test Pipelines

Backports

https://github.com/Azure/azure-container-networking/pull/2862
https://github.com/Azure/azure-container-networking/pull/2898
https://github.com/Azure/azure-container-networking/pull/2922
#2901

2898 was captured as part of the 2901 cherry-pick.

Reason for Change:

Issue Fixed:

Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[x] relevant PR labels added

Notes:

/azp run Azure Container Networking PR


text:
Setup SNAT Configuration Based on Azure Host Support

What this PR does / why we need it:
CNI will now query for SNAT and DNS support from Azure Host.
In Linux, the features can be separately applied; but on Windows SNAT will only be disabled if both new features on the Host are supported.

/azp run

/azp run

/azp run

/azp run

authors: jaer-tsun matmerr


text:
Edit: machine-learning-recommendation-api-sample-application.md

Sent email to Jaya with this feedback:
I have edited this topic. A few questions aside from my suggestions:
•	I think the topic is not titled well. It is really more about Sample app to create a recommendation model or Sample app for collecting recommendation data.
•	The purpose is also misleading. It seems to be more like:
Use this sample app to collect data and create a model that you can use to recommend items for users.
•	The topic is missing a link to the sample app. This is pretty frustrating for a reader.
•	Line 62: You need  a link to the documentation you are talking about (For a complete description of the APIs, please see the Microsoft Azure Marketplace documentation.)
•	I don’t think you need to list the APIs twice. You start one list at line 25 and do it again at line 54. You could easily combine this information. Use the actual names of the APIs. Links to each API would be helpful.
•	Line 70: We don’t want to point out bad behavior such as this: the created recommendation model is not meaningful.
I deleted that text.
•	We do not need legal disclaimers in the topics. We are covered as a website. I deleted.

Hi @ClarityQueen, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

authors: ClarityQueen azurecla

repo: Azure/azure-content


text:
Update key-vault-developers-guide.md

drat - I keep forgetting to update the article date
changed it

Hi @BrucePerlerMS, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

authors: BrucePerlerMS azurecla


text:
Added clarity for Private Peering

As discussed with @ganesr, this is a proposed change to the doc.

Hi @omartin2010, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (omartin). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@omartin2010 : Thanks for your contribution to the Azure documentation! The author, @charwen, has been notified to review your proposed change.

#sign-off

@tysonn please merge this PR.

authors: PRmerger Saisang azurecla charwen omartin2010


text:
Using the value of one operation as input for another, within the same TransactionalBatch

This is mostly directed at @ealsur (sorry 😉 ) in reference to a comment he made on the blog post originally announcing TransactionalBatch as a feature.
At the bottom, he stated:
"Using a value from one operation as input of another within the same TransactionalBatch is not currently supported."
Which left me wondering... is that something which will change in the future? Is that kind of functionality on the roadmap?
The reason I'm interested: I'm currently putting together something which requires an atomic read-write, and it looks like the only way to currently achieve this with CosmosDB is via a stored procedure written in JavaScript. That's fine, I've almost finished writing it, but... that particular area of CosmosDB seems stagnant at best. (The main documentation for the server-side Javascript environment it uses hasn't been updated since 2018, for example.)
So it'd be great to get a little bit of clarification on the intended future direction for situations like mine.

@abhijitpai Could you share if this is something that is on the roadmap or any ideas?

@RichWK can you give an example of why you need atomic read-write?

It's basically the same situation as described in Tom Robinson's comment on that blog post I linked to. This is what's happening:

We have a frontend where a user can request 1 to 10 unique IDs
These IDs are sequential, so they might end up with "100,000,022", "100,000,023" and "100,000,024", for example
If two users make a request at exactly the same time, they must not receive the same IDs

Previously I had an Azure Function talking to a Cosmos DB and doing this:

Read the "current ID"
Increment by however many IDs the user requested
Update the new "current" value back to the database (and supply the user with their IDs)

But that resulted in the same IDs being issued if two people made a request at exactly the same time — hence my current situation, writing a stored procedure for an atomic read-write.
Am I approaching this incorrectly?

Mmmm number incremental identifiers for distributed databases is kind of a tight pinch, isn't it?

Is there any reason unique-keys wouldn't solve the issue?

@ealsur Hahah yes, when you put it like that... it doesn't sound great. 😄 The frontend has very low usage, so CosmosDB was attractive due to serverless billing recently having entered preview status.
So regardless, it seems like this is too much of an edge case to be supported in the .NET SDK.
@j82w There isn't actually more than a single record being created, ever — this is the entire database:

If you have low concurrency for the requests trying to get these unique ids, just a read-increment-replace loop where the replace uses optimistic concurrency control as per https://docs.microsoft.com/en-us/azure/cosmos-db/database-transactions-optimistic-concurrency#optimistic-concurrency-control may suffice. The caller is only provided with the ids after the replace has succeeded.
For high concurrency, stored procedures as you mentioned could be an option for now to achieve what you need.
We are looking at exposing item patch functionality with an increment operator in future that can help simplify this use case.

Thanks for the advice! Much appreciated. @abhijitpai

authors: RichWK abhijitpai ealsur j82w


text:
Increment VSCode Extension version after release

Increment VSCode Extension version after release

VSCode Extension Installation Instructions

Download the extension at https://azuresdkreleasepreview.blob.core.windows.net/azd/vscode/pr/1727/azure-dev-0.5.0-alpha.1.vsix
Extract the extension from the compressed file
In vscode
a. Open "Extensions" (Ctrl+Shift+X)
b. Click the ...\ menu at top of Extensions sidebar
c. Click "Install from VSIX"
d. Select location of downloaded file

repo: Azure/azure-dev


text:
Shorten revision suffix for ACA apps

Fixes #2178
Max length of ACA resource name is 32 chars
Max length of ACA resource name + revision suffix is 54 chars
This leaves us with a maximum of 22 chars for revision suffix.  Our previous length was exactly at 22 but were still hitting the limit.
This reduces our revision to be azd-<timestamp> giving us a few extra buffer chars.

Azure Dev CLI Install Instructions
Install scripts
MacOS/Linux

May elevate using sudo on some platforms and configurations

bash:
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226 --version '' --verbose --skip-verify

pwsh:
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226' -Version '' -SkipVerify -Verbose

Windows
PowerShell install
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226' -Version '' -SkipVerify -Verbose;"

MSI install
powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"

Standalone Binary

Linux -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-linux-amd64.tar.gz
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-linux-arm64.tar.gz

MacOS -

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-darwin-amd64.zip
ARM64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-darwin-arm64.zip

Windows - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-windows-amd64.zip

MSI

https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/2226/azd-windows-amd64.msi

Container
docker run -it azdevcliextacr.azurecr.io/azure-dev:pr-2226

Documentation

learn.microsoft.com documentation

title: Azure Developer CLI reference (preview)
description: This article explains the syntax and parameters for the various Azure Developer CLI Preview commands.
author: alexwolftmsft
ms.author: alexwolf
ms.date: 05/16/2023
ms.service: azure-dev-cli
ms.topic: conceptual
ms.custom: devx-track-azdevcli
Azure Developer CLI reference (preview)
This article explains the syntax and parameters for the various Azure Developer CLI Preview commands.
azd
The Azure Developer CLI (azd) is an open-source tool that helps onboard and manage your application on Azure
Options
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
  -h, --help         Gets help for azd.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
azd config: Manage azd configurations (ex: default Azure subscription, location).
azd deploy: Deploy the application's code to Azure.
azd down: Delete Azure resources for an application.
azd env: Manage environments.
azd init: Initialize a new application.
azd monitor: Monitor a deployed application. (Beta)
azd package: Packages the application's code to be deployed to Azure. (Beta)
azd pipeline: Manage and configure your deployment pipelines. (Beta)
azd provision: Provision the Azure resources for an application.
azd restore: Restores the application's dependencies. (Beta)
azd template: Find and view template details. (Beta)
azd up: Provision Azure resources, and deploy your project with a single command.
azd version: Print the version number of Azure Developer CLI.

azd auth
Authenticate with Azure.
Options
  -h, --help   Gets help for auth.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth login: Log in to Azure.
azd auth logout: Log out of Azure.
Back to top

azd auth login
Log in to Azure.
Synopsis
Log in to Azure.
When run without any arguments, log in interactively using a browser. To log in using a device code, pass
--use-device-code.
To log in as a service principal, pass --client-id and --tenant-id as well as one of: --client-secret,
--client-certificate, or --federated-credential-provider.
azd auth login [flags]

Options
      --check-status                           Checks the log-in status instead of logging in.
      --client-certificate string              The path to the client certificate for the service principal to authenticate with.
      --client-id string                       The client id for the service principal to authenticate with.
      --client-secret string                   The client secret for the service principal to authenticate with. Set to the empty string to read the value from the console.
      --federated-credential-provider string   The provider to use to acquire a federated token to authenticate with.
  -h, --help                                   Gets help for login.
      --redirect-port int                      Choose the port to be used as part of the redirect URI during interactive login.
      --tenant-id string                       The tenant id or domain name to authenticate with.
      --use-device-code[=true]                 When true, log in by using a device code instead of a browser.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd auth logout
Log out of Azure.
Synopsis
Log out of Azure
azd auth logout [flags]

Options
  -h, --help   Gets help for logout.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd auth: Authenticate with Azure.
Back to top

azd config
Manage azd configurations (ex: default Azure subscription, location).
Synopsis
Manage the Azure Developer CLI user configuration, which includes your default Azure subscription and location.
Available since azure-dev-cli_0.4.0-beta.1.
The easiest way to configure azd for the first time is to run azd init. The subscription and location you select will be stored in the config.json file located in the config directory. To configure azd anytime afterwards, you'll use azd config set.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
Options
  -h, --help   Gets help for config.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config get: Gets a configuration.
azd config list: Lists all configuration values.
azd config list-alpha: Display the list of available features in alpha stage.
azd config reset: Resets configuration to default.
azd config set: Sets a configuration.
azd config unset: Unsets a configuration.
Back to top

azd config get
Gets a configuration.
Synopsis
Gets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config get <path> [flags]

Options
  -h, --help   Gets help for get.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list
Lists all configuration values.
Synopsis
Lists all configuration values in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config list-alpha
Display the list of available features in alpha stage.
azd config list-alpha [flags]

Options
  -h, --help   Gets help for list-alpha.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config reset
Resets configuration to default.
Synopsis
Resets all configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable to the default.
azd config reset [flags]

Options
  -h, --help   Gets help for reset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config set
Sets a configuration.
Synopsis
Sets a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config set <path> <value> [flags]

Examples
azd config set defaults.subscription <yourSubscriptionID>
azd config set defaults.location eastus

Options
  -h, --help   Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd config unset
Unsets a configuration.
Synopsis
Removes a configuration in the configuration path.
The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.
azd config unset <path> [flags]

Examples
azd config unset defaults.location

Options
  -h, --help   Gets help for unset.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd config: Manage azd configurations (ex: default Azure subscription, location).
Back to top

azd deploy
Deploy the application's code to Azure.
azd deploy <service> [flags]

Options
      --all                   Deploys all services that are listed in azure.yaml
  -e, --environment string    The name of the environment to use.
      --from-package string   Deploys the application from an existing package.
  -h, --help                  Gets help for deploy.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd down
Delete Azure resources for an application.
azd down [flags]

Options
  -e, --environment string   The name of the environment to use.
      --force                Does not require confirmation before it deletes resources.
  -h, --help                 Gets help for down.
      --purge                Does not require confirmation before it permanently deletes resources that are soft-deleted by default (for example, key vaults).

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd env
Manage environments.
Options
  -h, --help   Gets help for env.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env get-values: Get all environment values.
azd env list: List environments.
azd env new: Create a new environment.
azd env refresh: Refresh environment settings by using information from a previous infrastructure provision.
azd env select: Set the default environment.
azd env set: Manage your environment settings.
Back to top

azd env get-values
Get all environment values.
azd env get-values [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for get-values.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env list
List environments.
azd env list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env new
Create a new environment.
azd env new <environment> [flags]

Options
  -h, --help                  Gets help for new.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env refresh
Refresh environment settings by using information from a previous infrastructure provision.
azd env refresh [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for refresh.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env select
Set the default environment.
azd env select <environment> [flags]

Options
  -h, --help   Gets help for select.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd env set
Manage your environment settings.
azd env set <key> <value> [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for set.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd env: Manage environments.
Back to top

azd init
Initialize a new application.
azd init [flags]

Options
  -b, --branch string         The template branch to initialize from.
  -e, --environment string    The name of the environment to use.
  -h, --help                  Gets help for init.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment
  -t, --template string       The template to use when you initialize the project. You can use Full URI, <owner>/<repository>, or <repository> if it's part of the azure-samples organization.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd monitor
Monitor a deployed application. (Beta)
azd monitor [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for monitor.
      --live                 Open a browser to Application Insights Live Metrics. Live Metrics is currently not supported for Python apps.
      --logs                 Open a browser to Application Insights Logs.
      --overview             Open a browser to Application Insights Overview Dashboard.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd package
Packages the application's code to be deployed to Azure. (Beta)
azd package <service> [flags]

Options
      --all                  Deploys all services that are listed in azure.yaml
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for package.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd pipeline
Manage and configure your deployment pipelines. (Beta)
Options
  -h, --help   Gets help for pipeline.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline config: Create and configure your deployment pipeline by using GitHub or Azure Pipelines. (Beta)
Back to top

azd pipeline config
Create and configure your deployment pipeline by using GitHub or Azure Pipelines. (Beta)
azd pipeline config [flags]

Options
      --auth-type string        The authentication type used between the pipeline provider and Azure for deployment (Only valid for GitHub provider). Valid values: federated, client-credentials.
  -e, --environment string      The name of the environment to use.
  -h, --help                    Gets help for config.
      --principal-name string   The name of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-role string   The role to assign to the service principal. (default "contributor")
      --provider string         The pipeline provider to use (github for Github Actions and azdo for Azure Pipelines).
      --remote-name string      The name of the git remote to configure the pipeline to run on. (default "origin")

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd pipeline: Manage and configure your deployment pipelines. (Beta)
Back to top

azd provision
Provision the Azure resources for an application.
Synopsis
Provision the Azure resources for an application.
The command prompts you for the following values:

Environment name: The name of your environment.
Azure location: The Azure location where your resources will be deployed.
Azure subscription: The Azure subscription where your resources will be deployed.

Depending on what Azure resources are created, running this command might take a while. To view progress, go to the Azure portal and search for the resource group that contains your environment name.
azd provision [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for provision.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd restore
Restores the application's dependencies. (Beta)
azd restore <service> [flags]

Options
      --all                  Restores all services that are listed in azure.yaml
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for restore.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd template
Find and view template details. (Beta)
Options
  -h, --help   Gets help for template.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template list: Show list of sample azd templates. (Beta)
azd template show: Show details for a given template. (Beta)
Back to top

azd template list
Show list of sample azd templates. (Beta)
azd template list [flags]

Options
  -h, --help   Gets help for list.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details. (Beta)
Back to top

azd template show
Show details for a given template. (Beta)
azd template show <template> [flags]

Options
  -h, --help   Gets help for show.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

azd template: Find and view template details. (Beta)
Back to top

azd up
Provision Azure resources, and deploy your project with a single command.
azd up [flags]

Options
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for up.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

azd version
Print the version number of Azure Developer CLI.
azd version [flags]

Options
  -h, --help   Gets help for version.

Options inherited from parent commands
  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

See also

Back to top

authors: azure-sdk wbreza


text:
Feature Request: Create an artifact that checks for and installs Windows Updates

Scenario:
I'm creating a new VM to sysprep and use as a custom VHD image.  I want to apply all necessary artifacts and all Windows Updates before I sysprep the VM.
However, I have not been able to connect to the VM.  Therefore, I can't log in and do the Windows Updates myself.
It would be nice to have an artifact called "Install Windows Updates" that checks for updates, installs them, reboots as needed, and repeats until no more updates are found.

Thanks for the feedback.
We don't have this artifact as of today. I have created a User Voice entry for the same. We prioritize features based on customer votes for the same.
In the meantime, you can follow this doc to learn more on authoring artifacts: https://docs.microsoft.com/en-us/azure/lab-services/devtest-lab-artifact-author
Hope this helps.

authors: clisc tanmayeekamath

repo: Azure/azure-devtestlab

license: mit

license_source: bigquery


text:
Upgrading script to use syncCopy

As per customer issue we were made aware that the script isn't utilizing synchcopy. As such I've modified the script so that it does so.

@erickson-doug this is ready to be merged. Please do so when you have the chance. :)

@erickson-doug friendly poke! Would prefer this doesn't continue to slip as I said, it is addressing customer feedback.
Thanks in advance!

@roygara Merged. SOrry for the delay -- ping me on Skype or in email if you need a quick turnaround. I get far too many GitHub notifications...:-(

authors: erickson-doug roygara

repo: Azure/azure-docs-powershell-samples


text:
None-standard HOME directory path for root configured in all python images

The Python images (Python3.8, etc.) configure a none-standard HOME environment variable pointing to /home. This is not a default behavior on Linux!
The expected behavior for root is the path /root or for any other user a sub-path in home `/home/{username}´.
https://github.com/Azure/azure-functions-docker/blob/557319382e31c85835441429f217a1d03681a418/host/3.0/buster/amd64/python/python38/python38.Dockerfile#L44
This becomes a big problem when working with configuration files that are expected to be placed in the standard home directory. For example files like .netrc, .pypirc. etc...

@vrdmr - do you have any recommendations?

authors: mickare pragnagopa

repo: Azure/azure-functions-docker


text:
Updated Functions host version to 3.0.15417.

Releasing new Host versions.
V3 Release

PR information

[ ] The title of the PR is clear and informative.
[ ] There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[ ] If applicable, the PR references the bug/issue that it fixes in the description.
[ ] New Unit tests were added for the changes made and CI is passing.

I just curious that file change is 44. Last time it was 46. https://github.com/Azure/azure-functions-docker/pull/371/files
Compared with it,
This one:  isolated image is newly included
Last one  2.0-upgrade  images are included
isolated image looks good, however, we might need check if 2.0-upgrade is required. @pragnagopa  Do you know if we need it this time as new release?   For the isolated images, Do we have a pipeline to publish this ? or this time it is not necessary? @kashimiz

2.0-upgrade is required. please update host version in files in folder https://github.com/Azure/azure-functions-docker/tree/dev/host/2.0-upgrade with new host version

script is missing the step :https://github.com/Azure/azure-functions-docker/issues/384

authors: TsuyoshiUshio kashimiz pragnagopa


text:
Add support for batch/cardinality

We need to add cardinality to our function metadata (for bindings) based on the request parameter type.

related: https://github.com/Azure/azure-functions-dotnet-worker/issues/115

authors: ankitkumarr mhoeger

repo: Azure/azure-functions-dotnet-worker


text:
Function runtime error (Microsoft.Azure.WebJobs.Extensions.ApplicationInsights)

I have two projects, I can't find the difference but one of them wont start in Azure (run's locally).
I get following error;
• Functions runtime error:
Microsoft.Azure.WebJobs.Extensions.ApplicationInsights: Method not found: 'Void Microsoft.Azure.WebJobs.Logging.ApplicationInsights.ApplicationInsightsLoggerOptions.set_SamplingSettings(Microsoft.ApplicationInsights.WindowsServer.Channel.Implementation.SamplingPercentageEstimatorSettings)'.
I'm running on a Linux App Service, dotnet-isolated.
My project file looks as following:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <UserSecretsId>xxx</UserSecretsId>
	  <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ApplicationInsights" Version="1.0.0-preview4" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ServiceBus" Version="4.2.1" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage" Version="4.0.4" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.1.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.3.0" OutputItemType="Analyzer" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.5.2" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="4.0.1" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions.ServiceBus" Version="5.0.0" />
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="5.0.2" />
    <PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\services\Services.csproj" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

I'm also reference another project with Application Insights from my Azure Function project:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Library</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <ApplicationIcon />
    <StartupObject />
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.ApplicationInsights" Version="2.18.0" />
  </ItemGroup>
</Project>

Note: Seems like the issue is related to Azure Function running on an App Service (not consumption plan) which run a Linux OS.


text:
[DevCenter - Microsoft Dev Box] API Review

New API Review meeting has been requested.
Service Name: DevCenter - Microsoft Dev Box
Review Created By: Chris Miller
Review Date: 06/06/2023 01:00 PM PT
Onboarding Record: https://dev.azure.com/azure-sdk/Release/_workitems/edit/10882
PR: https://github.com/Azure/azure-rest-api-specs/pull/24291
Hero Scenarios Link: Not Provided
Core Concepts Doc Link: Not Provided
Description: Adding 2023-07-01-preview API version.
Additions:

Adding Environment Actions APIs
Adding Schedule list endpoints
Adding Dev Box troubleshoot API
Standardizing Id property on resource responses

Detailed meeting information and documents provided can be accessed here
For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here

Notes from REST API Review meeting 6/6/23

How will troubleshooting actions version over time? Troubleshooting is a very general term that could cover just diagnosing to performing actions -- might be too general.
"properties" as the result in the LRO status monitor -- why not called "result"?
Consider accepting an "Operation-id" header parameter on LROs to make them idempotent
Clean up of status monitors should be a high-priority item.
id property was added as "required" -- change to optional? Leave as required unless SDK breaking.

Note that id is not an ARM id, to avoid potential confusion
Is the structure of the ID really helpful? Maybe better to have a full URI

Why use sourceId and not poolId ? Better to have multiple properties with specific names.

consider consistency with actions
maybe have a sourceId builder/parser if you keep it

Time zones ? Need these to consider location of dev boxes

documented as "The IANA timezone id at which the schedule should execute." -- not an enum

How to troubleshoot when a troubleshoot operation is outstanding?
lastOperationId -- user determines that a troubleshoot operation is outstanding from the state, and then queries the operation to determine the state

lastOperationId is actually a URL. That needs to be clarified.
Maybe change to troubleshoot results
Or make a "troubleshoot" a proper resource

Adding @markweitzel , @mikekistler , and @JeffreyRichter per our discussion in the 6/7 office hours, so we can continue the conversation on this API with the same group of people.
We did some internal alignment on our team and have made the following updates in the linked PR based on the discussion in the review and the discussion in office hours. Please let us know any thoughts and concerns; we are more than happy to set up an ad-hoc meeting or jump back into office hours to hash out any continuing problems.
Endpoint changes

Based on the feedback around the Environment list operations API in office hours, we will align Dev Box and Environments by standing up an equivalent list operations API on the Dev Box resource. This will follow the discussed approach for Environments of having a single polymorphic endpoint, and we'll follow along with customers during the preview to evaluate their use/any pain points this produces.

We followed the FormRecognizer API for an example of a polymorphic operations API since it was a relatively recent API with similar semantics. Please let us know if there is other prior art we should consider here.
We are currently using startTime and endTime for consistency with our status monitor resources, but we can update to startedAt and endedAt per the most recent doc updates if alignment to the new best practice is more important than consistency here.

Updated the Environment operation get logs endpoint to return a plain text file rather than a plain text string response, given that the logs output could be quite large.

Would appreciate any guidance here; we searched for prior art and found a wide range of approaches (blob storage URIs, string responses, and files), so we aren't sure what the best practice is from an API perspective for returning a potentially large text output.

Property changes

Updated the id property to uri everywhere, and made these full dataplane URIs. We are open to naming suggestions here; I've seen this property called resourceId, resourceLocation, and resourceUri/uri in other dataplane APIs, so not certain what the best practice is. We've left existing id properties in place to avoid a breaking change.
Removed lastOperationId, per your guidance that this is not a great pattern
Added sourceType enums to both resources with sourceId properties (schedules and Dev Box actions) to surface the type of the source resource

Note: We could update this to sourceUri for schedules, but chose sourceId for consistency with the property on Dev Box actions. An alternative would be adding sourceUri and sourceType to schedules, then adding both properties to actions without removing the existing sourceId property, which is in the stable API.

Naming changes

Renamed troubleshoot to repair to reflect that we will take actions on the customer VMs
Updated type to kind on Environment and Dev Box operations APIs. Leveraging this as a polymorphic discriminator for both APIs.

From a behavioral perspective:

The work to implement an operations list API will also align well with supporting Operation-Id header because it will improve our control over tracking and fetching operations. This should enable us to add support for the idempotency pattern, and we have added a story to tackle this to our planning for next quarter so it can be included in our next API release.
The operations API work will also improve our ability to automatically clean up status monitors because we can leverage TTL features in cosmos, and this work has been added to our planning for next quarter as well. For our new operations APIs, we've added explicit descriptions that the operations have a 90 day TTL.

authors: azure-sdk chrissmiller mikekistler

repo: Azure/azure-rest-api-specs


text:
[Please ignore] trick to hack associated powerbi table

Assign this issue on Azure NW responsible person to make them presented in PowerBI dashboard

closed due to hackability


text:
Marketplace miberezi 2020

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?
new API version for new APIs
When you are targeting to deploy new service/feature to public regions? 24/1/2021
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version

[ ] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run

/azp run

/azp run SDK azure-sdk-for-go

/azp run SDK azure-sdk-for-go

/azp run

/azp run

/azp run

/azp run

/azp run SDK azure-sdk-for-net

/azp run SDK azure-sdk-for-net

/azp run

/azp run

.net SDK hang. @zhenglaizhang, @PhoenixHe-msft  could you pls take a look at this case?

.net SDK hang. @zhenglaizhang, @PhoenixHe-msft  could you pls take a look at this case?

@MiriBerezin what existing api-version should I compare this against?  The new spec is significantly different than the existing specs.

@MiriBerezin what existing api-version should I compare this against?  The new spec is significantly different than the existing specs.

@MiriBerezin what existing api-version should I compare this against? The new spec is significantly different than the existing specs.

This api-version contains only additional paths. old api-version is 2020-01-01

@MiriBerezin what existing api-version should I compare this against? The new spec is significantly different than the existing specs.

This api-version contains only additional paths. old api-version is 2020-01-01

.net SDK hang. @zhenglaizhang, @PhoenixHe-msft could you pls take a look at this case?

@PhoenixHe-msft  looks like .net gen exit unmannerly, please help take a look.
Mean while I will improve the pipeline to pass out the result even under such scenario. @ruowan

.net SDK hang. @zhenglaizhang, @PhoenixHe-msft could you pls take a look at this case?

@PhoenixHe-msft  looks like .net gen exit unmannerly, please help take a look.
Mean while I will improve the pipeline to pass out the result even under such scenario. @ruowan

Please remove L81-82 in readme.md. It's a misconfiguration.

Please remove L81-82 in readme.md. It's a misconfiguration.

pls remove npm-debug.log file.

pls remove npm-debug.log file.

Are your POST and PUT operations long running operations? If yes, you need to conform to this

@jorgearteiro no, our APIs are NOT long-running operations

@jorgearteiro no, our APIs are NOT long-running operations

Ok. There's an important checkbox that was not marked:
[] I have reviewed the documentation for the workflow.
We'll let it pass this time, but future PRs if the documentation was not read prior creating the PR, the PR would not be reviewed.

authors: MiriBerezin PhoenixHe-msft allenjzhang jorgecotillo leni-msft pilor ruowan zhenglaizhang


text:
Rebase dev-cognitiveservices-Language-2022-03-01-preview on main

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

This does not appear to be a rebase:

With your existing PR #18443, in whatever branch you were working, just run:
git fetch upstream main # assuming this repo is your upstream remote
git rebase FETCH_HEAD
# resolve conflicts
git push --force

Assuming this isn't matching the old branch policy instead of the new blanket ones @weshaggard created, the last line will just update PR #18443 and the underlying branch. You can just close this one then.

authors: abhahn heaths


text:
Swagger for repair apis.

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

@msyyc @changlong-liu
cosmos want to know why LRO change in commit https://github.com/Azure/azure-rest-api-specs/pull/22117/commits/c087a93f87f9f60873b37919796e9d351e07fb20 seems not reflected in Python SDK automation.
(readme default tag is this preview)

@msyyc @changlong-liu
cosmos want to know why LRO change in commit c087a93 seems not reflected in Python SDK automation. (readme default tag is this preview)

Hi @vivek-microsoft , the LRO changes in this commit is included in file stable/2022-11-15/managedCassandra.json which is not included in current default tag package-preview-2022-11: https://github.com/vivek-microsoft/azure-rest-api-specs/blob/5a93ad4e747404540f447e1a33875c0ee93be9b3/specification/cosmos-db/resource-manager/readme.md#tag-package-preview-2022-11
So it's not generated in python sdk.


text:
[Storage] Add Get Location Usage support

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
The PR is to ass support to get Location Usage API.
The rest API doc can be found in: https://microsoft.sharepoint.com/:w:/t/AzureStorage/EYFU1AAlf3BBqV6C28ajBB0BpOXZDKOfZYnoQnZOU6wivA?e=uP50YO
The feature is target to release for Build 5/7. Please help to review it.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-node

Automation for azure-libraries-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

authors: AutorestCI blueww


text:
Normalise line endings in specification files

1025 / 11257 of the JSON files in the specifications directory have CRLF
line endings, this change ensures consistency across all of the line
endings by normalising to just LF.
This change touches a lot of files, so understandably might be rejected.
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

Automation for azure-sdk-for-go

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

Hi @ifross89
We don't have guidance right now people authoring this file. This would mean that even if I merge your PR, the next one will just re-introduce the same CRLF anyway.
Also, your PR touches so many things that having it with no conflicts would be a miracle :). Also, this might conflict the entire set of currently opened PR, which is not acceptable. Last bu not least, we have feature branch that would not match anymore.
I would say that could be interesting indeed to enforce this kind of policy, but would be by configuring git first (.gitattributes: *.json text eol=LF), otherwise lost cause.
FYI @salameer

authors: AutorestCI azuresdkci ifross89 lmazuel


text:
Added content type to hanainstance restart

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] The spec follows the guidelines described in the Swagger checklist document.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?

Automation for azure-sdk-for-node

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

authors: AutorestCI PakDLiu azuresdkci


text:
Add APIs for throughput read and update

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-ruby
Encountered a Subprocess error: (azure-sdk-for-ruby)
Command: ['/usr/local/bin/autorest', '/tmp/tmpqhgfj8_8/rest/specification/cosmos-db/resource-manager/readme.md', '--perform-load=false', '--swagger-to-sdk', '--output-artifact=configuration.json', '--input-file=foo', '--output-folder=/tmp/tmprpb39uku']
Finished with return code 7
and output:
AutoRest code generation utility [version: 2.0.4283; node: v8.12.0]
(C) 2018 Microsoft Corporation.
https://aka.ms/autorest
Failure:
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4370/node_modules/@microsoft.azure/autorest-core
Error: Unable to start AutoRest Core from /root/.autorest/@microsoft.azure_autorest-core@2.0.4370/node_modules/@microsoft.azure/autorest-core
    at main (/opt/node_modules/autorest/dist/app.js:232:19)
    at <anonymous>

/root/.autorest/@microsoft.azure_autorest-core@2.0.4370/node_modules/@microsoft.azure/autorest-core/dist/app.js:33
    autorest_core_1.Shutdown();
    ^
ReferenceError: autorest_core_1 is not defined
    at process.on (/root/.autorest/@microsoft.azure_autorest-core@2.0.4370/node_modules/@microsoft.azure/autorest-core/dist/app.js:33:5)
    at emitOne (events.js:121:20)
    at process.emit (events.js:211:7)
    at process.emit (/node_modules/source-map-support/source-map-support.js:439:21)
fs.js:612
  return binding.close(fd);
                 ^

Error: EBADF: bad file descriptor, close
    at Object.fs.closeSync (fs.js:612:18)
    at StaticVolumeFile.shutdown (/opt/node_modules/autorest/dist/static-loader.js:352:10)
    at StaticFilesystem.shutdown (/opt/node_modules/autorest/dist/static-loader.js:406:17)
    at process.exit.n [as exit] (/opt/node_modules/autorest/dist/static-loader.js:169:11)
    at printErrorAndExit (/node_modules/source-map-support/source-map-support.js:423:11)
    at process.emit (/node_modules/source-map-support/source-map-support.js:435:16)
    at process._fatalException (bootstrap_node.js:391:26)

Automation for azure-sdk-for-js

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go
A PR has been created for you:
https://github.com/Azure/azure-sdk-for-go/pull/4791

Can one of the admins verify this patch?

Automation for azure-sdk-for-java

startbuild

@bizarreWizard Has this gone through an API/ARM review?

@bizarreWizard Has this gone through an API/ARM review?

@bizarreWizard Please set up a call with armapireview to get this reviewed. You will have to help me understand the API signature. It doesnt seem like the segments are correct as per ARM guidance.

@bizarreWizard can you resolve merged conflicts first so that we can review the latest.

@bizarreWizard have you completed API review as suggested by ARM? If not you will have to do that first and get a sign off from ARM before this PR can be merged.

@bizarreWizard the only now remaining is create a file called Feedback.md, add PR number, link to that file and capture the feedback or action item that you have been told to take in the next iteration.
Once you have this file in your PR, I can approve/merge this PR.

authors: AutorestCI azuresdkci bizarreWizard dsgouda ravbhatnagar shahabhijeet


text:
chore: jsonfmt postgresql

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

authors: AutorestCI azuresdkci nschonni