Re: removing NetworkManager from cloud image?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 11 Oct 2012, Matthew Miller wrote:

On Thu, Oct 11, 2012 at 02:17:14PM -0400, David Nalley wrote:

It's basically the same, but we have a different use case than a
_generic_ minimum install. I repeatedly hear that the base Fedora cloud
image should contain as little as possible

Times have changed, and certainly mindset needs to change given one is positioned in rich connectivity (a cloud) -- With FOSS and well stocked repositories, being able to get to a machine (a working network connection, and a listening SSH server, and then a functional package management tool, are really about all and end-user admin needs. One then adds packages to taste, ex post

Where are you hearing this from? And who is saying this? Cloud
Providers? Users with one or two instances? massive deployments
(thousands of VMs)?

We have run several hundred VMs for customers for several years, so are by no means, a 'whale' but one needs to provide a knowledgeable customer little more. A non-skilled customer has to face the learning curve, but the base image is not the place to do it; customized 'training wheel' images may be, but are out of scope here (as I understand the present discussion)

I've also heard some demand for a _bigger_ image -- "developer desktop in the
cloud", but I think that's a future step. That one almost certainly *would*
include NetworkManager.

** Really** ? If an end image user 'demand[s]' a fat machine or a fat environment, they are not well-informed. Harder to deploy quickly, harder (slower) to migrate, harder to backup, harder to roll-back to a backup. As they will become experienced, when they mature as developers, if they are serios, they will also be moving to building in clean chroots (mock and friends) which they can stuff full of cruft to their heart's content, and where the NM is really not in play

TESTING usually needs to happen in a local subnet [I say this having just come back from 'kicking' a LOCAL developmental KVM dom0 that got hung up for some reason; if it had been a domU I would have just snapshotted it, and killed it outright and picked through a loopmount corpse to see what went wrong]. With the move to integrated DevOps (puppet, cfengine, etc), these tsting units are by definition 'throw-away' images without volatile network connections (NOT in the 'sweet-spot' NM design use-case)

At least one additional cost comes in the form of QA - we can be
relatively certain that if NM works in a VM it will work in our cloud
image.

easy enough to see a NM failure to deploy in a local testing network with a broken box; h*ck -- the ModemManager ticket removals request that was cited sits untouched after six months -- NM will never be completed at that rate, as I read through the 'passage of time' based closes on prior NM reports

That's a good point, but as far as I know the "legacy" network scripts are
also still supported, right? (initscripts is still in the critical path).
Unifying network configuration in one code base seems like a good goal --
one of my motivations for the NetworkManager "one-shot config" RFE.

Everyone I know that has anything close-to-recent Fedora images is
building their own. (I am really surprised at the amount of use

Well, we haven't made it easy to do anything else. We're going to make it
easy with F18, and I think the smaller we can get it the more well-received
and useful to people it will be. One goal I have is to make the raw image
small enough that it's reasonable to distribute uncompressed to the Fedora
mirror network. That makes it trivial for users to pick it up and _go_.

F17 is not ready for automated deployment and hands off yum updates at the customer's sole management -- it hangs wayy too often.

In part I don't understand why F17 is so unsuitable; The move to grub2, and its partial completion have caused reboots to fail without warning through updates. It was bad enough to induce us to remove F17 images we had previously made visible to end customers, as the support load exploded and the cusomers did not want to pay for support on a bleeding edge, and unfinished product. F15 and 16 were fine (there was a niggling issue on F16 we had to address)

-- Russ herrold
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud



[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux