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
