<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018 at 12:37 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-05-14 09:57:17 -0600 (-0600), Wesley Hayutin wrote:<br>
> On Mon, May 14, 2018 at 10:36 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
[...]<br>
> > Couldn't a significant burst of new packages cause the same<br>
> > symptoms even without it being tied to a minor version increase?<br>
> <br>
> Yes, certainly this could happen outside of a minor update of the<br>
> baseos.<br>
<br>
Thanks for confirming. So this is not specifically a CentOS minor<br>
version increase issue, it's just more likely to occur at minor<br>
version boundaries.<br></blockquote><div><br></div><div>Correct, you got it</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> So the only thing out of our control is the package set on the<br>
> base nodepool image. If that suddenly gets updated with too many<br>
> packages, then we have to scramble to ensure the images and<br>
> containers are also udpated.<br>
<br>
It's still unclear to me why the packages on the test instance image<br>
(i.e. the "container host") are related to the packages in the<br>
container guest images at all. That would seem to be the whole point<br>
of having containers?<br></blockquote><div><br></div><div>You are right, just note some services are not 100% containerized yet.  This doesn't happen overnight it's a process and we're getting there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> If there is a breaking change in the nodepool image for example<br>
> [a], we have to react to and fix that as well.<br>
<br>
I would argue that one is a terrible workaround which happened to<br>
show its warts. We should fix DIB's pip-and-virtualenv element<br>
rather than continue rely on side effects of pinning RPM versions.<br>
I've commented to that effect on <a href="https://launchpad.net/bugs/1770298" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1770298</a><br>
just now.<br>
<br></blockquote><div><br></div><div>k.. thanks</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > It sounds like a problem with how the jobs are designed<br>
> > and expectations around distros slowly trickling package updates<br>
> > into the series without occasional larger bursts of package deltas.<br>
> > I'd like to understand more about why you upgrade packages inside<br>
> > your externally-produced container images at job runtime at all,<br>
> > rather than relying on the package versions baked into them.<br>
> <br>
> We do that to ensure the gerrit review itself and it's<br>
> dependencies are built via rpm and injected into the build. If we<br>
> did not do this the job would not be testing the change at all.<br>
> This is a result of being a package based deployment for better or<br>
> worse.<br>
[...]<br>
<br>
Now I'll risk jumping to proposing solutions, but have you<br>
considered building those particular packages in containers too?<br>
That way they're built against the same package versions as will be<br>
present in the other container images you're using rather than to<br>
the package versions on the host, right? Seems like it would<br>
completely sidestep the problem.<br></blockquote><div><br></div><div>So a little background.  The containers and images used in TripleO are rebuilt multiple times each day via periodic jobs, when they pass our criteria they are pushed out and used upstream.</div><div>Each zuul change and it's dependencies can potentially impact a few or all the containers in play.   We can not rebuild all the containers due to time constraints in each job.  We have been able to mount and yum update the containers involved with the zuul change.</div><div><br></div><div>Latest patch to fine tune that process is here <a href="https://review.openstack.org/#/c/567550/">https://review.openstack.org/#/c/567550/</a></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> An enhancement could be to stage the new images for say one week<br>
> or so. Do we need the CentOS updates immediately? Is there a<br>
> possible path that does not create a lot of work for infra, but<br>
> also provides some space for projects to prep for the consumption<br>
> of the updates?<br>
[...]<br>
<br>
Nodepool builds new images constantly, but at least daily. Part of<br>
this is to prevent the delta of available packages/indices and other<br>
files baked into those images from being more than a day or so stale<br>
at any given point in time. The older the image, the more packages<br>
(on average) jobs will need to download if they want to test with<br>
latest package versions and the more strain it will put on our<br>
mirrors and on our bandwidth quotas/donors' networks.<br></blockquote><div><br></div><div>Sure that makes perfect sense.  We do the same with our containers and images.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There's also a question of retention, if we're building images at<br>
least daily but keeping them around for 7 days (storage on the<br>
builders, tenant quotas for Glance in our providers) as well as the<br>
explosion of additional nodes we'd need since we pre-boot nodes with<br>
each of our images (and the idea as I understand it is that you<br>
would want jobs to be able to select between any of them). One<br>
option, I suppose, would be to switch to building images weekly<br>
instead of daily, but that only solves the storage and node count<br>
problem not the additional bandwidth and mirror load. And of course,<br>
nodepool would need to learn to be able to boot nodes from older<br>
versions of an image on record which is not a feature it has right<br>
now.<br></blockquote><div><br></div><div>OK.. thanks for walking me through that.  It totally makes sense to be</div><div>concerned with updating the image to save time, bandwidth etc.</div><div>It would be interesting to see if we could come up with something to protect</div><div>projects from changes to the new images and maintain images with fresh updates.</div><div><br></div><div>Project non-voting check jobs on the node-pool image creation job perhaps could be the canary in the coal mine we</div><div>are seeking.  Maybe we could see if that would be something that could be useful to both infra</div><div>and to various OpenStack projects? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Understood, I suspect this will become a more widespread issue as<br>
> more projects start to use containers ( not sure ).<br>
<br>
I'm still confused as to what makes this a container problem in the<br>
general sense, rather than just a problem (leaky abstraction) with<br>
how you've designed the job framework in which you're using them.<br>
<br>
> It's my understanding that there are some mechanisms in place to<br>
> pin packages in the centos nodepool image so there has been some<br>
> thoughts generally in the area of this issue.<br>
[...]<br>
<br>
If this is a reference back to bug 1770298, as mentioned already I<br>
think that's a mistake in diskimage-builder's stdlib which should be<br>
corrected, not a pattern we should propagate.<br></blockquote><div><br></div><div>Cool, good to know and thank you!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-- <br>
Jeremy Stanley<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>