Azure / Azure/azure-dev

Provision validation: auto-namespace extension rule IDs and surface owning extension in report/telemetry

Open
#9,060 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
569
Forks
364
Avg merge
2d 19h
Merged PRs (30d)
136

Description

## Context

The provider-agnostic provision validation feature (#9019) lets extensions register validation checks with a `RuleId`. Today the rule-ID namespace is **global**: core enforces uniqueness on `check_type + rule_id` across *all* installed extensions (`internal/grpcserver/validation_service.go` `onRegisterRequest`), and the `RuleId`/`DiagnosticId` strings are the only thing that maps a finding back to its owning extension.

Core already knows the owning `extension.Id` at registration and dispatch time (`validationCheckEntry.Extension`), but it is **not** surfaced in:
- the preflight report (`pkg/output/ux/preflight_report.go`), or
- telemetry (`PreflightExtensionRulesKey` / `PreflightDiagnosticsKey` in `pkg/infra/provisioning/provision_validation.go`).

As a result, each extension must hand-roll an extension prefix in its rule ID to keep findings mappable. For example, `azure.ai.agents` now uses `azure.ai.agents.resource_group_location_mismatch` (see PR #9007), and the demo extension uses bare IDs like `demo_provision_warning`. This is inconsistent and easy to get wrong.

## Problem

When we add rule suppressions, rule sets, or per-extension enable/disable in the future, customers need a reliable way to map a rule to the extension that owns it. Relying on a hand-rolled string prefix convention is fragile and not enforced.

## Proposed options

1. **Auto-namespace rule IDs** — core prepends the owning `extension.Id` to the registered `RuleId` (e.g. `/` or `.`), so extensions register short, local IDs and the effective/global ID is derived consistently. Update the global-uniqueness check accordingly.
2. **Dedicated extension-id field** — carry `extension.Id` as a structured field alongside each finding in the preflight report and telemetry (`PreflightExtensionRulesKey`/`PreflightDiagnosticsKey`), so rules are mappable without string parsing.
3. Both (1) and (2).

Option 2 (or 3) is likely the most robust: a structured field avoids parsing and preserves the raw rule ID.

## Acceptance criteria

- A finding surfaced by an extension check can be unambiguously mapped to its owning extension id, without relying on a hand-rolled string convention.
- Telemetry records the owning extension id for each invoked rule / diagnostic.
- Existing extensions (demo, azure.ai.agents) continue to work; document the recommended rule-ID convention.

## References

- Feature: #9019 (provider-agnostic provision validation checks)
- Consumer / motivating review: #9007 (azure.ai.agents resource-group location check) — reviewer @tg-msft raised the global-rule-ID mapping concern.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.