text:
Nested templates and Parameters Without Default Must Exist In CreateUIDefinition

Hello, we are in the process of certifying a managed application and we are getting the validation error in the issue title that is forcing us to add default values to all nested templates. Since they are nested templates, we understand that they are not directly connected to the CreateUIDefinition file and they should not be taken into account by that check.
I've built a minimal example to demonstrate the issue. I hope that can help better understand it, but happy to provide more details if needed.
createUiDefinition.json:
{
  "$schema": "https://schema.management.azure.com/schemas/0.1.2-preview/CreateUIDefinition.MultiVm.json#",
  "handler": "Microsoft.Azure.CreateUIDef",
  "version": "0.1.2-preview",
  "parameters": {
    "basics": [
      {}
    ],
    "outputs": {
      "mainParameter": "value-from-ui"
    }
  }
}

main.bicep:
param mainParameter string = 'default-value'

module module 'module.bicep' = {
  name: 'Module'
  params: {
    moduleParameter: mainParameter
  }
}

module.bicep:
param moduleParameter string

When built, the Bicep files produce the following ARM template:
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "0.9.1.41621",
      "templateHash": "4551264275492999207"
    }
  },
  "parameters": {
    "mainParameter": {
      "type": "string",
      "defaultValue": "default-value"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2020-10-01",
      "name": "Module",
      "properties": {
        "expressionEvaluationOptions": {
          "scope": "inner"
        },
        "mode": "Incremental",
        "parameters": {
          "moduleParameter": {
            "value": "[parameters('mainParameter')]"
          }
        },
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "1.0.0.0",
          "metadata": {
            "_generator": {
              "name": "bicep",
              "version": "0.9.1.41621",
              "templateHash": "15490559216858461434"
            }
          },
          "parameters": {
            "moduleParameter": {
              "type": "string"
            }
          },
          "resources": []
        }
      }
    }
  ]
}

The Parameters-Without-Default-Must-Exist-In-CreateUIDefinition check fails as follows.
$ Test-AzTemplate . -Tests @('Parameters-Without-Default-Must-Exist-In-CreateUIDefinition')"

Validating validation\createUiDefinition.json
  Parameters Without Default Must Exist In CreateUIDefinition
    [-] Parameters Without Default Must Exist In CreateUIDefinition (20 ms)
        moduleParameter does not have a default value, and is not defined in CreateUIDefinition.outputs

If we add a default value to the module parameter, the validation passes. However, that forces us to set default values for hundreds of parameters across multiple modules, which doesn't look right at all.
param moduleParameter string = ''

$ Test-AzTemplate . -Tests @('Parameters-Without-Default-Must-Exist-In-CreateUIDefinition')"

Validating validation\createUiDefinition.json
  Parameters Without Default Must Exist In CreateUIDefinition
    [+] Parameters Without Default Must Exist In CreateUIDefinition (16 ms)

@adrianmo , just want to offer that something does seem strange here. You should be able to do what you want and the marketplace should go and accept the ARM template that you showed. This is actually what you have to do for a location parameter, which I have gone and submitted successfully myself.
Are you seeing this issue when you upload to the partner center, or just locally? it may be that the partner center does not check this rule.
You can find the exact arm-ttk setup for ARM-TTK that the partner center uses here, https://aka.ms/arm-ttk-marketplace
Try running this over your code and see if the error still pops?
I have an example of an Azure DevOps pipeline where I run this version of ARM-TTK on my template before I submit to partner center, just in case that helps you too. https://github.com/microsoft/azure-gaming-devops/blob/main/marketplace/stage_arm_ttk.yml

@dciborow we've recreated this issue in #680 as well, and have seen the problem with nested templates since we started (1yr+). and yea it occurs in the partner center, as well as locally.

@bmoore-msft This looks related to #680, please assign it to me.

authors: NickSpag StartAutomating adrianmo dciborow


text:
Add begin and wait API for LRO

For mgmt. plane SDK, we want to add an API to create poller and poll final result simultaneously. It is an addition for current create poller API (BeginCreateOrUpdate). The possible name for the API is the same with the rest operation name (CreateOrUpdate). The reason is in mgmt. scenario, user always emphasis on the resource result regardless the operation is LRO or not. The problem is duplicity and may involve confusion. Since this should be a non-breaking feature, we may gather more user feedback first.

Another option as discussed offline is to provide a wrapper that customers use to get the same behavior.
type OperationWaiter[TResult any] struct {
    poller *runtime.Poller[TResult]
    err    error
}

func (ow OperationWaiter[TResult]) Wait(ctx context.Context, freq time.Duration) (TResult, error) {
    if ow.err != nil {
        return *new(TResult), ow.err
    }
    return ow.poller.PollUntilDone(ctx, freq)
}

func NewOperationWaiter[TResult any](poller *runtime.Poller[TResult], err error) OperationWaiter[TResult] {
    return OperationWaiter[TResult]{poller: poller, err: err}
}

This would allow callers to condense an LRO into a one-line call.
result, err := NewOperationWaiter(client.BeginSomeLRO(context.Background(), nil)).Wait(context.Background(), time.Second)

Based on our user study, true feelings of the LRO and none LRO operation is that they make the code look inconsistent. I know we have customer who write infra level code that would be ok with detailed control but there is customer who write none infra level code, consistency and easy to understand is one of their priorities, for those LRO operation, can we provide a none LRO-look-like call as an alternative?

We've noticed that it usually happened that service change an operation from synchronized to asynchronized which cause Go SDK breaking changes. In order to prevent such breaking changes, I'd prefer to generate both synchronized and asynchronized function for LRO. Besides preventing breaking changes, it could also give a simple usage for customer who does not care of the LRO undelaying logic. @jhendrixMSFT @JeffreyRichter What do you think?

Among current 7 Go mgmt. SDK packages which have v2+ version, 2 of them have the breaking of such change. And I have met more during my swagger review work. Here are some examples:

Mediaservices_CreateOrUpdate
FarmBeatsModels_Update
Workspaces_Update

Got another one from SQL. https://github.com/Azure/azure-rest-api-specs/pull/19953

So first, let me say that services should not make this specific breaking change and so there should not be a lot of these.
However, they do happen, and I appreciate the effort to not break Go SDK customers.
I'll also add that the service team is making this break for a reason and not just to make the customer experience worse.
So, my concern is that if the SDK initiates an LRO and this succeeds but then the polling fails, we return an error to the customer and now the customer doesn't know (since we put multiple operations into a single method) what to do: Did initiating the operation fail and so it never got started? Or, did it get started and now there is a problem with knowing its state?
The error recovery for these 2 scenarios is VERY different and a customer would have to write the proper code to deal with them separately/correctly. Having a wrapper function makes this much harder.

Your sample codes shows how to detect the error but not how to properly recover from the error.
If the client gets a PollingError, how does it continue polling without initiating the operation again?
Also, if the error is a networking error, then was it due to the initiating call or a polling call?
In theory, you could wrap any underlying error with PollingError but the proper error handling becomes much more complex now.

@JeffreyRichter  I think in Chenjie's code
if errors.As(err, &pollingErr) {
			poller := pollingErr.Poller
			_ = poller
			log.Fatalf("Inner error: %+v", errors.Unwrap(err))
		} else {
			log.Fatalf("Other error: %+v", err)
		}

