SST mass renaming (CASE-789)

[yselkowitz]

/cc @rlemosor

[rlemosor]

Nice, LGTM, Yaakov; and with a commit per renamed team. Thanks for doing this.

[yselkowitz]

This one is a bit confusing. It's named samba-storage but it looks like it should be ceph-storage instead?

[rlemosor]

You're right. In fact we had decided to delete the Samba team record and move ceph-related content under the ceph-storage team and/or anything that is IdM-related components to the IdM team. This was performed in Jira and the internal component ownership repo. But not here on the workloads. This was debated in a comment thread in the People Tagging spreadsheet owned by Perry Myers. Could you perform this change? Thanks for spotting. Link to that internal discussion: https://docs.google.com/spreadsheets/d/1Qk3sGf9EyDIaIlSsgbTeRY0jDHE8KGvOeWcwcpF3y-M/edit?disco=AAABXPbZ26s

[yselkowitz]

Modified; please verify.

[yselkowitz]

Also:

• Is rhel-sst-program an actual SST?
• What about the ACG L1 configs, can those be assigned (and renamed) to an SST, e.g. program (see the previous question)?
• (Side question: shouldn't eln be removed from the RHEL 8 ACG L1 config now that ELN is targeting RHEL 11?)
• Any chance that the IdM packages can be assigned to respective SSTs rather than the SSG?

[rlemosor]

1. rhel-sst-program has been a placeholder for the extended RHEL program team: it is not a real Engineering team. Perry Myers in fact wanted to find actual Engineering owners for anything rhel-sst-program currently owns in name. This is usually a laborious case-by-case analysis (it is almost completed at package level). The goal is to eventually delete rhel-sst-program as a selectable team record in all systems -- in Perry's view, artifacts associated with rhel-sst-program should in fact be associated with no team, i.e. the team record should be null/blank. IOW, for CR workloads, the maintainer line should probably be empty. If we go that direction, however, can the CR reports produced by asamalik handle an empty maintainer line?
2. Yes, agreed, the ACG CL1 workload needs to be assigned to no-one, or, as per still standing fallback, be assigned to this "virtual", non-Engineering team we call rhel-sst-program.
3. Yes, agreed eln should be removed from the RHEL 8 ACG CL config
4. I agree with you that SSG assignment is an out-of-process state (or at least an odd choice). Let me talk to the IdM group.

Let me consult with Perry on 1 -- which will resolve 2. And also consult with IdM on 3. Meanwhile, can you perform 3?

[yselkowitz]

1. I'm pretty sure a maintainer is required for each workload by CR. A way to avoid the problem though is to make sure that each package also has a proper SST listing as well. CR will show both but it should be obvious to the viewer who the actual owner should be. But isn't rhel-program-team the proper name for that? (That would also make it clearer that it is NOT referring to an actual SST.)
2. Reassigned and renamed the ACG L1 configs to rhel-sst-program (pending the above).
3. Done.
4. Understood.

I'd like to leave the bigger questions raised here for future iteration (and new CASE ticket(s)) so as not to unduly delay this further. If we can get an answer on the name to use for the Program, then we can work on SST listings for Program packages and SSG->SST conversion of IdM separately.

[rlemosor]

1. @yselkowitz , I discussed the rhel-sst-program vs rhel-program-team topic with Perry Myers and Brian Stinson and the point is moot. Brian accepts being the maintainer of workloads still associated with rhel-sst-program. So we can do a general serach and replace in that regard. The point that is now moot is my preoccupation logical consistency in team naming (the current convention is rhel-sst-$name even if the team in question is not an actual SST, such as in the cases of OSCI, CentOS Stream Eng, RHEL Upgrades, etc.; in that view, rhel-program-team would not be a valid team name; it would be outside of the People Tagging system and it would have no Rover Group; FWIW, it seems Perry already deleted that group anyway)
2. So please reassign to bstinson
3. Many thanks
4. No answer yet; I contacted one of the managers, will not maybe contact the Leads/POs, or the team's ML. May need more time. As per your suggestion, let's move this point to a new MR and CASE ticket.

[rlemosor]

All is looking good from my side. Onward with the mass rename! :)

[rlemosor]

All is looking good from my side. Onward with the mass rename! :)