[vvoytovych]

The activity processor routes the alerts for a failing activity policy to the team its owner labels name, and none of Milo's activity policies declared an owner, so a failing one alerted with no service and reached no team.

Each policy group now declares its owner, the control plane service and the platform team, because Milo's API server serves every group and the platform's service catalog places it there.

The owner sits on each group as a whole, so a policy added to a group takes it along, and a new test fails when a group declares none.

Changes

Change	Effect
Each of the six activity policy groups	labels its policies with the control plane service and the platform team
A new test	fails when a group declares no owner, or a policy file sits outside its group

Test plan

• The new test fails on every group before this change and passes after, and catches a group without labels, an empty label, and a stray policy file
• Every one of the rendered activity policies carries both owner labels
• After the release reaches production, the processor reports an owner for every Milo activity policy
• The next alert for a failing Milo activity policy posts to the platform team's channel with the control plane service

[ecv]

Approve.

Each of Milo's six activity policy groups now labels its policies with meta.datumapis.com/service: control-plane and meta.datumapis.com/team: platform. A failing Milo policy's alert reaches the platform team instead of nobody.

• Those are the keys the processor reads (policyServiceLabel and policyTeamLabel in activity's internal/activityprocessor/policy_ownership.go), so the owner reaches the alert's policy_service and policy_team.
• The labels go at group level without includeSelectors, so only metadata changes, and a new policy in a group takes the owner with it.