<div dir="ltr">HI Graeme,<div><br></div><div>I'm more interested in following RHEL OSP approach, so I install both Director or TripleO depending on my customers, but I'll take a close look on Kolla.</div><div><br></div><div>I have a question (I know it's out of scope) but if you can answer me, I appreciate it. For overcloud nodes images do we still need delorean repos? Or can we just install a clean Centos image with SIG repositories? I want the images to be as stable as possible.</div><div><br></div><div>Thanks </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 12:27 AM, 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 08:01, Pedro Sousa wrote:<br>
> My 2 cents here as an operator/integrator, since I've been using the<br>
> CentOS SIG repositories (mitaka) and following the RHEL Oficial<br>
> Documentation, I've managed to install several baremetal tripleo based<br>
> clouds with success. I've not tried tripleo quickstart,<br>
><br>
> I've also tried Fuel in the past and it works pretty well with the<br>
> plugin architecture and the network validation among other things, but<br>
> still I prefer tripleo, it gives me more flexibility to setup the<br>
> network the way I want it, and using ironic to provision the baremetal<br>
> hosts is pretty cool too. Also personally I prefer to use Centos than<br>
> Ubuntu as O.S base system, I find it more stable.<br>
><br>
> Still tripleo lacks the ease of installation that Fuel has, and an UI<br>
> would be great. Also, I'm not sure that using heat templates is the best<br>
> approach, specially when someone makes a mistake editing the yaml files<br>
> and stack returns an error. This could happen when you try to update the<br>
> overcloud nodes, scaling the compute nodes for example. It's not easy to<br>
> revert the heat stack when you make a mistake.<br>
><br>
> There's a lot of room to improve, specially in terms of complexity of<br>
> installation and update. Maybe containers (kolla) could be a good<br>
> approach in the future?<br>
<br>
</span>Hi Pedro,<br>
<br>
As an Operator and long time user of TripleO, I sympathise with you that<br>
the combination of heat templates and puppet are difficult to learn and<br>
don't have the mature tooling to help you understand and test how<br>
changes to the code will reflect in the real environment.<br>
<br>
One thing I will point out is that if you do a stack update that fails,<br>
more often than not it's not the end of the world. If you go on your<br>
controller plane and make sure pacemaker and all services are up and<br>
running, the state of the stack in heat on the undercloud doesn't really<br>
matter as much.<br>
<br>
This way we always try to "fail forward". If we do a bad stack update,<br>
we make sure the environment is stable again, and then push a new stack<br>
update with the fixes.<br>
<br>
Having a staging or test environment you can utilise to perform changes<br>
on first in order to identify these problems is also beneficial. We try<br>
and get all our Operators to have a virtual tripleo setup on a desktop<br>
for them to "develop" changes on, as well as a shared staging<br>
environments to do final testing of any proposed change before rolling<br>
into production.<br>
<br>
If you are interested in understanding our full development/rollout<br>
process I can go into more detail.<br>
<br>
Also kolla already supports centos/RDO, so you can head over to the<br>
kolla project and follow their documentation if you are interested in<br>
giving it a go. You are able to use Centos and RDO with containers right<br>
now, no need to wait for anything in the future.<br>
<br>
Regards,<br>
<br>
Graeme<br>
<span class=""><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Aug 1, 2016 at 9:45 PM, Mohammed Arafa <<a href="mailto:mohammed.arafa@gmail.com">mohammed.arafa@gmail.com</a><br>
</span><span class="">> <mailto:<a href="mailto:mohammed.arafa@gmail.com">mohammed.arafa@gmail.com</a>>> wrote:<br>
><br>
> I too am an end user and have a similar story. I had tried packstack<br>
> all in one but when it was time to deploy to actual servers I looked<br>
> to Ubuntu Maas. It was buggy so after a month or so of several<br>
> attempts I went to RDO. And was happy when I had my environment up.<br>
> But it was not reproducible. I spent months trying. And finally I<br>
> looked elsewhere and 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<br>
> it. Information overload? Too much time spent evaluating and too<br>
> little 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<br>
> an installer?<br>
><br>
> /outburst over<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<br>
> something with regards to user interface of these tools. This is<br>
> based on my own experience:<br>
><br>
> I started trying to deploy Openstack with Staypuft and The<br>
> Foreman. The UI of The Foreman was intuitive enough for the<br>
> discovery and provisioning of the servers. The OpenStack<br>
> 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<br>
> cloud. 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<br>
> and had to ask in the mailing list about how to present this or<br>
> change 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<br>
> on how others were installing Openstack. I was pointed to Fuel<br>
> as an 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<br>
> (at least not in version 9 that I tried). In any case, as a<br>
> deployer and installer, it is the most well rounded tool that I<br>
> found.<br>
><br>
> I’d love to see RDO moving into that direction, and having an<br>
> easy 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<br>
</span><div><div class="h5">>> <<a href="mailto:dms@redhat.com">dms@redhat.com</a> <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<br>
>> of RDO<br>
>> packages in different ways and configurations.<br>
>><br>
>> Unless I'm mistaken, TripleO Quickstart was originally created<br>
>> 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<br>
>> 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<br>
>> jobs (such<br>
>> as puppet-openstack-integration [2][3] and packstack [4][5])<br>
>> outside<br>
>> of the gate.<br>
>> It'll install dependencies that are expected to be there (i.e,<br>
>> usually<br>
>> set up by the openstack-infra gate preparation jobs), set up<br>
>> the trunk<br>
>> repositories we're interested in testing and the rest is<br>
>> handled by<br>
>> the upstream project testing framework.<br>
>><br>
>> The WeIRDO project is /very/ low maintenance and brings an<br>
>> exceptional<br>
>> amount of coverage and value.<br>
>> This coverage is important because RDO provides OpenStack<br>
>> packages or<br>
>> projects that are not necessarily used by TripleO and the<br>
>> reality is<br>
>> that not everyone deploying OpenStack on CentOS with RDO will<br>
>> 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<br>
>> proper.<br>
>><br>
>> I keep dreaming about how awesome upstream TripleO CI would be<br>
>> if all<br>
>> that effort was spent directly there instead -- and then that<br>
>> 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]:<br>
>> <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<br>
</div></div><div><div class="h5">>> <<a href="mailto:abregman@redhat.com">abregman@redhat.com</a> <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<br>
>>> 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<br>
>>> 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<br>
>>> fair :)<br>
>>><br>
>>> * Ansible-OVB[1] - Provisioning Tripleo heat stack, using the<br>
>>> OVB project.<br>
>>><br>
>>> * Ansible-RHOSP[2] - Product installation (RHOSP). Branch per<br>
>>> release.<br>
>>><br>
>>> * Octario[3] - Testing using RPMs (pep8, unit, functional,<br>
>>> tempest,<br>
>>> csit) + Patching RPMs with submitted code.<br>
>>><br>
>>> === Automation, QE ===<br>
>>> * InfraRed[4] - provision install and test. Pluggable and<br>
>>> 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<br>
>>> structure of<br>
>>> one main project and three sub projects (provision, install<br>
>>> 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<br>
>>> 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<br>
>>> 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<br>
>>> overlap<br>
>>> in many areas. Each group is basically using the same tasks<br>
>>> (provision<br>
>>> resources, build/import overcloud images, run tempest,<br>
>>> collect logs,<br>
>>> etc.)<br>
>>><br>
>>> Personally, I think it's a waste of resources. For each task<br>
>>> there is<br>
>>> at least two people from different groups who work on exactly<br>
>>> the same<br>
>>> task. The most recent example I can give is OVB. As far as I<br>
>>> know,<br>
>>> both groups are working on implementing it in their set of<br>
>>> tools right<br>
>>> now.<br>
>>><br>
>>> On the other hand, you can always claim: "we already tried to<br>
>>> 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<br>
>>> 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<br>
>>> that we<br>
>>> can collaborate once again or is it actually better to keep<br>
>>> it as it<br>
>>> is now.<br>
>>><br>
>>> If you agree that collaboration here makes sense, maybe you<br>
>>> 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<br>
>>> architecture<br>
>>> for the project(s) and decide on good review/gating process,<br>
>>> would be<br>
>>> a good start.<br>
>>><br>
>>> Please let me know what do you think and keep in mind that<br>
>>> this is not<br>
>>> about which tool is better!. As you can see I didn't mention<br>
>>> 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<br>
>>> choosing<br>
>>> the best tool. Our solution could be the combination of two<br>
>>> 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<br>
>>> 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>
><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>
> _______________________________________________<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></div>