6:11 p.m.
Hi
Here you go. Join the group and help make live upgrades work smoothly.
http://fedoraproject.org/wiki/SIGs/LiveUpgrade
Rahul
5:23 p.m.
Rahul Sundaram wrote:
Hi
Here you go. Join the group and help make live upgrades work smoothly.
http://fedoraproject.org/wiki/SIGs/LiveUpgrade
Excellent!
I'm already have done FC3-->FC5 by "yum upgrade" only. Yep, some magic
was needed. :)
And I even have plans to do FC5-->F7 these days immediately.
One thing is:
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).
Does such an expirience will be interesting for you?
BTW, the using of "yum upgrade" allows us to minimize an "outage"
period
for critical servers. Instead of up to 60min of update time by Anaconda,
we do "yum upgrade" on the live system, and have about 5min for reboot
(to catch new kernel and glibc).
Certainly, some packages from the new release should be ported to the
previous first -- for cases when "service foo restart" is not enough,
and we have to edit (new) config files manually (aka apache1-->apache2 etc.)
Regards,
Dmitry Butskoy
http://www.fedoraproject.org/wiki/DmitryButskoy
4:51 p.m.
Dmitry Butskoy wrote:
One thing is:
> 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).
Does such an expirience will be interesting for you?
Yes. Skipping a release and upgrading should work. Atleast that is what
we try to support.
Rahul
6:37 p.m.
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.
--
Les Mikesell
lesmikesell(a)gmail.com
7:51 p.m.
Les Mikesell wrote:
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
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, we have to browse for (security) updates of such apps
etc. 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.
It is always sadly for me to hear the recommendations to not use Fedora
in production. At least it is not true! Secondary, it is very harmfully
for Fedora Project, and even for RHEL.
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...
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.
~buc
8:11 p.m.
On Mon, 2007-10-22 at 18:21 +0400, Dmitry Butskoy wrote:
<snip>
It is always sadly for me to hear the recommendations to not use
Fedora
in production. At least it is not true! Secondary, it is very harmfully
for Fedora Project, and even for RHEL.
<snip>
I think it really depends on what you're looking for. For our school, I
was running three FC4 (later upgraded to FC5 and then FC6) servers and
got quite frustrated with having to upgrade them every 6-12 months,
especially as there were a number of issues I ran into during the
upgrade process (i.e. conf files needing a slightly different format for
something like Samba or BIND; I honestly don't remember exact details).
I ended up switching them over to CentOS 5 when it came out and I'm
quite happy with it, especially because I'm getting much fewer updates
and therefore rarely needing to restart them (think kernel updates).
On the other hand, we switched all of our desktop systems (except three
or four) over to Linux during the summer and Fedora 7 was my
distribution of choice there.
I only have to get the setup perfect once, and then I'm able to image it
to all of our desktops. That's something I can easily do every six
months, especially when the benefit is that the users get newer and
prettier software every six months. I've even managed to get beryl
running by default on 20 of the newer computers.
All that to say that CentOS vs. Fedora really comes down to your needs.
I haven't found Fedora to be particularly buggy or anything, but I did
find it a pain to update it as often as I needed to for my servers. On
the other hand, it's a perfect fit for my desktops.
Jonathan
9:02 p.m.
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(a)gmail.com
6056
days inactive
6058
days old
6 comments
4 participants
participants (4)
-
Dmitry Butskoy -
Jonathan Dieter -
Les Mikesell -
Rahul Sundaram