text:
az vm show|list: VM public IP not displayed anywhere

This is some annoying design that frustrates me every single time I use old CLI command azure vm list: IP of the VM is not listed. https://github.com/Azure/azure-xplat-cli/issues/2818
Every other compete CLIs and Portals  show the VM IP anytime list of VMs is presented to the user.
Now in the new cli, neither az vm list nor az vm show shows the public IP address of the VM. The old CLI showed it in azure vm show.

We have a command for this: az vm list-ip-addresses. The reason it doesn't show up in VM list or show (or even show with --expand instanceView) is simply because the compute service does not return that info.

@tjprescott got it! Thanks. Do you think this list-ip-addresses is discoverable enough? I guess it does the job for me, but I think these cmds listing VM(s) should show the IP addr, too. Perhaps you can make a query to the NRP (in parallel to fasten up) to get that and populate it in the VM response?

@ahmetalpbalkan we can work to make it more discoverable (for instance, putting a reference in the --help text). We might also be able to expose a --show-ip-addresses flag which would let the user "opt in" to the slower response in exchange for this info. @yugangw-msft is this something that could work?

I mean ideally it just should be there. It's there on the portal...
If I'm trying to view a VM I'm probably not trying to view its size, name, id, osDisk, osProfile, networkInterface IDs, right? I'm probably trying to connect to it.
If this doesn't work out, I'd prefer something short like az vm ip I think.

We have debated on this for several times. I have always wanted to display the ip-address in vm show.  The main augment was it might slow things down.
But for vm show it only involves 2 extra rest calls which are to get nic and then the public-ip.  The extra cost won't be that significant, as it mostly gets amortized in command loading, parsing and output.
So my opinion is still

do it for vm show
for vm list, if we get more user feedback, do like Travis suggested.  The nic number per each subscription could reach to 10000, so I feel much conformable with opt-in.
@johanste, @jasonrshaver

I think a more long-term healthier solution would be getting CRP APIs to expand the IP addresses of the instance if there are concerns around slowing the client-side down.

Agreed. That is what we had hoped for.
It is all about the trade-off to made under the context that there is no timeline yet for when the server end will get fixed, and at the same time people's daily lives will have to continue.

I would add FQDN to the PIP request for show|list. At least show. Or add it to list-ip-addresses. I miss that feature from xplat and can't find a way to get it at the VM level now.

az vm show -g yugangw -n yugangw-9 -d -otable
Name       ResourceGroup    PowerState    PublicIps       Fqdns                               Location
---------  ---------------  ------------  --------------  ----------------------------------  ----------
yugangw-9  yugangw          VM running    104.42.231.246  yugangw9.westus.cloudapp.azure.com  westus

Following command returning an empty line
az vm list-ip-addresses -g UbuntuCleanTest -n MyUbuntuVM
Shouldn't it return the ip address of MyUbuntuVM VM from UbuntuCleanTest resource group?

@jahongirman it should return that, provided the IP address has been resolved at the time you invoked the command.

authors: ahmetalpbalkan jahongirman ryankmcintyre tjprescott yugangw-msft


text:
{Doc} Update cffi troubleshooting, extension authoring and onboarding guide

Description

Update cffi troubleshooting when there's no RPM package;
Add back vendored SDK guidance;
Add PLR process in onboarding guide.
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.

Doc

source: gharchive/pull-request

authors: fengzhou-msft yonzhan

repo: Azure/azure-cli

license: MIT

license_type: permissive

license_source: github-api


text:
Annotate packages as supporting Python 3.7.

They've been distributed on MacOS using Python 3.7 for quite some time. It's good empirical evidence that we have the capacity to work with Python 3.7.
Note: Because this is targeting the flatten branch, we have many fewer places where this notation needs to be added.

Ping @tjprescott and @yugangw-msft

Got approval offline from both @tjprescott and @yugangw-msft, I'm pushing this one in :)


text:
[Fix][CNS] InterfaceID should be set to containerID instead of interfaceName if CNS managing state

Reason for Change:

This PR fixes an issue where interfaceID is set to interfaceName instead of containerID and this leads to incorrect CNS reconcilation where CNS key is interfaceName instead of containerID. This is the PR to change CNS running in managed state to recocile based on InterfaceID instead of podname+namespace: https://github.com/Azure/azure-container-networking/pull/1811
Issue Fixed:

Requirements:

[ ] uses conventional commit messages

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

Notes:

Can you add a log line here too:
GetExistingIPConfig() <<-- function too, if it happens to find an existing info for a given PodKey

repo: Azure/azure-container-networking


text:
[NPM] Remove unused codes to save and restore ipset and iptables

Reason for Change:

There are a bug in Save and Restore functions in iptm.go. It does not store iptables information into file with the error message "exec: Stdout already set"
As the similar issue exists in Restore function in iptm.go.
The first commit fixed the issues (in save and restore of iptables) in this PR.
However, we all agree to delete those codes since it is not necessary to save iptables information now and saving iptables information has high overhead.
So, I clean-up related save and restore codes for iptables and ipset in following commits.
.Issue Fixed:

Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests

Notes:

/azp run

\azp run


text:
Newtonsoft.Json: Self referencing loop detected for property 'Parent' with type 'Microsoft.Azure.Cosmos.Tracing.Trace'.

We are continuously addressing and improving the SDK, if possible, make sure the problem persist in the latest SDK version.

Describe the bug
Using continuationToken does not work
To Reproduce

Create an Azure Function HTTP Trigger
Inside the Azure Function, query for a paginated collection
Invoke the Azure Function without passing the continuationToken
Return the paginated result together with the FeedResponse<T>.ContinuationToken
Invoke the Azure Function again and pass the continuationToken

Expected behavior
This should get the next page
Actual behavior
Getting the following error

System.Private.CoreLib: Exception while executing function: Some_Paginated_Function. Newtonsoft.Json: Self referencing loop detected for property 'Parent' with type 'Microsoft.Azure.Cosmos.Tracing.Trace'. Path 'Item3.Diagnostics.Value.Children[0]'.

Environment summary
SDK Version: Microsoft.Azure.Cosmos v3.22.1
OS Version: MacOSX 12.0.1
Additional context
Nothing else is thrown in the terminal

How is the continuation value passed into the SDK? Are you sure the value is not being escaped through HTTP transit? For example: https://stackoverflow.com/questions/66995110/azure-cosmos-pagination-feedresponse-continuationtoken-not-working-in-the-next/66995871#66995871

Thanks @ealsur , I think I see the difference now from the response and from what I was getting in the parameter. The + and ~ and some other parts of the continuationToken gets removed when passed back to the endpoint.

You can try escaping or serializing the token as part of a larger object (not just send the token alone) during HTTP transit, it might be that whatever is happening between the token is generated on the initial call and it is received to be used on the second call (Server to Client serialization and/or Client to Server serialization) is modifying it and making it invalid.

@ealsur
What I did is return it as a deserialized object from the endpoint and let the client (mobile app) handle it and encode/serialize it back to a json string. And by the time it is needed to be used in the query parameter of the HTTP request, I make sure that it is URL Encoded.

When you did all those steps, did it work? Were you able to get the same format back?

@ealsur
What I did is return it as a deserialized object from the endpoint and let the client (mobile app) handle it and encode/serialize it back to a json string. And by the time it is needed to be used in the query parameter of the HTTP request, I make sure that it is URL Encoded.

I implemented this after you replied with the reference link.
This approach worked on my end and I got the same format back.

Can we close this Issue then?

This issue is not yet solved

@viplavdhande91 Please create a new Issue with your details. The author of this issue declared closure 3 years ago.

source: gharchive/issue

authors: ealsur kuromukira viplavdhande91


text:
Installer telemetry

Know installer channel
MSI -- Parameter to MSI that lays on the machine metadata to be included in telemetry (writes in the registry) ... Also, a file could be possible (and fewer code paths)
RPM/DEB -- Write to a file near the executable
Brew -- Write to a file near the executable
Install .sh script -- Write to a file near the executable
File name: .installed-by.txt (on Windows: hidden file)

What's left here? Is this required for 5/9 or just GA? I'm going to move it to GA release milestone but chime in if you disagree.

Instead of putting all changes into a single PR we could just release the MSI changes (already checked in), the winget/choco changes (pretty trivial), and the changes to azd.
This will give us some data right away and smooth the path for the install scripts (on which I'm doing a small refactor that is receiving the bulk of review comments)

This PR contains that minimal set of changes: https://github.com/Azure/azure-dev/pull/2099

authors: danieljurek savannahostrowski

repo: Azure/azure-dev


text:
[AspireDeployment] azd vs-server crashes after obtaining access token from VS IDE

After implementing VS IDE changes to respond to access token requests from azd vs-server, the azd.exe process crashes down as soon as any response is sent back. I tried using azd 1.7.0-pr.3589009 (commit 6cbc841e67b18efe7122907fd8a4b50be67989f9) build.
Example of response:
{   "token": "<access_token_value>",   "expiresOn": "2024-03-14T22:27:44.528Z",   "result": "success" }
The error shown is an invalid memory address or nil pointer dereference:

C:\Users\anvillan\source\repos\AspireApp>azd vs-server --cwd . --debug
2024/03/15 08:14:18 main.go:59: azd version: 1.7.0-pr.3589009 (commit 6cbc841e67b18efe7122907fd8a4b50be67989f9)
2024/03/15 08:14:18 main.go:229: using cached latest version: 1.7.0 (expires on: 2024-03-16T14:53:00Z)
2024/03/15 08:14:18 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:14:18 middleware.go:106: running middleware 'debug'
2024/03/15 08:14:18 middleware.go:106: running middleware 'experimentation'
2024/03/15 08:14:18 experimentation.go:42: assignment context: 0g5ad841:76970;
2024/03/15 08:14:18 middleware.go:106: running middleware 'telemetry'
2024/03/15 08:14:18 telemetry.go:38: TraceID: 306c633bbc8d83ff858f82b34205d09f
{"port":51528,"pid":1996,"azd":{"version":"1.7.0-pr.3589009","commit":"6cbc841e67b18efe7122907fd8a4b50be67989f9"}}
2024/03/15 08:20:24 server.go:107: handling rpc InitializeAsync
2024/03/15 08:20:24 server.go:206: handled rpc InitializeAsync in 0s
2024/03/15 08:20:29 telemetry.go:107: Telemetry transmitted in 139.194ms, statusCode: 400
2024/03/15 08:20:29 telemetry.go:107: Items accepted/received: 0/1
2024/03/15 08:20:29 telemetry.go:107: Errors:
2024/03/15 08:20:29 uploader.go:223: failed to transmit item C:\Users\anvillan.azd\telemetry\20240315T152024_0_3347564897.trn with non-retriable status code 400
2024/03/15 08:21:42 server.go:107: handling rpc GetEnvironmentsAsync
2024/03/15 08:21:42 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:21:42 server.go:206: handled rpc GetEnvironmentsAsync in 16.6457ms
2024/03/15 08:21:42 server.go:107: handling rpc OpenEnvironmentAsync
2024/03/15 08:21:42 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:21:42 container.go:172: 'azd vs-server'command asked for envFlag, but envFlag was not included in cmd.Flags().
2024/03/15 08:21:42 server.go:206: handled rpc OpenEnvironmentAsync in 11.8728ms
2024/03/15 08:21:44 server.go:107: handling rpc LoadEnvironmentAsync
2024/03/15 08:21:44 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:21:44 container.go:172: 'azd vs-server'command asked for envFlag, but envFlag was not included in cmd.Flags().
2024/03/15 08:21:44 server.go:107: handling rpc GetEnvironmentsAsync
2024/03/15 08:21:44 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:21:44 server.go:206: handled rpc GetEnvironmentsAsync in 2.5742ms
2024/03/15 08:21:46 command_runner.go:307: Run exec: 'dotnet msbuild C:\Users\anvillan\source\repos\AspireApp\AspireApp.AppHost\AspireApp.AppHost.csproj --getProperty:IsAspireHost' , exit code: 0
2024/03/15 08:21:46 server_service.go:95: [vWabD4wI/38= spinner] Analyzing Aspire Application (this might take a moment...)
[vWabD4wI/38= spinner] Analyzing Aspire Application (this might take a moment...)
2024/03/15 08:21:48 telemetry.go:107: Telemetry transmitted in 21.4165ms, statusCode: 400
2024/03/15 08:21:48 telemetry.go:107: Items accepted/received: 0/3
2024/03/15 08:21:48 telemetry.go:107: Errors:
2024/03/15 08:21:48 uploader.go:223: failed to transmit item C:\Users\anvillan.azd\telemetry\20240315T152144_0_1625535420.trn with non-retriable status code 400
2024/03/15 08:21:54 command_runner.go:307: Run exec: 'dotnet run --project AspireApp.AppHost.csproj --publisher manifest --output-path C:\Users\anvillan\AppData\Local\Temp\azd-provision450454868\apphost-manifest.json' , exit code: 0
2024/03/15 08:21:54 server.go:206: handled rpc LoadEnvironmentAsync in 10.3516191s
2024/03/15 08:21:54 server.go:107: handling rpc RefreshEnvironmentAsync
2024/03/15 08:21:54 project.go:120: Reading project from file 'C:\Users\anvillan\source\repos\AspireApp\azure.yaml'
2024/03/15 08:21:54 container.go:172: 'azd vs-server'command asked for envFlag, but envFlag was not included in cmd.Flags().
2024/03/15 08:21:55 command_runner.go:307: Run exec: 'dotnet msbuild C:\Users\anvillan\source\repos\AspireApp\AspireApp.AppHost\AspireApp.AppHost.csproj --getProperty:IsAspireHost' , exit code: 0
2024/03/15 08:21:55 server_service.go:95: [vWabD4wI/38= spinner] Analyzing Aspire Application (this might take a moment...)
[vWabD4wI/38= spinner] Analyzing Aspire Application (this might take a moment...)
2024/03/15 08:21:58 command_runner.go:307: Run exec: 'dotnet run --project AspireApp.AppHost.csproj --publisher manifest --output-path C:\Users\anvillan\AppData\Local\Temp\azd-provision1365460796\apphost-manifest.json' , exit code: 0
2024/03/15 08:21:58 command_runner.go:307: Run exec: 'C:\Users\anvillan.azd\bin\bicep.exe --version' , exit code: 0
2024/03/15 08:21:58 bicep.go:97: bicep version: 0.25.3
2024/03/15 08:21:58 bicep.go:111: using local bicep: C:\Users\anvillan.azd\bin\bicep.exe
2024/03/15 08:21:58 telemetry.go:107: Telemetry transmitted in 20.6612ms, statusCode: 400
2024/03/15 08:21:58 telemetry.go:107: Items accepted/received: 0/1
2024/03/15 08:21:58 telemetry.go:107: Errors:
2024/03/15 08:21:58 uploader.go:223: failed to transmit item C:\Users\anvillan.azd\telemetry\20240315T152154_0_1012758286.trn with non-retriable status code 400
2024/03/15 08:21:59 command_runner.go:307: Run exec: 'dotnet msbuild C:\Users\anvillan\source\repos\AspireApp\AspireApp.AppHost\AspireApp.AppHost.csproj --getProperty:IsAspireHost' , exit code: 0
2024/03/15 08:21:59 manager.go:201: delegating auth to external process
2024/03/15 08:21:59 command_runner.go:307: Run exec: 'dotnet --version' , exit code: 0
2024/03/15 08:21:59 dotnet.go:70: dotnet version: 8.0.300-preview.24122.6
2024/03/15 08:21:59 server_service.go:95: [vWabD4wI/38= spinner] Initialize bicep provider
[vWabD4wI/38= spinner] Initialize bicep provider
2024/03/15 08:22:01 command_runner.go:307: Run exec: 'C:\Users\anvillan.azd\bin\bicep.exe build C:\Users\anvillan\AppData\Local\Temp\azd-infra1624117193\main.bicep --stdout' , exit code: 0
2024/03/15 08:22:01 manager.go:201: delegating auth to external process
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0x929155]
goroutine 255 [running]:
github.com/azure/azure-dev/cli/azd/pkg/auth.(*RemoteCredential).GetToken(0xc00079a640, {0x13560c8, 0xc00017e410}, {{0x0, 0x0}, 0x0, {0xc000041fb0, 0x1, 0x1}, {0x0, ...}})
github.com/azure/azure-dev/cli/azd/pkg/auth/remote_credential.go:91 +0x775
github.com/azure/azure-dev/cli/azd/pkg/auth.EnsureLoggedInCredential({0x13560c8, 0xc00017e410}, {0x134ab40, 0xc00079a640}, 0xc0003024b0)
github.com/azure/azure-dev/cli/azd/pkg/auth/manager.go:178 +0x15b
github.com/azure/azure-dev/cli/azd/pkg/auth.(*multiTenantCredentialProvider).GetTokenCredential(0xc00030ade0, {0x13560c8, 0xc00017e410}, {0xc0007e0150, 0x24})
github.com/azure/azure-dev/cli/azd/pkg/auth/credential_providers.go:49 +0x105
github.com/azure/azure-dev/cli/azd/pkg/tools/azcli.(*UserProfileService).createGraphClient(0xc00031b1e0, {0x13560c8?, 0xc00017e410?}, {0xc0007e0150?, 0xc0007ad180?})
github.com/azure/azure-dev/cli/azd/pkg/tools/azcli/user_profile.go:41 +0x36
github.com/azure/azure-dev/cli/azd/pkg/tools/azcli.(*UserProfileService).GetSignedInUserId(0x24?, {0x13560c8, 0xc00017e410}, {0xc0007e0150?, 0x24?})
github.com/azure/azure-dev/cli/azd/pkg/tools/azcli/user_profile.go:55 +0x26
github.com/azure/azure-dev/cli/azd/pkg/azureutil.GetCurrentPrincipalId({0x13560c8, 0xc00017e410}, 0xc00017e410?, {0xc0007e0150, 0x24})
github.com/azure/azure-dev/cli/azd/pkg/azureutil/principal.go:20 +0x3f
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning.(*principalIDProvider).CurrentPrincipalId(0xc00031b220, {0x13560c8, 0xc00017e410})
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/current_principal_id_provider.go:43 +0x192
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep.(*BicepProvider).loadParameters(0xc00037f7a0, {0x13560c8, 0xc00017e410})
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:1644 +0x222
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep.(*BicepProvider).ensureParameters(0xc00037f7a0, {0x13560c8, 0xc00017e410}, {{0xc000617320, 0x5b}, {0xc00000bc67, 0x7}, 0xc000796ab0, 0xc000796b40, 0x0})
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:1939 +0xba
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep.(*BicepProvider).EnsureEnv(0xc00037f7a0, {0x13560c8, 0xc00017e410})
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:168 +0x290
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep.(*BicepProvider).Initialize(0xc00037f7a0, {0x13560c8, 0xc00017e410}, {0xc00034e540?, 0xc000273670?}, {{0x11807b9, 0x5}, {0xc0006205c0, 0x38}, {0x117fd1c, ...}, ...})
github.com/azure/azure-dev/cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:118 +0x199
github.com/azure/azure-dev/cli/azd/internal/vsrpc.(*environmentService).refreshEnvironmentAsync(0xc00017e320?, {0x13560c8, 0xc00017e410}, 0xc000514ba0, {0xc0005400a0, 0xa}, {0x4, {0x1358f68, 0xc00009abe0}})
github.com/azure/azure-dev/cli/azd/internal/vsrpc/environment_service_refresh.go:86 +0x2d8
github.com/azure/azure-dev/cli/azd/internal/vsrpc.(*environmentService).RefreshEnvironmentAsync(0xc00048c9c0, {0x13560c8, 0xc00017e410}, {{0xc000540070?, 0x10?}}, {0xc0005400a0, 0xa}, {0x4, {0x1358f68, 0xc00009abe0}})
github.com/azure/azure-dev/cli/azd/internal/vsrpc/environment_service_refresh.go:41 +0x97
github.com/azure/azure-dev/cli/azd/internal/vsrpc.(*environmentService).ServeHTTP.HandlerFunc3[...].func7({0x1358f68, 0xc00009abe0}, 0xc00032d158, {0x13566c8, 0xc000122880})
github.com/azure/azure-dev/cli/azd/internal/vsrpc/handler.go:186 +0x164
github.com/azure/azure-dev/cli/azd/internal/vsrpc.serveRpc.func1.1()
github.com/azure/azure-dev/cli/azd/internal/vsrpc/server.go:187 +0x673
created by github.com/azure/azure-dev/cli/azd/internal/vsrpc.serveRpc.func1 in goroutine 254
github.com/azure/azure-dev/cli/azd/internal/vsrpc/server.go:146 +0x48a

Example of response:
{ "token": "<access_token_value>", "expiresOn": "2024-03-14T22:27:44.528Z", "result": "success" }

There was a mismatch between the documentation in external-authentication.md and what the CLI (and VS Code, which also uses this protocol) did.  In the implementation we used the word status instead of result, but when I wrote the documentation after the fact, I accidently used result instead of status.
I updated the documentation as part of #3523 and also hardened the way we handle responses so if this field is not set we don't panic and instead return a better error about a malformed response.

authors: anvillan ellismg


text:
[Issue] [aspire] azd deploy removes custom domain bindings, can't work around after 1.9

Output from azd version
Run azd version and copy and paste the output here:
azd version 1.9.0 (commit 651394c3ddcfadff194d177f8b0ddf06fe3752bf)
Describe the bug
After running 'azd deploy' (locally or via CI/CD), custom domain bindings are removed from my container apps.
I was working around this using 'azd infra synth' as I've outlined here, with custom domains added to the output of the bicep files and referenced in the yaml files.
As of 1.9, the *.tmpl.yaml files have moved to the AppHost of the aspire project, and despite adding back in the yaml for the custom domain, it doesn't seem to be picking it up n working anymore.
To Reproduce
Deploy the aspire starter template. Set up a custom domain binding with a bring your own certificate on the deployed web app. Redeploy via azd having run azd infra synth. See domain binding disappear.
Expected behavior
Domain bindings should be retained, and ideally #1765 addressed so there's a clear way of doing this.
Environment
Information on your environment:
* .NET 8 Aspire preview 6
* IDE and version : Visual Studio 2022 10.0 Preview 7
Additional context
Add any other context about the problem here.

As of 1.9, the *.tmpl.yaml files have moved to the AppHost of the aspire project, and despite adding back in the yaml for the custom domain, it doesn't seem to be picking it up n working anymore.

@mip1983 I'm a little surprised about this, the intention was to just move the files to the infra folder under the app host (named by the resource name) but allow customization there - I'll take a look as to why that isn't working.
Regarding #1765, the long term direction is to be able to do these customizations in C# code in the app host, instead of having to fall back to infra synth to make customizations, but the story is still being flushed out - it's a key priority for us post the initial GA of Aspire - we want to get to a place where you have full access to the IaC within the aspire app host so you can make customizations instead of needing to run azd infra synth and edit.

@mip1983 I just did a quick experiment locally where I took the aspire starter app, ran azd infra synth followed by azd up and then modified the webfrontend.tmpl.yaml to add an extra environment variable (a simplification for me instead of setting up a custom domain and everything, but should still let us know if the changes were getting picked up or not) and after running azd deploy again I could see my changes were deployed.
You might consider running with --debug and re-directing stderr to a file like 2>debug.log.  We print a log message about what file we are loading and reading:
2024/05/08 13:01:30 service_target_dotnet_containerapp.go:186: using container app manifest from /Users/matell/dd/ellismg/AspireStarterChanges/AspireStarterChanges.AppHost/infra/webfrontend.tmpl.yaml

If we can't find the file, we log a message saying we are generating the infrastructure again from the manifest - I wonder if that's what is happening here?

Thanks @ellismg, I'll do some digging today with debug and see what I can see. I do have another instance of me and someone else finding it's not picking things up from yaml files in #3597, so maybe it is being generated again.

I've tried it running azd deploy locally with debug and my domain binding remains. I can see in the debug output:
2024/05/10 11:41:31 service_target_dotnet_containerapp.go:186: using container app manifest from
D:\source\ecoDriverAnalytics\ecoDriverAnalytics.Aspire\ecoDriverAnalytics.Aspire.AppHost\infra\ecodriver-analytics-api.tmpl.yaml
Which looks correct.
However, when I try it from Azure DevOps, the domain binding is removed again, the output on the console is:
2024/05/10 10:52:02 service_target_dotnet_containerapp.go:195: generating container app manifest from /home/vsts/work/1/s/.\ecoDriverAnalytics.Aspire\ecoDriverAnalytics.Aspire.AppHost\ecoDriverAnalytics.Aspire.AppHost.csproj for project ecodriver-analytics-api

@ellismg
Looking at the manifest path where it's not picked up the file running the DevOps pipeline, it looks a bit odd with the different slash directions, so I wondered if it was working locally on windows 11, but having trouble on the build agent which is ubuntu.
I've just tried updating my build pipeline to use 'windows_latest' rather than 'ubuntu_latest', and that seems to work, my app has deployed without losing the custom domain binding set in my yaml file.
Hopefully that helps you track this down, seems like a linux path issue.

@mip1983 , you can now use azd config set alpha.aca.persistDomains on to make azd to persist your domains w/o requiring to infra synth. See: https://github.com/Azure/azure-dev/pull/3955

Thanks @vhvb1989, I'll give that a try. Do you know if the problem with it not finding the manifest on the linux build agent has been resolved as well? Still using a windows agent at the moment.

/unresolve
Hi @vhvb1989, I've been running with 'azd config set alpha.aca.persistDomains on' configured in my build pipeline for a little while and it's generally worked until now.
Just did a build/release just now, one environment was fine but on production it took out the domain name binding for one of the container apps (certificate was still in place on the container apps environment and the binding was still there on the other container app).
Both are using a wildcard certificate uploaded to the container apps environment, both are using 'A' records and the domain names validate in the UI.

Thanks @vhvb1989, I'll give that a try. Do you know if the problem with it not finding the manifest on the linux build agent has been resolved as well? Still using a windows agent at the moment.

