Live Upgrade Special Interest Group

[Les Mikesell]

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 at gmail.com