Add support for provisioning Azure AI Search via the CDK#2820
Add support for provisioning Azure AI Search via the CDK#2820mitchdenny merged 2 commits intomicrosoft:mainfrom
Conversation
ghost
added
the
area-app-model
dotnet-policy-service
bot
added
the
community-contribution
| /// <param name="name">The name of the Azure AI Search resource.</param> | ||
| /// <param name="configureResource">Callback to configure the Azure AI Search resource.</param> | ||
| /// <returns>A reference to the <see cref="IResourceBuilder{AzureSearchConstructResource}"/>.</returns> | ||
| public static IResourceBuilder<AzureSearchConstructResource> AddAzureConstructSearch( |
There was a problem hiding this comment.
I think these would work better for customers if we called it AddAzureSearchConstruct because then it'll appear in intellisense next to the vanilla AddAzureSearch.
There was a problem hiding this comment.
We'll need to polish all of these depending on what our decision is around CDK exposure.
| } | ||
| } | ||
|
|
||
| output connectionString string = 'Endpoint=https://${searchService_7WkaGluF0.name}.search.windows.net' |
There was a problem hiding this comment.
Can this get acquired via a property. This may not be valid in non public clouds. The domain suffixes aren't universal across different clouds.
There was a problem hiding this comment.
Not today - but filed Azure/azure-sdk-for-net#42640 and Azure/azure-sdk-for-net#42639 to do something slightly better than this. I left a TODO at https://github.com/dotnet/aspire/pull/2820/files#diff-ea51a3d17e41fb2fc8010fc133d0d3ae6ec2f8faa9967ec063ea9208bb027078R71 to track patching this up.
mitchdenny
left a comment
mitchdenny
left a comment
There was a problem hiding this comment.
One comment on how the connection string is formed,ideally we can get the entire URI back from ARM instead of constructing it ourselves to avoid different DNS suffixes in different clouds.
3 participants
Microsoft Reviewers: Open in CodeFlow