chore: add owners for telco teams interfaces

[IronCore864]

Adding owners for the telco team's interfaces according to @patriciareinoso.

Note that currently only sdcore_config has tests (and are failing).

[IronCore864]

Can we use github teams instead of individuals? We probably don't want to maintain those.

No, we tried to do this, but issues could only be assigned to team members, not a whole team... PRs on the other hand can be assigned to teams.

The purpose here is to create issues automatically for failed interface tests and assign them to some people, not to list all member of a team.

That said, maybe I can work out a feature where we put team as owner here then use GitHub APIs to figure out members then assign issues to the members. What do you think @benhoyt @tonyandrewmeyer

[gruyaume]

Can we use github teams instead of individuals? We probably don't want to maintain those.

No, we tried to do this, but issues could only be assigned to team members, not a whole team... PRs on the other hand can be assigned to teams.

The purpose here is to create issues automatically for failed interface tests and assign them to some people, not to list all member of a team.

That said, maybe I can work out a feature where we put team as owner here then use GitHub APIs to figure out members then assign issues to the members. What do you think @benhoyt @tonyandrewmeyer

So how do you plan to keep this list up to date?

[benhoyt]

@IronCore864 That's a good idea (to list the team here, and if the script that creates the issues detects a team, it expands it using the GitHub API before assigning it to members). Maybe the items in the owners lists can be either teams or individuals, and if they're teams, we expand them before assigning the issue.

@gruyaume It's a good idea to make these teams instead of individuals to avoid so much upkeep. We'll try to change it to allow teams as above. And we plan to do a first pass to set the owners fields (to the appropriate teams), but after that the idea is that the owner/maintainer of the interface tests keeps it up to date.

[simskij]

@benhoyt @tonyandrewmeyer @IronCore864

I'm a little bit concerned by the use of the word "owner" as it implies actual ownership, while the charm relation interfaces is (or was at least at it's conception) meant to be owned by the special interest group forming around it. Maintainers, stewards, leads, or similar would probably be more appropriate.

To give you an example:

The ingress interface is used by both traefik, maintained by the observability team, and by nginx, maintained by IS DevOps. While the interface came to be out of our work on traefik, we do recognize that any changes to the interface should be agreed by all parties implementing the provider side of it. Calling one or the other owners shifts that balance toward one party having veto.

We could of course work around this by saying owners are both the traefik team and the nginx team, but then what happens when a third party also starts to gain interest in the direction of the interface? Do we keep increasing the list of owners? Do we intentionally leave a party out of the conversation? By using a term like maintainers we'd signal that it's a facilitating role, rather than a deciding one.

[benhoyt]

@simskij Good call. We can change that. I like maintainers.

[tonyandrewmeyer]

+1 for having the tool mitigate not being able to assign to individuals. Also +1 on the label maintainers.

The intention is that there needs to be someone (ideally it would really be a single person, but that becomes even harder to maintain) who is responsible for taking action when interface tests start to fail (maybe part of the issue here too is that there is, as far as I know, no intention for this field to mean anything other than "assigned test failure issues", but it seems like it's implying owner- or stewardship over the interface entirely).

The assignee doesn't need to fix the tests, they need to make sure that someone does. The failure is most likely in some provider/requirer of the interface and probably an issue needs to be opened somewhere else - it would be great if this tool could do that, but if I understand correctly, we didn't do that because of technical difficulties.

There is a backstop: Charm-Tech will be getting alerts for all the issues that are created, and following up on any that get stale. But that doesn't scale to be the first point of contact when a failure starts.

I do wonder if this system matures longer term so that it's less centralised. For example, if you want to claim that you provide/require an interface there's an API for that and it validates at the time that the specified version is compatible and that's re-done for new revisions (facilitated by charmhub, perhaps). So that there's no need to be running things on a schedule or have centralised issue reporting.

(There would need to be centralised checks for changes to the interface specification itself still, of course).

[IronCore864]

The "owners" field has been updated to "maintainer", where a GitHub team ID is used. This feature has been merged in this repo (and in the pytest-interface-tester as well), and now I'm updating the telco teams' interfaces with the maintainer field. Please take a final look before merging @benhoyt @gruyaume. Thanks!