Use Azure.Provisioning naming requirements by default for Container Apps environments

Open
  • Is something wrong?
#21,892 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, csharp
Domain
backend, cloud

Research direction

Start by reviewing the naming compatibility behavior introduced by #18737 and the proposal in #20178, then verify the requirements in Azure.Provisioning.AppContainers 1.3.0-beta.2 against Azure's ACA managed-environment constraints. Define a migration plan for existing environments and decide whether to retire, invert, or retain WithUniqueResourceNaming(); done means Aspire has a justified default and compatibility plan.

Written by the indexing model from the issue text.

Description

area-integrations
Is there an existing issue for this?
  • I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.

Aspire currently preserves the legacy generated naming requirements for Azure Container Apps managed environments (1-24 lowercase letters) to avoid renaming and recreating existing deployed environments. The corrected requirements supplied by Azure.Provisioning.AppContainers are used only when callers opt into WithUniqueResourceNaming().

This means Aspire maintains a custom compatibility resolver instead of following the naming requirements supplied by Azure.Provisioning by default.

Describe the solution you'd like

Once Azure.Provisioning.AppContainers exposes accurate ACA managed-environment naming requirements, revisit the compatibility behavior introduced by #18737 and use the SDK-provided requirements as Aspire's default.

The change needs an explicit migration/compatibility plan because changing the generated name can cause existing managed environments to be recreated. As part of the design, determine whether WithUniqueResourceNaming() should be retired, inverted, or retained as a compatibility mechanism.

Additional context
  • Follow-up proposal from #20178: https://github.com/microsoft/aspire/pull/20178#discussion_r4028262636
  • #18737 introduced the compatibility-preserving opt-in after #18722 exposed collisions caused by the former Azure.Provisioning requirements.
  • Azure.Provisioning.AppContainers 1.3.0-beta.2 updates the naming requirements, but they should be verified against Azure's actual ACA managed-environment constraints before changing Aspire's default.
Dominant language
C#
Stars
6.4k
Forks
1k
Avg merge
3d 3h
Merged PRs (30d)
349

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/aspire

All issues in microsoft/aspire

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.