clalancette / oz

Automated installation for guest images
GNU Lesser General Public License v2.1
310 stars 129 forks source link

Red Hat derivative JEOS kickstarts do not really create JEOS images #35

Closed wzzrd closed 11 years ago

wzzrd commented 11 years ago

Hi Chris,

I just had a good look at the Aeolus / Katello combination, and it seems that the kickstart files that are shipped as part of oz do not really create JEOS environments.

The base package group, that is installed by the kickstarts by default contains significantly more packages than the core package group. The core package group is generally used by admins in cloud environments to deploy systems (that I know of, that is) and not the base package group. The core group, for example, does not contain wireless-tools, smartmontools, strace, plymouth, rsync and nano, just to name a few.

Would you accept a pull request that tunes down that amount of packages in the shipped kickstart files for Red Hat derivatives? I would think to do that by replacing '%packages' with '%packages --nobase' and adding things that are generally really needed in a JEOS environment, like openssh-clients, lvm2, ntp, maybe man, maybe xz, etc.

I understand that being 'really needed' is rather a vague term and open to discussion and that that discussion needs to be had first, before actually doing this. Do you think this is a discussion worth having?

clalancette commented 11 years ago

Hi there, I would actually love to cut down the default package set; it will make things faster all around. I just haven't had time to do it myself :). Oz itself only requires a few things to be installed inside the guest: cron, sshd, yum, and dhclient/NetworkManager. That being said, one of my heavy users (imagefactory) may have needs beyond this. Before we do this, I would like to ask their opinion. I can't seem to find a way to "add CC" in github here, but I'll forward this thread to Ian Mcleod and maybe he can comment here. Thanks for the interest, this would definitely be a welcome improvement.

Chris

wzzrd commented 11 years ago

Well, I use oz on my laptop to spawn vm's from time to time, but the main reason I'm asking this, is Katello / Aeolus, which I find very interesting. ImageBuilder is used in there, afaik, so they should definitely be part of this discussion.

imcleod commented 11 years ago

Speaking for Image Factory, I don't believe we use anything in factory above and beyond what you already need for Oz.

However, it's possible that people who have working templates containing commands that depend on the existing JEOS may have to modify them to pull in packages that are not in @core.

My own feeling is that this risks being more trouble than it is worth. Just a quick skim of the contents of base in the F16 comps file reveals a number of packages I think most/many people will find essential in even a minimal system. Among them: basic man pages, NetworkManager, at, logrotate, bzip2, ethtools, nfs-utils, openssh-clients (which you've already mentioned) and sudo (essential for some EC2 use cases).

clalancette commented 11 years ago

I guess it really comes down to what the philosophy of "JEOS" in Oz really is. There are some benefits to reducing the package set further, including reduced install time (less disk writing, potentially less network traffic), and a reduced size of the final image (meaning that moving the image around will be faster). One of the biggest complaints from Oz users is the time it takes to install guests, so anything that we can do to reduce that is a benefit.

On the other hand, I see Ian's point about it being a (probably) minor benefit, and it does carry some risk with it. I guess I'm on the fence about it. Maxim, what are your reasons for reducing the package set? I'm just trying to see if there is anything I missed above.

Thanks, Chris

clalancette commented 11 years ago

So, I ended up doing something a little more conservative here. I reduced the package sets for Fedora and RHEL slightly by setting the %packages section to only @base. For Fedora 17, that removed approximately 35 packages, which is something of a savings. I think that is probably the best we will be able to do. If you disagree, feel free to open up a new bug.