on the bigger image idea [was Re: removing NetworkManager from cloud image?]
On Fri, Oct 12, 2012 at 02:55:05PM -0400, R P Herrold wrote: > >>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** ? > no public reply to my expresion of dis-belief, and private > "atta-boy's" for being willing to challenge that assertion. > > Threading is messed up in the on-line archives that I reviewed, and > the source was not expresly attributed, but I _think_ this was > Matthew, setting up either a straw-man, or forwarding content from > people not participating here > > What is the case FOR fatter images, and by whom? Not a strawman. This one comes from a university group who would like to offer a cloud desktop system to each user. Right now done with a shared system with NX, but it's planned to give per-student machines with full root access using OpenStack. In that case, they can easily build their own images, and it's me speculating that it'd be useful to provide a more complete base image. However, I also can see, in the future, a "try Fedora desktop in the cloud" web page, with an big shiny launch button and automatic connection via noVNC. Here, there's plenty of sense in making it look as much like the desktop spin as possible, as that's the point. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
Sorry to self-reply, but I had three replies out of band, and
wanted to surface the concerns / responses I received:
On Thu, 11 Oct 2012, R P Herrold wrote:
Times have changed, and certainly mindset needs to change
given one is positioned in rich connectivity (a cloud)
[and on to the topic of NOT shipping NM]
1.
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' ...
The use case 'hats' I wear are: cloud provider, and
end-instance using sysadmin ("I'm not just a member of the
cloud club for men, ...")
We have had some pretty spectacular failures with novices who
do not know sysadmin, and have not yet learned to read
documentation. We usually address their concerns, and add a
post-support call notation to make sure our interface was
doing the right thing. Considering: 'Adding NM' has never
crossed our radar ;)
_I_ speak for NOT shipping NM, as there has not been forth a a
common use case for it, except as bitrot neglect or a desire
to accomodate, say, systemd and not carry forward the static
networking scripts may exist
I think that some of the custom networking issues that
enterprise _can_ present are simply hard -- but in a
reasonably well defined environment such as a cloud, much less
so. Most networking set-ups tend to be unchanging for a given
client image once deployed. We enable 'network' and dhcp for
image deployment, which permits us to provision and manage IP
allocations via our DHCP / RADVD server backend
To the clients it looks like plain old dhcp setup and
provisioning. If they attempt to alter settings and, say,
attept to add a second alias or statically configure an IP, it
is not going to work without co-operation from the network
fabric provider (the cloud hoster). We at pmman are already
blocking such traffic by iptables / ebtables rules anyway, and
rogue packets will simply be dropped [an open routing rogue
ipv6 tunnel advertiser by a customer, caused us some head
scratching a couple of years ago]
Having NM present just takes up space (process table, memory,
and image size) to no good end in the fabric a cloud provider
makes visible to guest machines, so far as I have heard to
date
2. later:
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.
The argument about adding it to facilitate QA and testing by
shipping such is orthogonal to whether it should REMAIN in a
master image, and not a reason to include it generally
3.
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** ?
no public reply to my expresion of dis-belief, and private
"atta-boy's" for being willing to challenge that assertion.
Threading is messed up in the on-line archives that I
reviewed, and the source was not expresly attributed, but I
_think_ this was Matthew, setting up either a straw-man, or
forwarding content from people not participating here
What is the case FOR fatter images, and by whom?
4.
these testing units are by definition 'throw-away' images
without volatile network connections (NOT in the
'sweet-spot' NM design use-case)
and I think also cloud instances generally are not needing the
'benefits' for volatile networking path management that NM
brings to the table.
NOTE: the same case may be made, perhaps not so emphatically,
for wanting a more traditional init, rather that the 'one ring
to rule it all' systemd, but that battle was long ago lost ;)
-- Russ herrold
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, 11 Oct 2012, Robyn Bergeron wrote: And not to distract from that the above information or train of thought in general - I will casually mention that this is the type of thing that makes me think that starting to work with QA on a better (or perhaps "existent") set of criteria / testing process for cloud images. I think right now for EC2 it is basically "does it boot" - and IIRC the switch to grub2 certainly hosed us up quite a bit. My later post goes beyond that: 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 (new content) which implies keeping a collection of 'point in time backups, and firing them up, and making sure that all still works. We are set up to do (and do) quiescent dailies on selected test vitim canaries, so we can replicate the 'point in time' that a customer's box may have been at, the day before it 'went off the tracks' http://gallery.herrold.com/F17-backup-tree.png We throw away dailies after a week, weeklies after a month, as most problems have surfaced pretty quickly Does anyone test the creation and usage of their own images using other tools around alpha/beta, or simply wait until post-final-release? As noted, I tried (via RawHide) and our local testing instances dom0's, but it was clear that this was a non-starter. Back, ten years ago, I also tracked RawHide dailies, when on the former: testers-list but this was pre-cloud and I had dedicated machines and scripts (primarily kickstart recipies) to do this with Best regards, -- Russ herrold ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
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 ___
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 5:45 PM, Robyn Bergeron wrote: > On Thu, Oct 11, 2012 at 11:34 PM, 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. >>> >>> 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 >>> >> >> Hi Russ, >> >> 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?? >> Would you mind sharing what hypervisor/container you were using. >> Aside from constant reboots, post-update reboots, is there any >> additional areas for testing that you found need more >> attention/testing? > > And not to distract from that the above information or train of > thought in general - I will casually mention that this is the type of > thing that makes me think that starting to work with QA on a better > (or perhaps "existent") set of criteria / testing process for cloud > images. I think right now for EC2 it is basically "does it boot" - > and IIRC the switch to grub2 certainly hosed us up quite a bit. +1 ... it sounds like there will be more that we _can_ test with cloud-init 0.7 in the picture. > Does anyone test the creation and usage of their own images using > other tools around alpha/beta, or simply wait until > post-final-release? > I've done a couple of rounds of testing with ami-creator as the builder and Eucalyptus as the target cloud. This is the first Fedora release I've done that for during alpha/beta, though. I've tried to use a kickstart as close as possible to the official Fedora one from cloud-kickstarts; seems okay so far. Andy ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 11:34 PM, 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. >> >> 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 >> > > Hi Russ, > > 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?? > Would you mind sharing what hypervisor/container you were using. > Aside from constant reboots, post-update reboots, is there any > additional areas for testing that you found need more > attention/testing? And not to distract from that the above information or train of thought in general - I will casually mention that this is the type of thing that makes me think that starting to work with QA on a better (or perhaps "existent") set of criteria / testing process for cloud images. I think right now for EC2 it is basically "does it boot" - and IIRC the switch to grub2 certainly hosed us up quite a bit. Does anyone test the creation and usage of their own images using other tools around alpha/beta, or simply wait until post-final-release? > > --David > ___ > cloud mailing list > cloud@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/cloud ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
> > 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 > Hi Russ, 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?? Would you mind sharing what hypervisor/container you were using. Aside from constant reboots, post-update reboots, is there any additional areas for testing that you found need more attention/testing? --David ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
default JEOS images [was Re: removing NetworkManager from cloud image?]
On Thu, Oct 11, 2012 at 03:08:30PM -0400, David Nalley wrote: > So I promise I'll shut up after this (really) No no -- please go on whenever you have anything it say. [read, read, read nod head] > If I am running a public cloud - I have my own magic stuff for things > like password resets (not everyone uses cloud-init), or setting ip > addresses, or perhaps (and this is more common than you would believe) > use a custom kernel. If a really tiny image is important, I can definitely see that -- the kernel rpm is the biggest thing in the image. > Both of these have the same issue - they need JEOS, but JEOS is > defined slightly differently for each environment. How do you get > there? Well you could take the Fedora image run it, customize it to > your liking, snapshot it, and then use that disk image as your 'fedora > jeos image'. However that's awfully manual - and to boot there's a new People *do* do this and want to do this, though. But, we also want to support Boxgrinder, Oz, etc. That's another front, basically. > 800lb gorilla in the room, and for that a truly minimal, vanilla > install that works is a good thing - I'd be willing to bet that a > Fedora EC2 image gets far more use than some of our spins. Everyone Yes, that's a very good bet -- by something like a million times. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 2:44 PM, Matthew Miller wrote: >> 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_. > So I promise I'll shut up after this (really) You are right that we haven't made it easy to do anything else, but at the same time a default image isn't useful to a lot of folks - and let me explain why. If I am running a private cloud - I need things like configuration management, and some base level of configuration, because I didn't stand up an infrastructure than can spawn hundreds of VMs in a few minutes only to have to manually touch them. If I am running a public cloud - I have my own magic stuff for things like password resets (not everyone uses cloud-init), or setting ip addresses, or perhaps (and this is more common than you would believe) use a custom kernel. Both of these have the same issue - they need JEOS, but JEOS is defined slightly differently for each environment. How do you get there? Well you could take the Fedora image run it, customize it to your liking, snapshot it, and then use that disk image as your 'fedora jeos image'. However that's awfully manual - and to boot there's a new Fedora every 6 months, which potentially means you have to repeat that process every 6 months - which means it's prone to be different. And if I make a mistake - oops gotta start over from scratch - or at least the last good snapshot. This means it is ripe for automation - (because it's something that is repeated, and needs to be exactingly repeatable, and because it's somewhat unique to the specific deployment.). This makes tools like Boxgrinder (and BG isn't the only such tool, there are a plethora - RHT alone has 4 such tools that I am aware of) ideal because it allows them to very rapidly (and repeatably) get to their definition of JEOS, and even iterate if necessary. Also - on the front of wide adoption - keep in mind, that with the exception of Amazon, every other major cloud provider builds their own image of Fedora. Amazon doesn't care and doesn't have to, they are the 800lb gorilla in the room, and for that a truly minimal, vanilla install that works is a good thing - I'd be willing to bet that a Fedora EC2 image gets far more use than some of our spins. Everyone else seems to do their own thing - perhaps they do that because there was no option, or perhaps they do that for everyone - but the level of customization that we see for 'default fedora images' suggests it is the latter. --David ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 12:47:16PM -0600, Kurt Seifried wrote: > One note: man pages are informational in nature. All the man pages are > available online easily (or another system), so you can fullfill the need > for informational man pages/etc quite easily without having them locally > (I do this). This strategy doesn't work for binaries/libraries/etc of Not installing the docs turns out to be fraught with difficulty. Not installing every locale would provide a bigger benefit, but is even more complicated. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 02:29:16PM -0400, Andy Grimm wrote: > >> Splitting off more of the dependencies, (for example > >> https://bugzilla.redhat.com/show_bug.cgi?id=809098) would also help and be > >> progress forward for everyone. Likewise, it'd be great to see a "run once" > >> mode for NetworkManager so it doesn't need to just sit there basically > >> doing > >> nothing in the cases where its more advanced features aren't needed: > >> https://bugzilla.redhat.com/show_bug.cgi?id=863515 > +1 to these ideas. I think this is the right way to move forward. If we can get traction on these, then I'm happy leaving it. I'm really looking for easy improvements (like, moving the developer documentation out of libxml2 into libxml2-devel), and if the general consensus is that this _isn't_ one of those, okay then. :) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/2012 12:29 PM, Andy Grimm wrote: > I second this question. I've been down the "as small as possible" > road (at rPath, 5 years ago), and it's possible to go too far. > For example, we could exclude all docs and man pages from the > image. That would make it smaller, sure, but is it worth it? > People who want that can build their own. One note: man pages are informational in nature. All the man pages are available online easily (or another system), so you can fullfill the need for informational man pages/etc quite easily without having them locally (I do this). This strategy doesn't work for binaries/libraries/etc of course =). - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQdxQ0AAoJEBYNRVNeJnmTG/kP/2Y3hQ7pFvm/pX/37HlI2hKc aUPimtN/cc9J6qog1vKQJjUeSQWAwuepE39Y15l8YKG3Xh5AGeDYu41yzu76BrhG uikzvprCbInWRYjSNZxnTGp1lI41qG/jzqvobhw7Wh+ERbXHZfhHIv5JFu/tfeIB WzxvMYYkMdFXVZzRx6zWAMWdnAub92dNIEWQ03KqWqO4rU6fdTmExW8sjQ/PXWU2 ZXEib5qmdqsYLOGfUK70jurtMQjoaN9p6T+nUsF+hxKSBhZfgF+i1TwIaw3WvgoV xxwmsYA5KLosVli+f3PL0T2ns6QnV6JAV+Nhzv3dIIn0sQ0aiYBhu+WBfMMQAiV3 JgD7IlSgkMcp1446xHCOhC9sbdn3/KimRq37QKdgJQsyTXkGsRlUplsfGe4JcTkI rjRMOC8a0JlvP5lM6d3zjKWzpvW/oWzSSp2UygcYE/fQKyt5/TfZ+RorssREQ/uC xDqszYzg9rrQWGMqHP/Sx4IQHTkJIzgDxJZ48KOHFDwaZfhymPFlUa7e28nELHK9 jaGVA29/ikxePFnAdILKLBs8EmwW9NZ5jIpaZVV5VmM4ThLpW/5Ca8TQkQa8i9N5 MLDgUdYw2oayD4X52UDv1MntvPZqT4wF/ZK2yKihP+1IobZm+LeL1DDrENCU63Ac wdcwGV0FI20RSA/PM6UZ =xckB -END PGP SIGNATURE- ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
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 > Where are you hearing this from? And who is saying this? Cloud > Providers? Users with one or two instances? massive deployments > (thousands of VMs)? Well I haven't talked to *anyone* who said "put in more stuff"¹. But I'm mostly talking about developers building things in the cloud (smallish deployments) who want to start with very little and put their own on top, and academic cloud environments (getting close to your definition of massive) where resources are scarce and demand is high. I've also heard this echoed from Robyn, who can probably provide some more. 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. > 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. 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_. (1. Except vim.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 2:17 PM, David Nalley wrote: > On Thu, Oct 11, 2012 at 2:03 PM, Matthew Miller > wrote: >> On Thu, Oct 11, 2012 at 01:41:31PM -0400, Andy Grimm wrote: >>> This feels like https://bugzilla.redhat.com/show_bug.cgi?id=693602 all >>> over again (the debate about whether to make "minimal" installs >>> include NM or to make sure that the network service starts correctly >>> when NM is absent). I am no fan of NM, but I think the memory >> >> 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 > > Where are you hearing this from? And who is saying this? Cloud > Providers? Users with one or two instances? massive deployments > (thousands of VMs)? I second this question. I've been down the "as small as possible" road (at rPath, 5 years ago), and it's possible to go too far. For example, we could exclude all docs and man pages from the image. That would make it smaller, sure, but is it worth it? People who want that can build their own. > , and this is an attempt to move in that >> direction. I know it's not a huge amount overall, but I also don't see much >> cost to doing it. The big changes are going to take a lot of work, so >> there's also value in hitting the various smaller ones for a cumulative >> improvment. > > 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. +1 ... this is the argument I made about SELinux to folks at Eucalyptus. Sure, we could switch it to permissive mode, but we still also have to test with it enforcing. This is the same thing -- we'd still need to ensure that each Fedora release works in various clouds with NM installed, so it might as well be the default way that we do things. >>> [...] and since the decision as far as I'm aware is >>> that "minimal" installs now contain NM, we should go along with that. >> >> Well, from the bug: "You'll still be able to install without NM via a >> kickstart if you really must." That's what I'm proposing, not blocking NM >> from Cloud entirely. (Which would be silly.) The primary reason that the old-style network service is still supported is that some key features like bonding still don't quite work in NM, but there is work happening upstream to this end. For example: https://bugzilla.gnome.org/show_bug.cgi?id=540995 >>> Wherever NM causes a problem, it should be treated as an NM bug and >>> fixed, not used as an excuse to deviate for the standard distro >>> install. >> >> Splitting off more of the dependencies, (for example >> https://bugzilla.redhat.com/show_bug.cgi?id=809098) would also help and be >> progress forward for everyone. Likewise, it'd be great to see a "run once" >> mode for NetworkManager so it doesn't need to just sit there basically doing >> nothing in the cases where its more advanced features aren't needed: >> https://bugzilla.redhat.com/show_bug.cgi?id=863515 >> +1 to these ideas. I think this is the right way to move forward. Andy ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 2:03 PM, Matthew Miller wrote: > On Thu, Oct 11, 2012 at 01:41:31PM -0400, Andy Grimm wrote: >> This feels like https://bugzilla.redhat.com/show_bug.cgi?id=693602 all >> over again (the debate about whether to make "minimal" installs >> include NM or to make sure that the network service starts correctly >> when NM is absent). I am no fan of NM, but I think the memory > > 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 Where are you hearing this from? And who is saying this? Cloud Providers? Users with one or two instances? massive deployments (thousands of VMs)? , and this is an attempt to move in that > direction. I know it's not a huge amount overall, but I also don't see much > cost to doing it. The big changes are going to take a lot of work, so > there's also value in hitting the various smaller ones for a cumulative > improvment. 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. > >> consumption angle is a weak argument (the RSS for NM on my system is >> 4MB right now -- that's less than 1% of the RAM of the smallest >> instance type in EC2), [...] > > 1% saved is 1% earned. :) We're not just targetting EC2, and many > local/private cloud providers would like to use smaller images. In my > experience, memory is easily the first limit hit in virtualization. Which local/private cloud providers? Everyone I know that has anything close-to-recent Fedora images is building their own. (I am really surprised at the amount of use Boxgrinder is getting for just that thing, in places so large that I wouldn't expect it.) My inference is that Amazon (corporately) is just so large that they don't really care (anymore) whether there is a Fedora image or not, and since Fedora 8 they really haven't gone through the hoops to get it there. Every other cloud provider that has Fedora has done the work on their own, and typically has custom bits they add to their image, or custom configuration, so that a Fedora produced image isn't going to be what they deploy. > >> [...] and since the decision as far as I'm aware is >> that "minimal" installs now contain NM, we should go along with that. > > Well, from the bug: "You'll still be able to install without NM via a > kickstart if you really must." That's what I'm proposing, not blocking NM > from Cloud entirely. (Which would be silly.) > >> Wherever NM causes a problem, it should be treated as an NM bug and >> fixed, not used as an excuse to deviate for the standard distro >> install. > > Splitting off more of the dependencies, (for example > https://bugzilla.redhat.com/show_bug.cgi?id=809098) would also help and be > progress forward for everyone. Likewise, it'd be great to see a "run once" > mode for NetworkManager so it doesn't need to just sit there basically doing > nothing in the cases where its more advanced features aren't needed: > https://bugzilla.redhat.com/show_bug.cgi?id=863515 > > ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 01:41:31PM -0400, Andy Grimm wrote: > This feels like https://bugzilla.redhat.com/show_bug.cgi?id=693602 all > over again (the debate about whether to make "minimal" installs > include NM or to make sure that the network service starts correctly > when NM is absent). I am no fan of NM, but I think the memory 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, and this is an attempt to move in that direction. I know it's not a huge amount overall, but I also don't see much cost to doing it. The big changes are going to take a lot of work, so there's also value in hitting the various smaller ones for a cumulative improvment. > consumption angle is a weak argument (the RSS for NM on my system is > 4MB right now -- that's less than 1% of the RAM of the smallest > instance type in EC2), [...] 1% saved is 1% earned. :) We're not just targetting EC2, and many local/private cloud providers would like to use smaller images. In my experience, memory is easily the first limit hit in virtualization. > [...] and since the decision as far as I'm aware is > that "minimal" installs now contain NM, we should go along with that. Well, from the bug: "You'll still be able to install without NM via a kickstart if you really must." That's what I'm proposing, not blocking NM from Cloud entirely. (Which would be silly.) > Wherever NM causes a problem, it should be treated as an NM bug and > fixed, not used as an excuse to deviate for the standard distro > install. Splitting off more of the dependencies, (for example https://bugzilla.redhat.com/show_bug.cgi?id=809098) would also help and be progress forward for everyone. Likewise, it'd be great to see a "run once" mode for NetworkManager so it doesn't need to just sit there basically doing nothing in the cases where its more advanced features aren't needed: https://bugzilla.redhat.com/show_bug.cgi?id=863515 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
Re: removing NetworkManager from cloud image?
On Thu, Oct 11, 2012 at 1:19 PM, Matthew Miller wrote: > The simple old-fashioned network configuration works just fine for basic > cloud use-cases which I can think of, and NetworkManager a) brings in a lot > of dependencies of little value in this case (e.g. ModemManager, > wpa_supplicant). Plus, out of the box in the EC2 image, NetworkManager is > the second-largest memory consumer (after dhclient). It's not huge, but if > we want to get as JEOSy as possible, this seems pretty painless and > straightforward. > > Thoughts? This feels like https://bugzilla.redhat.com/show_bug.cgi?id=693602 all over again (the debate about whether to make "minimal" installs include NM or to make sure that the network service starts correctly when NM is absent). I am no fan of NM, but I think the memory consumption angle is a weak argument (the RSS for NM on my system is 4MB right now -- that's less than 1% of the RAM of the smallest instance type in EC2), and since the decision as far as I'm aware is that "minimal" installs now contain NM, we should go along with that. Wherever NM causes a problem, it should be treated as an NM bug and fixed, not used as an excuse to deviate for the standard distro install. Just my two cents. Andy ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
