<div dir="ltr"><div><div>does this tripleo ui integrate into horizon like tuskar did?<br></div><br></div>and if i recall correclty rdo was _renamed_ to tripleO a few months back<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 7:10 PM, Graeme Gillies <span dir="ltr"><<a href="mailto:ggillies@redhat.com" target="_blank">ggillies@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/08/16 06:45, Mohammed Arafa wrote:<br>
> I too am an end user and have a similar story. I had tried packstack all<br>
> in one but when it was time to deploy to actual servers I looked to<br>
> Ubuntu Maas. It was buggy so after a month or so of several attempts I<br>
> went to RDO. And was happy when I had my environment up. But it was not<br>
> reproducible. I spent months trying. And finally I looked elsewhere and<br>
> was told fuel.<br>
> With fuel I have ha and ceph and live migration with in 2 hours. And<br>
> repeatable too<br>
><br>
> And yes. When tripleo quick start showed up. I did not even look at it.<br>
> Information overload? Too much time spent evaluating and too little<br>
> building something productive? And now I hear of even more.<br>
><br>
> In honesty with the rename of RDO to triple o is there any need for an<br>
> installer?<br>
><br>
> /outburst over<br>
<br>
</span>Hi,<br>
<br>
Just to clear up some confusion here, RDO and TripleO are two very<br>
different things.<br>
<br>
RDO Is an RPM distribution of Openstack that aims to track upstream<br>
Openstack as closely as possible. We provide stable RPM trees for the<br>
current stable releases of Openstack, as well as RPM trees of the latest<br>
Openstack code as it's committed upstream (through DLRN).<br>
<br>
You can deploy and manage Openstack with RDO however you would like<br>
including puppet, chef, ansible, saltstack, and RDO also works with some<br>
of the complete installer projects like TripleO and even kolla (you can<br>
see the containers created by kolla have centos/RDO options at [1]).<br>
<br>
TripleO is an Openstack project which Red Hat is largely involved in,<br>
and aims to make an Openstack installer using Openstack itself. It<br>
currently works best with RDO because that's where most of our effort is<br>
focussed, but there is no technical reason it can't work with other<br>
distros or Operating systems.<br>
<br>
Both of these pieces go into our downstream commercial Offering. RDO<br>
becomes Red Hat Openstack Platform, while TripleO becomes RHOS Director.<br>
<br>
If you wish to consume RDO there is no reason for you to be forced to<br>
use TripleO, and are welcome to use any other deployment method or tool.<br>
We welcome people expanding RDO by utilising it however they please,<br>
deploying it however they like.<br>
<br>
I would love to hear from more people in the community who are using RDO<br>
and not using the default packstack/TripleO installers, as it allows us<br>
to get a better understanding of users needs, and helps us learn more<br>
about what tools and workflows work best for people.<br>
<br>
Regards,<br>
<br>
Graeme<br>
<br>
[1] <a href="https://hub.docker.com/u/kolla/" rel="noreferrer" target="_blank">https://hub.docker.com/u/kolla/</a><br>
<span class=""><br>
><br>
><br>
> On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <<a href="mailto:ibravo@ltgfederal.com">ibravo@ltgfederal.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:ibravo@ltgfederal.com">ibravo@ltgfederal.com</a>>> wrote:<br>
><br>
> If we are talking about tools, I would also want to add something<br>
> with regards to user interface of these tools. This is based on my<br>
> own experience:<br>
><br>
> I started trying to deploy Openstack with Staypuft and The Foreman.<br>
> The UI of The Foreman was intuitive enough for the discovery and<br>
> provisioning of the servers. The OpenStack portion, not so much.<br>
><br>
> Forward a couple of releases and we had a TripleO GUI (Tuskar, I<br>
> believe) that allowed you to graphically build your Openstack cloud.<br>
> That was a reasonable good GUI for Openstack.<br>
><br>
> Following that, TripleO become a script based installer, that<br>
> required experience in Heat templates. I know I didn’t have it and<br>
> had to ask in the mailing list about how to present this or change<br>
> that. I got a couple of installs working with this setup.<br>
><br>
> In the last session in Austin, my goal was to obtain information on<br>
> how others were installing Openstack. I was pointed to Fuel as an<br>
> alternative. I tried it up, and it just worked. It had the<br>
> discovering capability from The Foreman, and the configuration<br>
> options from TripleO. I understand that is based in Ansible and<br>
> because of that, it is not fully CentOS ready for all the nodes (at<br>
> least not in version 9 that I tried). In any case, as a deployer and<br>
> installer, it is the most well rounded tool that I found.<br>
><br>
> I’d love to see RDO moving into that direction, and having an easy<br>
> to use, end user ready deployer tool.<br>
><br>
> IB<br>
><br>
><br>
> __<br>
> Ignacio Bravo<br>
> LTG Federal, Inc<br>
</div></div>> <a href="http://www.ltgfederal.com" rel="noreferrer" target="_blank">www.ltgfederal.com</a> <<a href="http://www.ltgfederal.com" rel="noreferrer" target="_blank">http://www.ltgfederal.com</a>><br>
<span class="">><br>
><br>
>> On Aug 1, 2016, at 1:07 PM, David Moreau Simard <<a href="mailto:dms@redhat.com">dms@redhat.com</a><br>
</span><div><div class="h5">>> <mailto:<a href="mailto:dms@redhat.com">dms@redhat.com</a>>> wrote:<br>
>><br>
>> The vast majority of RDO's CI relies on using upstream<br>
>> installation/deployment projects in order to test installation of RDO<br>
>> packages in different ways and configurations.<br>
>><br>
>> Unless I'm mistaken, TripleO Quickstart was originally created as a<br>
>> mean to "easily" install TripleO in different topologies without<br>
>> requiring a massive amount of hardware.<br>
>> This project allows us to test TripleO in virtual deployments on just<br>
>> one server instead of, say, 6.<br>
>><br>
>> There's also WeIRDO [1] which was left out of your list.<br>
>> WeIRDO is super simple and simply aims to run upstream gate jobs (such<br>
>> as puppet-openstack-integration [2][3] and packstack [4][5]) outside<br>
>> of the gate.<br>
>> It'll install dependencies that are expected to be there (i.e, usually<br>
>> set up by the openstack-infra gate preparation jobs), set up the trunk<br>
>> repositories we're interested in testing and the rest is handled by<br>
>> the upstream project testing framework.<br>
>><br>
>> The WeIRDO project is /very/ low maintenance and brings an exceptional<br>
>> amount of coverage and value.<br>
>> This coverage is important because RDO provides OpenStack packages or<br>
>> projects that are not necessarily used by TripleO and the reality is<br>
>> that not everyone deploying OpenStack on CentOS with RDO will be using<br>
>> TripleO.<br>
>><br>
>> Anyway, sorry for sidetracking but back to the topic, thanks for<br>
>> opening the discussion.<br>
>><br>
>> What honestly perplexes me is the situation of CI in RDO and OSP,<br>
>> especially around TripleO/Director, is the amount of work that is<br>
>> spent downstream.<br>
>> And by downstream, here, I mean anything that isn't in TripleO proper.<br>
>><br>
>> I keep dreaming about how awesome upstream TripleO CI would be if all<br>
>> that effort was spent directly there instead -- and then that all work<br>
>> could bear fruit and trickle down downstream for free.<br>
>> Exactly like how we keep improving the testing coverage in<br>
>> puppet-openstack-integration, it's automatically pulled in RDO CI<br>
>> through WeIRDO for free.<br>
>> We make the upstream better and we benefit from it simultaneously:<br>
>> everyone wins.<br>
>><br>
>> [1]: <a href="https://github.com/rdo-infra/weirdo" rel="noreferrer" target="_blank">https://github.com/rdo-infra/weirdo</a><br>
>> [2]: <a href="https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack" rel="noreferrer" target="_blank">https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack</a><br>
>> [3]:<br>
>> <a href="https://github.com/openstack/puppet-openstack-integration#description" rel="noreferrer" target="_blank">https://github.com/openstack/puppet-openstack-integration#description</a><br>
>> [4]: <a href="https://github.com/rdo-infra/ansible-role-weirdo-packstack" rel="noreferrer" target="_blank">https://github.com/rdo-infra/ansible-role-weirdo-packstack</a><br>
>> [5]:<br>
>> <a href="https://github.com/openstack/packstack#packstack-integration-tests" rel="noreferrer" target="_blank">https://github.com/openstack/packstack#packstack-integration-tests</a><br>
>><br>
>> David Moreau Simard<br>
>> Senior Software Engineer | Openstack RDO<br>
>><br>
>> dmsimard = [irc, github, twitter]<br>
>><br>
>> David Moreau Simard<br>
>> Senior Software Engineer | Openstack RDO<br>
>><br>
>> dmsimard = [irc, github, twitter]<br>
>><br>
>><br>
>> On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <<a href="mailto:abregman@redhat.com">abregman@redhat.com</a><br>
</div></div><div><div class="h5">>> <mailto:<a href="mailto:abregman@redhat.com">abregman@redhat.com</a>>> wrote:<br>
>>> 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<br>
>>> project.<br>
>>><br>
>>> * Ansible-RHOSP[2] - Product installation (RHOSP). Branch per<br>
>>> 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<br>
>>> 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<br>
>>> (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<br>
>>> 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<br>
>>> 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>
>>><br>
>>> If you agree that collaboration here makes sense, maybe you have<br>
>>> 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>
>>><br>
>>> Please let me know what do you think and keep in mind that this<br>
>>> 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>
>>><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]<br>
>>> <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>
>>><br>
>>> _______________________________________________<br>
>>> rdo-list mailing list<br>
</div></div>>>> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a> <mailto:<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a>><br>
<span class="">>>> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>>><br>
>>> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br>
</span>>>> <mailto:<a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a>><br>
>><br>
>> _______________________________________________<br>
>> rdo-list mailing list<br>
>> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a> <mailto:<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a>><br>
<span class="">>> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
>><br>
>> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br>
</span>>> <mailto:<a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a>><br>
><br>
><br>
> _______________________________________________<br>
> rdo-list mailing list<br>
> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a> <mailto:<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a>><br>
<span class="">> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
><br>
> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br>
</span>> <mailto:<a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a>><br>
<span class="im HOEnZb">><br>
><br>
><br>
> _______________________________________________<br>
> rdo-list mailing list<br>
> <a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/rdo-list</a><br>
><br>
> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br>
><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
Graeme Gillies<br>
Principal Systems Administrator<br>
Openstack Infrastructure<br>
Red Hat Australia<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
<table cellpadding="4" cellspacing="0" width="418">
<colgroup><col width="138">
<col width="158">
<col width="98">
</colgroup><tbody><tr valign="TOP">
<td style="border:none;padding:0in" width="138">
<p><img src="http://www.in-egypt.net/RED-HAT-LOGO.jpg" name="UNIQUE_ID_SafeHtmlFilter_graphics1" border="0" height="184" width="135"></p>
</td>
<td style="border:none;padding:0in" width="158">
<p><a href="https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1" target="_blank"><font color="#000080"><img src="http://www.in-egypt.net/ITIL_Logo.jpg" name="UNIQUE_ID_SafeHtmlFilter_graphics2" border="1" align="BOTTOM" height="156" width="156"></font></a></p>
</td>
<td style="border:none;padding:0in" width="98">
<p><img src="http://www.in-egypt.net/linkedin.png" name="UNIQUE_ID_SafeHtmlFilter_graphics3" border="0" align="BOTTOM" height="96" width="96"></p>
</td>
</tr>
<tr valign="TOP">
<td style="border:none;padding:0in" width="138">
<p><a href="https://www.redhat.com/wapps/training/certification/verify.html?certNumber=805010942448935&verify=Verify" target="_blank"><b>805010942448935</b></a><b>
</b>
</p>
</td>
<td style="border:none;padding:0in" width="158">
<p><a href="https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1" target="_blank"><b>GR750055912MA</b></a></p>
</td>
<td style="border:none;padding:0in" width="98">
<p><b>Link to me on <a href="http://www.linkedin.com/in/mohammedarafa" target="_blank">LinkedIn</a></b></p>
</td>
</tr>
</tbody></table>
</div></div>
</div>