Still an issue :(

Marking this a complete for persisting the custom domains.
We can use https://github.com/Azure/azure-dev/issues/3891 for tracking the CI/CD pipeline path issue.


text:
[Issue] azd init should ignore some files

When a user runs azd init it copies all files from the repo.  Sometimes we don't want that.
The template author may want a CONTRIBUTING.md file in the repo or a file in the .github folder for the template authoring experience.  But doesn't want the user to have that file when they are using the template.
Examples of files that we don't want to be copied when initialization a template, but should be in the repo.
https://github.com/Azure-Samples/agent-openai-python-prompty/blob/main/CONTRIBUTING.md
https://github.com/Azure-Samples/agent-openai-python-prompty/blob/main/CHANGELOG.md
https://github.com/Azure-Samples/agent-openai-python-prompty/blob/main/.github/CODE_OF_CONDUCT.md
https://github.com/Azure-Samples/agent-openai-python-prompty/blob/main/.github/workflows/azure-dev-validation.yaml
Suggestion:
Add a .azdignore file to the root of the repo that contains files/paths that azd should ignore during the init.

What about git clone , a codespace or manual donwload?   There would be an inconsistency between acquiring templates with azd init v/s other acquisition methods.
Here's an alternative:

Create a branch-name convention (similar to the gh-pages convention).

Tell users they can publish a branch named azd-template
When azd init runs, it will check if azd-template branch exists and if yes, will use that branch instead of main branch
Template author can then lock an azd-template ready version and keep working/making changes on main.
We can create gh-action for publishing the azd-template branch and use the .azdignore for it.

And strategy like this would enable folks to start a codespace from the azd-template branch to use and own the template, or from main branch to contribute to the template itself (like updating the .azdignore files)

As a template author I do not want to manage two different branches - too much overhead.

We can only control how azd itself acquires templates.  I think this feature would be helpful for template authors that want to exclude files during the azd init process.
We know if developers manually acquire the template that the azd ignore file will not be processed.
One other idea is that any additional azd init call on a template after clone will check for the existence of the file and clean any effected files.

Seeing that PR #4146 is closed in favor of PR #4258 and its corresponding issues #1039 #4215. Marking this issue as not planned. Feel free to open if you think otherwise @jongio


text:
Add azd package to context menus and command palette

Closes #1839

VSCode Extension Installation Instructions

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

VSCode Extension Installation Instructions

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

VSCode Extension Installation Instructions

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

authors: azure-sdk bwateratmsft


text:
[Feature Request] 'az devops service-endpoint share' command

Is your feature request related to a problem? Please describe.
I can create Azure DevOps service endpoints but because the secrets are stored inside the endpoint, I do not want to create an endpoint in each project but instead use the built-in sharing functionality of service endpoints in Azure DevOps. Currently I have to call the REST API for that: https://docs.microsoft.com/en-us/rest/api/azure/devops/serviceendpoint/endpoints/share service endpoint?view=azure-devops-rest-6.0
Describe the solution you'd like
Command: az devops service-endpoint share
Parameters:

--id Id of the service endpoint to share. Alternatively --endpoint-name and --project-name parameters could be supplied for better usability
--target-project-name Name of the project where shared endpoint will be created
--target-name Name of the shared endpoint

This would be a great feature! Can't wait to use it!

authors: bergmeister kewljedi

repo: Azure/azure-devops-cli-extension


text:
Get-MsolGroupMember - duplicate syntax example and how to retrieve devices?

https://learn.microsoft.com/en-us/powershell/module/msonline/get-msolgroupmember?view=azureadps-1.0
Hi, looks like there's a duplicate syntax example on the page.
Also, the doco states that this cmdlet retrieves "members can be either users or groups." only.
I'm having a hard time finding a way to retrieve devices/computers from an msol group. Assuming it's possible? Perhaps a pointer on that page would help.
Cheers

Hi @SpitFire-666, thanks for reaching out.
The syntax has a small different on the parameter variants (MaxResults vs All).
Also, to get device group members, I would recommend that you use the Microsoft Graph PowerShell module cmdlet which has this supported. Please note that the MSOnline module is planned for deprecation and we are asking users to upgrade to the new module replacing MSOnline.

repo: Azure/azure-docs-powershell-azuread


text:
What is the Azure Functions Team's Plan with regards to .NET 6?

I saw a reference to Azure Functions 4.0 in another issue. Will AF 4.0 coincide with .NET 6? If so, where does that leave the .NET 5.0 work present in this repo?

Yes. Public preview for v4 will be announced very very soon. It'll have preview support for .NET 6. You have the option of both in-process and isolated process for .NET 6 on v4.
V4 is expected to be GA at the same time as .NET 6 LTS GA.
The isolated model provided by the SDK in this repo can be used with .NET 5 (in v3) and .NET 6 (v4). It'll also be the path forward for .NET 7 and beyond.

Awesome, thank you.

repo: Azure/azure-functions-dotnet-worker


text:
re-adding project reference

Re-adding the project ref that I had removed earlier. It was causing issues on official builds.
PS @kshyju -- your comment asking why I did this was a good one :-)

/check-enforcer evaluate


text:
Android: quickstart refresh all items

Hi,
I created an Easy Table called ToDoItem and  I run the quickstart mobile app in Android Studio
The app seems to be working OK  with Azure Easy Table, except for the fact that does not filter any data when I try to query data from the table.
It seems the where clause is simple ignored even though I've data in the Easy table with rows set to true in field completed .
Any idea? Is it necessary to edit the script of the easy tables in azure?
return mToDoTable.where().field("complete").
eq(val(false)).execute().get();
Thank you in advance.
Fátima Pereira

Hi @ProfFatimaPereira, thanks for reaching out. So in the API doc there is no val() would that solve the issue:
List<ToDoItem> result = mToDoTable
    .where()
    .field("complete").eq(false)
    .execute()
    .get();

Hi @ProfFatimaPereira,
we haven't heard from you in a while so I'm closing this issue.
Feel free to reopen this issue if it isn't resolved or you have additional questions.

authors: MatkovIvan ProfFatimaPereira clpolet

repo: Azure/azure-mobile-apps-quickstarts

license_source: bigquery


text:
[Cognitive Services] Model validation fails with errors

Validating "examples" and "x-ms-examples" in /Users/Veronica/github/openapi-validation-tools/arm-cognitiveservices/swagger/cognitiveservices.json:
Operation: CognitiveServicesAccounts_GetProperties
example-in-spec
RESPONSE_BODY_VALIDATION_ERROR: Found errors in validating the example for response with statusCode "200" in operation "CognitiveServicesAccounts_GetProperties".
InnerErrors:
1. code: INVALID_TYPE
message: Expected type object but found type string
path:
description: Cognitive Services Account is an Azure resource representing the provisioned account, its type, location and SKU.

