| 2018-11-23 12:44:55 |
Bogdan Dobrelya |
bug |
|
|
added bug |
| 2018-11-23 12:45:35 |
Bogdan Dobrelya |
tripleo: status |
New |
Triaged |
|
| 2018-11-23 12:45:37 |
Bogdan Dobrelya |
tripleo: importance |
Undecided |
High |
|
| 2018-11-23 12:45:38 |
Bogdan Dobrelya |
tripleo: milestone |
|
stein-2 |
|
| 2018-11-23 12:45:58 |
Bogdan Dobrelya |
tags |
|
containers queens-backport-potential rocky-backport-potential tech-debt |
|
| 2018-11-23 12:47:13 |
Bogdan Dobrelya |
summary |
Reduce kolla containers image size by moving off puppet bits |
Reduce kolla containers image size by moving off puppet bits we override for tripleo |
|
| 2018-11-23 12:49:38 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo [0] from into the base container image, which bloats the size of all containers for all services. And we use ~101 images for a typical deployment. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the remaining steps happening later on, including runtime/operational stages as well.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo [0] from into the base container image, which bloats the size of all containers for all services. And we use ~101 images for a typical deployment of a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the remaining steps happening later on, including runtime/operational stages as well.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-23 16:39:56 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo [0] from into the base container image, which bloats the size of all containers for all services. And we use ~101 images for a typical deployment of a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the remaining steps happening later on, including runtime/operational stages as well.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo [0] from into the base container image, which bloats the size of all containers for all services. And we use ~101 images for a typical deployment of a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the remaining steps happening later on, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-23 16:42:30 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo [0] from into the base container image, which bloats the size of all containers for all services. And we use ~101 images for a typical deployment of a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the remaining steps happening later on, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-23 16:57:19 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Or just using another config image that contains all those puppet bits for all of the containers configured via puppet. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-26 13:56:21 |
OpenStack Infra |
tripleo: status |
Triaged |
In Progress |
|
| 2018-11-26 13:56:21 |
OpenStack Infra |
tripleo: assignee |
|
Bogdan Dobrelya (bogdando) |
|
| 2018-11-26 16:49:35 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Or just using another config image that contains all those puppet bits for all of the containers configured via puppet. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB for each of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
Assuming that like a 30 container images would be required to deploy a compute node, for a 1000 of distributed computes deployed over edge WAN connections, that saves 30*1000*16 = 480 GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-26 17:03:06 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-26 17:03:43 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-26 17:04:26 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and volumes from it, when configuring containerized services via puppet* deployment steps. Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and consuming volumes from it, when configuring containerized services via puppet* deployment steps (docker-puppet.py). Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-27 10:20:45 |
Bogdan Dobrelya |
tags |
containers queens-backport-potential rocky-backport-potential tech-debt |
containers edge queens-backport-potential rocky-backport-potential tech-debt |
|
| 2018-11-27 18:48:07 |
Dan Prince |
bug |
|
|
added subscriber Dan Prince |
| 2018-11-28 09:52:09 |
Bogdan Dobrelya |
summary |
Reduce kolla containers image size by moving off puppet bits we override for tripleo |
Reduce kolla containers image size by moving off puppet/systemd config only dependencies we override for tripleo |
|
| 2018-11-28 10:07:10 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and consuming volumes from it, when configuring containerized services via puppet* deployment steps (docker-puppet.py). Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well.
This saves approximately 16MB + 61 MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
And there is also a lot on unrelated packages it pulls into each of the containers via that base layer via the puppet dependency of puppet-tripleo:
[zuul@undercloud ~]$ repoquery -R --resolve puppet
bash-0:4.2.46-30.el7.x86_64
rubygem-rgen-0:0.6.6-2.el7.noarch
rubygem-json-0:1.7.7-33.el7_4.x86_64
facter-1:2.4.4-4.el7.x86_64
ruby-shadow-0:1.4.1-23.el7.x86_64
coreutils-0:8.22-21.el7.x86_64
systemd-0:219-57.el7_5.3.x86_64
shadow-utils-2:4.1.5.1-24.el7.x86_64
libselinux-utils-0:2.5-12.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.i686
ruby-0:2.0.0.648-33.el7_4.x86_64
libselinux-ruby-0:2.5-12.el7.x86_64
ruby-augeas-0:0.5.0-1.el7.x86_64
ruby-libs-0:2.0.0.648-33.el7_4.x86_64
hiera-1:1.3.4-5.el7.noarch
tar-2:1.26-34.el7.x86_64
I'm not sure we want to have those as additional targets for security vulnerabilities fixes to be maintained, nor as potential attack vectors in executables and libs.
To get the final size numbers for end containers images, we'll need to track those all the way down and exclude that overlaps to the openstack-base image layer sitting on top.
Though, even with these numbers of an extra ~80MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 80*5000 = 390GB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there)
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and consuming volumes from it, when configuring containerized services via puppet* deployment steps (docker-puppet.py). Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well. Nor should any containerized a service require systemd (it brings in a lot of totally useless for containers dependencies for a 190MB of total!)
So we can save approximately 16MB + 61MB + 190MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
16610038
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
$ $ repoquery -R --resolve systemd | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
170945969
We do not want to maintain CVE fixes for those extra components as it has nothing to containerized openstack services, not we do not need them lying in containers as dead weight.
With these numbers of an extra ~270MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 270*5000 = 1,3TB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there).
Note that some other components packages, like openstack-heat* still do require systemd, that should be fixed as well to not add it back for the upper layers sitting on top of the base one.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2018-11-28 14:27:41 |
Bogdan Dobrelya |
summary |
Reduce kolla containers image size by moving off puppet/systemd config only dependencies we override for tripleo |
Reduce kolla containers image size by moving off puppet/systemd config only bits and its dependencies we override for tripleo |
|
| 2019-01-13 22:51:43 |
Emilien Macchi |
tripleo: milestone |
stein-2 |
stein-3 |
|
| 2019-01-21 13:51:01 |
Bogdan Dobrelya |
tripleo: status |
In Progress |
Opinion |
|
| 2019-01-21 13:51:03 |
Bogdan Dobrelya |
tripleo: assignee |
Bogdan Dobrelya (bogdando) |
|
|
| 2019-02-11 13:47:19 |
Bogdan Dobrelya |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1671362 |
|
| 2019-02-11 13:47:19 |
Bogdan Dobrelya |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1654672 |
|
| 2019-02-11 13:47:19 |
Bogdan Dobrelya |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=167137 |
|
| 2019-03-04 08:40:10 |
Bogdan Dobrelya |
summary |
Reduce kolla containers image size by moving off puppet/systemd config only bits and its dependencies we override for tripleo |
Reduce kolla containers image size by moving off puppet config only bits and its dependencies we override for tripleo |
|
| 2019-03-04 08:43:28 |
Bogdan Dobrelya |
description |
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and consuming volumes from it, when configuring containerized services via puppet* deployment steps (docker-puppet.py). Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well. Nor should any containerized a service require systemd (it brings in a lot of totally useless for containers dependencies for a 190MB of total!)
So we can save approximately 16MB + 61MB + 190MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
16610038
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
$ $ repoquery -R --resolve systemd | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
170945969
We do not want to maintain CVE fixes for those extra components as it has nothing to containerized openstack services, not we do not need them lying in containers as dead weight.
With these numbers of an extra ~270MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 270*5000 = 1,3TB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there).
Note that some other components packages, like openstack-heat* still do require systemd, that should be fixed as well to not add it back for the upper layers sitting on top of the base one.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
Bug created for systemd dependencies https://bugs.launchpad.net/tripleo/+bug/1818484
Currently, we include puppet-tripleo (which pulls in puppet, what in turn adds systemd, ruby and more...) into the base container image, which affects [0] the size of all containers for all services, adds more subjects for CVEs handling and potential vectors of attacks. And we use ~101 images for a typical deployment, having a 146 of total images. For edge scenarios, where there are potentially (tens of) thousands nodes distributed over high latency and limited bandwidth WAN networks, that poses a problem.
The solution is creating a side car container and consuming volumes from it, when configuring containerized services via puppet* deployment steps (docker-puppet.py). Note, we cannot just use a single config image that contains all those puppet bits for all of the containers configured via puppet as there is services specific config actions like calling cinder-manage from puppet, for example. Containers need no to keep those puppet packages for the later deployment steps, including runtime/operational stages as well. Nor should any containerized a service require systemd (it brings in a lot of totally useless for containers dependencies for a 190MB of total!)
So we can save approximately 16MB + 61MB + 190MB for the base layer of the container images (checked with):
$ repoquery -R --resolve puppet-tripleo | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
16610038
$ repoquery -R --resolve puppet | xargs -n1 rpm -qa --queryformat '%10{size} - %-25{name} \t %{version}\n'
[zuul@undercloud ~]$ repoquery -R --resolve puppet | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
61145246
$ $ repoquery -R --resolve systemd | xargs -n1 -I{} bash -c "rpm -qi {}" 2>&1 | awk '/Size/ {print $NF}' | paste -sd+ - | bc
170945969
We do not want to maintain CVE fixes for those extra components as it has nothing to containerized openstack services, not we do not need them lying in containers as dead weight.
With these numbers of an extra ~270MB per each remote edge compute host, for a 5000 of distributed computes deployed over edge WAN connections, that saves 270*5000 = 1,3TB of traffic (and the time it takes to transfer those from the control plane to remote edge sites and/or local registries sitting there).
Note that some other components packages, like openstack-heat* still do require systemd, that should be fixed as well to not add it back for the upper layers sitting on top of the base one.
[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/136191.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136272.html |
|
| 2019-03-15 15:40:33 |
Bogdan Dobrelya |
tripleo: importance |
High |
Medium |
|
