removing NetworkManager from cloud image?

R P Herrold herrold at owlriver.com
Thu Oct 11 22:59:07 UTC 2012


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



More information about the cloud mailing list