[CLI] If an extension ties into an existing command group, and has only in_preview subcommands, the parent command group is being marked as in_preview

[abossard]

Summary

When working on the health-models extension I noticed this:

• the extension is overwriting to get into monitor health-models
• all sub commands, e.g. monitor health-models entity .... are being marked as in_preview
• there seems to be a roll-up or mechanism in the extension code generator, that then will mark the whole monitor ... as in_preview

It might be an edge case, since the issue is only relevant, if there's a separate extension targeting an existing command group.

Steps to reproduce

tbd

Actual behavior

tbd

Expected behavior

• The generator should verify if there might be others adding commands to the group that are not in_preview

[abossard]

Disclaimer: Copilot-assisted; this is a potential minimal fix sketch, not verified end-to-end.

Where it comes from

The general command group stable vs preview flow (this is all fine):

A command group carries no own preview flag in the aaz spec:

• _build_command_group_from_aaz initializes every group to Stable (src/aaz_dev/cli/controller/az_atomic_profile_builder.py:117-119),
• the stable/preview is then derived by rolling up the group's children (:87-96):

Source:

if AAZStageEnum.Stable in stages:
    command_group.register_info.stage = AAZStageEnum.Stable
elif AAZStageEnum.Preview in stages:
    command_group.register_info.stage = AAZStageEnum.Preview
elif AAZStageEnum.Experimental in stages:
    command_group.register_info.stage = AAZStageEnum.Experimental
elif not stages:
    command_group.register_info = None

But with extension referencing existing command groups (this is potentially not fine)

The roll-up only sees the children in the extension's current profile.

• When an extension contributes only preview commands under an existing shared root group (e.g. monitor), the stage set is {Preview} with no Stable to anchor it
• so the shared root is emitted as @register_command_group("monitor", is_preview=True).

Example for a minimal fix

Don't let the roll-up assign a preview/experimental stage to the profile's top-level (root) command groups:

• those are the shared global namespaces (monitor, network, vm, …) that an extension merely extends.
• even sub-grouping the extension introduces would still roll up

Idea:

• pass an is_root flag from __call__ (:36-37) and clamp root groups:

     for name, view_cmd_group in view_profile.command_groups.items():
-        cmd_group, clients = self._build_command_group(view_cmd_group)
+        cmd_group, clients = self._build_command_group(view_cmd_group, is_root=True)
         ...

-    def _build_command_group(self, view_command_group):
+    def _build_command_group(self, view_command_group, is_root=False):
         ...
         if AAZStageEnum.Stable in stages:
             command_group.register_info.stage = AAZStageEnum.Stable
-        elif AAZStageEnum.Preview in stages:
+        elif AAZStageEnum.Preview in stages and not is_root:
             command_group.register_info.stage = AAZStageEnum.Preview
-        elif AAZStageEnum.Experimental in stages:
+        elif AAZStageEnum.Experimental in stages and not is_root:
             command_group.register_info.stage = AAZStageEnum.Experimental
         elif not stages:
             command_group.register_info = None
+        elif is_root:
+            command_group.register_info.stage = AAZStageEnum.Stable
         else:
             raise NotImplementedError()

So this would keep monitor stable, even if all sub commands and groups that are added from an extension would be marked in preview.

Trade-offs / caveats

• maybe it's not common that extension go into existing root groups and add only preview commands
• maybe e.g. the health-models extension should not be a separate extension, but be part of the monitoring extension
• maybe it's possible make a larger fix, collecting more metadata before doing the roll-up