If the error is a polling error, developers can get that poller from the error and try poll until done again
If the error is not a polling, developers can try to re-launch the request, or just simply throw that as an exception
I understand there will be situation that the poller failed again, however that would be some policy setting in customer's code, both our old way of LRO and the new way of LRO cannot handle the failure situation happened in error recovering code

Yes. Here is the comparison:
Async:
	poller, err := client.BeginDelete(ctx, "rg1", "cache1", "cache2", nil)
	if err != nil {
		// retry for start operation failure
		log.Fatalf("failed to start operation: %v", err)
	}
	_, err=poller.PollUntilDone(ctx, nil)
	if err != nil {
		// retry for polling failure
		log.Fatalf("failed to poll result: %v", err)
	}

Sync:
	_, err = client.Delete(ctx, "rg1", "cache1", "cache2", nil)
	if err != nil {
		var pollingErr *runtime.PollingError[LinkedServerClientDeleteResponse]
		if errors.As(err, &pollingErr) {
			poller := pollingErr.Poller
			_ = poller // retry for polling failure
			log.Fatalf("failed to poll result: %v", err)
		} else {
			// retry for start operation failure
			log.Fatalf("failed to start operation: %v", err)
		}
	}

@jhendrixMSFT To answer your concern about the execution time increasement if we provide a synchronized method for LRO, I list the LRO execution time distribution as follows. Most operations can be done in 20 seconds. Regarding we also provide begin method for customer to migrate, I think the change is worthy.
Some statistics related to total time for LRO based on CLI telemetry data:
88% of the LRO calls could be completed in 32sec
92% in ~1min (64 sec)
95% in 2min+ (130 sec)
The raw data could be found in polling time consumption analysis - Azure CLI.xlsx

Time(ms)
operations
percentage

1
92
0.00

2
94
0.004265747

4
118
0.005354874

8
146
0.006625522

16
479
0.021737157

32
1235
0.056044654

64
2325
0.105509167

128
3911
0.177482302

256
6025
0.273416228

512
8143
0.369531675

1024
10524
0.477582138

2048
12760
0.57905246

4096
14827
0.672853512

8192
16653
0.755717916

16384
18200
0.82592122

32768
19482
0.884098748

65536
20356
0.923761118

131072
21003
0.953122164

262144
21433
0.972635687

524288
21669
0.983345435

1048576
21827
0.99051552

2097152
21930
0.99518969

source: gharchive/issue

authors: JeffreyRichter jhendrixMSFT tadelesh xboxeer

license: MIT

license_type: permissive

license_source: github-api


text:
added examples and new features

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

[ ] Have you run ./scripts/ci/test_static.sh locally? (pip install pylint flake8 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.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it microsoft/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/williexu/azure-cli-extensions.git@storage_examples#subdirectory=src/$EXT&egg=$EXT"

source: gharchive/pull-request

authors: azuresdkci williexu

repo: Azure/azure-cli-extensions


text:
containerapp auth add prepare process

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

az containerapp auth update
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.

authors: Greedygre yonzhan


text:
Improve --pattern documentation with additional examples

Resource Provider
Azure Storage Blobs
Description of Work Requested
I'd like to suggest expanding the documentation around the --pattern parameter. Specifically, there is a lack of examples for common globbing scenarios. The tools for powerful patterns seem to be available, but the exact syntax required to achieve certain outcomes is not obvious.
I opened this SO question about making an exclusion pattern for the az storage blob delete-batch command. You can find other folks having trouble with different scenarios.
I'm sure you can think of many example patterns that one might want to use, but here's a quick brain dump:

Delete everything except for one specific directory
Delete everything except for multiple specific directories
Delete everything in a specific nested directory
Delete all but one particular blob in a specific nested directory
Delete everything from a specific directory that matches an extension (*.txt)
Delete everything from a specific directory that matches multiple extensions (*.txt or *.html)
Delete everything from a specific directory that does NOT match an extension (*.txt)
Delete everything from a specific directory that does NOT match multiple extensions (*.txt or *.html)

Providing such examples in the documentation will help others to form the correct patterns for their needs.

@tomfaltesek  Thanks for your suggestion.  I think you can try our new az storage remove  command with --exclude flag, which is in preview now. Wait for you feedback😊

Thanks for the reply, @Juliehzl. The az storage remove command with the --exclude flag looks like it should work fine. Although, that command was added in version 2.0.70 of the Azure CLI and my Azure DevOps build agent currently has version 2.0.68.
Fortunately, I can use the answer to this SO question to exclude directories with the existing Azure CLI commands.
Regardless of the new az storage remove command, consumers may want more detailed documentation on the --pattern parameter. Not only is it available for the az storage blob delete-batch, but it can also be used in the az storage blob download-batch and az storage blob upload-batch.

Adding a few more use cases to the list for after using az storage blob upload-batch --pattern:

upload everything with a particular file extension (*.txt)
upload everything with a particular file extension somewhere in the name (*.tar.gz, *.tar.gz.sha256)
upload everything that matches multiple file extensions (*.txt, *.md)

and 2) are quite simple to implement (*.txt and *.txt*), but I haven't found any concrete examples demonstrating 3).

In particular, I'd love to read more on the expected behaviour and limitations of the [seq] pattern matcher. There's very little information available on how it should be used. I've looked everywhere (including by looking through several test cases in azure-cli itself), but didn't find any concrete examples other than what was provided in the SO answer shared above.

update: looks like the pattern matcher comes from fnmatch, a python library that provides UNIX-style file pattern match sequences. The documentation doesn't appear to demonstrate much information on how the pattern matcher works, however you can drop into a python shell to play around with some patterns to see what the it provides as a regular expression.
><> python
Python 2.7.15+ (default, Oct  7 2019, 17:39:04)
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fnmatch
>>> fnmatch.translate("*")
'.*\\Z(?ms)'

dupe of #3982

Just as what @bacongobbler said, the --pattern in azure cli is based on fnmatch library. What --pattern can match is limited, but I will add more information and examples for the usage.

authors: Juliehzl bacongobbler tomfaltesek

repo: Azure/azure-cli


text:
webapp:[('PKCS12 routines', 'PKCS12_parse', 'mac verify failure')] when attempting to upload new certificate

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp config ssl upload
Errors:
[('PKCS12 routines', 'PKCS12_parse', 'mac verify failure')]
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 206, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 603, in execute
    raise ex
cli/core/commands/__init__.py, ln 661, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 654, in _run_job
    six.reraise(*sys.exc_info())
...
python3.6/site-packages/OpenSSL/crypto.py, ln 3067, in load_pkcs12
    _raise_current_error()
python3.6/site-packages/OpenSSL/_util.py, ln 54, in exception_from_error_queue
    raise exception_type(errors)
OpenSSL.crypto.Error: [('PKCS12 routines', 'PKCS12_parse', 'mac verify failure')]

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 webapp config ssl upload --name {} --resource-group {} --certificate-file {} --certificate-password {} --query {}

Expected Behavior
Environment Summary
Linux-4.9.184-linuxkit-x86_64-with-debian-9.11
Python 3.6.5
Shell: bash

azure-cli 2.0.73

Additional Context

Can you run the command with --debug & share the details please excluding any sensitive info. Thank you.

@DaveSin can you please share more details here for debugging please, after trying this with the latest version of CLI? Thank you.
Reactivate when you add more details here.

Hi All, I found I had this error when my password contained special characters such as @ or $ etc...

Hi, I am still facing this issue and my password is just alphabets.

