Kevin's musings

Over the years we have had many folks show up and ask us to run their web application in Fedora Infrastructure. Very often they don’t realize it’s not as easy as they first think to just write, deploy and maintain a full time application that our contributors and users will grow to depend on.

We have a process for new applications, called the Request for Resources: https://fedoraproject.org/wiki/Request_For_Resources at first glance it looks a bit long and arduous, but their are good reasons for the process and following it for new applications:

• First, does the application do something that helps Fedora or our users or contributors? Are their places that share our values already doing this thing? An example is when we ran wordpress. Sure it’s open source and useful, but wordpress.com does that as it’s primary mission, why not let them handle it better than we can and we can focus on Fedora.
• We have a bias (and I am happy to admit it is) to python and flask/pyramid framework applications. This is really due to the fact that our active applications developers and others know these frameworks, know how to deploy and manage them, how to look at logs, common problems or issues and so on. So, if you want to us to deploy and maintain an app that is not using that language or framework, you have a very steep road ahead.
• Do you have a group of folks working on your application, or is it just you? If it’s just you, we will likely stop right there until there’s more people involved. In addition to the problem of when you are away or unable to look at problems, applications developed by one single person also lack peer review and auditing for security issues or the like.
• Is your application packaged and available in EPEL? If not, that will be something you need to do before you even start the RFR process. The reasons for this: a known place to report bugs, known source and builds, signed packages, known place to contribute, known maintainers/co-mainainers, and easy way for us to watch new bugs as they are filed.
• Are you able and willing to port your application to newer releases as they happen? RHEL doesn’t release too often, but when it does we usually pretty aggressively move to new releases. You or your team should be ready to update your application for those new versions.
• Do we have some way to contact someone who knows the application well? If your application breaks at 4am on a Saturday morning, Fedora sysadmins will get paged, but if there’s no one available to help fix things, your application could be down a while, and that’s not something we want to deploy. Our users and contributors expect a high uptime from us, and we ensure that by making sure our applications are high quality and people are available to fix them.
• Can whatever you are trying to do be added to an existing application? We are usually happy to look at adding functionality where it makes sense, and if your goal is related to something we have already deployed perhaps it could just be added instead of running another application.
• We require SOP’s and docs be written as part of the RFR process. This isn’t just overhead, it’s to allow people to manage the application if they don’t have direct experience with it. If there’s a known good, documented process to do common tasks with your application anyone who has the ability and can read it can just do it and not be blocked on application authors being available.
• Likewise monitoring is important as part of the process. It’s easy to check that a web server is answering, but does that mean the application is up and running and healthy? Or are their other checks we could do that would test that?
• There’s some applications we run where we aren’t upstream for them. In those cases we really want to make sure that we have good communication with the upstream project and that it’s active and open to bug fixes and changes. Also, there should be several people on the Fedora infrastructure team that know those applications and are able to talk with upstream about our needs and fixes.

So, in summary, writing an application is only the very small start of the work involved. Packaging, deploying, documenting, maintaining, adjusting for changes, fixing bugs, fixing security issues, monitoring, all need to happen to and it’s up to YOU to plan for and provide those resources so you don’t leave Fedora Infrastructure trying to do them long after you are gone.

If you have ideas around a new application you expect to run in Fedora Infrastructure, you should come talk with us. The sooner in the process the better for you (no need to re-write an application later or redo a bunch of things to meet our process) and for us (help design new applications to meet our needs from the ground up).