[AzureSearch] Resource Manager 2026-03-01-preview Release#40408
[AzureSearch] Resource Manager 2026-03-01-preview Release#40408
Conversation
…d 05 search.json as search_new.json for baseline
…es valiation; Passed prettier check
yangylu91
requested review from
BevLoh,
Draconicida,
admayber,
efrainretana,
jonathanserbent,
kuanlu95 and
xiong-qiao
as code owners
Next Steps to MergeNext steps that must be taken to merge this PR:
Comment generated by summarize-checks workflow run. |
github-actions
bot
added
brownfield
API Change CheckAPIView identified API level changes in this PR and created the following API reviews
|
|
@yangylu91 I've opened a new pull request, #40703, to work on those changes. Once the pull request is ready, I'll request review from you. |
|
@yangylu91 I've opened a new pull request, #40704, to work on those changes. Once the pull request is ready, I'll request review from you. |
* Initial plan * Add missing systemData fields to SearchCreateOrUpdateService.json Co-authored-by: yangylu91 <53235012+yangylu91@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: yangylu91 <53235012+yangylu91@users.noreply.github.com>
…eAuthOptions example (#40704) * Initial plan * Fix inconsistent upgradeAvailable value in SearchCreateOrUpdateServiceAuthOptions example Co-authored-by: yangylu91 <53235012+yangylu91@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: yangylu91 <53235012+yangylu91@users.noreply.github.com>
|
@psah434 We've updated the PR and resolved all comments. Could you pls take a look again? Thank you! |
yangylu91
added
WaitForARMFeedback
github-actions
bot
removed
the
WaitForARMFeedback
yangylu91
added
WaitForARMFeedback
HeidiSteen
left a comment
HeidiSteen
left a comment
There was a problem hiding this comment.
Sorry the late review. The main things: I don't see AR ops (KB, KB Retrieve, KS) in the SearchListOperations. Also, for the big "search.json" file, I think you might want to clarify if something is unique to dedicated services only.
| "properties": { | ||
| "type": "Microsoft.Storage/storageAccounts", | ||
| "groupId": "blob", | ||
| "description": "Azure AI Search indexers can connect to blobs in Azure Storage for reading data from an indexer data source, for writing intermediate results of indexer execution or for storing any knowledge store projections." |
There was a problem hiding this comment.
This description doesn't mention private connections. Suggestion: "Indexers can make private connections to blobs in Azure Storage for reading data, writing to an enrichment cache, and writing to a knowledge store."
If debug sessions is also supported, I would add "saving a debug session" to the list.
| "properties": { | ||
| "type": "Microsoft.Storage/storageAccounts", | ||
| "groupId": "table", | ||
| "description": "Azure AI Search indexers can connect to tables in Azure Storage for reading data from an indexer data source, for writing intermediate results of indexer execution or for storing any knowledge store projections." |
There was a problem hiding this comment.
similar suggestion: "Indexers can make private connections to tables in Azure Storage for reading data, writing to an enrichment cache, and writing to a knowledge store."
| "properties": { | ||
| "type": "Microsoft.DocumentDB/databaseAccounts", | ||
| "groupId": "Sql", | ||
| "description": "Azure AI Search indexers can connect to Azure Cosmos DB API for NoSQL for reading data from an indexer data source." |
There was a problem hiding this comment.
suggestion for this + other DS: "can connect privately"
| "provider": "Microsoft Search", | ||
| "resource": "Search Services", | ||
| "operation": "Get Search Service", | ||
| "description": "Reads the search service." |
There was a problem hiding this comment.
Is this for reading stuff like Get Service Stats or Get Index Stats? I suggest clarifying it so that people don't think it's a query action. Perhaps: "Returns index and indexer status and metrics, and object information."
| "provider": "Microsoft Search", | ||
| "resource": "Search Services", | ||
| "operation": "Stop Search Service", | ||
| "description": "Stops the search service." |
There was a problem hiding this comment.
Suggestion: "Unloads a serverless search service due to inactivity and pauses billing."
| }, | ||
| "provisioningState": { | ||
| "$ref": "#/definitions/ProvisioningState", | ||
| "description": "The state of the last provisioning operation performed on the search service. Provisioning is an intermediate state that occurs while service capacity is being established. After capacity is set up, provisioningState changes to either 'Succeeded' or 'Failed'. Client applications can poll provisioning status (the recommended polling interval is from 30 seconds to one minute) by using the Get Search Service operation to see when an operation is completed. If you are using the free service, this value tends to come back as 'Succeeded' directly in the call to Create search service. This is because the free service uses capacity that is already set up.", |
There was a problem hiding this comment.
any qualifiers or interesting things to say about serverless provisioning?
| }, | ||
| "SearchServiceStatus": { | ||
| "type": "string", | ||
| "description": "The status of the search service. Possible values include: 'running': The search service is running and no provisioning operations are underway. 'provisioning': The search service is being provisioned or scaled up or down. 'deleting': The search service is being deleted. 'degraded': The search service is degraded. This can occur when the underlying search units are not healthy. The search service is most likely operational, but performance might be slow and some requests might be dropped. 'disabled': The search service is disabled. In this state, the service will reject all API requests. 'error': The search service is in an error state. 'stopped': The search service is in a subscription that's disabled. If your service is in the degraded, disabled, or error states, it means the Azure AI Search team is actively investigating the underlying issue. Dedicated services in these states are still chargeable based on the number of search units provisioned.", |
There was a problem hiding this comment.
anything to say about serverless?
| { | ||
| "name": "Disabled", | ||
| "value": "disabled", | ||
| "description": "The search service is disabled and all API requests will be rejected." |
There was a problem hiding this comment.
is this serverless only? And should the description say "unloaded" ?
| "properties": { | ||
| "name": { | ||
| "$ref": "#/definitions/SkuName", | ||
| "description": "The SKU of the search service. Valid values include: 'free': Shared service. 'basic': Dedicated service with up to 3 replicas. 'standard': Dedicated service with up to 12 partitions and 12 replicas. 'standard2': Similar to standard, but with more capacity per search unit. 'standard3': The largest Standard offering with up to 12 partitions and 12 replicas (or up to 3 partitions with more indexes if you also set the hostingMode property to 'highDensity'). 'storage_optimized_l1': Supports 1TB per partition, up to 12 partitions. 'storage_optimized_l2': Supports 2TB per partition, up to 12 partitions.'" |
There was a problem hiding this comment.
add serverless? If not, then suggest adding "dedicated" to this description and the one above.
| }, | ||
| "UpgradeAvailable": { | ||
| "type": "string", | ||
| "description": "Indicates if the search service has an upgrade available.", |
There was a problem hiding this comment.
this is dedicated only right? You can't switch from a dedicated tier to a serverless SKU I assume...
Synced offline with Heidi. Since this PR is likely to be reviewed today and our SDK work depends on it, we’ll proceed as planned. Given the release timeline, we’ll address the spec and example comments in a follow-up PR, as they are non-breaking. |
| - code: LroErrorContent | ||
| from: search.json | ||
| reason: Agreement with ARM reviewers to update in next API version. | ||
| - code: RequiredPropertiesMissingInResourceModel |
There was a problem hiding this comment.
I think this is flagged because your list is an array of non-resource objects, not because the container itself is not a resource. The values[] array should contain resource type instances with the standard ARM top-level properties. Basically, the point GET returns a resource and the collection GET returns an array of resources. Please fix the API spec and remove this suppression.
There was a problem hiding this comment.
Thanks for the detailed feedback.
We discussed the suggested changes drafted in PR #40876 internally. Implementing the regional GET and updating the response shape would require corresponding service and client updates, as well as coordination with our UX team. As a result, the change introduces rollout and compatibility risks for this release.
We do want to address ARM guidance appropriately before GA. At the same time, we would like to avoid introducing unnecessary risk if this can be staged in a subsequent preview iteration.
Would it be acceptable to address this change in the next preview version prior to GA?
Appreciate your guidance.
github-actions
bot
removed
the
WaitForARMFeedback
yangylu91
added
WaitForARMFeedback
|
please address comments from chris and heidi |
github-actions
bot
removed
the
WaitForARMFeedback
Got it. For Heidi's feedback on description and examples: I've updated the offline sync agreement that we'll have a follow-up PR for updating descriptions separately. For Chris' feedback on Offerings API: I've updated the internal discussion and requested to suppressing it in this preview and addressing it in next preview. By 3/6: Talked with the oncale ARM reviewer Pallavi. Still waiting for the ARM review team's response on the suppression request. |
ARM (Control Plane) API Specification Update Pull Request
Tip
Overwhelmed by all this guidance? See the
Getting helpsection at the bottom of this PR description.PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.
Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!
Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.
Additional information
This PR was recreated for Search Resource Manager 2026-03-01-preview, based on #40123.
Reason: After the previous PR was created, the stable 2025-05-01 Swagger in main was converted from hand-authored to TSP-compiled. Since the earlier PR was based on the hand-authored version, CI reported many false-positive breaking changes (e.g., inline schemas vs. definition references with equivalent semantics). To avoid noisy diffs, we recreated the PR and applied the 2026-03-01-preview changes on top of the TSP-compiled 2025-05-01 Swagger.
Future plan: The timeline for 2026-03-01-preview overlaps with the 2025-05-01 TSP migration, so this release continues to use Swagger-based changes. We will fully migrate to TSP and develop in TSP starting with the next RP release.
Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table in the `Generated ApiView` comment added to this PR. You can use ApiView to show API versions diff.Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the [suppressions guide](https://aka.ms/azsdk/pr-suppressions) to get approval.Getting help
Purpose of this PRandDue diligence checklist.write accessper aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositoriesNext Steps to Mergecomment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.and https://aka.ms/ci-fix.
queuedstate, please add a comment with contents/azp run.This should result in a new comment denoting a
PR validation pipelinehas started and the checks should be updated after few minutes.