Example in spec should be specified as json and not string.
From swagger:
        "responses": {
          "200": {
            "description": "The resource provider should return 200 (OK) to indicate that the operation completed successfully.\nFor a detailed explanation of each field in the response body, please refer to the request body description in the PUT resource section. The only GET specific properties are “name,” “type” and “id.”\nField\tDescription\nKind\trequired.  String.\n\tThe API set for this API account. It can be \n\t· a single API, for example: Face API, Vision API, Speech API. \n\ta bundle of APIs:  Face + Speech, Vision + Emotion, etc.\nsku.name\tRequired.\n\tThe pricing tier/plan of this API. Could be: \n\tF0 - Free\n\tB0 - Basic\n\tS0 - Standard\n\tP0 - Premium\n",
            "schema": {
              "$ref": "#/definitions/CognitiveServicesAccount"
            },
            "examples": {
              "application/json": "{\n  “id”: “/subscriptions/{id}/resourceGroups/{group}/providers/{rpns}/{type}/{name}”,\n  “name”: “{name}”,\n  “type”: “Microsoft.CognitiveSerices/accounts”,\n  \"location\": \"North US\",\n  \"tags\": {\n    \"key1\": \"value 1\",\n    \"key2\": \"value 2\"\n   },\n  \"kind\" : \"resource kind\",\n   \"sku\": {\n\t    \"name\": \"sku code\"\n\t} \n  “etag”: “00000000-0000-0000-0000-000000000000”,\n  \"properties\": { }\n}"
            }
          },

> Operation: CognitiveServicesAccounts_ListByResourceGroup
	> example-in-spec
		> INTERNAL_ERROR: An internal error occured while validating the example for response with statusCode "200" in operation "CognitiveServicesAccounts_ListByResourceGroup".
		> { code: 'INTERNAL_ERROR',

message: 'An internal error occured while validating the example for response with statusCode "200" in operation "CognitiveServicesAccounts_ListByResourceGroup".',
innerErrors: [ [TypeError: obj must be an Array or an Object] ] }
Definition in swagger for response object only defines a value array, doesn't contain a next link, which is listed in the example from the spec.
Also example should be specified as a json object, not a string.
From swagger:
        "responses": {
          "200": {
            "description": "The resource provider should return 200 (OK) to indicate that the operation completed successfully. For other errors (e.g. internal errors) use the appropriate HTTP error code.\nThe nextLink field is expected to point to the URL the client should use to fetch the next page (per server side paging). This matches the OData guidelines for paged responses here. If a resource provider does not support paging, it should return the same body (JSON object with “value” property) but omit nextLink entirely (or set to null, *not* empty string) for future compatibility.\nThe nextLink should be implemented using following query parameters:\n· skipToken: opaque token that allows the resource provider to skip resources already enumerated. This value is defined and returned by the RP after first request via nextLink.\n· top: the optional client query parameter which defines the maximum number of records to be returned by the server.\nImplementation details:\n· NextLink may include all the query parameters (specifically OData $filter) used by the client in the first query. \n· Server may return less records than requested with nextLink. Returning zero records with NextLink is an acceptable response. \nClients must fetch records until the nextLink is not returned back / null. Clients should never rely on number of returned records to determinate if pagination is completed.",
            "schema": {
              "$ref": "#/definitions/CognitiveServicesAccountListResult"
            },
            "examples": {
              "application/json": "{\n  “value”: [\n    {\n        “id”: “{url to resource 1}”,\n        “name”: “Name1”,\n        “type”: “Microsoft.CognitiveServices/accounts”,\n        \"location\": \"North US\"    \n        \"kind\" : \"resource kind\",\n        \"sku\": {\n\t        \"name\": \"sku code\"\n\t  }, \n        \"etag\": \"00000000-0000-0000-0000-000000000000\",\n        \"properties\": { }\n    },\n    {\n        “id”: “{url to resource 2}”,\n        “name”: “Name2”,\n        “type”: “Microsoft.CognitiveServices/accounts”,\n        \"location\": \"North US\",\n        \"kind\" : \"resource kind\",\n        \"sku\": {\n\t        \"name\": \"sku code\"\n\t  }, \n        \"etag\": \"00000000-0000-0000-0000-000000000000\",\n        \"properties\": { }\n    }\n  ],\n  “nextLink”: “{originalRequestUrl}?$skipToken={opaqueString}”\n}"
            }
          },

Swagger model definition:
    "CognitiveServicesAccountListResult": {
      "properties": {
        "value": {
          "readOnly": true,
          "type": "array",
          "items": {
            "$ref": "#/definitions/CognitiveServicesAccount"
          },
          "description": "Gets the list of Cognitive Services accounts and their properties."
        }
      },
      "description": "The list of cognitive services accounts operation response."
    },

@kirthik, you can assign this to me.
@veronicagg, could you tell me what tool you were using to scan the swagger and got these errors? And could you give me some quick hints on how to fix it?

@veronicagg , I guess you were using node cli.js validate-example? I get different set of errors though:
error: Found errors in validating the response with statusCode "200" for example in spec for operation "CognitiveServicesAccounts_GetProperties".:
{ code: 'RESPONSE_VALIDATION_ERROR',
message: 'Found errors in validating the response with statusCode "200" for example in spec for operation "CognitiveServicesAccounts_GetProperties".',
innerErrors:
[ { code: 'INVALID_RESPONSE_BODY',
errors:
[ { code: 'INVALID_TYPE',
params: [ 'object', 'string' ],
message: 'Expected type object but found type string',
path: [],
description: 'Cognitive Services Account is an Azure resource representing the provisioned account, its type, location and SKU.' } ],
message: 'Invalid body: Expected type object but found type string',
path: [] } ] }

@felixwa errors may have changed a bit, since we're actively working on the tool, feel free to look at one of the latest: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211069098#L1056
and linter validations: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211069096#L3330 (you can search for cognitiveservice specs in the log to see all failures).

@felixwa I think in particular for this error: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211069098#L1056 you'd want to turn the example in this line https://github.com/Azure/azure-rest-api-specs/blob/master/arm-cognitiveservices/2016-02-01-preview/swagger/cognitiveservices.json#L223  into an object instead of surrounding it with "" (which makes it be a string, see http://swagger.io/specification/#exampleObject)

@veronicagg , this issue has been fixed with the new version (2017-04-18) of swagger file. Can you close this one or you need me to fix the old version too (2016-02-01-preview)?

@felixwa sounds good, thanks!

authors: felixwa veronicagg

repo: Azure/azure-rest-api-specs


text:
Adjust command names for backward compatibility with GA version

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

[ ] 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
Adding a new service

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

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

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

Please follow the link to find more details on PR review process.

/azp run automation - sdk

authors: AutorestCI sotaneja


text:
[Hub Generated] Review request for Microsoft.Confluent to add version preview/2020-03-01-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
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?

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
Adding a new service

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

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

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

Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run automation - sdk

/azp run unifiedPipeline

hi @ruowan , as of now we are not planning to support CLI, so is it mandatory to pass the SDK Cliextension task?

The PR is to pull everything from RPSaaSMaster of private repo to public repo for service release.  Everything in RPSaaSMaster should already been reviewed and approved by ARM RPSaaS team.

authors: AutorestCI alluri02 josefree


text:
Adding Azure CLI build configuration for Quota  APIs

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
[ ] new API version
[ x] update existing version for new feature - Adding Azure CLI configuration for publishing.
[ ] 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.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
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)
[ x] SDK of Python
[ ] SDK of Java
[x ] SDK of Js
[ x] SDK of Go
[ x] PowerShell
[x ] CLI
[ ] Terraform
[ ] No, no need to refresh 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

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

@JustinConway Please point me to readme.cli.md commands and formats.
I tries to test the CLI, but got following error:
TypeError: init() got multiple values for argument 'base_url'
How do I resolve this error?
Thanks.

Please review the PR. The CLI generation Issue is fixed.
We need to release the CLI package ASAP.
Thanks.

Please let me know, if anything else is needed from myside?
Can we merge the PR?
Thanks.

merged

What's the process for Azure Powershell  release?

authors: qiaozha rahuls-microsoft


text:
[Hub Generated] Review request for Microsoft.CostManagement to add version stable/2019-11-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Please ensure to add changelog with 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
[x] 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.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[x] SDK of Python
[x] SDK of Java
[x] SDK of Js
[x] SDK of Go
[x] PowerShell
[x] CLI
[ ] Terraform
[ ] 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.
[ ] 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

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

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

The purpose of this PR is just to improve description of the Query Filter property for better user guidance.

Hi, @weidongxu-microsoft, would you know how long it usually takes for the changes to reach the SDKs? I'm looking at the CLI docs to be updated with this PR:
https://docs.microsoft.com/en-us/cli/azure/costmanagement?view=azure-cli-latest#az_costmanagement_query-optional-parameters

You probably need to send request for python https://portal.azure-devex-tools.com/tools/request-api-release and then contact CLI, or directly contact CLI team.

authors: jochav weidongxu-microsoft


text:
[Hub Generated] Public private branch 'yuwzho/appplatform-2021-08-01-preview'

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
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 langauge 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 copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

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

The PR is created based on the updates in the private branch. The updates in the PR has already been reviewed and approved with this PR Azure/azure-rest-api-specs-pr/4120

/azp run

@ArcturusZhang @msyyc , the cross version breaking change was approved in associated PR at private repo. Can you approve from SDK perspective?


text:
Remove enum for category properties

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
[X] 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):

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

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

We have approval for the breaking change (attached)

https://msazure.visualstudio.com/One/_workitems/edit/16986590


text:
vmss: support for passing a health probe to update

The Update struct for a Virtual Machine Scale Set doesn't currently expose the 'HealthProbe' block required when updating a VMSS with an Automatic/Rolling Upgrade Policy using the Update method:
{
	"properties": {
		"upgradePolicy": {
			"mode": "Rolling",
			"rollingUpgradePolicy": {
				"maxBatchInstancePercent": 21,
				"maxUnhealthyInstancePercent": 22,
				"maxUnhealthyUpgradedInstancePercent": 23,
				"pauseTimeBetweenBatches": "PT30S"
			}
		},
		"virtualMachineProfile": {
			"storageProfile": {
				"imageReference": {
					"publisher": "Canonical",
					"offer": "UbuntuServer",
					"sku": "18.04-LTS",
					"version": "latest"
				}
			},
			"networkProfile": {
				"networkInterfaceConfigurations": [{
					"name": "example",
					"properties": {
						"primary": true,
						"enableAcceleratedNetworking": false,
						"dnsSettings": {
							"dnsServers": []
						},
						"ipConfigurations": [{
							"name": "internal",
							"properties": {
								"subnet": {
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/virtualNetworks/acctestnw-190928080303507041/subnets/internal"
								},
								"primary": true,
								"privateIPAddressVersion": "IPv4",
								"applicationGatewayBackendAddressPools": [],
								"applicationSecurityGroups": [],
								"loadBalancerBackendAddressPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/backendAddressPools/test"
								}],
								"loadBalancerInboundNatPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/inboundNatPools/test"
								}]
							}
						}],
						"enableIPForwarding": false
					}
				}]
			}
		}
	}
}

which currently returns:
{
	"error": {
		"code": "BadRequest",
		"message": "Rolling Upgrade mode is not supported for this Virtual Machine Scale Set because a health probe or health extension was not provided."
	}
}

This PR adds the HealthProbe block to the Update object, which when specified allows the Update to complete successfully:
{
	"properties": {
		"upgradePolicy": {
			"mode": "Rolling",
			"rollingUpgradePolicy": {
				"maxBatchInstancePercent": 21,
				"maxUnhealthyInstancePercent": 22,
				"maxUnhealthyUpgradedInstancePercent": 23,
				"pauseTimeBetweenBatches": "PT30S"
			}
		},
		"virtualMachineProfile": {
			"storageProfile": {
				"imageReference": {
					"publisher": "Canonical",
					"offer": "UbuntuServer",
					"sku": "18.04-LTS",
					"version": "latest"
				}
			},
			"networkProfile": {
				"healthProbe": {
					"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/probes/acctest-lb-probe"
				},
				"networkInterfaceConfigurations": [{
					"name": "example",
					"properties": {
						"primary": true,
						"enableAcceleratedNetworking": false,
						"dnsSettings": {
							"dnsServers": []
						},
						"ipConfigurations": [{
							"name": "internal",
							"properties": {
								"subnet": {
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/virtualNetworks/acctestnw-190928080303507041/subnets/internal"
								},
								"primary": true,
								"privateIPAddressVersion": "IPv4",
								"applicationGatewayBackendAddressPools": [],
								"applicationSecurityGroups": [],
								"loadBalancerBackendAddressPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/backendAddressPools/test"
								}],
								"loadBalancerInboundNatPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/inboundNatPools/test"
								}]
							}
						}],
						"enableIPForwarding": false
					}
				}]
			}
		}
	}
}

which then returns:
{
	"name": "acctestvmss-190928080303507041",
	"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Compute/virtualMachineScaleSets/acctestvmss-190928080303507041",
	"type": "Microsoft.Compute/virtualMachineScaleSets",
	"location": "westeurope",
	"tags": {},
	"sku": {
		"name": "Standard_F2",
		"tier": "Standard",
		"capacity": 0
	},
	"properties": {
		"singlePlacementGroup": true,
		"upgradePolicy": {
			"mode": "Rolling",
			"rollingUpgradePolicy": {
				"maxBatchInstancePercent": 21,
				"maxUnhealthyInstancePercent": 22,
				"maxUnhealthyUpgradedInstancePercent": 23,
				"pauseTimeBetweenBatches": "PT30S"
			}
		},
		"virtualMachineProfile": {
			"osProfile": {
				"computerNamePrefix": "acctestvmss-190928080303507041",
				"adminUsername": "adminuser",
				"linuxConfiguration": {
					"disablePasswordAuthentication": false,
					"ssh": {
						"publicKeys": []
					},
					"provisionVMAgent": true
				},
				"secrets": [],
				"allowExtensionOperations": true,
				"requireGuestProvisionSignal": true
			},
			"storageProfile": {
				"osDisk": {
					"createOption": "FromImage",
					"caching": "ReadWrite",
					"writeAcceleratorEnabled": false,
					"managedDisk": {
						"storageAccountType": "Standard_LRS"
					}
				},
				"imageReference": {
					"publisher": "Canonical",
					"offer": "UbuntuServer",
					"sku": "18.04-LTS",
					"version": "latest"
				}
			},
			"networkProfile": {
				"healthProbe": {
					"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/probes/acctest-lb-probe"
				},
				"networkInterfaceConfigurations": [{
					"name": "example",
					"properties": {
						"primary": true,
						"enableAcceleratedNetworking": false,
						"dnsSettings": {
							"dnsServers": []
						},
						"enableIPForwarding": false,
						"ipConfigurations": [{
							"name": "internal",
							"properties": {
								"primary": true,
								"subnet": {
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/virtualNetworks/acctestnw-190928080303507041/subnets/internal"
								},
								"privateIPAddressVersion": "IPv4",
								"loadBalancerBackendAddressPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/backendAddressPools/test"
								}],
								"loadBalancerInboundNatPools": [{
									"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/acctestrg-190928080303507041/providers/Microsoft.Network/loadBalancers/acctestlb-190928080303507041/inboundNatPools/test"
								}]
							}
						}]
					}
				}]
			},
			"diagnosticsProfile": {
				"bootDiagnostics": {
					"enabled": false
				}
			},
			"priority": "Regular"
		},
		"provisioningState": "Updating",
		"overprovision": false,
		"doNotRunExtensionsOnOverprovisionedVMs": false,
		"uniqueId": "9e2399ba-dc3a-4307-bef5-d2a423a50ecd"
	}
}

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Can one of the admins verify this patch?

@ArcturusZhang sorry to ping you - would you mind tagging this "Service Team" so the Compute team could take a look? This is unfortunately blocking a couple of new resources we're trying to ship

authors: AutorestCI azuresdkci tombuildsstuff


text:
Lint 0605

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. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
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.

/azp run automation - sdk

/azp run

authors: AutorestCI tiramisuq


text:
Fix esp32 broken link

#1853

/azp run c - client - tests

/check-enforcer override

repo: Azure/azure-sdk-for-c


text:
Change the order of credentials in the DefaultAzureCredential

@scottaddie: "Wow the order of credentials was determined in the C++ DefaultAzureCredential. We typically put the dev tool credentials at the very end of the chain. We see Managed Identity as more important."
@antkmsft: "The order is the one I presented to the C++ team initially, but you are right, we should try to change it. Initially, I think, ManagedIdentityCredential was at the end because unlike other languages, our ManagedIdentityCredential does not probe the IP address yet, and just tries to get the token. But still, that should not be the factor that prevents it from being in the middle of the chain. The good thing is that everywhere in documentation we say that although we are documenting the order of credentials, we may change their order in the future, and that would not be considered a breaking change. So let me to open an issue to change the order, and update the docs and the SVG."

Here are the order that other languages are following:

Environment
WorkloadIdentity
ManagedIdentity
AzureCli/Dev-specific credentials like IntelliJ/etc.

https://github.com/Azure/azure-sdk-for-go/blob/e7968b534c61da1e38a683e21ac690deb14833c7/sdk/azidentity/default_azure_credential.go#L46C1-L51
https://github.com/Azure/azure-sdk-for-java/blob/26bd513d93b5301797d7127cf4f6f55ae81c47c6/sdk/identity/azure-identity/src/main/java/com/azure/identity/DefaultAzureCredential.java#L19-L35
https://github.com/Azure/azure-sdk-for-net/blob/a932f53e2fc200cee443614a0bf991b02b518055/sdk/identity/Azure.Identity/src/Credentials/DefaultAzureCredential.cs#L17-L28

Re-opening https://github.com/Azure/azure-sdk-for-cpp/pull/5156 until we fix the responsiveness of ManagedIdentityCredential on failure.
https://github.com/Azure/azure-sdk-for-cpp/issues/4952

authors: ahsonkhan antkmsft

repo: Azure/azure-sdk-for-cpp


text:
Docs: link to root Getting Started section from Storage's readme

Inspired by #2386 and #2387, see also #2296.

@Jinming-Hu, I applied your suggestions


text:
[azservicebus] RPC and retry logic problems

Currently troubleshooting an issue with a customer where it appears there are some weaknesses in our error handling with RPC calls (these are used for things like RenewLock, PeekMessages, or backup message settlement).
As part of this there's another potential issue for this customer where early cancellation could potentially interrupt connection/link recovery, which is more problematic for RPC, than for other code paths like sending and receiving.

This was fixed with https://github.com/Azure/azure-sdk-for-go/pull/23400

repo: Azure/azure-sdk-for-go


text:
[AutoPR portal/resource-manager] Add Swagger and Examples for shared dashboards to Azure

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/5811

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/4721


text:
fix a problem that token generated from storage explorer, without spr in query, is using http

the go sdk checks for spr parameter, but when it comes to tokens generated from Storage Explorer, there is no such spr parameter, and the sdk get empty string for spr. so after compares empty string and "https", it sets useHTTPS to false, while it actually needs to set it to true
this patch just altered that and add a test case. the test account has been deleted to prevent malformed requests but the test case should not be influenced
it's my first PR here. tell me if there is something need to be done and i'll do it.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: jeffguorg sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Can one of the admins verify this patch?

Hello!  This PR is merging master into latest which is dragging in a bunch of extra changes.  Can you please create a new PR from your fork of latest (or a branch off of latest) into upstream/latest?

Hi, i just opened another PR and I'm closing this one. sorry for my mistake

authors: azuresdkci jeffguorg jhendrixMSFT msftclas


text:
Brief Question - Is this scenario possible?

