Server Admins: Why not Fedora?

[Kevin Fenzi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 01 Nov 2013 12:49:45 -0400
Stephen Gallagher <sgallagh at redhat.com> wrote:
...snip...

> I'm sure there are other reasons and I'd like to hear them. Also, for
> those of you who *do* use Fedora in production, I'd like to hear the
> reasons why you chose to do so. What did Fedora gain you?


So, I'll toss my 10 cents out here. :) 

First, at home I do run fedora on my servers. I have 2 big servers
(which I recently replaced/upgraded). One is my 'production' and the
other a 'test'. On the production one I run the most recent fedora
stable (right now f19) and on the test I usually jump it to branched
after or around alpha (so it's running f20 branched right now). 

For the most part things go pretty smoothly overall. I think the
updates policy we put in place a few years ago has helped at least
reduce those really nasty updates that break things badly. I typically
update my production server/vm's once a week or so. Even a week of
Fedora updates is usually quite a pile. I often don't really look, just
apply everything and if something breaks drill down to fix it. 

Now in Fedora Infrastructure: We used to run only 1 Fedora machine (our
compose machine that needed to run composes as the release it was
composing for). However, in the last few years we have branched out to
using Fedora in more places: 

* All the new arm builders are running Fedora (there's no RHEL/CentOS
  available for them yet). 

* So, since they were all Fedora, we moved all the other buildvm's
  also to Fedora (to keep things the same and since we were maintaining
  the build set anyhow). 

* We have also recently allowed Fedora in specific cases when
  RHEL/CentOS is too old. For example, the mailman01.stg hyperkitty
  instance is Fedora 19 (it needs a newer python and stack of things). 

Our pain points aren't so much the lifecycle. We have things setup to
redeploy machines pretty easily, doing so every 6 months shouldn't be a
big deal. The bigger pain for us is the updates flow. If you apply
fedora updates about once a week, theres a pretty gigantic pile of
them, so it would take you a while to look through them and see what
they are. If you apply less often (for our builders they are isolated,
so we just rebuild them with updates every few months), there's
basically no way to look at all the updates and see if you care. 

For the net facing machines (like hyperkitty) we have moved to
installing yum-cron and asking it to install security updates every
day. I'm not sure how well this is going to work in practice tho, as I
get the impression very few people just consume security updates, most
people just apply everything every day. 

So, IMHO the biggest thing we could do to help 'server' people wanting
to use Fedora would be to identify 'server' packages and try and make
sure updates are actually security issues or something that is actually
wanted/needed, and try and prevent piles of '1.0 to 1.0.1 minor update' 
Or perhaps we could look at bundling things and having a 'server'
update every 2 months or something that we test, with only security
updates between. Then server using folks could deploy Fedora 21 server,
just get security/critical until 21.1 came out and then they just
redeploy on 21.1 and lather, rinse, repeat. 

This doesn't mean to say that I wouldn't want more rapid updates on
desktops or other things... just that a core set of server packages
(and their deps) would be nice to be slower flowing. 

kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJSc/gHAAoJEEs3sNgP+7tefpMQAIyAAerCLUi2EPSC4CSJYyNn
tne0CpXftLC6S8oMPtnRIraHKf31uv/y56VjbRbe6QenUz9xtoYHJ4/Vb+deGfSf
T8fbvQVwXcRjf+x1DOMUD+f8xHCWTcq5kjaXG+DYneghwoJoIXUhPRWgd8eWLmZJ
T1WJRNG5fhop2/S8l7zcqWNRuBmIArjAtJo2cE5OH9WOX3x5Gnls/4d+XH6cP1zh
LMHibZMF9KzpreWRxXAwiVmm/fCxhLYByaOfF1dOG5wXLoCjmOdRymq8KjNDbYbt
5nwTHNS6vFVObplYi5d4jrQJQ2weVNwwWPAGUqcB1dPFbRISWJv29Jpxv//LW7Z+
/wYX18hOqLjEMCwyaUebOmyrI+LNMi2eiywug+L4y8gLo252w+Sey4DglSH/PgE0
jBPVIBgh4y5nh3KDskU0kb1VDnEcBPIQfC0Hs7BbSMWmIHwMmz79u1QcL1Ct8c+W
a7yZHVrAvBJ3di1ZPZwxOiS4sDBD4ifKpJThh/UJTsMWF/xeWpPTPIpiC8fpDlR1
LHvv59F3Yg4dU4PuHrRJUMjyN/HkY0F73t5tGtQseROsLTBAsXW/J1I3qSlmUo8A
3aV2uCYXjtTKJBPFWsq7URhwGJcQgYsVyQpyvQDx+lxzEtV1J2Fai4WmtDIH2LgL
BNYqWu6QfpUPaYnyphQr
=o7Uc
-----END PGP SIGNATURE-----