<div dir="ltr">John,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 9: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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote><div><br></div><div>Here is small sum of frameworks/tools to give you an idea what we are currently using to test RHOS components.<br><br>To create Triple-O undercloud/overcloud we are using the:<br><br><a href="https://github.com/redhat-openstack/ansible-ovb">https://github.com/redhat-openstack/ansible-ovb</a><br></div><div><br></div><div>And then to install RHOSP on existing Triple-O:<br><br><a href="https://github.com/redhat-openstack/ansible-rhosp">https://github.com/redhat-openstack/ansible-rhosp</a><br><br></div><div>Then to run CI in such environment we use octario which is our main tool to run different flavors of tests and it's separate CI tool to be ready with different provisioning frameworks.<br><br><a href="https://github.com/redhat-openstack/octario/">https://github.com/redhat-openstack/octario/</a><br><br><br></div><div>In the simplistic environment to run simple tests we are using InfraRed to provision simple instance (without Triple-O):<br><br><a href="https://github.com/rhosqeauto/InfraRed">https://github.com/rhosqeauto/InfraRed</a><br><br></div><div>And then we run octario in such environment to run actual tests.<br><br></div><div>Ideally if the provisioning parts were common and we could reuse them. Currently we need to use yet another set of tools to be able to patch rpm's prior to running tests.<br><br></div><div>There was an idea planted by dsariel to move some of the playbooks into ansible-galaxy roles (possibly other teams had such idea as well), which I can see it's another +1 for going with tools currently developed by Wes as they are pretty separate and could be converted into ansible-galaxy, to be available across different use-cases, but then it would need to be well defined so the roles are not multiplied and we won't end up having similar roles.<br><br><br></div><div>best<br></div><div>Michal Pryc<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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>
<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>
<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></div>