On Thu, Mar 07, 2019 at 13:47 Jeremy Stanley wrote:
On 2019-03-07 11:32:39 +0900 (+0900), Tristan Cacqueray wrote: [...]
IIUC, we would need to wait for a fix to land in the debian-stretch image,
We could just wait for the fix to land in Debian itself (they're going to be part of the coordinated disclosure of most of the sort of vulnerabilities you're talking about so should be available at basically the same time as it's announced by researchers) and then rebuild those images ourselves if that step is taking too long... or get involved with the community who maintains them and help out?
then wait for a new opendevorg/python-builder image and finally wait for a new zuul image to be published.
Luckily OpenDev and Zuul image building is managed in the same system and maintained by mostly the same people so I wouldn't anticipate much lag there. But also, this entire stack of images is buildable by downstream consumers who want to do that themselves instead of waiting for us.
IIUC, the Zuul image is updated when a change is merged in the Zuul repository, so it seems like we are missing a periodic rebuild of the Zuul image, especially for the tagged releases. I don't know how the opendevorg/python-builder gets updated. My question was more about what are the concrete actions we need to perform to update one of the layers managed by opendev. Because from an end-user perspective, what used to be a host update and service restart is now replaced by pulling a brand new debian+opendev+zuul image. Monty mentioned in the other thread that rebuilding the Zuul image should update the debian packages too.
Or what happen when the zuul image gets published with an incompatible openstacksdk requirement? [...]
I don't see where the choice of underlying distribution comes into play here. We'd explicitly choose which version of OpenStackSDK to install, so if it's incompatible then that's on us, right?
That's correct, the underlying distribution won't prevent pip from pulling unwanted bits. But this is a new issue/behavior with these layered builds because you can't prevent the Zuul layer from pulling new bits when all you want to do is update the base layer (at least with the current Dockerfile and requirements.txt file from the Zuul repository). These concerns are already adressed by Monty suggestion tu support local builds of the image. I just meant to discuss a couple of scenarios and how its going to affect user of the Zuul image provided by opendev. Regards, -Tristan
-- Jeremy Stanley _______________________________________________ Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss