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.
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 lists.openstack .org/pipermail/ openstack- dev/2018- November/ 136272. html
[1] http://