Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

BTW: I'm considering writing my own "supervisord"-like in go (to make it
single binary)

which unlike runit, s6 and others does not intend to be full init system
(no ttys, no logs, no crons)
just like supervisord, it just process supervisor that allow you to run
multiprocess container.
I'm considering an almost compatible ini syntax to systemd (so it could be
called go-systemd, or yet another fake systemd)

why not just supervisord, because we are considering python-less micro base
image for apps that does not need python specially go binary containers
(ex. busybox, etcd, kube*, .. )

but I'm not sure if this is even a good idea or not



On Thu, Jul 14, 2016 at 12:02 AM, Muayyad AlSadi  wrote:

> Try fake runtime which provides systemd (fake one indeed).
>
> On Wed, Jul 13, 2016, 11:55 PM Colin Walters  wrote:
>
>>
>>
>> On Mon, Jun 20, 2016, at 01:57 PM, Micah Abbott wrote:
>> > On 06/20/2016 09:38 AM, Joe Brockmeier wrote:
>> > > Have we published any comparisons of an Alpine image "fully loaded"
>> > > (e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you
>> actually
>> > > install things like Apache httpd, or whatnot the comparison looks much
>> > > closer.
>> >
>> > I hacked up some quick Dockerfiles for this particular example (httpd)
>> > and the end result is that alpine was still smaller - 8.652 MB vs.
>> 232.8 MB
>>
>> The largest chunk of this is that the httpd RPM pulls in systemd, and
>> that's
>> going to be true presently for a lot of our RPMs.  So that's a whole
>> subthread to this.
>>
>> It'd be possible to teach micro-yuminst to just ignore requirements
>> on specific packages like systemd, while still allowing anyone who
>> explicitly
>> wants them to pull them in.
>>
>>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

Try fake runtime which provides systemd (fake one indeed).

On Wed, Jul 13, 2016, 11:55 PM Colin Walters  wrote:

>
>
> On Mon, Jun 20, 2016, at 01:57 PM, Micah Abbott wrote:
> > On 06/20/2016 09:38 AM, Joe Brockmeier wrote:
> > > Have we published any comparisons of an Alpine image "fully loaded"
> > > (e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you actually
> > > install things like Apache httpd, or whatnot the comparison looks much
> > > closer.
> >
> > I hacked up some quick Dockerfiles for this particular example (httpd)
> > and the end result is that alpine was still smaller - 8.652 MB vs. 232.8
> MB
>
> The largest chunk of this is that the httpd RPM pulls in systemd, and
> that's
> going to be true presently for a lot of our RPMs.  So that's a whole
> subthread to this.
>
> It'd be possible to teach micro-yuminst to just ignore requirements
> on specific packages like systemd, while still allowing anyone who
> explicitly
> wants them to pull them in.
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Colin Walters]

On Mon, Jun 20, 2016, at 01:57 PM, Micah Abbott wrote:
> On 06/20/2016 09:38 AM, Joe Brockmeier wrote:
> > Have we published any comparisons of an Alpine image "fully loaded"
> > (e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you actually
> > install things like Apache httpd, or whatnot the comparison looks much
> > closer.
> 
> I hacked up some quick Dockerfiles for this particular example (httpd) 
> and the end result is that alpine was still smaller - 8.652 MB vs. 232.8 MB

The largest chunk of this is that the httpd RPM pulls in systemd, and that's
going to be true presently for a lot of our RPMs.  So that's a whole subthread 
to this.

It'd be possible to teach micro-yuminst to just ignore requirements
on specific packages like systemd, while still allowing anyone who explicitly
wants them to pull them in.

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I'll be happy if arg parsing is missing but the assumed default is nodocs

On Wed, Jul 13, 2016, 11:47 PM Colin Walters  wrote:

> On Wed, Jul 13, 2016, at 04:40 PM, Muayyad AlSadi wrote:
>
> What about my question about the equivalent of "--setopt tsflags=nodocs"
>
> @walters does micro-yuminst assume this option
>
>
> https://github.com/cgwalters/micro-yuminst/issues/1
>
> I'll rework the command line parsing soon to better support things like
> this.
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Colin Walters]

On Wed, Jul 13, 2016, at 04:40 PM, Muayyad AlSadi wrote:
> What about my question about the equivalent of "--setopt
> tsflags=nodocs"
>
> @walters does micro-yuminst assume this option
 
https://github.com/cgwalters/micro-yuminst/issues/1
 
I'll rework the command line parsing soon to better support things like
this.
 

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

What about my question about the equivalent of "--setopt tsflags=nodocs"

@walters does micro-yuminst assume this option

On Wed, Jul 13, 2016, 11:25 PM Colin Walters  wrote:

> On Wed, Jul 13, 2016, at 09:40 AM, Tim St. Clair wrote:
>
> Awesome!
>
> Do we have a formal position, or is this still POC?
>
>
> Still a PoC, but I believe it'd be relatively easy for downstreams to
> productize.  For
> example, we're using librepo[1] which is the same library used by dnf (and
> rpm-ostree)
> that knows how to speak TLS client certificates[2] that Red Hat Enterprise
> Linux uses
> to gate access to content.  And for that matter implements RPM GPG
> verification the same
> way.
>
> In general the micro-yuminst layer will require some maintenance but not
> that much;
> "yum -y install" is 95% of anyone wants to do in Docker images.
>
> Probably the next interesting question is whether the current base images
> should derive from this.
>
> Anyways, I encourage feedback as issues in
> https://github.com/cgwalters/centos-dockerbase-minimal
>
> If there's enough interest, we'll see about importing it into the
> projectatomic/ github org and
> taking next steps like integrating it into the CentOS build processes.
>
> BTW, I set up a Jenkins job for this:
> https://ci.centos.org/job/atomic-dockerimage-centosmin/
>
> [1] https://github.com/rpm-software-management/librepo
> [2] https://github.com/rpm-software-management/libhif/pull/144
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Colin Walters]