Query/Question
I want to know if this scenario is possible via this Azure SDK -
Given a Spring Boot Java app on an Azure App Service with a provisioned Managed Identity, can the Spring Boot app utilise that Managed Identity to connect to a SQL Server + Database (assuming of course that the MI has been given appropriate access)?
If so, is there any documentation on this, if not, is this a planned feature or is it not feasible?
Why is this not a Bug or a feature Request?
Purely meant to be a question about existing functionality.

https://docs.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15
@connor-miller-kr  would you try this ?

authors: connor-miller-kr stliu

repo: Azure/azure-sdk-for-java


text:
[QUERY] How to implement proper paging API using azure spring data cosmos SDK?

Query/Question
We need to develop a paging query REST API to support a UI datagrid component. The datagrid shows data in page of 100 at a time. User can click next/pre page button to show the next or previous page. They can also enter a specific page # to jump to the corresponding page of data.
We have looked at the paging query support from azure spring data cosmos sdk and documentation. But it doesn't clearly indicate how we can use it to achieve our requirement.
We define the following query method in Repository class.
 Page<DataEntity> findByPartitionKey(       String partitionKey,       Pageable pageable);
We then make the query in domain service like below.
 Sort sort = Sort.by(Order.asc("key"));     CosmosPageRequest pageRequest =         CosmosPageRequest.of(page, pageSize, null, sort);     Page<DataEntity> page =         repository.findByPartitionKey(partitionKey, pageRequest);
But this query always return the first page no matter which page number we provide.
We found the following documentation and example from Microsoft page.

Supports Spring Data Pageable, Slice and Sort.
Based on available RUs on the database account, cosmosDB can return items less than or equal to the requested size.
Due to this variable number of returned items in every iteration, user should not rely on the totalPageSize, and instead iterating over pageable should be done in this way.

`private List getUsersByLastName(String lastName, int pageSize) {
final CosmosPageRequest pageRequest = new CosmosPageRequest(0, pageSize, null);
Slice<User> slice = repository.getUsersByLastName(lastName, pageRequest);
List<User> content = slice.getContent();
while (slice.hasNext()) {
    Pageable nextPageable = slice.nextPageable();
    slice = repository.getUsersByLastName(lastName, nextPageable);
    content.addAll(slice.getContent());
}
return content;

}`
From this and other information I collected, it seems to me: First, the paging API doesn't guarantee to return the required page size of documents. I need to iterate over nextPageable until I get enough number of data for requested page size. Second, I can't request any page without starting from page 0 and then use slice.nextPageable() to query the next page. This doesn't work well with our ui and API requirement, since we need to get a fixed size of page of data and we need to be able to get any page of data without needing to request page sequentially.
Do you have any suggestion how we can implement our specific paging API requirement?
Why is this not a Bug or a feature Request?
A clear explanation of why is this not a bug or a feature request?
Setup (please complete the following information if applicable):

OS: Windows or Linux
IDE: Eclipse
Library/Libraries: com.azure.spring:azure-spring-boot-starter-cosmos:3.6.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[X ] Query Added
[ X] Setup information Added

@backwind1233 could you please follow up with @zhoujia1974?

Hi @kushagraThapar, could you please follow up with this?

@kushagraThapar How do I get a continuation token back when I use OFFSET LIMIT? My custom query method is like below. Do I need to change the return type to Page and also add a Pageable parameter like the custom query method 2? But if I do use a pageable together with OFFSET LIMIT query, will the pageable conflict with OFFSET LIMIT? I would assume Cosmos SDK will insert some query fragment based on the pageable parameter and the query fragment may interfere with OFFSET LIMIT?
Before paging.
@Query(       "SELECT * FROM c WHERE c.partitionKey = @partitionKey ORDER BY c.key OFFSET @offset LIMIT @limit")   List<SomeEntity> findLineItems(       @Param("partitionKey") String partitionKey,       @Param("offset") int offset,       @Param("limit") int limit);
After paging.
@Query(       "SELECT * FROM c WHERE c.partitionKey = @partitionKey ORDER BY c.key OFFSET @offset LIMIT @limit")   Page<SomeEntity> findLineItems(       @Param("partitionKey") String partitionKey,       @Param("offset") int offset,       @Param("limit") int limit,       Pageable pageable);

@zhoujia1974 - To get the continuation token and rely on OFFSET and LIMIT queries, its better to use the Cosmos Java SDK to handle continuation token.
Instead of using spring query annotation, it is best to use Java SDK query APIs, which can help you retrieve continuation token. You can get cosmosClient through applicationContext in spring cosmos, and then call the Java SDK query APIs with the OFFSET and LIMIT query and use the continuation token returned in the response.
Spring Data doesn't have a good pagination mechanism as I explained above. So your best bet might be to use the Java SDK query API.

@zhoujia1974 we have recently improved on this area with a few PR's but I believe this one will help you the most and will go out with our next release: https://github.com/Azure/azure-sdk-for-java/pull/30276
You should be able to see from the newly added unit tests how to achieve your goals. You can jump to the next/pre page via continuation token usage and you can now jump to any page you choose.


text:
Move readme from starter module into it's content module for azure-spring-cloud-starter-cache

Parent issue: #23938

the starter has been removed from repo.


text:
[BUG] Update azure-communication-email as it contains vulnerabilities

Describe the bug
The current relaese of azure-communication-email 1.0.2
Uses io.netty:netty-codec-http2:4.1.89.Final which has the reported vulnerability https://nvd.nist.gov/vuln/detail/CVE-2023-44487
How reliable is this library at all? I doesn't seem that there is any regular maintaining to ensure new version of dependencies etc.

wrong version


text:
mgmt, aks, bug fix on KubernetesCluster update

Description
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request 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 more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

The reason we had getAgentPoolInner is that

update/remove of agent pool can be done in PATCH to cluster endpoint
but add of agent pool cannot be done in cluster, it had to be a PUT to agent pool endpoint (one layer deeper than cluster)


text:
JavaCheckStyleRule: Package Naming

Add a CheckStyle Rule for PackageName.
Issue: CheckStyle: Pacakage Naming (Start and Patterns) #3268

Can one of the admins verify this patch?

Did this test turn up any new failures in our codebase?

no failures.

Did you test against other illegal package names? e.g. no characters other than lower-case 'a' through 'z', no spaces, no underscores, etc.

"no characters other than lower case a - z" is different than the notes required. Current regular expression is only check not A-Z, underscore, hyphen,  I will edited the regular expression.
Note:
The regular expression:"^(?=.{9,80}$)((com.microsoft.azure|com.azure)(.[^A-Z_-]{1,20})*)+$"
(?=.{9,80}) means the total length packages name is between 9 to 80 characters.
^(com.microsoft.azure|com.azure) means the package name have to start with either com.microsoft.azure or com.azure.

modify the current partial of regular expression from (.[^A-Z_-]{1,20})* to  (.[a-z]{1,20})*) will meet the requirement that "no character other than lower case 'a' through 'z' "

Looks good. Please improve the comment to clarify all the rules being enforced, and then this can be merged.

the new comment is updated. Does it looks good?

authors: JonathanGiles azuresdkci mssfang


text:
Increment versions for recoveryservices releases

Increment package versions for recoveryservices releases

API change check
API changes are not detected in this pull request.


text:
[BUG] Set secret operation of the Key Vault Secrets Client overrides the content type of the secret with application/json

Description

Fixes sync and async implementations to use the contentType value set by the caller in the payload
Adds entry to changelog

Resolves https://github.com/Azure/azure-sdk-for-java/issues/37019
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request 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 more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

Hi,
I wasn't sure how to modify the test data for the mock/stub used. Could you please let me know how to add a new assertion?
Thank you in advance!

@nagyesta The root cause analysis is spot on and the proposed changes look good on principle, but they required a bit more tinkering to keep things working as they used to before the latest release. Additionally, there were other setSecret... and updateSecret... methods with this issue to update as well. I took the liberty of creating a PR with these changes against your branch to keep your authorship for when we eventually merge into main, feel free to review it and merge into your branch when you get a chance.

We auto-generate some of the code found in this library and I'm not 100% sure yet about if we'll need to account for that with these changes. If that's the case I will take care of it on a separate PR.

Hi @vcolin7 ,
thank you very much for the PR and apologies for missing those! I have merged your changes into my branch.
Please let me know in case anything comes up, I am happy to help!

@nagyesta No worries, thank you for opening the issue and taking things in the right direction! I added a couple of things I missed in my original PR and re-recorded our tests (we use test recordings to avoid testing against the service every time).


text:
Increment versions for core releases

Increment package versions for core releases

API change check
API changes are not detected in this pull request.


text:
[Service Bus] Amqp Message Properties and Header defined both in Service Bus and core-amqp

We now export AmqpMessageProperties and AmqpMessageHeader from the Service Bus package
Similar things are exported from @azure/core-amqp as well.
We shouldnt need to duplicate these.
Consider re-using the ones from @azure/core-amqp

Done with #12091

repo: Azure/azure-sdk-for-js


