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][12]00[12].
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Joe | T134251 Allow mobrovac to run puppet on SC(A|B) | |||
| Resolved | Joe | T135386 Cleanup puppet from unneeded and empty single-service "roots" |
Event Timeline
Comment Actions
There is no single admin group "sca" or "scb". These are collections of services and admin groups.
sca means:
- cxserver-admin
- zotero-admin
- apertium-admins
scb means:
- citoid-admin
- citoid-roots
- citoid-users
- cxserver-admin
- graphoid-admin
- mathoid-admin
- mathoid-roots
- zotero-admin
- mobileapps-admin
- changeprop-admin
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.
Comment Actions
Given the request, I think it'd be wise to set up something new. My request is not tied to a particular service role, but to the hosts themselves.
Comment Actions
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
Comment Actions
I'd go for sc-admins (as in Service cluster admins).
Not sure to whom the question is directed, nor the question itself really. Mind elaborating?
Comment Actions
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 .
Comment Actions
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.
Comment Actions
Because the concept of SC(A|B) is already a deviation from that:
How so? The concept is designed to allow multiple roles/services per host.
Comment Actions
@JanZerebecki Puppet runs on a per-host basis, not per-service. Hence, I'm not asking for a specific service admin group to be able to run it, but I'm asking that I can do it. I'm not sure what is bothering you about that.
Comment Actions
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...
Comment Actions
While I appreciate some of the principles (but not all) put forward by @Dzahn and @JanZerebecki, I am used to reason in terms of reality and not in terms of principles:
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.
Comment Actions
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.
Comment Actions
Change 288928 had a related patch set uploaded (by Rush):
admin: general service cluster group
Comment Actions
Change 288929 had a related patch set uploaded (by Rush):
admin: add sc-admins to sc(a|b) hosts