On Mon, 10 Jan 2011, "Jóhann B. Guðmundsson" wrote:
> On 01/10/2011 04:55 PM, Mike McGrath wrote:
> > It's just about identifying what ones needs are, and picking the best OS
> > for the need. In Fedora's case we do have Fedora on some servers, but for
> > most of our needs RHEL is a better fit.
>
> Certainly that would apply in most cases but since we are distribution
> in it self we should be showcasing what Fedora is capable of doing.
>
One thing it'd be capable of doing is consuming large amounts of our
infrastructure team's time upgrading our hosts regularly.
> How do you feel this reflects on the work that the cloud SIG and server
> SIG are trying to do?
>
I'm pretty sure the cloud SIG and server SIG are intimately familiar with
the issues of running Fedora in a server environment. There are still
several good reasons to have a cloud SIG and server SIG focusing on those
use cases.
> Which services does our own infrastructure considered better to run on
> RHEL than Fedora that can not live on a 13 month life cycle?
>
git, fedorahosted, web applications, reverse proxy servers, our mail
servers, our collaboration servers (including this mailing list, asterisk,
gobby), the build servers, the database servers, our virtualization
servers, monitoring servers, fedora people, torrent, mirrors, account
system, and DNS immediately come to mind.
I'm afraid you're falling into a common fallacy (one I tried to outline in
my initial post) and you're focusing on the tools and not the problems
we're trying to solve.
The fact is a 13 month life cycle is useless to us in Fedora
Infrastructure, 13 months is a myth. Run this thought experiment:
Lets say we somehow got everything migrated to Fedora 14 on release day.
Everything is running great, everyone is happy.
6 months go by and now Fedora 15 is out. Everyone is happy.
We look around at the services listed above and oh, crap. We've got 6
months to migrate everything to Fedora 16. Stop doing *EVERYTHING* and
get to coding, testing, setting up a staging environment. Test the
upgrade path to the database servers, make sure all custom code we have
written works on the new libraries we're going to have.
But there's a got'cha here. You see, Fedora 16. The one we're going to
upgrade to. Is still rawhide. We don't even know what it's quite going
to be. So we wait. until about half way through the cycle. Now. We've
got 3 months or so to make sure everything works in the new Fedora 16.
Then 1 month to actually pull it off. If we slip, even a little bit.
We're now running on systems that are no longer getting security updates.
If we've run short on people to run migrations what do we do with those
systems? Hell, it took us 9 months to get fas working on the new 0.5
sqlalchemy not 3. That was just ONE service. Even as I write this I am
laughing a little bit at the thought of having to upgrade everything in a
4 month time span. We don't have anywhere near the resources to do that.
So sure, we could run Fedora for everything, especially if we slimmed our
offering considerably. But what do we gain? Many of the systems above
hardly change as far as their primary purpose goes. Look at our dns
servers. They run bind. But they also have several underlying systems
that make them part of our infrastructure. Monitoring, configuration
management, account systems, etc. So by upgrading dns every 6 or 12
months, literally gain NOTHING. But the time lost in creating the staging
tests, upgrading them, running the tests, then scheduling the downtime in
production and doing the actual upgrades is actually quite large.
I get where the "we should run Fedora" sentiment comes from. I do. But
even a surface level look into what it would take to actually run Fedora
in our infrastructure makes it clear why we don't. It's just about
picking the right tool for the job is all.
-Mike
_______________________________________________
advisory-board mailing list
advisory-board@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
