<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018 at 12:08 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 14, 2018, at 8:57 AM, 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>
> > On 2018-05-14 07:07:03 -0600 (-0600), Wesley Hayutin wrote:<br>
> > [...]<br>
<br>
snip<br>
<br>
> ><br>
> > This _doesn't_ sound to me like a problem with how we've designed<br>
> > our infrastructure, unless there are additional details you're<br>
> > omitting.<br>
> <br>
> <br>
> So the only thing out of our control is the package set on the base<br>
> nodepool image.<br>
> If that suddenly gets updated with too many packages, then we have to<br>
> scramble to ensure the images and containers are also udpated.<br>
> If there is a breaking change in the nodepool image for example [a], we<br>
> have to react to and fix that as well.<br>
<br>
Aren't the container images independent of the hosting platform (eg what infra hosts)? I'm not sure I understand why the host platform updating implies all the container images must also be updated.<br></blockquote><div><br></div><div>You make a fine point here, I think as with anything there are some bits that are still being worked on. At this moment it's my understanding that pacemaker and possibly a few others components are not 100% containerized atm.  I'm not an expert in the subject and my understanding may not be correct.  Untill you are 100% containerized there may still be some dependencies on the base image and an impact from changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> <br>
> > 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>
> <br>
> We do that to ensure the gerrit review itself and it's dependencies are<br>
> built via rpm and injected into the build.<br>
> If we 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 worse.<br>
<br>
You'd only need to do that for the change in review, not the entire system right?<br></blockquote><div><br></div><div>Correct there is no intention of updating the entire distribution in run time, the intent is to have as much updated in our jobs that build the containers and images.</div><div>Only the rpm built zuul change should be included in the update, however some zuul changes require a CentOS base package that was not previously installed on the container e.g. a new python dependency introduced in a zuul change.  Previously we had not enabled any CentOS repos in the container update, but found that was not viable 100% of the time.</div><div><br></div><div>We have a change to further limit the scope of the update which should help [1], especialy when facing a minor version update.</div><div><br></div><div> [1] <a href="https://review.openstack.org/#/c/567550/">https://review.openstack.org/#/c/567550/</a></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
<br>
snip<br>
<br>
> > Our automation doesn't know that there's a difference between<br>
> > packages which were part of CentOS 7.4 and 7.5 any more than it<br>
> > knows that there's a difference between Ubuntu 16.04.2 and 16.04.3.<br>
> > Even if we somehow managed to pause our CentOS image updates<br>
> > immediately prior to 7.5, jobs would still try to upgrade those<br>
> > 7.4-based images to the 7.5 packages in our mirror, right?<br>
> ><br>
> <br>
> Understood, I suspect this will become a more widespread issue as<br>
> more projects start to use containers ( not sure ).  It's my understanding<br>
> that<br>
> there are some mechanisms in place to pin packages in the centos nodepool<br>
> image so<br>
> there has been some thoughts generally in the area of this issue.<br>
<br>
Again, I think we need to understand why containers would make this worse not better. Seems like the big feature everyone talks about when it comes to containers is isolating packaging whether that be python packages so that nova and glance can use a different version of oslo or cohabitating software that would otherwise conflict. Why do the packages on the host platform so strongly impact your container package lists?<br></blockquote><div><br></div><div>I'll let others comment on that, however my thought is you don't move from A -> Z in one step and containers do not make everything easier immediately.  Like most things, it takes a little time. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> <br>
> TripleO may be the exception to the rule here and that is fine, I'm more<br>
> interested in exploring<br>
> the possibilities of delivering updates in a staged fashion than anything.<br>
> I don't have insight into<br>
> what the possibilities are, or if other projects have similiar issues or<br>
> requests.  Perhaps the TripleO<br>
> project could share the details of our job workflow with the community and<br>
> this would make more sense.<br>
> <br>
> I appreciate your time, effort and thoughts you have shared in the thread.<br>
> <br>
> <br>
> > --<br>
> > Jeremy Stanley<br>
> ><br>
> <br>
> [a] <a href="https://bugs.launchpad.net/tripleo/+bug/1770298" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1770298</a><br>
<br>
I think understanding the questions above may be the important aspect of understanding what the underlying issue is here and how we might address it.<br>
<br>
Clark<br></blockquote><div><br></div><div>Thanks Clark, let me know if I did not get everything on your list there. Thanks again for your time. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>