In T303744#11588126, @JMeybohm wrote:

I disagree this being a duplicate of T412693: Ensure all Chart.yaml files include required metadata fields as that one aims at chart ownership while this task aims at ownership for k8s namespaces (or groups of deployments if that makes more sense). Those might contain deployments of charts maintained by the same group/team - but that's not a requirement.

What comes to mind would be to add a "namespaces" key in chart.yaml, sort of

<snip>
home: https://wikitech.wikimedia.org/wiki/Memcached_for_MediaWiki
sources:
  - https://gerrit.wikimedia.org/r/admin/repos/operations/docker-images/production-images
team: https://wikitech.wikimedia.org/wiki/SRE/Service_Operations
maintainers:
  - name: Effie Mouzeli
    email: effie@wikimedia.org
namespaces:
  - mw-mcrouter: "SRE/ServiceOps"

Which could work for the things we can easily identify. I am in two minds regarding adding a CI check for this as well, but it is not something we need to think about now.

How does that sound?

I don't think it makes much sense to maintain a list of namespaces where something is deployed inside the artifact that is being deployed.
My aim here was to add an annotation or label to the namespace objects in kubernetes. This could easily be done during namespace creation in https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/helmfile.d/admin_ng/values/main.yaml#14 and https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/helmfile.d/admin_ng/helmfile_namespaces.yaml. The hard part is to figure out the identifier to add add (phab tag, team name, .. ideally not something that changes every quarter) and the actually responsible group (as usual).

I think it might make sense for the identifier to add to match a 'team' in the context of alerting receivers. For instance, it would be useful to associate the mw-api-int namespace alerts with teams in alertmanager, because that is a reference we know points at humans who care to receive alerts.

In T303744#11602583, @Blake wrote:

I think it might make sense for the identifier to add to match a 'team' in the context of alerting receivers. For instance, it would be useful to associate the mw-api-int namespace alerts with teams in alertmanager, because that is a reference we know points at humans who care to receive alerts.

+1

In T303744#11592146, @JMeybohm wrote:

I don't think it makes much sense to maintain a list of namespaces where something is deployed inside the artifact that is being deployed.
My aim here was to add an annotation or label to the namespace objects in kubernetes. This could easily be done during namespace creation in https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/helmfile.d/admin_ng/values/main.yaml#14 and https://gerrit.wikimedia.org/r/plugins/gitiles/operations/deployment-charts/+/refs/heads/master/helmfile.d/admin_ng/helmfile_namespaces.yaml. The hard part is to figure out the identifier to add add (phab tag, team name, .. ideally not something that changes every quarter) and the actually responsible group (as usual).

+1 to this being namespace-bound, as well as it being orthogonal to T412693. However we should use the same identifying mechanism for clarity.

In T303744#11602583, @Blake wrote:

I think it might make sense for the identifier to add to match a 'team' in the context of alerting receivers. For instance, it would be useful to associate the mw-api-int namespace alerts with teams in alertmanager, because that is a reference we know points at humans who care to receive alerts.

I agree. I was just afraid to use team names since those unfortunately change quire frequently within the WMF. But we probably need to do some maintenance on the identifiers no matter what we choose. So the only really important thing is that we use the same everywhere (routing, namespaces, charts,container images) and that we have a reliable way to contact the people behind the identifier (that's why I initially thought of phab tags).