= Request for resources SOP

== Contents

* <<_contact_information>>
* <<_introduction>>
* <<_pre_sponsorship>>
* <<_planning>>
* <<_development_instance>>
* <<_staging_instance>>
* <<_production_deployment>>
* <<_maintenance>>

== Contact Information

Owner::
  Fedora Infrastructure Team
Contact::
  #fedora-admin
Location::
  fedoraproject.org/wiki
Servers::
  dev, stg, production
Purpose::
  Explains the technical part of Request for Resources

== Introduction

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.

== Pre sponsorship

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.

=== Requirements for continuing:

* MUST have a RFR ticket.
* MUST have the ticket assigned and accepted by someone in
infrastructure sysadmin-main group.

== Planning

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:

* Should the resource be load balanced?
* Does the resource need caching?
* Can the resource live on it's own instance to separate it from more
critical services?
* Who all is involved in maintaining and deploying the instance?

=== Requirements for continuing

* MUST discuss/note the app on the infrastructure mailing list and
answer feedback there.
* MUST determine who is involved in the deployment/maintaining the
resource.

== Development Instance

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
xref:developer_guide:security_policy.adoc[Application
Security Policy]. Any deviations from the policy _must_ be noted in the
request for audit.

=== Requirements for continuing

* MUST have RFR sponsor sign off that the resource is ready to move to
the next step.
* MUST have answered any outstanding questions on the infrastructure
list about the resource. Decisions about caching, load balancing and how
the resource would be best deployed should be determined.
* MUST add any needed SOP's for the service. Should there be an Update
SOP? A troubleshooting SOP? Any other tasks that might need to be done
to the instance when those who know it well are not available?
* MUST perform self-evaluation of the
xref:developer_guide:security_policy.adoc[Application
Security Policy].
* MUST tag in the security officer in the ticket so an audit can be
scheduled, including the results of the Security Policy evaluation.

== Staging Instance

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.

=== Requirements for continuing

* MUST have sign off of RFR sponsor that the resource is fully
configured in Ansible and ready to be deployed.
* MUST have a deployment schedule for going to production. This will
need to account for things like freezes and availability of
infrastructure folks.
* MUST have an approved audit by the security officer or appointed
delegate.

== Production deployment

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.

== Maintenance

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

== Ticket comment template

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

* *Software*: <mynewservice>
* *Advantage for Fedora*: <It will give us unicorns>
* *Sponsor*: <someone>

Phase II

* *Email list thread*: <https://lists.fedoraproject.org/....>
* *Upstream source*: <https://github.com/...>
* *Development contacts*: <person1, person2>
* *Maintainership contacts*: <person2, person3>
* *Load balanceable*: <yes/no>
* *Caching*: <yes/no, which paths, ...>

Phase III

* *SOP link*: <https://docs.fedoraproject.org/infra/sysadmin_guide/.....>
* *Application Security Policy self-evaluation*: ....
* *Audit request*: <https://pagure.io/fedora-infrastructure/issue/....>
(can be same)
* *Audit timeline*: <04-11-2025 - 06-11-2025> (timeline to be provided
by the security officer upon audit request)

Phase IV

* *Ansible playbooks*: <ansible/playbooks/groups/myservice.yml>
* *Fully rebuilt from ansible*: <yes>
* *Production goal*: <08-11-2025>
* *Approved audit*: <https://pagure.io/fedora-infrastructure/issue/....>
