Any modifications in config and/or coordinated deploys on SC(A|B) require Puppet to be forced on the whole cluster. As I manage one way or the other most (if not all) SC(AB) services, being able to manage Puppet on the cluster would be a real life saviour for me. Hereby I ask the appropriate access level to do sudo puppet agent * on sc[ab]00.
|Resolved||Joe||T134251 Allow mobrovac to run puppet on SC(A|B)|
|Resolved||Joe||T135386 Cleanup puppet from unneeded and empty single-service "roots"|
- Mentioned In
- rOPUP25ad72eac3c2: admin: add sc-admins to sc(a|b) hosts
rOPUPa5974538e01f: admin: general service cluster group
rOPUP594ca850529b: admin: general service cluster group
T135548: Expand sc-admins to provide sufficient coverage for sc* clusters
rOPUPa13fcbe94435: admin: add sc-admins to sc(a|b) hosts
rOPUP61856d8229f9: admin: general service cluster group
- Mentioned Here
- T135548: Expand sc-admins to provide sufficient coverage for sc* clusters
T93428: Streamline our service development and deployment process
There is no single admin group "sca" or "scb". These are collections of services and admin groups.
So this request either means "let all users in all these admin groups run puppet on all the hosts that have these groups", or we have to setup something new.
Alright, then we should create a new group (naming suggestions? "scab-admins" may not be the best :), but for this purpose, and then put it on the hosts via hieradata/role/common/sca.yaml and scb.yaml
Any modifications in config and/or coordinated deploys on SC(A|B) require Puppet to be forced on the whole cluster.
Directed to you. You implied that this request is not related to any service but only to hosts. Why deviate from the normally used assignment of roles/services to hosts? See https://wikitech.wikimedia.org/wiki/Puppet_coding#When_we_use_puppet ,
https://wikitech.wikimedia.org/wiki/Puppet_coding#Organization and https://wikitech.wikimedia.org/wiki/Puppet_coding#WMF_Design_conventions .
Because the concept of SC(A|B) is already a deviation from that: there are multiple unrelated services running on each of these hosts, most of which I deploy/maintain. Having the right to run puppet under one of the admin groups makes no sense to me since the run impacts all of them.
Puppet runs on a per-host basis,
That does not contradict the concept of roles/services. There are more things that are only available for the whole host, but a role/service still reserves/requires them on the host it is applied on. The result is that roles/service may conflict and you only may have those on the same host that do not conflict.
I'm not asking for a specific service admin group to be able to run it,
As far as I understand your request you should, but maybe a different solution is better as I do not understand why running puppet would be needed as the puppet catalog may not have changed. If some administrative task for a service requires this, an admin group for that service should ensure that a user in that group can perform that task. Permission for one task should only require membership in one group. Permission for one group of tasks like deployment of service x should only require membership in one group. Permissions are never assigned to individuals only to groups.
That being said I suspect that this ticket originates from an architectural deficiency in these services, maybe that is T93428...
Marko is basically the only person outside of ops taking care of all the operational aspects of all services at the moment: he is acting as a de-facto devops on all of the services stratum, including being involved in deployment, troubleshooting and infrastructural changes on all of them and on the base template all the node services are based on.
His de-fact role is that of 'services-admin' if you want; the fact that he is the only one doing that is somewhat a concern of course...
Back to the point: let's not get some (questionable, as I don't agree with everything in your arguments) principle get in the way of reality:
Marko is helping both ops and the dev teams in managing those services, and he needs to be able to enable/disable/run puppet, period.
I don't think he is interested in dealing with our bizantine intricacies or that spending his time (or mine, by the way) arguing about such mundane details is a good use of his abilities.
I am going to deal with this now, but please let's not get in such discussions over an access request we already approved.
Also, I think @mobrovac is the only one in Services who even has shell on sc* right now. That's not a sustainable situation, but lets address that separately. Edit: See T135548: Expand sc-admins to provide sufficient coverage for sc* clusters.