On Wed, Jul 13, 2016, at 09:40 AM, Tim St. Clair wrote:
> Awesome!
>
> Do we have a formal position, or is this still POC?
 
Still a PoC, but I believe it'd be relatively easy for downstreams to
productize.  For
example, we're using librepo[1] which is the same library used by dnf
(and rpm-ostree)
that knows how to speak TLS client certificates[2] that Red Hat
Enterprise Linux uses
to gate access to content.  And for that matter implements RPM GPG
verification the same
way.
 
In general the micro-yuminst layer will require some maintenance but not
that much;
"yum -y install" is 95% of anyone wants to do in Docker images.
 
Probably the next interesting question is whether the current base
images should derive from this.
 
Anyways, I encourage feedback as issues in
https://github.com/cgwalters/centos-dockerbase-minimal
 
If there's enough interest, we'll see about importing it into the
projectatomic/ github org and
taking next steps like integrating it into the CentOS build processes.
 
BTW, I set up a Jenkins job for this:
https://ci.centos.org/job/atomic-dockerimage-centosmin/
[1] https://github.com/rpm-software-management/librepo
[2] https://github.com/rpm-software-management/libhif/pull/144
 

Re: [atomic-devel] Smaller fedora & centos images

[Tim St. Clair]

Awesome!

Do we have a formal position, or is this still POC?

Cheers,
Tim

On Tue, Jul 12, 2016 at 1:30 PM, Colin Walters  wrote:

