Infrastructure Apprentice

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(add some workflow items)
m (linked ansible docs page in Further Information)
 
(11 intermediate revisions by 8 users not shown)
Line 5: Line 5:
 
== Access to many infrastructure machines ==
 
== Access to many infrastructure machines ==
  
Members of the fi-apprentice group have ssh/shell access to many machines, but no sudo rights or ability to commit to puppet (but they do have read-only puppet access). Access is via the bastion.fedoraproject.org machine and from there to each machine. See the [[SSH Access Infrastructure SOP]] for more info.. Exceptions to this access are: backups*, db*, fas*, sign*, rel*, ns* and compose*, These machines may contain sensitive data and are almost always in a production mode.  
+
Members of the fi-apprentice group have ssh/shell access to many machines, but no sudo rights or ability to commit to ansible (but they do have read-only access). Access is via the bastion.fedoraproject.org machine and from there to each machine. See the [https://infrastructure.fedoraproject.org/infra/docs/sshaccess.rst SSH Access Infrastructure SOP] for more info. Exceptions to this access are: backups*, db*, fas*, sign*, rel*, ns* and compose*, These machines may contain sensitive data and are almost always in a production mode.
  
 
== Nagios alerts ==
 
== Nagios alerts ==
  
This group does NOT get Nagios alerts. If you wish to receive them, you should join the sysadmin group, otherwise you can see them trough #fedora-noc channel or Nagios web interface at: https://admin.fedoraproject.org/nagios/.
+
This group does NOT get Nagios alerts. If you wish to receive them, you should join the sysadmin group, otherwise you can see them trough #fedora-noc channel or Nagios web interface at: https://admin.fedoraproject.org/nagios/ and https://admin.fedoraproject.org/nagios-external
  
 
== Regular checkins ==
 
== Regular checkins ==
  
On the first of each month a mentor will mail all the folks in the group. This email will ask what tasks they are working on or interested in, what they are using their access for and if they intend to be active in infrastructure. Please look for and answer these emails as they come to you.
+
On the first of each month a mentor will mail all the folks in the group. This email will ask what tasks they are working on or interested in, what they are using their access for and if they intend to be active in infrastructure. Please look for and answer these emails as they come to you. If you fail to answer you will be removed from the group. Don't worry, it's easy to be re-added later when you have more time.
  
 
== Length of membership ==
 
== Length of membership ==
  
 
This group will be pruned often of inactive folks who miss checkins. Members who have not logged into any machine and/or are not active will be removed. There's nothing personal in this, and you're welcome to re-join later when you have more time.  
 
This group will be pruned often of inactive folks who miss checkins. Members who have not logged into any machine and/or are not active will be removed. There's nothing personal in this, and you're welcome to re-join later when you have more time.  
 +
 +
== Longer term quests ==
 +
 +
There's a few items we need help with ongoing and apprentices are encouraged to work on these items and provide patches and ask questions, etc. The current list:
 +
 +
* Update group variables in ansible for CSI standards for machines that don't have any listed. See: https://docs.fedoraproject.org/en-US/Community_Services_Infrastructure/1/html/Security_Policy/index.html for information on CSI, and look at the ansible repo under inventory/group_vars/ for groups without CSI information. Patches adding this information for groups can be sent to the infrastructure list to be reviewed and applied.
 +
 +
* Our docs aren't all using the same template. See the /git/infra-docs repo and propose patches to update documents to use the same templates as the rest.
  
 
== easyfix tickets ==
 
== easyfix tickets ==
Line 28: Line 36:
 
* Pick a ticket
 
* Pick a ticket
  
Look in https://fedorahosted.org/fedora-infrastructure/report/14 for a ticket that looks interesting to you. If the ticket is already assigned, but hasn't had any action in a while, feel free to ask on ticket if it's still being worked on, and if no reply in a week or so, take it over. Some tickets can be worked on by several people, so feel free to ask in ticket if this is one of those kinds of tasks and what part you can work on.  
+
Look in https://fedorahosted.org/fedora-infrastructure/report/14 for a ticket that looks interesting to you. If the ticket is already assigned, but hasn't had any action in a while, feel free to ask on ticket if it's still being worked on, and if no reply in a week or so, take it over. Some tickets can be worked on by several people, so feel free to ask in ticket if this is one of those kinds of tasks and what part you can work on. If a ticket seems really old and like it may no longer be needed, please add it to the agenda of the next meeting and we will discuss it there and close it or rework it as needed.  
  
* Make patch for fix from git puppet repo  
+
* Make patch for fix from git ansible repo  
  
Most any task will require changes to puppet. You can check this out on lockbox01 and make edits to your local copy. Apprentices don't have commit privleges, only checkout, so you will need to make your fix, get a patch of it and attach it to the ticket for someone to apply once it's been reviewed. See the http://infrastructure.fedoraproject.org/infra/docs/puppet.txt for how to check out the puppet git repo. Then 'git diff' should provide a patch for you against the current version in git.  
+
Most any task will require changes to ansible. You can check this out on lockbox01.phx2 (just "git clone /git/ansible" there) and make edits to your local copy. Apprentices don't have commit privleges, only checkout, so you will need to make your fix, get a patch of it and attach it to the ticket for someone to apply once it's been reviewed. Then 'git diff' should provide a patch for you against the current version in git.  
  
 
* Attach your patch to ticket
 
* Attach your patch to ticket
  
Attach your patch to the ticket and add a comment asking someone to review the patch and apply it if it looks good.  
+
Attach your patch to the ticket and add a comment asking someone to review the patch and apply it if it looks good. Note that trac doesn't send notification on just adding an attachement, you need to add a comment about your attachement as well so notification goes out to people watching the ticket to review your patch.
  
== IRC tips ==
+
== IRC Tips ==
  
 
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:  
 
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:  
Line 44: Line 52:
 
* 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.  
 
* 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.  
  
* Try and avoid Private messages to specific team members. Instead ask your questions in #fedora-admin or #fedora-noc 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.  
+
* Try to avoid private messages to specific team members. Instead ask your questions in #fedora-admin or #fedora-noc 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.  
  
 
* 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.  
 
* 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.  
Line 50: Line 58:
 
* 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.  
 
* 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.  
  
* Being active in IRC and asking questions is a great way to find out how things are setup and gain more trust.  
+
* Being active in IRC and asking questions is a great way to find out how things are setup and gain more trust.
 +
 
 +
* Watching discussion in IRC can often lead to some topic or area you might be interested in helping out with. If so, please feel free to chime in in channel that you would be interested in helping out and ask how you could do so.  
  
 
== Further information ==
 
== Further information ==
  
For further information on this group, please ask in #fedora-admin on irc.freenode.net and/or the fedora infrastructure mailing list.
+
For further information on this group, please ask in #fedora-admin on irc.freenode.net and/or the fedora infrastructure [[Infrastructure#Mailing_list | mailing list]].
 +
 
 +
Ansible documentation is available at http://docs.ansible.com/
 +
 
 +
[[Category:Infrastructure]]

Latest revision as of 21:09, 27 August 2015

Contents

[edit] Infrastructure Apprentice

The 'fi-apprentice' group in the Fedora Account System is one with a lot of read-only access to various Fedora infrastructure machines. This group is used for new folks to look around at the infrastructure setup, check machines and processes and see where they might like to contribute moving forward. This also allows apprentices to examine and gather info on problems, then propose solutions.

[edit] Access to many infrastructure machines

Members of the fi-apprentice group have ssh/shell access to many machines, but no sudo rights or ability to commit to ansible (but they do have read-only access). Access is via the bastion.fedoraproject.org machine and from there to each machine. See the SSH Access Infrastructure SOP for more info. Exceptions to this access are: backups*, db*, fas*, sign*, rel*, ns* and compose*, These machines may contain sensitive data and are almost always in a production mode.

[edit] Nagios alerts

This group does NOT get Nagios alerts. If you wish to receive them, you should join the sysadmin group, otherwise you can see them trough #fedora-noc channel or Nagios web interface at: https://admin.fedoraproject.org/nagios/ and https://admin.fedoraproject.org/nagios-external

[edit] Regular checkins

On the first of each month a mentor will mail all the folks in the group. This email will ask what tasks they are working on or interested in, what they are using their access for and if they intend to be active in infrastructure. Please look for and answer these emails as they come to you. If you fail to answer you will be removed from the group. Don't worry, it's easy to be re-added later when you have more time.

[edit] Length of membership

This group will be pruned often of inactive folks who miss checkins. Members who have not logged into any machine and/or are not active will be removed. There's nothing personal in this, and you're welcome to re-join later when you have more time.

[edit] Longer term quests

There's a few items we need help with ongoing and apprentices are encouraged to work on these items and provide patches and ask questions, etc. The current list:

  • Our docs aren't all using the same template. See the /git/infra-docs repo and propose patches to update documents to use the same templates as the rest.

[edit] easyfix tickets

There are tickets marked with the 'easyfix' keyword that may be suitable for apprentices to learn how things are setup, and also contribute a fix. See: https://fedorahosted.org/fedora-infrastructure/report/14 for this report.

[edit] Working on a ticket workflow

  • Pick a ticket

Look in https://fedorahosted.org/fedora-infrastructure/report/14 for a ticket that looks interesting to you. If the ticket is already assigned, but hasn't had any action in a while, feel free to ask on ticket if it's still being worked on, and if no reply in a week or so, take it over. Some tickets can be worked on by several people, so feel free to ask in ticket if this is one of those kinds of tasks and what part you can work on. If a ticket seems really old and like it may no longer be needed, please add it to the agenda of the next meeting and we will discuss it there and close it or rework it as needed.

  • Make patch for fix from git ansible repo

Most any task will require changes to ansible. You can check this out on lockbox01.phx2 (just "git clone /git/ansible" there) and make edits to your local copy. Apprentices don't have commit privleges, only checkout, so you will need to make your fix, get a patch of it and attach it to the ticket for someone to apply once it's been reviewed. Then 'git diff' should provide a patch for you against the current version in git.

  • Attach your patch to ticket

Attach your patch to the ticket and add a comment asking someone to review the patch and apply it if it looks good. Note that trac doesn't send notification on just adding an attachement, you need to add a comment about your attachement as well so notification goes out to people watching the ticket to review your patch.

[edit] IRC Tips

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.
  • Try to avoid private messages to specific team members. Instead ask your questions in #fedora-admin or #fedora-noc 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.
  • 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.
  • 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.
  • Being active in IRC and asking questions is a great way to find out how things are setup and gain more trust.
  • Watching discussion in IRC can often lead to some topic or area you might be interested in helping out with. If so, please feel free to chime in in channel that you would be interested in helping out and ask how you could do so.

[edit] Further information

For further information on this group, please ask in #fedora-admin on irc.freenode.net and/or the fedora infrastructure mailing list.

Ansible documentation is available at http://docs.ansible.com/