<div dir="ltr">Hi,<div><br></div><div>Long time lurker first time poster.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 28, 2018 at 3:14 PM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Before going down to my specific context, I would like to raise that we're having more and more dependencies outside of OpenStack (Ceph, MariaDB, Ansible, OVS, etc); and we know that all of them can easily "break" projects like TripleO and therefore cause problems in the production chain.</div><div>I would like to understand if we have a common path for these projects, to include them in delorean and in our machinery so we can easily test them in RDO CI (and stop manual testing like we are doing now).</div></div></blockquote><div><br></div><div>In my previous experience, we would backport newer versions of libvirt, OVS, Ceph, and etc to the ubuntu cloud archive for users who are still on the LTS. Initially it was a bit of a hassle because we would find something that something that would break like an older library or a dependency that is not in Xenial or a feature would change that we were not expecting. </div><div><br></div><div>However, once we release we were also taking responsibility of taking care of things like updating newer versions of the software due to CVEs or backports. This was automated as well, but it is something to be aware of and mindful of.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>We all know that we can't and don't want to consume EPEL but for some projects it's going to be problematic, I'll discuss about one of them a bit later in this email.</div><div>My proposal is the following:</div><div><br></div><div>- Identify which projects we have had troubles in the past months and that we are not automatically testing when new versions bump up (OVS? Ceph? etc)</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>- For these projects, how could we either 1) import them in delorean and automatically bump them at each new tag, with proper CI job in place or 2) have a repo that is nightly build from imports on latest tags available from their upstream repos), and have periodic jobs that test these bits.</div></div></blockquote><div><br></div><div>I think it would be a good idea to being conservative at the beginning of the cycle and then taking it on a case by case basis. Over time we automated the importation into the archive because we became more familiar with what we had.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>What I like with 1) is that we can easily test them independently (e.g. a new version of OVS) versus all together in 2) (a new version of OVS + a new version of MariaDB, etc).</div><div><br></div></div></blockquote><div><br></div><div>it should be pretty easy to test them all together. I think you are going to have a version matrix like what is done in tripleo with the feature sets.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Which leads to my second question... how are going to ship Ansible.</div><div>I talked with Sam Doran (in cc) today and it seems like in the near future Ansible would be shipped via <a href="http://releases.ansible.com" target="_blank">releases.ansible.com</a> or EPE (and not from CentOS Extras anymore).</div><div>So here are the questions:</div><div><br></div><div>1) How are we going to test new versions of Ansible in RDO CI context?</div><div>2) Where should we ship it? Back in my proposal, would it make sense to import Ansible in RDO and gate each bump (proposal #1) or take upstream, put in a deps repo (as we have current I believe) and test it with a periodic jobs among other new deps.</div><div><br></div></div></blockquote><div><br></div><div>I think you would follow upstream processes in consuming ansible.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Discussion is open, thanks for participating,</div><span class="m_6491401964223017917HOEnZb"><font color="#888888">-- <br><div class="m_6491401964223017917m_-5805283241216174518gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<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/ma<wbr>ilman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproje<wbr>ct.org</a><br>
<br></blockquote></div><br></div></div></div>