m (fix ML link) |
m (typo) |
||
Line 33: | Line 33: | ||
* If at any point in time the primary or secondary contacts become unresponsive, the project may be removed. | * If at any point in time the primary or secondary contacts become unresponsive, the project may be removed. | ||
* Test instances are NOT backed up unless requested. Once something goes live it will be brought into the normal fold of what we do | * Test instances are NOT backed up unless requested. Once something goes live it will be brought into the normal fold of what we do | ||
* | * Ultimately the board has final say on what is and is not "Fedora" | ||
[[Category:Infrastructure]] | [[Category:Infrastructure]] |
Revision as of 11:58, 7 August 2010
Purpose - Request for Resources
The purpose of this form is to help track requests for resources and to attach resources with their project leaders. In general the way this works is someone fills out an RFR ticket (see below) and sends an email to the infrastructure team for approval. If for some reason the request is denied the requester should take their issue to the Fedora Advisory Board or to the Fedora Project Board. If you work for a company or Red Hat and have a budget, you are far more likely to be able to get request approved. There's only so much stuff to go around.
Request Resources
All one has to do to request resources is choose the Infrastructure/RequestForResourcesTemplate . Then fill out a ticket on https://fedorahosted.org/fedora-infrastructure/ and join the fedora-infrastructure-list . Once on the list make sure to send an email about your RFR. Remember, not only is this a request, it is also a proposal. Include all information about why this is important for Fedora and why we should dedicate resources to test it and ultimately deploy, support and back it up.
All information on the page is required. Pay close attention to the "Expiration Date". This is the date by which this project will either be migrated to production hardware, or will have been declared a failure and taken to the board to decide if it should be deleted or remain.
What to expect
All infrastructure discussion is done in the open as much as possible. This is especially true for new ideas and new requests so be prepared to defend your ideas and make sure that you have a clearly defined goal in mind. Unfortunately our resources are finite and we can't just do everything for everyone whenever they ask for it. Requesters not satisfied here should not be discouraged, final say will always happen with the Fedora Advisory Board or the Fedora Project Board and even if they should say no, there's always other places to turn to to host your project.
Those who's project is approved may be given a complete Xen machine or only a service to work with. Those with an entire Xen machine must keep it up to date and in a working order. The purpose of the machine is to make sure that requests don't have to wait on the infrastructure team for action. It's a way for us to get out of your way while you are implementing this new service.
It is the job of those requesting resources to find a sponsor and convince them the project is worth their time. *Not all projects can be approved* If not initially accepted, remember to contact a sponsor and explain why the project should be accepted and how Fedora benefits from it. Contact a sponsor on the FIGs page related to the request. (For example, if you're building a website, contact a sponsor of the sysadmin-web or sysadmin-test group)
Project Leaders
In the perfect world your request would get approved and within days your request would be live and people could access it. In reality it takes much longer with a lot more work. This is especially true of the project leader. The project leader is typically the person who made the RFR and is responsible for seeing the project through to conclusion. They will need to find an infrastructure member with access to the test servers and must work together with the team to make sure the work is getting done.
The infrastructure team doesn't intentionally not do work but often times other things get busy and if a Project Leader isn't around to continue to work with Infrastructure by asking when things will be done and what can be done to help, then that RFR typically gets forgotten about. This is actually a very community way of doing things. In the corporate world the boss says do and it gets done. In the community world if the person who thought the thing up doesn't care to stick around and see it through to conclusion then its questionable if that thing should have been done in the first place.
Requirements
All Fedora Projects must be on working, supported hardware. Hardware that is EOLed or "hobby hardware" will never be accepted into Fedora Infrastructure for a production application that we then support. The bottom line is that we're not going to say "we now support this" if the box might die in the middle of the night and no replacements can be found. Fedora has grown and matured quite a bit since its inception, proper production hardware is part of that.
All production resources must be clusterable / load balanceable. Preferably the latter. So remember when you're asking for resources, you're typically asking for _at least_ double what you need to get something up and running. Shared storage or database being the exception to this. Make sure to think hard about what you're asking. Don't forget about backups and storage space. Imagine if your project is wildly popular but suddenly running out of disk space.
Warnings
- If at any point in time the primary or secondary contacts become unresponsive, the project may be removed.
- Test instances are NOT backed up unless requested. Once something goes live it will be brought into the normal fold of what we do
- Ultimately the board has final say on what is and is not "Fedora"