Request for resources SOP

Once a RFR has a sponsor and has been generally agreed to move forward, this SOP will describe the technical parts of moving a RFR through the various steps it needs from idea to implementation. Note that for high level and non technical requirements, please see the main RFR page.

A RFR will go through (at least) the following steps, but note that it can be dropped, removed or reverted at any time in the process and that MUST items MUST be provided before the next step is possible.

Until a RFR has a sysadmin-main person who is sponsoring and helping with the request, no further technical action should take place with this SOP. Please see the main RFR SOP to aquire a sponsor and do the steps needed before implementation starts. If your resource requires packages to be complete, please finish your packaging work before moving forward with the RFR (accepted/approved packages in Fedora/EPEL). If your RFR only has a single person working on it, please gather at least another person before moving forward. Single points of failure are to be avoided.

Once a sponsor is aquired and all needed packages have been packaged and are available in EPEL, we move on to the planning phase. In this phase discussion should take place about the application/resource on the infrastructure list and matrix. Questions about how the resource could be deployed should be considered:

In this phase a development instance is setup for the resource. This instance is a single virtual host running the needed OS. The RFR sponsor will create this instance and also create a group 'sysadmin-resource' for the resource, adding all responsible parties to the group. It’s then up to sysadmin-resource members to setup the resource and test it. Questions asked in the planning phase should be investigated once the instance is up. Load testing and other testing should be performed. Issues like expiring old data, log files, acceptable content, packaging issues, configuration, general bugs, security profile, and others should be investigated. At the end of this step a email should be sent to the infrastucture list explaining the testing done and inviting comment. Also, the security officer should be informed that a new service will need a review in the near future. In the request for the security audit, please add the results of self-evaluation of the Application Security Policy. Any deviations from the policy must be noted in the request for audit.

The next step is to create a staging instance for the resource. In this step the resource is fully added to Ansible/configuration management. The resource is added to caching/load balancing/databases and tested in this new env. Once initial deployment is done and tested, another email to the infrastructure list is done to note that the resource is available in staging.

The security officer should be informed as soon as the code is reasonably stable, so that they can start the audit or delegate the audit to someone.

Finally the staging changes are merged over to production and the resource is deployed.

Monitoring of the resource is added and confirmed to be effective.

The resource will then follow the normal rules for production. Honoring freezes, updating for issues or security bugs, adjusting for capacity, etc.

You can copy/paste this template into your RFR ticket. Keep the values empty until you know answers - you can go back later and edit the ticket to fill in information as it develops.

Phase I

Phase II

Phase III

Phase IV