@anuradhaarao can you open a new issue if possible - since this was originally opened on a very old version of CLI so I'd like to get more details on this if possible. Thanks!

@panchagnula  - opened up a new one here : https://github.com/Azure/azure-cli/issues/1472.

authors: Ado77 DaveSin anuradhaarao panchagnula


text:
AZ interactive - Sandbox

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az interactive
Errors:
The command failed with an unexpected error. Here is the traceback:
No module named 'prompt_toolkit.interface'
Traceback (most recent call last):
  File "/usr/lib64/az/lib/python3.9/site-packages/knack/cli.py", line 233, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 663, in execute
    raise ex
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 726, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 697, in _run_job
    result = cmd_copy(params)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/__init__.py", line 333, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/usr/lib64/az/lib/python3.9/site-packages/azure/cli/command_modules/interactive/custom.py", line 41, in start_shell
    azext_interactive.start_shell(cmd, style=style)
  File "/home/zoubeirqadi/.azure/cliextensions/interactive/azext_interactive/__init__.py", line 10, in start_shell
    from .azclishell.app import AzInteractiveShell
  File "/home/zoubeirqadi/.azure/cliextensions/interactive/azext_interactive/azclishell/app.py", line 33, in <module>
    from prompt_toolkit.interface import Application, CommandLineInterface
ModuleNotFoundError: No module named 'prompt_toolkit.interface'

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 interactive

Expected Behavior
Environment Summary
Linux-5.4.0-1094-azure-x86_64-with-glibc2.35 (Cloud Shell), CBL-Mariner/Linux
Python 3.9.13
Installer: RPM

azure-cli 2.41.0

Extensions:
interactive 0.4.5
ai-examples 0.2.5
ml 2.10.0
ssh 1.1.2

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

Additional Context

Duplicate of https://github.com/Azure/azure-cli/issues/24213

authors: yonzhan zqadi


text:
Wrong error message for command "az acr login" with wrong username :

Describe the bug
When trying to connect to an azure ACR with either :
az acr login -n registry_name -u wrong_username -p password
or
docker login registry_server_login -u wrong_username -p password
the error message is
Error response from daemon: Get "https://myregistry.azurecr.io/v2/": unauthorized: Application not registered with AAD.
Related command
az acr login
Errors
Error response from daemon: Get "https://myregistry.azurecr.io/v2/": unauthorized: Application not registered with AAD.
Issue script & Debug output
I think that it is irrelevant here
Expected behavior
We expect the following error (which we get with good username and wrong password):
Error response from daemon: Get "https://my_registry.azurecr.io/v2/": unauthorized: {"errors":[{"code":"UNAUTHORIZED","message":"authentication required, visit https://aka.ms/acr/authorization for more information."}]}
although it is not clear, at least it is less wrong. Something better would be
"wrong credentials " or "wrong username/password"
Environment Summary
azure-cli                         2.62.0 *
core                              2.62.0 *
telemetry                          1.1.0
Dependencies:
msal                              1.28.1
azure-mgmt-resource               23.1.1
Python location '/opt/az/bin/python3'
Extensions directory '/home/ludovicarnould/.azure/cliextensions'
Python (Linux) 3.11.8 (main, Jul  4 2024, 02:23:40) [GCC 11.4.0]
Legal docs and information: aka.ms/AzureCliLegal
Additional context
No response

Hi @LudovicArnould1,
2.62.0 is not the latest Azure CLI(2.63.0).
If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

The error persists after the upgrade

I see what you are saying. This error seems to be returned because of how an invalid username is handled on the API side. I agree it's not a very clear or actionable error and will bring it up with my team (ACR) to see if we can support a more descriptive result or at least better document it. Thanks for bringing this up!


text:
Move VM Image List off of GitHub

Notice in the cloud.py, we have a hardcoded path to a file hosted in github. It means every time users execute az vm image list, the command will fetch the file from raw.githubusercontent.com. This render a few issues:

Why do we rely on a third party to host files for runtime execution?
Github is not a file share service. It is a source control service. That means the url we relies on is not 100% reliable.
Github can throttle the access to this file just like they throttle the release files, which will break our command.
Github can be blocked in some subnet or behind a firewall, which will make this command unusable.
Github won’t guarantee the performance of this file host.

I understand that the logic behind this is that this fire will be updated after CLI is released so as to keep to the latest image types list. However, we should have this file publish to a storage account under our control to guarantee the user experience.

endpoints=CloudEndpoints(
  | management='https://management.core.windows.net/',
  | resource_manager='https://management.azure.com/',
  | sql_management='https://management.core.windows.net:8443/',
  | batch_resource_id='https://batch.core.windows.net/',
  | gallery='https://gallery.azure.com/',
  | active_directory='https://login.microsoftonline.com',
  | active_directory_resource_id='https://management.core.windows.net/',
  | active_directory_graph_resource_id='https://graph.windows.net/',
  | active_directory_data_lake_resource_id='https://datalake.azure.net/',
  | vm_image_alias_doc='https://raw.githubusercontent.com/Azure/azure-rest-api-specs/master/arm-compute/quickstart-templates/aliases.json'),    # pylint: disable=line-too-long
  |

@JasonRShaver I agree. It's better to use Azure Storage for file hosting.
@jseely Have you run az cloud set --name AzureUSGovernment? What does "no public internet access" mean? Can you access Azure public cloud resource?

This is for a government client. They have their environment locked down. I would assume that would mean they would not have access to Azure Public Cloud resources either. I can try to get more details...
Is it not possible to have the CLI pull the data required from the Resource Provider?

@jseely
This doc contains the alias for a few commonly used images.  It is co-maintained by CLI and Compute service team, you can bypass the query by providing the urn. here are the examples to pull from the RP
(env) C:\sdk\azure-cli>az vm image list -otable --publisher canonical --offer ubuntu --sku 18.04 --all --query "[].urn"
Result
------------------------------------------------------
Canonical:UbuntuServer:18.04-DAILY-LTS:18.04.201907180
Canonical:UbuntuServer:18.04-DAILY-LTS:18.04.201908011
Canonical:UbuntuServer:18.04-DAILY-LTS:18.04.201908070
Canonical:UbuntuServer:18.04-DAILY-LTS:18.04.201908131
Canonical:UbuntuServer:18.04-DAILY-LTS:18.04.201908140
Canonical:UbuntuServer:18.04-LTS:18.04.201804262
...

(env) C:\sdk\azure-cli>az vm create --image Canonical:UbuntuServer:18.04-LTS:18.04.201804262 -g myRG -n myVM

@yugangw-msft in our usage the --image value that we provide is a Managed Image. Are you saying it shouldn't be looking up the githubusercontent.com content in this case?

No, it shouldn't be.
For managed images which were captured/built by customers, they have 2 kinds of residences:

As a standalone images, which can be retrieved through az imge list
In a shared image gallery which can be retrieved through  az sig image-version list

Close issue for it's inactive for a long time.

This is not inactive for a long time. This is an active issue we still have.

This is not inactive for a "long time." This is an active issue we still have. Two weeks when the last comment is "yeah it shouldn't be doing this" doesn't seem like a closable issue to me.

OK. I don't think Github is a file server.

I have opened this PR #10658 which should fix the issue we were running into.
I also noticed a remark in https://github.com/Azure/azure-powershell/issues/8027 from @BorisB2015 that a solution for this may be to add the aliases doc, that's currently on githubusercontent.com, into the build process for both the Powershell module and the Azure CLI. I think that may be a better long term solution as the image aliases will then also be made available to uses in Azure Environments without public internet access. (Note: I have two large customers in the Defense and Banking industries where this is the case)

