[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Live Upgrade Special Interest Group



Dmitry Butskoy wrote:

Often test upgrading to the current development branch of one of the test releases from the previous general release

but our policy is to skip one release (i.e. FC1-->FC3-->FC5-->F7) ...

We use Fedora in a production environment, and half-year cycle is too fast for us. (CentOS and friends are "too slow" OTOH).

CentOS isn't going to be _that_ much different since it would approximate FC1->FC3->FC6 so far - especially if you wait for some updates to stabilize the fedora release before you upgrade. I'd think you would be better off using Centos as the base in production but building a few apps that matter to you from fedora src rpms or finding a repository that does that.


Actually, Fedora is capable for production environment!
For example, see the post https://www.redhat.com/archives/fedora-devel-list/2006-October/msg00928.html

In my opinion, anyone who has kept a fedora box running for any length of time has either used extremely common hardware or just been lucky. My experience, mostly on Dell and IBM server hardware with MPT scsi controllers is that every 6 months or so an update kernel won't boot. Yes you can select the previous kernel if you are at the console of the machine during the reboot, but most of my production boxes are in remote locations where that is not a reasonable option, and even if you do manage to select the old kernel you have to wonder what security updates you don't have installed.

Certainly, we have tried the way "RHEL/CentOS in the base plus some apps of more new versions". But then we have to re-compile all such "new apps" by hand,

Which generally amounts to taking a fedora source rpm and issuing a
rpmbuild --rebuild  ...  command.

> we have to browse for (security) updates of such apps
etc.

Or watch for it to appear in a fedora update that you run on a non-production machine.

OTOH, comparing "the base" of RHEL and "the base" of Fedora (stable, not rawhide) -- in the situation where we are skilled enough -- we had chosen Fedora. And even with the base of Fedora, from time to time we are compelled to use the newest versions of some apps.

In some cases you can find yum-compatible repositories that you can use with RHEL/Centos to get these apps.

It is always sadly for me to hear the recommendations to not use Fedora in production. At least it is not true!

Let's just say our experiences differ... I happen to feel rather strongly about production servers that fail to boot after updates.

Secondary, it is very harmfully for Fedora Project, and even for RHEL.

I don't see how it harms RHEL. The whole point of RHEL vs. fedora is the additional testing and stability. If the Fedora Project wanted their product to be used in production they would make stability a priority.

RHEL is based on Fedora, and expects that software in Fedora is tested enough (by community). But if Fedora is actually never used in the real critical production environments, then you cannot say "it is tested enough". I hope you do not believe that RedHat or anyone else can test all the real situations just in laboratories...

No, what I believe is that the testing mostly happens in non-production environments where you can afford the problems of an update that breaks or changes behavior.

If you can, you should use Fedora. Certainly there are situations where you can not, but if you do not use Fedora just because you are afraid, or you wish to spend more time for games rather than for filling bugzilla reports... No comments.

I don't use fedora in production because of previous experience. At approximately the points in time when the RHEL cuts have been made (late FC1,FC3,FC6), my experience has been that fedora became very dependable, so it is not impossible for that to happen. But, each next FCx version release after those made wild changes that I wouldn't want anywhere near a production machine.

--
  Les Mikesell
   lesmikesell gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]