<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 8:49 PM Wesley Hayutin <<a href="mailto:whayutin@redhat.com">whayutin@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 11:56 AM Mike Burns <<a href="mailto:mburns@redhat.com" target="_blank">mburns@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">So, if I understand this right...<div><br></div><div>* We're keeping the centos7 and centos8 versions of Ussuri consistent</div><div>* There is no actual build of the latest commits built on either centos7 or centos8</div><div>* There is no possible way to have an Ussuri release on Centos7</div><div><br></div><div>Assuming the above is true, I would say to turn off all the centos7 stuff and focus all effort on getting Ussuri latest built on centos8.  There does not appear to be any value in continuing work on centos7 if we can't actually deliver it at the end of the day.</div><div><br></div><div>Mike</div></div></blockquote><div><br></div><div>Agreeing and building on what Mike said.. this certainly raises the priority on CentOS-8.  There are still tripleo patches incoming that will not be pinned ( I think )</div><div>Having a better understanding here of what has been pinned and what is in progress w/o consulting rdo-info all the time would be handy.</div><div><br></div></div></div></blockquote><div><br></div><div>Yes, tripleo patches are not pinned and should keep bulding in current repo..<br></div><div><br></div><div>Currently pinned packages because of py2 issues:</div><div><br></div><div></div><div></div><div></div><div>- nova</div><div>- keystone</div><div></div><div></div><div></div><div>- cinder</div><div><div>- glance</div><div>- neutron</div><div>- neutron-lib</div><div>- neutron-vpnaas</div><div>- networking-generic-switch</div></div><div>- horizon</div><div><div>- heat-dasboard</div><div>- murano-dashboard</div></div><div><div>- octavia</div><div>- mistral</div></div><div>- ironic</div><div>- ironic-staging-drivers</div><div>- ironic-python-agent</div><div>- hardware</div><div>- kolla</div><div>- senlin</div><div>- tobiko</div><div>- rally</div><div>- heat-tempest-plugin</div><div>- zaqar-tempest-plugin</div><div>- mistral-tempest-plugin</div><div><br></div><div>Also, update of oslo-libraries to latest releases is blocked so we are still using previous ones.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>I think the check, gate and promotion jobs for centos-7 ussuri need to stay in place, however they should just always pass which would lower the amount of work w/ regards to centos-7 but not eliminate it.   It could also be the case that tripleo breaks itself from time to time, but I'm sure Emilien would never let that happen as he's a robot and not human.</div><div><br></div></div></div></blockquote><div><br></div><div>There should be no problem with check jobs for c7, that will keep using latest promoted content + current tripleo and family. TripleO patches requiring changes in pinned projects will fail in CentOS7.<br></div><div><br></div><div>WRT promotion based on consistent link, as we get consistent link stuck by unpinning packages to get them updated in CentOS8, i'm not sure if periodic pipeline will keep running or it detects the link is still pointing to the same hash and will skip it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>I digress </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 20, 2020 at 9:05 AM Alfredo Moralejo Alonso <<a href="mailto:amoralej@redhat.com" target="_blank">amoralej@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid9"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid10"><span>Hi,</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid11"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid124"><span>I'd like to open </span><span>a </span><span>discussion about the status of RDO Ussuri repositories on CentOS7.</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid13"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid701"><span>As you know RDO and upstream teams (kolla, puppet-openstack, TripleO, TripleO CI, etc...) have been working to switch to CentOS8 during last</span><span> few</span><span> weeks.</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid15"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid730"><span>In order to make the transition easier from CentOS</span><span> </span><span>7 to CentOS</span><span> </span><span>8, RDO is still maintaining Trunk repos consistent for both CentOS</span><span> </span><span>7/</span><span>P</span><span>ython</span><span> </span><span>2 and CentOS</span><span> </span><span>8/</span><span>P</span><span>ython</span><span> </span><span>3. As </span><span>OpenStack </span><span>p</span><span>rojects</span><span> have been dropping support for </span><span>P</span><span>ython</span><span> </span><span>2, we've </span><span>started </span><span>pinning them to </span><span>the </span><span>last commit working with </span><span>P</span><span>ython</span><span> </span><span>2</span><span>[1], we were expecting that transition will finish soon but it's still goin</span><span>g</span><span> on.</span><span> Over</span><span> </span><span>time</span><span>,</span><span> the number of pinned packages ha</span><span>s</span><span> been growing including services and </span><span>O</span><span>slo libraries where we can't follow upper-constraints anymore</span><span>[2]</span><span>. Recently, </span><span>K</span><span>olla has removed support for CentOS</span><span> </span><span>7 so i doubt it makes sense to keep pinning packages to keep RDO Trunk consistent artificially and continue running promotion pipelines on a repo with so many </span><span>outdated</span><span> packages. Also, pinning these projects makes that changes needed for CentOS 8 will not be in RDO and would need to be backported manually to each package. My proposal is:</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid17"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid739"><span>- Unpin all packages in Ussuri to follow master trunk</span><span>,</span><span> or versions in u</span><span>pper</span><span>-c</span><span>onstraints</span><span> (for clients and libraries).</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid885"><span>- RDO Ussuri on CentOS</span><span> </span><span>7 repo consistent link will not move anymore (so no more promotions based on it).</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid907"><span>- We</span><span> wi</span><span>ll keep running centos7-master</span><span> DLRN builder</span><span>, so </span><span>that </span><span>packages still buil</span><span>ing</span><span> with </span><span>P</span><span>ython</span><span> </span><span>2 will be available in current repo [3] to be used by team</span><span>s</span><span> </span><span>needing them</span><span> until migration to CentOS 8 is finished everywhere.</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid897"><span>- Projects which already ha</span><span>ve</span><span> </span><span>C</span><span>ent</span><span>OS </span><span>8 jobs gating in master branch can remove </span><span>C</span><span>ent</span><span>OS </span><span>7 ones.</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid377"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid599"><span>We understand this can add some pressure on moving to CentOS8 to the teams working on it, but I'd say it's already a priority and it's justified at this stage.</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid22"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid811"><span>What do you think about this plan?, is there any reason to keep CentOS</span><span> </span><span>7</span><span> artificially </span><span>consistent and promoting at this point of the transition to CentOS</span><span> </span><span>8?</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid224"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid25"><span>Best regards,</span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid26"><br></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid27"><span>Alfredo</span></div><div><span><br></span></div><div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid355"><span>[1] </span><span><a href="https://review.rdoproject.org/r/#/q/topic:pin-py2" target="_blank">https://review.rdoproject.org/r/#/q/topic:pin-py2</a></span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid374"><span>[2] </span><span><a href="https://review.rdoproject.org/r/#/c/24796/" target="_blank">https://review.rdoproject.org/r/#/c/24796/</a></span></div><div id="gmail-m_-5547514522950751848gmail-m_4326451281573226441gmail-m_3675691944376874546gmail-magicdomid373"><span>[3] </span><span><a href="http://trunk.rdoproject.org/centos7-master/current" target="_blank">http://trunk.rdoproject.org/centos7-master/current</a></span></div><span></span></div></div>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproject.org</a><br>
</blockquote></div>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/mailman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproject.org</a><br>
</blockquote></div></div>
</blockquote></div></div>