| Jdforrester-WMF | |
| Jun 22 2023, 8:39 PM |
Apparently per T339936#8957335 we give out deployment nowadays, as since 2017 the rights have effectively merged.
Should we drop this group? From my count[0] there are only three users in that group and not deployment, so it's just a area of confusion without adding value?
[0]:
$ cat data.yaml| yq '.groups.deploy-service.members - .groups.deployment.members'
thcipriani, dduvall, smalyshev, jdlrobson, santhosh]Of these, the first two are pulled in via *releng_members.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Drop deploy-service group | operations/puppet | production | +3 -9 |
Yes, the overlap in people is small, and at first it does seem to make sense to merge them.
But the groups have pretty different privileges. A member of "deploy-service" has a shell on deployment servers but no other servers and no sudo privileges. And they don't need more to deploy services on k8s.
The deploy-service group, afair started as "deployer of a nodejs service" and nowadays it is "deployer of a kubernetes service".
A member of "deployment" though has shell on all appservers and has a bunch of sudo privs to do things like restarting apache and php, fixing deploy permissions and run anything as scap and more.
So I am adding serviceops but I think this is more like "deploy-service is the future / k8s" and "deployment" will go away when scap and appservers go away.
If deploy-service is used for k8s deploys, surely everyone in 'deployment' needs it with MediaWiki moving to k8s.
But not all services will have anything to do with what's on the appservers.
So surely the question is more, does anyone need the right to just deploy all k8s services? Assuming that's what the group does.
If they do, then the group is still needed. If not, then maybe it can go.
They definately don't do the same thing though.
basically "deployment" is "mediawiki scap deployers" and deploy-service is "any service k8 deployers" and started as "node deployers" (when gwicke/mobrovac et al started deploying things on node).. unless I am mistaken.
This might have been the case historically, however these days the Puppet manifests for k8s service deployment do refer to deployment instead. See for example T308308 where people were blocked from deploying to k8s because they were not in that group.
Should we drop this group? From my count[0] there are only three users in that group and not deployment, so it's just a area of confusion without adding value?
Out of those three:
So I'd say let's just drop that group.
Change 934411 had a related patch set uploaded (by Majavah; author: Majavah):
[operations/puppet@production] Drop deploy-service group
per role/common/deployment_server/kubernetes.yaml
profile::admin::groups: - deployment - deploy-service - deploy-ml-service
nowadays it is sufficent to be only in deploy-service to get shell on deployment servers. The role they are using also renamed to "deployment_server::kubernetes" at some point.
Regardless it is true that the helm user group is deployment profile::kubernetes::deployment_server::helm_user_group: deployment. So yes, for access to helm files it would be needed. Maybe deploy-service should be used for that in the future? It is configurable in Hiera.
deployment is the group to be used for deploying to k8s. Initially we had targetted wikidev but that was changed in T305729 to narrow the access a bit
We never targeted deploy-service for k8s, that was for the sc* clusters as far as I remember. But I doubt it's that easy to drop the group.
git grep deploy-service |wc -l 53
some of these uses appears to be in RSpecs, so they are probably(famous last words) easily removed/replace, but others (e.g. arclamp which is deployed via scap) appear way more involved.
I'm boldly removing sre-access-requests since I don't think there's anything actionable for clinic duty