<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge <span dir="ltr"><<a href="mailto:trown@redhat.com" target="_blank">trown@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy folks,<br>
<br>
In the TripleO meeting two weeks ago, it came up that tripleo-quickstart<br>
is being used as a CI tool in RDO. This came about organically, because<br>
we needed to use RDO CI to self-gate quickstart (it relies on having a<br>
baremetal virthost). It displaced another ansible based CI tool there<br>
(khaleesi) and most(all?) of the extra functionality from that tool<br>
(upgrades, scale, baremetal, etc.) has been moved into discrete ansible<br>
roles that are able to plugin to quickstart.[1]<br>
<br>
We are still left with two different tool sets, where one should suffice<br>
(and focus CI efforts in one place).<br>
<br>
I see two different ways to resolve this.<br>
<br>
1. Actively work on making the tripleo-ci scripts consumable external to<br>
tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming<br>
upstream CI for packstack and puppet, so it is not totally far-fetched<br>
to add support for TripleO jobs.<br></blockquote><div><br></div><div>I think we have to at least point out that RDO is not the only other target for a CI tool.</div><div>There are a few more groups that would benefit from the leadership of the upstream CI system.  Without </div><div>calling out specific groups, I'm thinking of the various OpenStack network teams, performance teams,</div><div>test teams, etc.. that rely on setting up TripleO as the base for their work. To make things a bit more complicated</div><div>there is not a single source of requirements for the various groups that would benefit from a robust, </div><div>flexible upstream TripleO CI tool set.  I'm not convinced that the current bash scripts can be </div><div>reworked or wrapped in a way that can be flexible enough to handle what is an essentially</div><div>unknown set of requirements.</div><div><br></div><div>IMHO we require a tool set that is pluggable, composable and flexible enough such that</div><div>other development, and CI teams that rely on TripleO as the base for their work feel comfortable extending</div><div>and replacing parts of the CI tool set to fit their needs.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Pros:<br>
- All CI development just happens directly in tripleo-ci and RDO just<br>
inherits that work.<br>
<br>
Cons:<br>
- This is totally untried, and therefore a totally unknown amount of work.<br>
- It is all or nothing in that there is no incremental path to get the<br>
CI scripts working outside of CI.<br>
- We have to rewrite a bunch of working ansible code in bash which IMO<br>
is the wrong direction for a modern CI system.<br>
<br>
<br>
2. Actively work on making tripleo-ci consume the ansible work in<br>
tripleo-quickstart and the external role ecosystem around it.<br>
<br>
Pros:<br>
- This could be done incrementally, replacing a single function from<br>
tripleo.sh with an invocation of tripleo-quickstart that performs that<br>
function instead.<br>
- We would be able to pull in a lot of extra functionality via these<br>
external roles for free(ish).<br>
<br>
Cons:<br>
- Similarly unknown amount of work to completely switch.<br>
- CI development would be done in multiple repos, though each would have<br>
discrete and well defined functionality.<br>
<br>
<br>
Personally, I don't think we should do anything drastic with CI until<br>
after we release Newton, so we don't add any risk of impacting new<br>
features that haven't landed yet. I do think it would be a good goal for<br>
Ocata to have a CI system in TripleO that is consumable outside of<br>
TripleO. In any case, this email is simply to garner feedback if other's<br>
think this is a worthy thing to pursue and opinions on how we can get there.<br></blockquote><div><br></div><div>+1 here.  I agree there should be enough time for thoughtful conversation without</div><div>disrupting higher priority work. </div><div><br></div><div>Thanks for sending this out John!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
[1]<br>
<a href="https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role-tripleo" rel="noreferrer" target="_blank">https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role-tripleo</a><br>
(note not all of these are actively used/developed)<br>
[2] <a href="https://github.com/rdo-infra/weirdo" rel="noreferrer" target="_blank">https://github.com/rdo-infra/weirdo</a><br>
<br>
<br>
<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><br></div></div>