search

Azure / bicep-registry-modules

Bicep registry modules
MIT License
499 stars 347 forks source link

[AVM Module Issue]: search service module should output endpoint URI #2986

Open stewartadam opened 2 months ago

stewartadam commented 2 months ago

Check for previous/existing GitHub issues

Issue Type?

Feature Request

Module Name

avm/res/search/search-service

(Optional) Module Version

No response

Description

Search service outputs do not include the endpoint name. Users can re-construct it themselves using the conventional URL format like https://${searchService.name}.search.windows.net but the module should be authoritative on this and output the correct endpoint as an output (even if its just doing the above internally).

(Optional) Correlation Id

No response

avm-team-linter[bot] commented 2 months ago

@stewartadam, thanks for submitting this issue for the avm/res/search/search-service module!

[!IMPORTANT] A member of the @Azure/avm-res-search-searchservice-module-owners-bicep or @Azure/avm-res-search-searchservice-module-contributors-bicep team will review it soon!

krbar commented 2 months ago

@stewartadam the resource provider does not return the endpoint URI, so we need to create it within the module. The proposed method in the description (https://${searchService.name}.search.windows.net) only covers the Azure Global cloud and not other environments like US Gov. Unfortunately, the Bicep function environment(), which would provide a clean way to implement the endpoint URI, does not return the DNS suffix for the search service. As mentioned in https://github.com/Azure/bicep/issues/12482, this may not change soon. I suggest waiting for the avm/utl/general/get-environment module (https://github.com/Azure/Azure-Verified-Modules/issues/898), which will serve as an AVM workaround for the missing DNS suffixes in the "endpoints" API.

@Azure/avm-core-team-technical-bicep what do you guys think?

AlexanderSehr commented 2 months ago

@stewartadam the resource provider does not return the endpoint URI, so we need to create it within the module. The proposed method in the description (https://${searchService.name}.search.windows.net) only covers the Azure Global cloud and not other environments like US Gov. Unfortunately, the Bicep function environment(), which would provide a clean way to implement the endpoint URI, does not return the DNS suffix for the search service. As mentioned in Azure/bicep#12482, this may not change soon. I suggest waiting for the avm/utl/general/get-environment module (Azure/Azure-Verified-Modules#898), which will serve as an AVM workaround for the missing DNS suffixes in the "endpoints" API.

@Azure/avm-core-team-technical-bicep what do you guys think?

Sounds reasonable to me. The environment() function actually lacks quite a few entries. Fortunately, the endpoint the @stewartadam suggested is deterministic and hence very easy to construct. Once the environment() function or the utl module is implemented, I don't see any harm in adding the output though.

microsoft-github-policy-service[bot] commented 2 months ago

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

  • To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
  • To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!