https://github.com/Azure/azure-rest-api-specs/blob/master/arm-compute/quickstart-templates/aliases.json
This is the file that we use to convert alias to urn.
@jseely Thanks for creating the PR.
I agree. Let the CI task copy the latest file to project as a resource file. Then CLI/Powerver no longer need to visit github.

https://github.com/Azure/azure-rest-api-specs/blob/master/arm-compute/quickstart-templates/aliases.json
This is the file that we use to convert alias to urn.
@jseely Thanks for creating the PR.
I agree. Let the CI copy the latest file to project as a resource file. Then CLI/Powershell can read from it if there is no internet access.

I merged the PR. It will be available in Azure 2.0.76. Official Release: 11/04/2019.
PR: [Compute] vm create: Add a local copy of image alias file so that it can be accessed in a restricted network environment
Environment like Azure GOV can't access Internet other than servers of Azure. When creating VM, Azure CLI visit a image alias file in Github to translate image alias to full urn. This patch intends to add a local copy of this file as a backup in case of network issue.

authors: JasonRShaver anEXPer jseely qwordy yugangw-msft


text:
[NetAppFiles] Anf 4232 - CLI versionFor2019-11-01 API - Add Volume Revert to revert volume to a snapshot

Description

Updates NetAppFiles Azure CLI to API version 2019-01, adding Volume Revert operation used to revert a volume to one of its snapshots. Removes mountTargets operation as mount targets information is available as part of Volume properties.
Testing Guide

// Create a snapshot from a volume
az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --name myvolname
// Revert a volume to a snapshot
az netappfiles volume revert -g mygroup --account-name myaccname --pool-name mypoolname --name myvolname --snapshot-id 9760acf5-4638-11e7-9bdb-020073ca3333

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.
[NetAppFiles] az volume revert:  Added Volume Revert to revert a volume to one of its snapshots.
[NetAppFiles] BREAKING CHANGE: az netappfiles mount-target: Removed.
[NetAppFiles] az volume show: Added site to Active Directory Properties

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.

NetAppFiles

@haroldrandom test recordings have been updated.
Can we please get this reviewed asap as customers are waiting for changes in this PR.

@haroldrandom  All tests run successfully I don't see why the pipeline should be failing now.  Can you advice ?

/azp run

authors: audunn haroldrandom yonzhan


text:
[HDInsight]Support compute isolation and return private ip address

Description

The related swagger spec PR is https://github.com/Azure/azure-rest-api-specs/pull/12612
Testing Guide

az hdinsight create -t spark --version 3.6 -g MyResourceGroup -n MyCluster \
        -p "HttpPassword1234!" --storage-account MyStorageAccount \
        **--enable-compute-isolation** --workernode-size "Standard_E8S_V3" --headnode-size
        "Standard_E8S_V3"

--enable-compute-isolation is the new added parameter when creating cluster, the above command will create a cluster with compute isolation feature.
History Notes

[HDInsight] az hdinsight create: Add a new parameter --enable-compute-isolation to support create cluster with compute isolation feature.

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.

Hi @Juliehzl  @kairu-ms  Could you please help review this PR? Thanks

@kairu-ms to help with this PR.

authors: aim-for-better yonzhan


text:
[Azure Cache for Redis] Configure Private Endpoint Connection commands and added help examples for Azure Cache for Redis

Description
Configure private-endpoint-connection commands for Azure Cache for Redis.
Added help examples for Azure Cache for Redis.
Testing Guide
private-endpoint-connection Commands
Show private endpoint
az network private-endpoint-connection show
example:
az network private-endpoint-connection show --id "/subscriptions/{subscriptionId}/resourceGroups/MyResourceGroup/providers/Microsoft.Cache/Redis/MyCache/privateEndpointConnections/MyPrivateEndpointConnection"
Reject connection status
az network private-endpoint-connection reject
example:
az network private-endpoint-connection reject --id "/subscriptions/{subscriptionId}/resourceGroups/MyResourceGroup/providers/Microsoft.Cache/Redis/MyCache/privateEndpointConnections/MyPrivateEndpointConnection"
Delete Private Endpoint
az network private-endpoint-connection delete
example:
az network private-endpoint-connection delete --id "/subscriptions/{subscriptionId}/resourceGroups/MyResourceGroup/providers/Microsoft.Cache/Redis/MyCache/privateEndpointConnections/MyPrivateEndpointConnection"
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.

private link for Redis

authors: AnshulBhl yonzhan


text:
{Package} Bump up azure-core to 1.30.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.

Package

1.30.0 is not enough. azure-identity requires azure-core>=1.31.0 since https://github.com/Azure/azure-sdk-for-python/pull/36882.

