Adding new admin members
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD1B96442B9F85C7EF612144 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What should our process be for: * When a new person is interested in helping on the Infra team? * When that new person is ready for more more responsibility? * When that new person is now an experienced person and can be handed one or more root account accesses? Ideally we'll use sudo and groups to segment what people can do, so that means: * What are the logical groups we should make for sudo? ** One for each service we want to split out? - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enigCD1B96442B9F85C7EF612144 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iD8DBQFQzzae2ZIOBq0ODEERAs/ZAJ4vvIGNtpI6J6P/svk15B3HG8AyJgCaA/DP pzzqG9FkCuq3OwlVJz8zrTw= =tbdI -----END PGP SIGNATURE----- --------------enigCD1B96442B9F85C7EF612144--
Well, as I see it, you should have your different services documented, each service could essentially have different kind of levels of access. Depending on that service. Isnt someone "responsible" for each service, they should be able to specify what different levels they'd like to offer to different people. - - Regarding the point of "verifying" a user, I guess it'd be good to have some sort of "mentorship" or "apprenticeship"-thing where someone will be their contact person in the desired project/group they get involved with. This person is responsible to approve/disapprove the new person. To verify both their knowledge and wether or not they can be "trusted". Not that the information in oVirt perhaps is something secretive but yeah, I think you get it. - - Now, who has root? Well, essentially, this ought to be a very limited set of users. Now, I've got lots of experience from organisations of different sizes. And it truly goes the wrong way as the number of people with root access increases. Mainly because some just arent knowledgeable enough to be entrusted with such an access. They put the systems at risk all the time. Which is bad. - - ... Well, these are just my thoughts on the subject. I guess I fall into the category of people that want to be accepted into the "infra team". But still, the above is the basis I'd like to see in any organisation. On Mon, Dec 17, 2012 at 4:13 PM, Karsten 'quaid' Wade <kwade@redhat.com>wrote:
What should our process be for:
* When a new person is interested in helping on the Infra team? * When that new person is ready for more more responsibility? * When that new person is now an experienced person and can be handed one or more root account accesses?
Ideally we'll use sudo and groups to segment what people can do, so that means:
* What are the logical groups we should make for sudo? ** One for each service we want to split out?
- Karsten -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- /Alexander Rydekull
I think that moving to new jenkins,foreman server will allow us to better manage authership via misc roles. jenkins will probably use open-id plugin to allow access and we'll manage users permissions per project/view.. foreman also have a very extensive permissions system, so we can allow certain users to manage some services without giving them administrator. as for "sudo" access, we can create "system jobs" in jenkins to allow specific functions to run on slaves, like installing new rpms on jenkins slaves (which we have now). Eyal. ----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, December 17, 2012 5:13:30 PM Subject: Adding new admin members
What should our process be for:
* When a new person is interested in helping on the Infra team? * When that new person is ready for more more responsibility? * When that new person is now an experienced person and can be handed one or more root account accesses?
Ideally we'll use sudo and groups to segment what people can do, so that means:
* What are the logical groups we should make for sudo? ** One for each service we want to split out?
- Karsten -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (3)
-
Alexander Rydekull -
Eyal Edri -
Karsten 'quaid' Wade