On Thu, 11 Oct 2012, David Nalley wrote:
F17 is not ready for automated deployment and hands off yum updates at the
customer's sole management -- it hangs wayy too often.
This is incredibly valuable feedback. If it's not overly proprietary
information, I'd be fascinated to know what the relative support load
from various distros is over their various releases. Any chance you
track that information??
sure: of Red Hat family derived distributions, no load from
CentOS (5 or 6; i686 or x86_64); no load from a private label
RHEL 6 sources s390x product; no load from Rosa; no load from
Mandriva; no load from a couple other 'private label'
distributions; all the load from Fedora (14, 15, 16, 17).
Within that, one issue in F16, all the rest in F17. I tested
a 'bleeding RawHide' offering possibility, but that was simply
an adventure of debugging, every time one updated
Would you mind sharing what hypervisor/container you were using.
CentOS 5 xen, CentOS 6 KVM, with minimal local addons
Aside from constant reboots, post-update reboots, is there any
additional areas for testing that you found need more
attention/testing?
Updates in a fast moving distribution like F are not economic
to support to the provider. If an update won't apply hands
off and reboot cleanly, it is broken. If one cannot always
run:
(shutdown, snap a quiescent backup, and restart)
yum -y update && reboot
of an an arbitrarily stale image in the supported cycle, it is
broken (Fedora expects 'nigh daily updates and reboots, but
people take vacations or dont reboot daily, so stale cruft
accumulates). So long as all is under package management and
in the four corners, one needs to be able to always update and
reboot
Particularly with F17, the complexity of building a well
formed set and durable (outside in the dom0) grub2 starting
configs is part of the real issue (we need to be able to
'hands off' migrate customer off xen and into KVM, at least
one way, as hardware aged and gets replaced), but there has
been breakage within updates inside the F17 domU's as well --
too many moving parts; we have to crawl through what backups
if any the customer has, to reconstruct what they did to their
instance; and and end customer has no good tools for managing
the same -- we revive when we can, or simply at least make
readible the corpse's image for salvage
We have had a tool so the customer can self-service get at,
and rsync down a copy, or NFS mount those RO loop mounted
corpses for a couple years now
We make quiescent backups trivial, but customers don't use
them enough. [Amazon's data recovery model model is 'we may
kill at any time' and you need to be ready to re-deploy from
gold masters and automated configuration on the fly, without
need for prior state; I think people have not figured out the
implications of this all that well]
The 'forever unfinished' and intentionally bleeding edge
nature of Fedora is part of it as well, or course. Update
churn is expected in Fedora, and that makes the most recent
gold release less suitable for use. The next back release
has at most 7 months to live, so it is hard to justify
investing much effort in paying for third-party (hosting
provider) supporting for most customers
We've (pmman.com) been providing VM's native ipv6 for a couple
years now, and think were the first non big-fish doing so
under a RHEL / CentOS base. Luke (prgmr) uses a Debian base
as I understand it, and is NOT permitting kernel updates at
all in his VM's. We've solved all of what Gene Czar
(Czarcinski) is hitting [the last couple week's libvirt ML]
long since
Our VM gold-images all abide the CentOS IRC test and rule
about being freely updatable at all times and not excluding
anything, so permitting updates of any package and not holding
out for special add on packages or such. A somewhat hard
constraint, but one I think will (probably) be attained
implicitly with the F gold images. External add-on archive
needs _should_ be satisfied by getting wanted matter within
the four corners of Fedora (mod Patent and License exclusions
-- and no need for sound modules and other problematic areas
by and large)
Our users include some very sharp cookies from (three major
Linux distribution's devloper user groups), and former
@redhat's so we are not dealing with novices here. FWIW, they
are hitting similar issues to those seen at pmman, when under
VMware as well, with F17
I expect once F18 goes gold, and update churn is less hectic
in F17 that we'll get F17 solved - but no bugs I would file on
F17 will (in all likelyhood) get fixed -- Fedora is forever
fixated on the future, and the auto-close rule permits
'papering over' issues too well. I cannot fight nor change
that, and there is no percentage in filing bugs that just get
auto-closed. Been there, done that.
Hope this helps
-- Russ herrold
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