Context: azure-core==1.28.0 is not compatible with the latest azure-identity 1.18.0 which requires azure-core>=1.31.0  (https://github.com/Azure/azure-sdk-for-python/pull/36882). We have to bump azure-core so that the latest azure-identity can be installed in the same virtual environment.

authors: jiasli kairu-ms yonzhan


text:
Add support for managed instance's proxy override and public data endpoint enabled

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

[x] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[x] I adhere to the Command Guidelines.

Is there a way to specify argument type to be bool?
There is currently a regression in westcentralus and I'm not able to run the test as Managed Instance creation gets stuck . Once the region is refreshed with a fix, I'll rerun the test and update test recordings.


text:
[Network] New Commands for RC6

Fixes #846. cc/ @DeepakRajendranMsft, @MikhailTryakhov for feedback.
Adds the following commands and tests:

nic get-effective-route-table
nic list-effective-nsg
vnet peering delete
vnet peering show
vnet peering create
vnet peering update (generic update)
vnet peering list
vnet check-ip-address

nic show-effective-route-table
Command
    az network nic show-effective-route-table: The get effective routetable operation retrieves all
    the route tables
    applied on a networkInterface.

Arguments

Resource Id Arguments
    --ids              : One or more resource IDs. If provided, no other 'Resource Id' arguments
                         should be specified.
    --name -n          : The network interface (NIC).
    --resource-group -g: Name of resource group.

nic list-effective-nsg
Command
    az network nic list-effective-nsg: The list effective network security group operation retrieves
    all the
    network security groups applied on a networkInterface.

Arguments

Resource Id Arguments
    --ids              : One or more resource IDs. If provided, no other 'Resource Id' arguments
                         should be specified.
    --name -n          : The network interface (NIC).
    --resource-group -g: Name of resource group.

vnet peering create
Command
    az network vnet peering create: Peerings in a VirtualNework resource.

Arguments
    --name -n           [Required]: The name of the VNET peering.
    --remote-vnet-id    [Required]: ID of the remote VNET.
    --resource-group -g [Required]: Name of resource group.
    --vnet-name         [Required]: The virtual network (VNET) name.
    --allow-forwarded-traffic     : Allows forwarded traffic from the VMs in the remote VNET.
    --allow-gateway-transit       : Allows gateway link to be used in the remote VNET.
    --allow-vnet-access           : Allows VMs in the remote VNET to access all VMs in the local
                                    VNET.
    --use-remote-gateways         : Allows VNET to use the remote VNET's gateway. Remote VNET
                                    gateway must have --allow-gateway-transit enabled for remote
                                    peering. Only 1 peering can have this flag enabled. Cannot be
                                    set if the VNET already has a gateway.

Though English is not my first language, but the help text looks pretty awkward, particular The list effective network security group operation retrieves..., should be shrunk to the operation retrieves. Also the line break after all the is unnecessary.
I know this is caused by we are loading the SDK doc. I suggest we should override it, unless we have a plan to update across all.
az network nic list-effective-nsg: The list effective network security group operation retrieves
    all the
    network security groups applied on a networkInterface.

The rest LGTM

Since we will need to improve help across the board, I went ahead and overrode the descriptions for the vnet and nic commands (not just the ones in this PR).

In reply to: 247488615 [](ancestors = 247488615)

authors: tjprescott yugangw-msft


text:
ChangeFeedIterator.HasMoreResults returns true even all the change feeds returned

Describe the bug
After get FeedIterator from GetChangeFeedIterator api, the HasMoreResults always return as true even all the change feeds returned. It is cross partition.
Expected behavior
We should get HasMoreResult as false after all the change feeds returned.
Actual behavior
The HasMoreResult always return s true even FeedResponse Status Code is not modified.
Environment summary
SDK Version: 3.20.1-preview
Windows

It appears to be expected based on https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-pull-model#consuming-an-entire-containers-changes:

Because the change feed is effectively an infinite list of items encompassing all future writes and updates, the value of HasMoreResults is always true

From response, the status code is notmodified, so we should use that to determine based on document you shared. Is that correct?

authors: SamGuoMsft john-soklaski


text:
Performance: Adds AuthorizationHelper Improvements to ConvertToBase64string method

Pull Request Template
Description
Instead of using ‘ArrayPool.Shared.Rent(capacity)’ to allocate byte array temporarily, we can use stackalloc byte[]. It avoids the overhead of allocating and deallocating the buffer .
|                       Method |           Mean |     Error |  StdDev |  StdErr |    Min |     Q1 |   Median   |     Q3 |      Max |      P80 |      P85 |      P90 |      P95 |     P100 |      Op/s |
|------------------------------------ |---------:|----------:|----------:|----------:|---------:|---------:|---------:|---------:|---------:|---------:|---------:|---------:|---------:|---------:|----------:|-------:|------:|------:|----------:|---------------------:|-----------------:|
|    CreateSignatureGeneration-Master | 726.9 ns | 34.16 ns | 51.13 ns | 9.34 ns | 667.8 ns | 680.9 ns | 722.5 ns | 746.6 ns | 863.3 ns | 753.1 ns | 774.0 ns | 799.1s | 822.4 ns | 863.3 ns | 1375,743.5 |
|      ReadSignatureGeneration-Master | 698 ns | 7.57 ns | 10.61 ns | 2.04 ns | 682.6 ns | 689.4 ns | 696.9 ns | 706.3 ns | 720.7 ns | 708.7 ns | 709.1 ns | 712.3 ns | 713.3 ns | 720.7 ns | 1432,681|
| CreateSignatureGeneration-Updated   | 672.9 ns | 19.06 ns | 28.54 ns | 5.21 ns | 634.2 ns | 651.4 ns | 668.5 ns | 688.8 ns | 737 ns | 700.4 ns | 703.6 ns | 709.4 ns | 728.6 ns | 737 ns | 1486,017 |
|   ReadSignatureGeneration-Updated   | 647.5 ns | 7.80 ns | 10.41 ns | 2.08 ns | 625.3 ns | 642.2 ns | 648.3 ns | 654.8 ns | 665 ns | 656.7 ns | 659 ns | 660.5 ns | 662.1 ns | 665 ns | 1544,291

Type of change
Please delete options that are not relevant.

[] Bug fix (non-breaking change which fixes an issue)
[] New feature (non-breaking change which adds functionality)
[] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[] This change requires a documentation update

Closing issues
To automatically close an issue: closes #IssueNumber

Would be great to include memory also part of diagnostics.

Closing the issue for now as there is lack of clarity around the ask and still waiting on requesting team.

authors: aavasthy kirankumarkolli


text:
Github Enterprise Managed user can't see the public issues while trying to login using the Github Enterprise account.

A GitHub Enterprise Managed User (GHEM) is experiencing difficulties accessing public issues on GitHub Community repositories. Despite attempting to view these issues, the user is unable to do so. Additionally, the user logs into their GitHub Enterprise account using Single Sign-On (SSO). We need assistance in resolving this issue to allow the user to access public issues on GitHub.

@swissrerakeshv this doesn't seem to be related to AZD. Seems to be a GitHub issue. Please file it here - https://support.github.com/ ref: https://docs.github.com/en/enterprise-cloud@latest/support/contacting-github-support/creating-a-support-ticket

repo: Azure/azure-dev


text:
[codespaces/vscode] When launching "debug" for API we should ensure that azd provision succeeded

When launching debug we should check to ensure that azd provision has run successfully before launching. Otherwise the user will receive obscure errors relating to the API app amounting to a lack of resources or configuration (depending on how the API app is written)

This is not a problem. The dotenv tasks used to prepare debugging error out when no environment is found.


text:
New Join Domain Artifact - "A specified logon session does not exist. It may already have been terminated."

Hi,
The New Join Domain Artifact seems to be unable to join my domain and throws the following error - "A specified logon session does not exist. It may already have been terminated."
The domain controller is at the end of an IPSec tunnel (via newtwork gateway) but I can remote from my DevTestLabs machine onto the domain controller (so connectivity seems to be fine). I've also managed to join the domain manually by remoting onto the box.
Any ideas?
Many Thanks
Chris

Hi Chris,
Can you share what is the VM image you are using? What's the OS? It may be related to the following security policy.
Network access: Do not allow storage of passwords and credentials for network authentication
Perhaps you can check to see if this option is enabled. If so, can you try disabling it and run the artifact again? It may help us narrow down the root cause.

It seemed to be solved by supplying the full domain name in front of the user with domain join permission. All seems OK now and works perfectly.

authors: chrispont leovms

repo: Azure/azure-devtestlab

license: mit

license_source: bigquery


text:
Docs.MS Release Updates for azure-spring-cloud-autoconfigure

Update docs metadata and targeting for release of azure-spring-cloud-autoconfigure

Docs Build status updates of commit 8451e03:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/spring-cloud-autoconfigure-readme.md
:warning:Warning
View (azure-java-stable)
Details

package.json
:white_check_mark:Succeeded

docs-ref-services/latest/spring-cloud-autoconfigure-readme.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 11, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'springcloud'.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

repo: Azure/azure-docs-sdk-java


text:
Azure Service Bus output binding for Azure Functions is limited to message body

The way the service bus output bindings are implement seem to only support the message body... You can't set messageId, sessionId, applicationProperties, etc.  This makes it useless almost any real world use cases.
Are there plans to properly implement this binding?
Found these related "User Voice" issues, but they are stale and have no comments addressing this issue:
https://feedback.azure.com/d365community/idea/eea36d62-f224-ec11-b6e6-000d3a4f0da0
https://feedback.azure.com/d365community/idea/df849c4f-f224-ec11-b6e6-000d3a4f0da0

Are there still no progress on this issue? The functionality to be able to output an entire ServiceBusMessage have been around for ages and is really importande in some scenarios. In my case controlling serialization AND setting a schedule enqueue time.
Having to manually use a servicebus client to output this will mess up the code and is a step backwards compared to the support that was already there in in-process mode.

I cannot believe these extremely fundamental and basic functionalities are not provided yet?

authors: ChuckJonas SamVanhoutte cannehag

repo: Azure/azure-functions-dotnet-worker


text:
When will Release version 4 of the Node.JS programming model for Azure Functions?

Hello Azure fn team,
about V4 programming model when will be get stable? do you have any release plan?
We are writing new app with (50-75) functions with other Azure Service bus, SignalR and redis cache.
What would be you advise, should we start with v4, and in upcoming months it will be released?
Regards

Hello, you can see our timeline estimates in our Roadmap here: https://github.com/Azure/azure-functions-nodejs-library/wiki/Roadmap

authors: ejizba sunil-bagde

repo: Azure/azure-functions-nodejs-library


text:
Improve TypeScript-templates experience in Portal

Updated AF tools allow to create TypeScript-template for Azure Functions in VSCode, that is great.

Displaying files from the /dist folder
The structure of the project suggests that after ts-files are compiled, the output js-files are store in the /dist folder.

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2017",
    "outDir": "dist",
    "rootDir": ".",
    "sourceMap": true,
    "strict": false
  }
}

