[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29398 [Internal Services/Tor Sysadmin Team]: Create a template for requesting infrastructure resources
#29398: Create a template for requesting infrastructure resources
-------------------------------------------------+---------------------
Reporter: ln5 | Owner: tpa
Type: task | Status: new
Priority: Medium | Milestone:
Component: Internal Services/Tor Sysadmin Team | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+---------------------
Comment (by Alan khan):
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.pagure.io/infra-docs/.....>
* **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/....>
.. _`Application Security Policy`: https://fedora-infra-
docs.readthedocs.io/en/latest/dev-guide/security_policy.html
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29398#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs