kubevirt / libvirt

DEPRECATED Vanilla dockerized libvirt image, used as a base for kubevirt

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Container size can be reduced

stu-gott opened this issue · comments

Because this image is currently based on Fedora, we're pulling in a large number of unused dependencies. This noticeably increases first-time use (before docker gets a chance to cache the image).

We should attempt to use a smaller base image if possible.

In general I do consider this to be rather an enhancement than a bug, because it is just a on time speed thing.

However, on a first thought I see a few options to improve this, so just for the record:

  • Use blacklisting to remove unneeded dependencies
  • Use the centos7-atomic base image, to use an even smaller base image
  • Try an alpine based image

@stu-gott Can you check if this is still relevant? Since the fedora image got slimmed down, I don't think there's much that can be removed anymore. Trying to remove each package I found out there are 14 removable packages which make it total of roughly 20 MB, out of which almost 10 MB is cracklib-dicts.Given the fact that the installed packages are in another order of magnitude, I don't see the point in it. If you have an idea instead, let me know.
@fabiand Distro changing can be an option, but I think there are more important things distro-related (security updates, etc.) than image size. Again, if you have any more idea, let me know.

For the reasons mentioned above I would close this in case there are no ideas in a couple of days. Just to start cleaning some queues slowly.

I agree on distro and image size.

However, the distro discussion has a different impact and I'll raise that discussion elsewhere.

For me size is not an issue atm.

One more thing is that if this is based on the same distro as other kubevirt images, then changing the distro will actually make everyone pull two distros instead of one.
@stu-gott Are you OK with this staying as it is given the circumstances?

The base image/distro argument is a good oen.

At best we have the same base.

@nertpinx Yes, let's go ahead and close this. As @fabiand originally noted this is an enhancement anyways, and as you point out, it's not necessarily helpful.