The function.json file in the function folder also references to that dist folder. 👍
The portal in the editing interface by default opens files from the dist folder. 👍
But when I go to the "View files" tab, I can't find the source index.js file. ☹

Recompile ts files through the portal.
It would be helpful to automatically compile/recompile .ts-files if I'm able to edit them through the portal. But probably, I don't want to install tsc on the app level. ☹

I know that it is not so easy to implement it without complicating other things.. But the current experience is somehow incomplete. You allow editing files, but it makes no sense, as they are not compiled.

I understand that it is up to the developer to figure out such things, but the node-version that is used in AF at least supports ES2018, and the default target version for TS in the template is ES2016. It seems like a common default across the industry, but it would be helpful to expose somehow to developers, that they can level up target version up to ES2018 (e.g., in docs or in comments in the template).

@mhoeger - Please take a look.

@kichinsky - thanks for taking a look and for the feedback!! How did you deploy to get to this state? The flow we want developers to follow is to develop and test functions locally and then publish (by default, it publishes as "read-only"). For further changes, the expectation was to make them locally and then publish. Could you tell us how you got to using the TypeScript template but not publishing as read-only (using run-from-package)?

@mhoeger I'm using ADO Pipelines to deploy from the typescript source code (I had to add compiler step on build to make it working). You are right, by default as soon as I configure CI/CD it is readonly, but...

When I attemp to explore the files by default the portal opens the index.js file, but it is not available in the list of files:

So it is not about editing, just looking through the code.

I can turn read-only mode off, and I can still edit files through the App Service Editor. Meanwhile it is against CI/CD practices, it still makes sence for experiments and live tunning/debugging. So in such a case I would prefer to edit TS-files, but I have to compile them then.

@kichalla - I still struggle with this scenario because our local debug/tuning is going to run the same code paths as production. I definitely understand the convenience of being able to adjust deployed code, but we've seen a lot of mistakes in the past from being able to directly alter production code and we're trying to move away from this dangerous game.
We'll keep this under consideration, but it's hard to justify putting in a good chunk of dev hours to simplify a scenario we want to discourage. Would making remote debugging easier meet your needs? That's something we are more inclined to invest in across languages / across scenarios.

@mhoeger I think it is more complicated meanwhile the ultimate goal is still to simplify and streamline developer experience.
The way how I hear what you say is that there some dangereous practices (e.g., editing on deployment) and we are trying to get rid of them (by pushing towards local testing and strong CI/CD pipeline). But having front-end background I feel that there is a mismatch in that approach. And it lays in a different place.

There are use cases when I just wanna get something live in the cloud quickly. For context - it is usually on the prototyping stage, when I don't really care about production constrains, etc. My only goal is to get it work. Then for me, it is easier to setup continuous deployment with something like ADO Pipelines than manually trigger uploading from VS Code. But... executing ADO Pipeline for each update takes time. So now, when I just need to fix one line of code and see, if it works, it is much faster to do it through the portal, check whether it works and update than in the source code, redeploy, etc. My motivation is to do what is faster, not what is more secure.

Than if I have a front-end background, than it is in my DNA to trust real execution vs. local testing. It is my habbit to alter code through debugging tools built-in to the browser, to edit almost live-code and see changes. Just one small example: if I didn't install locally dotnet, I can't install CosmosDB extensions, then I can't test it locally, etc -- but if I add binding through the portal it happens automatically. So my trust is already broken with local testing/running. Now the question is how I can continue doing it my way without sacrificing security, stability, etc. I don't say that it should be all live in cloud (meanwhile I can image a prototyping-staging without constrains). I just say that we should take into account the developer nature instead of trying to alter it just because we think that our way is the right one. The question N1 is how to increase the trust in local testing, and the question N2 is how to allow that live-editing that is natural for most of front-end (web-) developers?

@kichinsky  any Luck on the CI/CD with the Typescript, we are also facing the same issue directly we can't able to push typescript based functions :(

@vamsi981 My current setup to deploy Azure Functions (AF) on TypeScript through Azure DevOps (ADO) is the following:

In AF portal -- setup the source code and CI/CD to use ADO. It will generate some standard pipelines for build and deploy.
For the source code - ensure you have the extensions.csproj file (run func extensions install) in your folder. It will capture the dependencies from your integration points. You need to install the Azure Functions Core Tools before running the func command.
In the ADO in your build pipeline:

Add Compile TypeScript step (there is an extension in the marketplace, that you can easily search from the interface). Ensure you configured the path to the source folder or your tsconfig.json.
Add a new Bash step with two commands:

dotnet restore extensions.csproj
dotnet build extensions.csproj --output ./bin/

Configure the working directory for this step as well.

We are aware of the issues for in-portal editing of TypeScript functions and there will be even more issues for both JS and TS once we implement https://github.com/Azure/azure-functions-nodejs-worker/issues/480 (because the new programming model will require a certain amount of app-level code, not just one js/ts file per function).
I'm skeptical we will fix these with the existing in-portal editing, but there's talk of doing a prototype with GitHub Codespaces to replace in-portal editing. If that works happens, it would not be for a while and also would not be specific to Node.js - so I'll put this in the tracking milestone for now

authors: ejizba kichinsky mhoeger pragnagopa vamsi981

repo: Azure/azure-functions-nodejs-worker


text:
Deletion and re-deploy does runs into errors

I still see a deletion problem: I deleted 3 Functions on ACA at 8:16 but was not able to do a fresh deploy at 8:18

{\"error\":{\"code\":\"Conflict\",\"message\":\"Request specified that resource '/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx/resourcegroups/kw-m2-rg/providers/Microsoft.Web/sites/kw-m2acafrecvexp' is new, but resource already exists.
This may be due to a pending delete operation, try again later.\"}}

Waiting some more minutes then brings up a different error:

{"code":"DeploymentFailed","target":"/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx/resourceGroups/kw-m2-rg/providers/Microsoft.Resources/deployments/acafBase-Distributor","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.","details":[{"code":"InternalServerError","message":"There was an unexpected InternalServerError.  Please try again late
r.  x-ms-correlation-request-id: 0c897159-bb41-43e4-845e-5c7c7042e13a"}

How long is one is supposed to wait? And if this is to be expected, it should be mentioned in docs.

issue is fixed now

repo: Azure/azure-functions-on-container-apps


text:
[ARM] Add expand OData to get resource group api

$expand should support createdTime and changedTime for resource groups. No reason why we shouldn't include this in our spec.

No customer feedback for this. We will revisit if we hear otherwise. @kirthik - please close the issue.

authors: ravbhatnagar vivsriaus

repo: Azure/azure-rest-api-specs


text:
Initial submission of TimeSeriesInsights public preview swagger spec and examples

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.
================
Validation:

I have run the swagger-linter plugin in vsCode and the open-api validation tool on the spec.
The spec has also passed review by the ARM team and their validation tools.
I have used AutoRest to generate a .NET client from the spec and tested all operations with real resources.

Notes on Examples
I have added examples for all operations for each of our resource types. I have not hooked up the EventSource samples as I am getting validation errors that I believe indicate the tool isn't handling inheritance correctly. If I hook the EventSourcesGet.json example, the tool reports:
{ code: 'RESPONSE_VALIDATION_ERROR',
message: 'Found errors in validating the response with statusCode "200" for x-ms-example "EventSourcesGet" in operation "EventSources_Get".',
innerErrors:
[ { code: 'INVALID_RESPONSE_BODY',
errors:
[ { code: 'OBJECT_ADDITIONAL_PROPERTIES',
params:
[ [ 'creationTime',
'provisioningState',
'keyName',
'eventHubName',
'consumerGroupName',
'serviceBusNamespace',
'eventSourceResourceId' ] ],
message: 'Additional properties not allowed: creationTime,provisioningState,keyName,eventHubName,consumerGroupName,serviceBusNamespace,eventSourceResourceId',
path: [ 'properties' ],
description: 'Properties of the event source.' } ],
message: 'Invalid body: Additional properties not allowed: creationTime,provisioningState,keyName,eventHubName,consumerGroupName,serviceBusNamespace,eventSourceResourceId',
path: [] } ] }
However, the additional properties are members of EventHubEventSourceCommonProperties, which inherit (allOf) AzureEventSourceProperties, which in turn inherit (allOf) EventSourceCommonProperties.
AutoRest understands this inheritance when I use it to generate the .NET Client.

@sandshadow,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@sandshadow Could you please also update x-ms-examples/spec for the response codes to resolve following error categories:

[ ] RESPONSE_STATUS_CODE_NOT_IN_EXAMPLE
[ ] RESPONSE_STATUS_CODE_NOT_IN_SPEC

Reference CI: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/223796765#L1078

@sandshadow Regarding the issue you are facing on polymorphic response validation, could you please let me know which version of oav are you using? Also please shoot an email with your example file to me so that we can look into it? Thanks

@sandshadow Thanks for sending the traces. I'll look into it. Meanwhile if you have fixed the above two errors RESPONSE_STATUS_CODE_NOT_IN_EXAMPLE & RESPONSE_STATUS_CODE_NOT_IN_SPEC. Let me know we should be good to proceed. Thanks!

@vishrutshah I have just added the commit that removes the example for EventSources_Get to prevent errors when running "oav validate-example" until we solve the problems with polymorphic responses. The  RESPONSE_STATUS_CODE_NOT_IN_EXAMPLE & RESPONSE_STATUS_CODE_NOT_IN_SPEC errors should be fixed now.

@vishrutshah I have not implemented an operations API yet.
Re:  ServiceDefinitionParameters - I do define a ApiVersionParameter in the global parameters section:
    "ApiVersionParameter": {
      "name": "api-version",
      "in": "query",
      "required": true,
      "type": "string",
      "description": "Version of the API to be used with the client request. Current version is 2017-02-28-preview."
    },

Re:  SecurityDefinitionsStructureValidation. I do have a Security Definitions object defined.
"securityDefinitions": {
    "azure_auth": {
      "type": "oauth2",
      "authorizationUrl": "https://login.microsoftonline.com/common/oauth2/authorize",
      "flow": "implicit",
      "description": "Azure Active Directory OAuth2 Flow",
      "scopes": {
        "user_impersonation": "impersonate your user account"
      }
    }
  },

Any idea why the linter is complaining about either of these? The message says "A swagger must have security definitions and must adhere to the specific structure." Is there some reference I can look at to see the "specific structure"?
Are any of these linter errors blocking for completing the PR?
Thanks,
Eric

@sandshadow Ahaa things looks good but not sure why linter is complaining.
I've put more information onto
bug https://github.com/Azure/autorest/issues/2129 - SecurityDefinitionsStructureValidation
bug https://github.com/Azure/autorest/issues/2128 - ServiceDefinitionParameters

No modification for Ruby

No modification for NodeJS

No modification for Python

authors: AutorestCI msftclas sandshadow vishrutshah


text:
Add the march public preview API version of extended location

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 service onboarding
[X] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.

The new version is already deployed. The manifest will finish deploying tomorrow.
I believe our public preview begins at the end of the month, and this will need to be ready before then so that we can update the SDK.

When you expect to publish swagger? Please provide date, or month to public if date is not available yet.

We need to publish this swagger ASAP.

If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after 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
[X] No, no need to refresh for updates in this PR

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of "no breaking changes"
[X] I have reviewed the documentation for the workflow.
[X] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?
*one issue not related to this change was already present in the existing version - maybe the tools were updated? - looking for guidance here as I may need to fix in this PR.

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
[X] Ensure to copy the existing version into new directory structure for first commit (including refactoring) and then push new changes including version updates in separate commits. This is required to review the changes efficiently.
Adding a new service

[X] 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 Breaking Change 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 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.

/azp run

Signing off from ARM side.


text:
Azure Event Grid: Creating baseline version for new API version 2017-09-15-preview

Azure Event Grid: Creating baseline version for new API version 2017-09-15-preview.

With the first commit, the contents of this file are EXACTLY the same as the contents of 2017-06-15-preview with the exception of updating the API version from 2017-06-15-preview to 2017-09-15-preview.
The follow-up commit contains the actual changes corresponding to the new API version.

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.

@kalyanaj,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@kalyanaj
Can you fix this error:
{
"type": "Error",
"code": "XmsExamplesRequired",
"message": "Please provide x-ms-examples describing minimum/maximum property set for response/request payloads for operations.",
"id": "R2022",
"validationCategory": "SDKViolation",
"providerNamespace": null,
"resourceType": null,
"sources": [
"file:///home/travis/build/Azure/azure-rest-api-specs/specification/eventgrid/resource-manager/Microsoft.EventGrid/2017-09-15-preview/EventGrid.json:18:4 ($.paths)"
]
}

@sarangan12, Regarding the x-ms-examples, there's another active PR in review (#1648) to add x-ms-examples for Azure Event Grid (I had gotten an exception for this earlier). Once that PR gets merged, I will merge the x-ms-examples into the Swagger for the newer API version. The Swagger for the newer API version (2017-09-15-preview) is required to unblock the PRs for the .NET SDK / PowerShell etc., so it will be great if we can do them in parallel without blocking on it.

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-ruby

authors: AutorestCI kalyanaj msftclas sarangan12


text:
update-x-ms-parameter-location-for-recoveryservicessitere…

…covery
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.

@jianyexi @qiaozha to confirm whether Linter is false alarm as it should be only impact SDK

/azp run

/azp run

authors: akning-ms colawwj qiaozha


text:
Review request for Microsoft.HealthcareApis to add version stable/2022-12-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM API Information (Control Plane)
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
[x] 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.

Target is early December.

When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.

Ideally ASAP, but also targeting early December

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):

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] 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:

[x] 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.

/azp run


text:
Update listVault.json

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.

/azp run

/azp run


text:
Changing customconfig from int32 to int64

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.

This commit was treated and no generation was made for Azure/azure-sdk-for-python

This commit was treated and no generation was made for Azure/azure-sdk-for-go

Added minimum value. I am aware this is a breaking change, but the current version is broken for 50% of the custom search instances, so it is a change we must make.

@ravbhatnagar Are you ok with this changes?

@q3blend could you also provide an example which has this parameter to fix this issue https://travis-ci.org/Azure/azure-rest-api-specs/jobs/337527734

Automation for azure-sdk-for-python

This commit was treated and no generation was made for Azure/azure-sdk-for-go

This commit was treated and no generation was made for Azure/azure-sdk-for-go

This commit was treated and no generation was made for Azure/azure-sdk-for-go

Swagger to SDK encountered an unknown error: (Azure/azure-sdk-for-go)
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/github_tools.py", line 29, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 180, in rest_handle_action
    return rest_pull_close(body, github_con, restapi_repo, sdk_pr_target_repo, sdkbase)
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 311, in rest_pull_close
    rest_pr.create_issue_comment("Was unable to create SDK %s PR for this closed PR.", sdkid)
TypeError: create_issue_comment() takes 2 positional arguments but 3 were given

authors: AutorestCI q3blend sergey-shandar


text:
update Patch model name

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
[x] 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.
fixes #23708

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

@jackofallops Please fill in the correct checkboxes in the first comment so we can get a quick overview of what's going on with this PR and make sure you've understood the relevant linked docs.

/azp run

@jackofallops Please fill in the correct checkboxes in the first comment so we can get a quick overview of what's going on with this PR and make sure you've understood the relevant linked docs.

@jackofallops Could you please follow this suggestion ?

@jackofallops Please fill in the correct checkboxes in the first comment so we can get a quick overview of what's going on with this PR and make sure you've understood the relevant linked docs.

@jackofallops Could you please follow this suggestion ?

Hi @navba-MSFT - The referenced comment was made at 5am my time (UK), so I've only just seen it.  I'm not a Microsoft employee, so do not have access to the links in the first comment, and the section is for MSFT employees only? Can you be more specific about the additional information needed? The issue describes the problem, and this PR is a self-explanatory change to address a violation in the spec, but I'm happy to provide additional info as required or make amendments to the PR as needed?
Thanks!

@jackofallops Please fill in the correct checkboxes in the first comment so we can get a quick overview of what's going on with this PR and make sure you've understood the relevant linked docs.

@jackofallops Could you please follow this suggestion ?

Hi @navba-MSFT - The referenced comment was made at 5am my time (UK), so I've only just seen it. I'm not a Microsoft employee, so do not have access to the links in the first comment, and the section is for MSFT employees only? Can you be more specific about the additional information needed? The issue describes the problem, and this PR is a self-explanatory change to address a violation in the spec, but I'm happy to provide additional info as required or make amendments to the PR as needed?
Thanks!

@jackofallops Please update the PR description here.

Hi @navba-MSFT - I'd be happy to. Can you please be specific about what is necessary to be updated? I have completed all I that I am instructed to in the template, and having checked many other open PRs none have any further information than I have provided. Please elaborate.

@v-jiaodi @naveedaz Could you please review this PR once you get a chance ? Thanks in advance.

@JeffreyRichter Could you help take a look at the breaking change of this PR ? Thanks

Ideally, the models for PUT and PATCH are identical. This way, a customer could create and initialize a struct via an SDK and then pass that to either a PUT or PATCH method. Or call a GET (which returns an initialized struct) and then pass that to PUT or PATCH. It seems to me that you are purposely making the models different.
That being said, if the service has already GA'd then we don't want to introduce a breaking change. So is this change correcting the swagger to make it accurately reflect the currently-shipping service behavior?

/azp run

authors: JeffreyRichter jackofallops navba-MSFT v-jiaodi


text:
Fix schema issue for Microsoft.App in 2024-02-02-preview

ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

[!NOTE]
As of January 2024 there is no PR assignee. This is expected. See https://aka.ms/azsdk/pr-arm-review.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Click here to see the details of Step 1, Breaking Changes review
If you are in purview of Step 1 of the diagram, follow the Breaking Changes review process.
IMPORTANT! This applies even if you believe your PR was mislabeled, for any reason, including tool failure.

Click here to see the details of Step 2, ARM review
See https://aka.ms/azsdk/pr-arm-review.

 Click here to see the diagram footnotes
Diagram footnotes
[1] See ARM review queue (for PR merge queues, see [2]).
[2] public repo merge queue, private repo merge queue (for ARM review queue, [1])
The ARM reviewer on-call engineer visits the merge queue twice a day, so the approximate ETA for merges is 12 - 24 hours.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[ ] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been generated using OpenAPI Hub).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[ ] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[ ] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with PR workflow diagram Step 2 (ARM review), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

/pr RequestMerge


text:
FormRecognizer - Minor update to help text.

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-js

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

authors: AutorestCI azuresdkci ramparab


text:
[Hub Generated] Review request for Microsoft.Billing to add version preview/2018-11-01-preview

If you are a MSFT employee you can view your work branch via this link.
Contribution checklist:

[x] I have reviewed the documentation for the workflow.
[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-js

Automation for azure-sdk-for-ruby

Can one of the admins verify this patch?

Automation for azure-sdk-for-go

Automation for azure-sdk-for-net
A PR has been created for you:
https://github.com/azure/azure-sdk-for-net/pull/6403
.NET SDK Commits:
https://github.com/adxsdknet/azure-sdk-for-net/pull/6403/commits/f9cbc296845932be678ed9a95adce1b39d765b8f

Automation for azure-sdk-for-java

@sarang-amondikar has this API been deployed?

@jhendrixMSFT the api  is not yet deployed, we want to test it in ppe first

Sounds good, please update when the API is live so we can merge.

@AutorestCI regenerate azure-sdk-for-go

the api is now deployed to prod, could you please approve this PR?

authors: AutorestCI adxsdknet azuresdkci jhendrixMSFT sarang-amondikar


text:
Remove incorrect scopes for Usage details.

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:

[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[x] 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-go

Can one of the admins verify this patch?

authors: AutorestCI addesai azuresdkci


text:
CODEOWNERS: Adding automation section

Adding automation owners

/check-enforcer override

repo: Azure/azure-sdk-for-android


text:
Azure Central: TELEMETRY_FREQUENCY_IN_SECONDS not working

Hello guys,
Im not sure if this is expected behavior but I specified 1 hour interval to send telemetry data to iot central, as I dont want to incur more cost to use the service while im testing the behavior.
On the screenshot below, I specified the interval to be 3600 (1 hour) but on the console log output, its publishing telemetry every 10 seconds.
Maybe the max frequency is 10 seconds interval ? If not, its a bug.

On IoT Central Device Page,  I confirm that it received telemetry value every 10 seconds.

Hi @ghostidentity, thank you for bringing this to our attention. It looks like there is a missing call to azure_pnp_set_telemetry_frequency in the main .ino file.
For the ESP32 IoT Central sample which you are running, you can add the following in the setup function after azure_pnp_init():
azure_pnp_set_telemetry_frequency(TELEMETRY_FREQUENCY_IN_SECONDS);. That should change the frequency at which telemetry is sent, let me know if this is not the case.

authors: RLeclair ghostidentity

repo: Azure/azure-sdk-for-c