<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <span dir="ltr"><<a href="mailto:abregman@redhat.com" target="_blank">abregman@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I would like to start a discussion on the overlap between tools we<br>
have for deploying and testing TripleO (RDO & RHOSP) in CI.<br>
<br>
Several months ago, we worked on one common framework for deploying<br>
and testing OpenStack (RDO & RHOSP) in CI. I think you can say it<br>
didn't work out well, which eventually led each group to focus on<br>
developing other existing/new tools.<br>
<br>
What we have right now for deploying and testing<br>
--------------------------------------------------------<br>
=== Component CI, Gating ===<br>
I'll start with the projects we created, I think that's only fair :)<br>
<br>
* Ansible-OVB[1] - Provisioning Tripleo heat stack, using the OVB project.<br>
<br>
* Ansible-RHOSP[2] - Product installation (RHOSP). Branch per release.<br>
<br>
* Octario[3] - Testing using RPMs (pep8, unit, functional, tempest,<br>
csit) + Patching RPMs with submitted code.<br>
<br>
=== Automation, QE ===<br>
* InfraRed[4] - provision install and test. Pluggable and modular,<br>
allows you to create your own provisioner, installer and tester.<br>
<br>
As far as I know, the groups is working now on different structure of<br>
one main project and three sub projects (provision, install and test).<br>
<br>
=== RDO ===<br>
I didn't use RDO tools, so I apologize if I got something wrong:<br>
<br>
* About ~25 micro independent Ansible roles[5]. You can either choose<br>
to use one of them or several together. They are used for<br>
provisioning, installing and testing Tripleo.<br>
<br>
* Tripleo-quickstart[6] - uses the micro roles for deploying tripleo<br>
and test it.<br>
<br>
As I said, I didn't use the tools, so feel free to add more<br>
information you think is relevant.<br>
<br>
=== More? ===<br>
I hope not. Let us know if are familiar with more tools.<br>
<br>
Conclusion<br>
--------------<br>
So as you can see, there are several projects that eventually overlap<br>
in many areas. Each group is basically using the same tasks (provision<br>
resources, build/import overcloud images, run tempest, collect logs,<br>
etc.)<br>
<br>
Personally, I think it's a waste of resources. For each task there is<br>
at least two people from different groups who work on exactly the same<br>
task. The most recent example I can give is OVB. As far as I know,<br>
both groups are working on implementing it in their set of tools right<br>
now.<br>
<br>
On the other hand, you can always claim: "we already tried to work on<br>
the same framework, we failed to do it successfully" - right, but<br>
maybe with better ground rules we can manage it. We would defiantly<br>
benefit a lot from doing that.<br>
<br>
What's next?<br>
----------------<br>
So first of all, I would like to hear from you if you think that we<br>
can collaborate once again or is it actually better to keep it as it<br>
is now.<br></blockquote><div><br></div><div>+1 on collaboration, with that being said I can't support forcing groups to use one tool or another.</div><div>Forcing the issue only builds resentment across teams.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you agree that collaboration here makes sense, maybe you have ideas<br>
on how we can do it better this time.<br>
<br>
I think that setting up a meeting to discuss the right architecture<br>
for the project(s) and decide on good review/gating process, would be<br>
a good start.<br></blockquote><div><br></div><div>Not sure why upstream tripleo is left out of this discussion.  Ideally if possible we all need to be using</div><div>upstream CI tools where we can, and if you can't use upstream tools do your best to move the tool(s) upstream.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Please let me know what do you think and keep in mind that this is not<br>
about which tool is better!. As you can see I didn't mention the time<br>
it takes for each tool to deploy and test, and also not the full<br>
feature list it supports.<br>
If possible, we should keep it about collaborating and not choosing<br>
the best tool. Our solution could be the combination of two or more<br>
tools eventually (tripleo-red, infra-quickstart? :D )<br>
<br>
"You may say I'm a dreamer, but I'm not the only one. I hope some day<br>
you'll join us and the infra will be as one" :)<br></blockquote><div><br></div><div>Thanks Arie!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] <a href="https://github.com/redhat-openstack/ansible-ovb" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/ansible-ovb</a><br>
[2] <a href="https://github.com/redhat-openstack/ansible-rhosp" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/ansible-rhosp</a><br>
[3] <a href="https://github.com/redhat-openstack/octario" rel="noreferrer" target="_blank">https://github.com/redhat-openstack/octario</a><br>
[4] <a href="https://github.com/rhosqeauto/InfraRed" rel="noreferrer" target="_blank">https://github.com/rhosqeauto/InfraRed</a><br>
[5] <a href="https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role" rel="noreferrer" target="_blank">https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role</a><br>
[6] <a href="https://github.com/openstack/tripleo-quickstart" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-quickstart</a><br>
</blockquote></div><br></div></div>