text:
[Service Bus] Meaningful names for .env variabes

https://github.com/Azure/azure-sdk-for-js/pull/1202#issuecomment-463352341

The names ARM_SERVICEBUS_CLIENT_ID, ARM_SERVICEBUS_TENANT_ID, ARM_SERVICEBUS_SECRET are misleading.
Initially, those names made sense when we used them only for creation/deletion of entities using arm-servicebus  -> #1164
Now, we are using the same variables for creating the namespace using createFromAadTokenCredentials -> #1202 (arm-servicebus is not used here)

Proposing to change them to AAD_CLIENT_ID, AAD_TENANT_ID, AAD_SERVICEBUS_SECRET

Do you want to do the rename just for the AAD test or for create/delete resources as well?

The same AAD_CLIENT_ID, AAD_TENANT_ID, AAD_SERVICEBUS_SECRET can be used for both the creation/deletion - cleanup and create namespace from AADTokenCreds

If it is just about re-using the values, then why create a new issue for this?
Why not tackle this as part of #1202?

Can be done.

We would be updating testUtils.
creation-deletion PR needs to be updated as well as that is the only reference we have for these env vars(may be helpful in creating documetation).

Initial thought was that we are doing many things at once and wanted to do this after the createFromAadTokenCredentials.

Updated the PR https://github.com/Azure/azure-sdk-for-js/pull/1164/#Update-2
564fdda - Updated testUtils as part of #1202

Closing this issue.

authors: HarshaNalluru ramya-rao-a


text:
[core] - core-tracing should not re-declare OTel interfaces at all

Audit and remove the duplicate declaration of:

Context
ContextAPI
context
Exception
ExceptionWithCode
ExceptionWithMessage
ExceptionWithName
getSpan
getSpanContext
getTracer
Link
isSpanContextValid
setSpan
setSpanContext
Span
SpanAttributes
SpanAttributeValue
SpanContext
SpanKind
SpanStatus
SpanStatusCode
TimeInput
TraceFlags
Tracer
TraceState

from core-tracing. Where needed / possible re-export them from OTel directly. This requires adding downlevel-dts to core-tracing and ensuring export type is downleveled correctly.

I am creating new stories after our meeting - going to close this as the new API design will likely not redeclare OTel interfaces anyway


text:
No error, empty result when using endpoint URL from azure portal incorrectly

Package Name: @azure/cognitiveservices-translatortext
Package Version: 1.0.0
Operating system: Windows 10 2004 OS Build 19041.207
[ ] nodejs

version:

[x] browser

name/version: Edge Chromium Dev:  Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.3 Safari/537.36 Edg/83.0.478.5

[x] typescript

version: 3.8.3

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

This was the configuration where I encountered it, but I imagine it generalizes to other environments and packages.
Describe the bug
I'm not sure if this would be considered a bug or not. It is just some feedback about behavior that tripped me up. I'm still a beginner at all things TypeScript, JavaScript, Azure, REST. Maybe others in the same position would make the same mistake, and maybe the SDK can make it easier somehow to diagnose the mistake?
Making my first ever Azure service call, I got to the point where I needed to pass an endpoint. It seemed logical to me that the endpoint would be what the Azure portal showed me along with the key:

However, this was not correct. I needed to use https://api.cognitive.microsofttranslator.com instead, which I eventually found in Azure docs, but it took me quite a while to spot it. It would have been nice if the SDK pointed out my mistake by throwing an error, but instead I got a successful yet empty result from my API call, leading me to believe that my mistake must have been elsewhere.
To Reproduce
Steps to reproduce the behavior:

Create a CognitiveServices TranslatorText resource in the azure portal
Use the sample code here, using the endpoint (incorrectly) and key from azure portal

Expected behavior
An error is reported.
Acutal behavior
The code succeeds but returns an empty result.
Screenshots
This is what you get: 200 OK with an empty result.

Additional context
N/A

(You can remove the "customer-reported" tag, I have joined the team and found this while experimenting as ramping up exercise.)

.

.

Thanks for reporting @nguerrera
This is an auto generated library based on the swagger specification from the service team.
From what I know, in this scenario, the client cannot make any validations on the provided endpoint and it is up to the service to throw an error.
@sarangan12, Please correct me if my understanding above is wrong

@ramya-rao-a  The (incorrect)endpoint is configured in such a manner that it returns empty result which is acceptable to our SDK. From SDK side we cannot do much here.
On a side note, this was my experience too when I tried building samples a while back. The correct fix would be to fix the portal and display the correct endpoint. Else, all new devs would face this experience. Should be reported to the portal team

Thanks for the explanation. That makes sense is there someone we can tag into the conversation from the portal team?

@nguerrera, I believe each Azure service team has their own contacts for their parts of the portal. Please reach out to @dfulcer or @ChrisHMSFT to get more details. Also, I believe this problem is common to almost all Cognitive Services, not just translator text, something to keep in mind when we design a solution for this.


text:
[Identity] Removing the null return type on getToken()

This PR removes the null return type on the getToken() of the Identity credentials.
Identity credentials extend TokenCredential, which continues to have null as a possibility.
While TokenCredentials may return null, Identity does not need to return null since it will throw at least a CredentialUnavailable error instead of returning null.
This decision doesn't necessarily need to impact the the base type TokenCredential because other TokenCredential implementations may use null reasonably outside of Identity.
It also does not necessarily need to impact the rest of our codebase since outside of Identity we compare the credential against the TokenCredential base class, which means that the null possibility exists if we ever decide to implement credentials outside of Identity, as we have done so.
The changelog entries will be available here: https://github.com/Azure/azure-sdk-for-js/pull/14405
Fixes #14421

@deyaaeldeen hi hi! Where's the nit? I don't see it.


text:
Revert "[Search Documents] Migrating search-documents to the new recorder"

Reverts Azure/azure-sdk-for-js#20125
As discussed offline, I will be reverting the changes.
@HarshaNalluru Please review and approve the PR

/azp run js - search-documents - tests-weekly

/azp run js - search-documents - tests-weekly

/azp run js - search-documents - tests-weekly


text:
[@azure/eventgrid] Update System events for EG Version 5.9.0

Packages impacted by this PR
@Azure/eventgrid
Issues associated with this PR
NA
Describe the problem that is addressed by this PR
This PR consists of the following changes:

Added new System Events:

Microsoft.ResourceNotifications.ContainerServiceEventResources.ScheduledEventEmitted

A new property policyRunSummary has been added to StorageLifecyclePolicyCompletedEventData interface.
New properties StorageLifecycleCompletionStatus and KnownStorageLifecycleCompletionStatus have been added.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
There are no specific/complex design scenarios for this task. It is a straightforward regenerate and some standard changes to the custom layer of the code.
Are there test cases added in this PR? (If not, why?)
No. This item is standard and we need not add test cases for every new events. The existing cases would be sufficient.
Provide a list of related PRs (if any)

https://github.com/Azure/azure-sdk-for-js/pull/28176 (This is the PR that adds similar events to the SDK in the 5.1.0 release)
https://github.com/Azure/azure-sdk-for-js/pull/28513 (This is the PR that adds similar events to the SDK in the 5.2.0 release)
https://github.com/Azure/azure-sdk-for-js/pull/28891 (This is the PR that adds similar events to the SDK in the 5.3.0 release)
https://github.com/Azure/azure-sdk-for-js/pull/29035 (This is the PR that adds similar events to the SDK in the 5.4.0 release)
https://github.com/Azure/azure-sdk-for-js/pull/29872 (This is the PR that adds similar events to the SDK in the 5.5.0 release)
https://github.com/Azure/azure-sdk-for-js/pull/30811 (This is the PR that adds similar events to the SDK in the 5.6.0 release)

Command used to generate this PR:**(Applicable only to SDK release request PRs)
autorest --typescript swagger\README.md
Checklists

[X] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[X] Added a changelog (if necessary)

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/eventgrid


text:
[Record and Playback] Update lint step in the test-utils-recorder

Build failed for the PR https://github.com/Azure/azure-sdk-for-js/pull/4883 when test-utils-recorder is imported in keyvault packages because of the outdated lint step.
Thanks to @KarishmaGhiya for helping.
/cc - @sadasant

So I think the reason why the ci did not check this earlier, is because the js-client-ci did not kick in for the checks @HarshaNalluru

Yes, this is the related build of that PR - https://dev.azure.com/azure-sdk/public/_build/results?buildId=94123&view=logs&jobId=b9afb22f-0837-5d02-bc24-6c30aee08bcf

I don't see @azure-test-utils-recorder in the lint step of Analyze job.

@HarshaNalluru That is because lint is running only on those libraries which have been onboarded to rush - present in rush.json AND which have the   "sdk-type": "client" set in package.json.
@azure-test-utils-recorder doesn't have sdk-type set in package.json, hence the ci doesn't run the lint step on it. This was expected behaviour

authors: HarshaNalluru KarishmaGhiya