The GNOME Infrastructure Apprentice Program

One of the main obstacles we've been having with the Infrastructure Team over the time has been the lack of volunteers. Welcoming someone into the team meant trusting someone well enough to grant administrative privileges with all the consequences that takes in. Additionally even in the case we trusted the person who was applying for the role the training period was going to cost more time to an existing team member than it could afford in terms of time and things that could have been accomplished while at it with a direct benefit of the GNOME Project and Community.

Another problem that arose in the past has been our Puppet repository being completely private as it was storing certificates, passwords and other sensitive information we wouldn't want to make public.

With the advent of FreeIPA and more fine-grained permissions and the deployment of hiera-eyaml-gpg (and the migration of other sensitive information away from the Puppet repository itself) for external lookups of passwords, salts and other keys we are glad to announce the GNOME Infrastructure Apprentice Group.

Joining the Program

Prerequisites

The Program is open to everyone willing to help but we have some prerequisites in place. The interested person should be:

1. Part of an existing FOSS community
2. Familiar with how a FOSS Project works behind the scenes
3. Familiar with popular tools like Puppet, Ansible, Git
4. Familiar with RHEL as the OS of choice
5. Familiar with popular Sysadmin tools, softwares and procedures
6. Eager to learn new things, make constructive discussions with a team, provide feedback and new ideas

I think I do have the listed prerequisites, how do I join?

Joining the Program can be achieved in the following way:

1. Subscribe to the gnome-infrastructure and infrastructure-announce mailing lists

2. Join the #sysadmin IRC channel on irc.gnome.org

3. Send a presentation e-mail to the gnome-infrastructure mailing list stating who you are, what your past experiences and plans are as an Apprentice
4. Once the presentation has been sent an existing Infrastructure Team member will evaluate your application and follow-up with you introducing you to the Program

For applicants now being Apprentices

I was accepted as an Apprentice, what now?

As an apprentice you will be able to:

1. Access the Puppet and Ansible repositories the Infrastructure Team keeps around to manage all the machines running the GNOME Project.

Apprentices then can:

1. Suggest improvements to existing Puppet modules and/or Ansible roles

2. Start working on a project or easy-fix ticket available to them. Apprentice projects and easy-fix tickets will be listed under the Infrastructure GitLab project with a special label called [giapprentice].

Workflow suggestions

You might want to consider automatizing the following operations:

1. Auto indentation and other syntax-related editor plugins (making use of VIM's puppet-syntax-vim is highly recommended, files are available HERE

Why having a good Puppet knowledge is important for these tasks?

As stated above the only way you will have to initially contribute to the GNOME Infrastructure will be accessing the Puppet repository that stores all the configurations files for the GNOME machines currently in use. Proposing changes, new modules or reviewing existing modules thus require a good understanding of how Puppet internals do work and how they operate and fit together within the GNOME Infrastructure.

Once the Program will be more mature we'll introduce additional accesses for apprentices who have provided a good amount of contributions over the time and have demonstrated the needed dedication and passion when performing the tasks they were assigned to.

Cloning the Puppet repository

The Puppet repository is managed through Git and hosted on the GNOME's GitLab instance at https://gitlab.gnome.org/Infrastructure/puppet.

Cloning the Ansible repository

The Ansible repository is managed through Git and hosted on the GNOME's GitLab instance at https://gitlab.gnome.org/Infrastructure/ansible.

First patches and contributions

You've been looking at the existing Puppet modules or Ansible roles and you have an improvement in mind you'd like to propose? Submit it for review! this way:

1. Fork the upstream Puppet repository or 1. Fork the upstream Ansible repository

2. Add your changes to the forked repository
3. Submit them as a Merge Request directly to the upstream repository
4. Any of the Infrastructure Team members will review your patch and eventually approve, merge it

Validating your changes before submitting a patch

After you've made your changes and before submitting your patch against GitLab, you can:

1. Validate your syntax puppet parser validate init.pp

2. Lint your module puppet-lint init.pp

Testing your changes directly on the target production environment is actually not possible as that requires root access on the machine.

What you should avoid

Being an Apprentice is a great occasion we provide to contributors to start learning our processes, procedures and tools. There are specific behaviours we would like you to avoid while being part of the Program and specifically:

1. Do not request more permissions than you currently have, existing members will propose you for a higher role if they feel so
2. Do not request to join the Infrastructure Team as a full member after contributing for just a few months

3. If you are unable to keep contributing for some reason please let the team know by mailing the gnome-infrastructure mailing list

IRC suggestions

One of the primary ways the infrastructure team communicates is via IRC. Here's a few tips to best communicate with the rest of the team: Feel free to ask questions when you think of them/run into them, but don't expect everyone to drop what they are doing and answer right then. Please be patient.

1. Try to avoid private messages to specific team members. Instead ask your questions in #sysadmin if at all possible. This allows anyone to help you out and also other folks to see the answer and peer review the answers you get.
2. Try and assume best intentions on past decisions. There is often a reason for something being setup the way it is or there's some history behind it. "Have we considered switching from foo to bar?" is great, "Why are you using foo! bar is better, we should switch to it right now" is not.
3. Keep in mind many of the infrastructure folks are busy, so do try and avoid 'pinging' them unless there's a specific need or you know they are active in channel. Many people have a IRC 'trigger' that notifies them when someone mentions their nick.
4. Being active in IRC and asking questions is a great way to find out how things are setup and gain more trust.