> ...3 weeks later:
>
> On Tue, Jun 21, 2016, at 04:59 PM, Colin Walters wrote:
>
>
> It does seem viable to create a `centosmin` image that in some cases uses
> different package builds (e.g. ensuring rpm doesn't pullrelatively close in
> being min-coreutils + bash + yum.  Some postprocessing on the depchain such
> as deleting `.py{,c}` files etc. would help.
>
>
> I realized recently that the work we'd been doing in libhif[1] which is a
> C library for package management
> would allow us to have a minimal "yum -y install" reimplementation[2]
> using libhif, which would be
> good for such a minimal image as then we could drop Python for example.
>
> I spent some of last Friday's plane flight back from the Summit working on
> it:
> https://github.com/cgwalters/centos-dockerbase-minimal
>
> You can try it with:
>
> docker pull docker.io/cgwalters/centosmin
>
> I've only done some basic smoketesting on it.  Compressed it's 28MB,
> uncompressed 77MB right now.
> I estimate it wouldn't be too hard to get within 60MB, but past that
> things get a bit trickier as we
> need to investigate single-binary coreutils, a minimal libcurl build, and
> in general trimming
> out a lot of the duplication in our C libraries like only having openssl
> and not nss, trimming down
> glib2 etc.
>
> I'm curious what people think.  The tradeoff is we now have two base
> images (per distribution).
>
> [1] https://github.com/rpm-software-management/libhif
> [2] https://gitlab.com/cgwalters/micro-yuminst
>



-- 
Cheers,
Timothy St. Clair
tstcl...@redhat.com

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

does your minimal micro-yuminst assume "--setopt tsflags=nodocs"


On Tue, Jul 12, 2016 at 9:30 PM, Colin Walters  wrote:

> ...3 weeks later:
>
> On Tue, Jun 21, 2016, at 04:59 PM, Colin Walters wrote:
>
>
> It does seem viable to create a `centosmin` image that in some cases uses
> different package builds (e.g. ensuring rpm doesn't pullrelatively close in
> being min-coreutils + bash + yum.  Some postprocessing on the depchain such
> as deleting `.py{,c}` files etc. would help.
>
>
> I realized recently that the work we'd been doing in libhif[1] which is a
> C library for package management
> would allow us to have a minimal "yum -y install" reimplementation[2]
> using libhif, which would be
> good for such a minimal image as then we could drop Python for example.
>
> I spent some of last Friday's plane flight back from the Summit working on
> it:
> https://github.com/cgwalters/centos-dockerbase-minimal
>
> You can try it with:
>
> docker pull docker.io/cgwalters/centosmin
>
> I've only done some basic smoketesting on it.  Compressed it's 28MB,
> uncompressed 77MB right now.
> I estimate it wouldn't be too hard to get within 60MB, but past that
> things get a bit trickier as we
> need to investigate single-binary coreutils, a minimal libcurl build, and
> in general trimming
> out a lot of the duplication in our C libraries like only having openssl
> and not nss, trimming down
> glib2 etc.
>
> I'm curious what people think.  The tradeoff is we now have two base
> images (per distribution).
>
> [1] https://github.com/rpm-software-management/libhif
> [2] https://gitlab.com/cgwalters/micro-yuminst
>

Re: [atomic-devel] Smaller fedora & centos images

[Colin Walters]

...3 weeks later:
 
On Tue, Jun 21, 2016, at 04:59 PM, Colin Walters wrote:
>
> It does seem viable to create a `centosmin` image that in some cases
> uses different package builds (e.g. ensuring rpm doesn't
> pullrelatively close in being min-coreutils + bash + yum.  Some
> postprocessing on the depchain such as deleting `.py{,c}` files etc.
> would help.
 
I realized recently that the work we'd been doing in libhif[1] which is
a C library for package management
would allow us to have a minimal "yum -y install" reimplementation[2]
using libhif, which would be
good for such a minimal image as then we could drop Python for example.
 
I spent some of last Friday's plane flight back from the Summit
working on it:
https://github.com/cgwalters/centos-dockerbase-minimal
 
You can try it with:
 
docker pull docker.io/cgwalters/centosmin
 
I've only done some basic smoketesting on it.  Compressed it's 28MB,
uncompressed 77MB right now.
I estimate it wouldn't be too hard to get within 60MB, but past that
things get a bit trickier as we
need to investigate single-binary coreutils, a minimal libcurl build,
and in general trimming
out a lot of the duplication in our C libraries like only having openssl
and not nss, trimming down
glib2 etc.
 
I'm curious what people think.  The tradeoff is we now have two base
images (per distribution).
 
[1] https://github.com/rpm-software-management/libhif
[2] https://gitlab.com/cgwalters/micro-yuminst

Re: [atomic-devel] Smaller fedora & centos images

[Colin Walters]

On Wed, Jun 15, 2016, at 08:23 PM, Tim St. Clair wrote:
> Can we finally address this image size issue?
>
> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/kubernetes-dev/zGMa4QkC_QE/gR43SztlBwAJ
>
> I've sent emails about it in the past, and adoption is moving fast.
 
There has been recent work on this:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2016-February/msg00033.html
 
Basically it relies on RPM weakdeps.  At this point, I'm not entirely
sure we can just take systemd and for that matter coreutils, etc. out of
the base image at least in a released stream.
 
It does seem viable to create a `centosmin` image that in some cases
uses different package builds (e.g. ensuring rpm doesn't pullrelatively
close in being min-coreutils + bash + yum.  Some postprocessing on the
depchain such as deleting `.py{,c}` files etc. would help.
 
It looks like in CentOS 7 it's actually viable to create a container
with just `yum`, but in Fedora 23 at least `dnf` ends up pulling in a
whole lot of stuff including `systemd` which does get messy to address
in a single-source base without weakdeps.
 
 

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

for those, they can strip locales (see david link)
how much would they save?



On Tue, Jun 21, 2016 at 4:11 AM, Derek Carr  wrote:

> Why does 1 not matter?  If a cluster orchestrator charges your container
> for its image size, it would matter.  There are some Kubernetes users in
> the community that have that goal and want to charge local disk usage to
> the pod (including shared image layers).  Admittedly, there are other users
> that do not want to do that, but it does mean the on disk format matters
> for some folks.
>
> On Monday, June 20, 2016, Muayyad AlSadi  wrote:
>
>> I gave up shrinking locales because they compress will
>>
>> There are two use cases for small images
>> 1. The on disk format, which is shared between multiple containers via
>> layers
>>
>> 2. When export tarball and pass it.
>>
>> For 1. Fat does not matter and for 2 it also does not matter because
>> ~100mb becomes 2mb.
>>
>> On Tue, Jun 21, 2016, 3:43 AM David O.  wrote:
>>
>>> A little self-plug: Here's how I do it:
>>> https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
>>> It's designed to run in a container of the same OS (F23 can build F24)
>>> so it can be built anywhere...
>>>
>>> Anyway, apart from systemd and locales I'm in favor of fat base images
>>> when an entire OS is needed. Because in the end not only it saves storage
>>> and bandwidth but also memory (same page cache).
>>> What we should focus on is avoiding fracturization (everything built on
>>> different base images) and educating people that smaller is not always
>>> better.
>>> So I don't think it's worth the effort to remove even dnf from the base
>>> images when it would/should include python3 either way.
>>>
>>> We could also go down the rabbit hole and create a tree of base images
>>> starting with the bare minimum.
>>> Is this also in the realm of the "layered images" project?
>>>
>>> Just my two cents.
>>> And for static binaries and unikernels there is no need for an OS anyway.
>>>
>>

Re: [atomic-devel] Smaller fedora & centos images

[Derek Carr]

Why does 1 not matter?  If a cluster orchestrator charges your container
for its image size, it would matter.  There are some Kubernetes users in
the community that have that goal and want to charge local disk usage to
the pod (including shared image layers).  Admittedly, there are other users
that do not want to do that, but it does mean the on disk format matters
for some folks.

On Monday, June 20, 2016, Muayyad AlSadi  wrote:

> I gave up shrinking locales because they compress will
>
> There are two use cases for small images
> 1. The on disk format, which is shared between multiple containers via
> layers
>
> 2. When export tarball and pass it.
>
> For 1. Fat does not matter and for 2 it also does not matter because
> ~100mb becomes 2mb.
>
> On Tue, Jun 21, 2016, 3:43 AM David O.  wrote:
>
>> A little self-plug: Here's how I do it:
>> https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
>> It's designed to run in a container of the same OS (F23 can build F24) so
>> it can be built anywhere...
>>
>> Anyway, apart from systemd and locales I'm in favor of fat base images
>> when an entire OS is needed. Because in the end not only it saves storage
>> and bandwidth but also memory (same page cache).
>> What we should focus on is avoiding fracturization (everything built on
>> different base images) and educating people that smaller is not always
>> better.
>> So I don't think it's worth the effort to remove even dnf from the base
>> images when it would/should include python3 either way.
>>
>> We could also go down the rabbit hole and create a tree of base images
>> starting with the bare minimum.
>> Is this also in the realm of the "layered images" project?
>>
>> Just my two cents.
>> And for static binaries and unikernels there is no need for an OS anyway.
>>
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I gave up shrinking locales because they compress will

There are two use cases for small images
1. The on disk format, which is shared between multiple containers via
layers

2. When export tarball and pass it.

For 1. Fat does not matter and for 2 it also does not matter because ~100mb
becomes 2mb.

On Tue, Jun 21, 2016, 3:43 AM David O.  wrote:

> A little self-plug: Here's how I do it:
> https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
> It's designed to run in a container of the same OS (F23 can build F24) so
> it can be built anywhere...
>
> Anyway, apart from systemd and locales I'm in favor of fat base images
> when an entire OS is needed. Because in the end not only it saves storage
> and bandwidth but also memory (same page cache).
> What we should focus on is avoiding fracturization (everything built on
> different base images) and educating people that smaller is not always
> better.
> So I don't think it's worth the effort to remove even dnf from the base
> images when it would/should include python3 either way.
>
> We could also go down the rabbit hole and create a tree of base images
> starting with the bare minimum.
> Is this also in the realm of the "layered images" project?
>
> Just my two cents.
> And for static binaries and unikernels there is no need for an OS anyway.
>

Re: [atomic-devel] Smaller fedora & centos images

[David O.]

A little self-plug: Here's how I do it:
https://github.com/oszi/dockerfiles/blob/master/_base/make-rootfs.sh
It's designed to run in a container of the same OS (F23 can build F24) so
it can be built anywhere...

Anyway, apart from systemd and locales I'm in favor of fat base images when
an entire OS is needed. Because in the end not only it saves storage and
bandwidth but also memory (same page cache).
What we should focus on is avoiding fracturization (everything built on
different base images) and educating people that smaller is not always
better.
So I don't think it's worth the effort to remove even dnf from the base
images when it would/should include python3 either way.

We could also go down the rabbit hole and create a tree of base images
starting with the bare minimum.
Is this also in the realm of the "layered images" project?

Just my two cents.
And for static binaries and unikernels there is no need for an OS anyway.

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

given a fake-runtime,

yum --nogpgcheck --installroot=$OSROOT --releasever=23 --setopt
tsflags=nodocs install httpd

I got the following

[root@fedora osroot]# for i in . usr/lib/ usr/lib/locale/ usr/share/locale/
usr/share/i18n; do du -sm $i ; done
227.
109usr/lib/
109usr/lib/locale/
28usr/share/locale/
10usr/share/i18n

so most of the 227MB are locales and i18n

I noticed that httpd pulled systemd-libs because it depends on
libsystemd.so.0()(64bit)

I don't know why it needs systemd libs (if it's for notify, I don't need it
inside docker)



On Tue, Jun 21, 2016 at 1:17 AM, Muayyad AlSadi  wrote:

> >localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
> $OSROOT --delete-from-archive
>
> the line was
>
> localedef --prefix $OSROOT --list-archive  | grep -v en_US | xargs
> localedef --prefix $OSROOT --delete-from-archive
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

>localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
$OSROOT --delete-from-archive

the line was

localedef --prefix $OSROOT --list-archive  | grep -v en_US | xargs
localedef --prefix $OSROOT --delete-from-archive

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

> I hacked up some quick Dockerfiles for this particular example (httpd)
and the end result is that alpine was still smaller - 8.652 MB vs. 232.8 MB

you can use this trick to strip ~100MB

localedef --prefix $OSROOT --list-archive  xargs localedef --prefix
$OSROOT --delete-from-archive
mv $OSROOT/usr/lib/locale/locale-archive
$OSROOT/usr/lib/locale/locale-archive.tmpl
chroot $OSROOT /usr/sbin/build-locale-archive

but if you measure the size of the compressed tarball, it's not much.

you can try use

rpm --root $OSROOT --dbpath /var/lib/rpm --initdb

then add a temporary yum line pointing to the repo

cat <> $OSROOT/etc/yum.repos.d/tmp.repo
[tmp$i]
name=tmp$i
$line
gpgcheck=0
EOF

then install your packages (you don't need to have much)

yum --nogpgcheck --installroot=$OSROOT --releasever=$release $yumsetopt
install -y $packages

if you install system-release using rpm you can eliminate "--nogpgcheck"
and "$OSROOT/etc/yum.repos.d/tmp.repo"

maybe you may want to make sure to install "filesystem" (with either
busybox or "bash grep tar coreutils findutils sed cpio cyrus-sasl gawk vi
passwd sudo")

add httpd to that and let's see

Re: [atomic-devel] Smaller fedora & centos images

[Joe Brockmeier]

On Mon, Jun 20, 2016 at 1:57 PM, Micah Abbott  wrote:

>
> As this is just one example, it would still be interesting to see how
> other apps compare.
>

Interesting, thanks for that.

I would say this is an area where we need to improve, but we also need
folks to show up with suggestions/patches. This something I'd like to see
as well, but I don't know that I'm the best person to try to implement
it... (Which is to say, I could hack at it, but I don't think anybody would
be pleased by the results.)

Best,

jzb
-- 
Joe Brockmeier | Community Team, OSAS
j...@redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

Re: [atomic-devel] Smaller fedora & centos images

[Micah Abbott]

On 06/20/2016 09:38 AM, Joe Brockmeier wrote:

Have we published any comparisons of an Alpine image "fully loaded"
(e.g., with the actual tools) vs. Fedora, etc.? AIUI, when you actually
install things like Apache httpd, or whatnot the comparison looks much
closer.


I hacked up some quick Dockerfiles for this particular example (httpd) 
and the end result is that alpine was still smaller - 8.652 MB vs. 232.8 MB


Full details here - 
https://miabbott.fedorapeople.org/alpine_httpd_vs_fedora_httpd.txt



As this is just one example, it would still be interesting to see how 
other apps compare.


-Micah

Re: [atomic-devel] Smaller fedora & centos images

[David O.]

I've been building my own base images with dnf/yum using installroot. While
I get better results, the images are still large and the biggest waste of
space is systemd. I'm not sure what happened with fakesystemd or
systemd-container but I liked the idea of replacing systemd with something
that makes more sense *in* lightweight containers. I think Dan Walsh talked
about this in detail.

On Mon, Jun 20, 2016 at 5:40 PM Muayyad AlSadi  wrote:

> I was socked by the size of the following file
>
> ls -lh /usr/lib/locale/locale-archive
> -rw-r--r--. 1 root root 107M Jun  8 11:07 /usr/lib/locale/locale-archive
>
> but I was socked more that even after stripping it the total compressed
> image size did not change at all (because more of the content of that file
> is redundant and compressible)
>
> moral of the store: don't look to base image size as metric
>
>
>

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

I was socked by the size of the following file

ls -lh /usr/lib/locale/locale-archive
-rw-r--r--. 1 root root 107M Jun  8 11:07 /usr/lib/locale/locale-archive

but I was socked more that even after stripping it the total compressed
image size did not change at all (because more of the content of that file
is redundant and compressible)

moral of the store: don't look to base image size as metric

Re: [atomic-devel] Smaller fedora & centos images

[Joe Brockmeier]

On Thu, Jun 16, 2016 at 9:50 AM, Tim St. Clair  wrote:

> My primary concern is mind-share and "precedent eventually leads to
> practice".  If all the images and examples presented say :
>
> ' FROM: alpine '
>
> We've lost the hearts and minds of developers, and we are no longer a part
> of the conversation.
>

Have we published any comparisons of an Alpine image "fully loaded" (e.g.,
with the actual tools) vs. Fedora, etc.? AIUI, when you actually install
things like Apache httpd, or whatnot the comparison looks much closer.

Not to say we don't need to reduce image size, but perhaps starting from
base image size is less like real life than looking at the finished image
size as deployed?

Best,

jzb
-- 
Joe Brockmeier | Community Team, OSAS
j...@redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

Re: [atomic-devel] Smaller fedora & centos images

[Muayyad AlSadi]

alpine is something like busybox,
It does not use the true and tested gnu glibc, it uses musl instead.

It has its use case which is different than fedora.

Usage of Alpine in official docker images is also political decision
because they have hired its main developer.

The size of the base image is not really a big deal when we have layers.
It's good to have a small base image but no more than that.

I believe we should eliminate translation of command line tools. Eliminate
useless i18n/l10n files, time zones, ... in some stripped base images.

Yum/dnf can be told to skip docs.

Split packages and take only needed parts.

Re: [atomic-devel] Smaller fedora & centos images

[Tim St. Clair]

My primary concern is mind-share and "precedent eventually leads to
practice".  If all the images and examples presented say :

' FROM: alpine '

We've lost the hearts and minds of developers, and we are no longer a part
of the conversation.

On Wed, Jun 15, 2016 at 8:32 PM, Derek Carr  wrote:

> I am sympathetic to Tim Hockin's perspective.  I am not sure where the
> size versus value equation tips, but if I go to a restaurant for an
> appetizer and the menu only shows entrees I can see where folks like Tim
> come from with their request.  It's hard to argue with someone that they
> should eat more, and it seems like there is a community of folks that want
> smaller base images.
>
> I think a lot of the users in Golang ecosystem want small base images
> because the binaries that they build ironically end up kind of large!
>
> I am working on pod eviction in Kubernetes now when a node is low on
> disk.  I could see some deployment models that charged image usage to the
> pod rather than choosing to treat shared image layers as a cost to the
> underlying infra even if we are not doing that yet in this first
> iteration.  For those cases, users may think they should care more than
> operators want or need them to care about the image size.
>
> On Wednesday, June 15, 2016, Tim St. Clair  wrote:
>
>> Can we finally address this image size issue?
>>
>>
>> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/kubernetes-dev/zGMa4QkC_QE/gR43SztlBwAJ
>>
>> I've sent emails about it in the past, and adoption is moving fast.
>>
>> --
>> Cheers,
>> Timothy St. Clair
>> tstcl...@redhat.com
>>
>


-- 
Cheers,
Timothy St. Clair
tstcl...@redhat.com

Re: [atomic-devel] Smaller fedora & centos images

[Derek Carr]

I am sympathetic to Tim Hockin's perspective.  I am not sure where the size
versus value equation tips, but if I go to a restaurant for an appetizer
and the menu only shows entrees I can see where folks like Tim come from
with their request.  It's hard to argue with someone that they should eat
more, and it seems like there is a community of folks that want smaller
base images.

I think a lot of the users in Golang ecosystem want small base images
because the binaries that they build ironically end up kind of large!

I am working on pod eviction in Kubernetes now when a node is low on disk.
I could see some deployment models that charged image usage to the pod
rather than choosing to treat shared image layers as a cost to the
underlying infra even if we are not doing that yet in this first
iteration.  For those cases, users may think they should care more than
operators want or need them to care about the image size.

On Wednesday, June 15, 2016, Tim St. Clair  wrote:

> Can we finally address this image size issue?
>
>
> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/kubernetes-dev/zGMa4QkC_QE/gR43SztlBwAJ
>
> I've sent emails about it in the past, and adoption is moving fast.
>
> --
> Cheers,
> Timothy St. Clair
> tstcl...@redhat.com 
>