[rdo-list] Multiple tools for deploying and testing TripleO

Mon Aug 1 22:59:22 UTC 2016

On 02/08/16 03:59, Ignacio Bravo wrote:
> If we are talking about tools, I would also want to add something with
> regards to user interface of these tools. This is based on my own
> experience:
> 
> I started trying to deploy Openstack with Staypuft and The Foreman. The
> UI of The Foreman was intuitive enough for the discovery and
> provisioning of the servers. The OpenStack portion, not so much.
> 
> Forward a couple of releases and we had a TripleO GUI (Tuskar, I
> believe) that allowed you to graphically build your Openstack cloud.
> That was a reasonable good GUI for Openstack.
> 
> Following that, TripleO become a script based installer, that required
> experience in Heat templates. I know I didn’t have it and had to ask in
> the mailing list about how to present this or change that. I got a
> couple of installs working with this setup.
> 
> In the last session in Austin, my goal was to obtain information on how
> others were installing Openstack. I was pointed to Fuel as an
> alternative. I tried it up, and it just worked. It had the discovering
> capability from The Foreman, and the configuration options from TripleO.
> I understand that is based in Ansible and because of that, it is not
> fully CentOS ready for all the nodes (at least not in version 9 that I
> tried). In any case, as a deployer and installer, it is the most well
> rounded tool that I found.
> 
> I’d love to see RDO moving into that direction, and having an easy to
> use, end user ready deployer tool.
> 
> IB

Hi Ignacio,

You might not be aware but currently there is work being done on a new
TripleO UI (replacing Tuskar).

https://github.com/openstack/tripleo-ui

You can see a demo of it at

https://www.youtube.com/watch?v=1Lc04DKGxCg

Regards,

Graeme

> 
> 
> __
> Ignacio Bravo
> LTG Federal, Inc
> www.ltgfederal.com <http://www.ltgfederal.com>
> 
> 
>> On Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms at redhat.com
>> <mailto:dms at redhat.com>> wrote:
>>
>> The vast majority of RDO's CI relies on using upstream
>> installation/deployment projects in order to test installation of RDO
>> packages in different ways and configurations.
>>
>> Unless I'm mistaken, TripleO Quickstart was originally created as a
>> mean to "easily" install TripleO in different topologies without
>> requiring a massive amount of hardware.
>> This project allows us to test TripleO in virtual deployments on just
>> one server instead of, say, 6.
>>
>> There's also WeIRDO [1] which was left out of your list.
>> WeIRDO is super simple and simply aims to run upstream gate jobs (such
>> as puppet-openstack-integration [2][3] and packstack [4][5]) outside
>> of the gate.
>> It'll install dependencies that are expected to be there (i.e, usually
>> set up by the openstack-infra gate preparation jobs), set up the trunk
>> repositories we're interested in testing and the rest is handled by
>> the upstream project testing framework.
>>
>> The WeIRDO project is /very/ low maintenance and brings an exceptional
>> amount of coverage and value.
>> This coverage is important because RDO provides OpenStack packages or
>> projects that are not necessarily used by TripleO and the reality is
>> that not everyone deploying OpenStack on CentOS with RDO will be using
>> TripleO.
>>
>> Anyway, sorry for sidetracking but back to the topic, thanks for
>> opening the discussion.
>>
>> What honestly perplexes me is the situation of CI in RDO and OSP,
>> especially around TripleO/Director, is the amount of work that is
>> spent downstream.
>> And by downstream, here, I mean anything that isn't in TripleO proper.
>>
>> I keep dreaming about how awesome upstream TripleO CI would be if all
>> that effort was spent directly there instead -- and then that all work
>> could bear fruit and trickle down downstream for free.
>> Exactly like how we keep improving the testing coverage in
>> puppet-openstack-integration, it's automatically pulled in RDO CI
>> through WeIRDO for free.
>> We make the upstream better and we benefit from it simultaneously:
>> everyone wins.
>>
>> [1]: https://github.com/rdo-infra/weirdo
>> [2]: https://github.com/rdo-infra/ansible-role-weirdo-puppet-openstack
>> [3]: https://github.com/openstack/puppet-openstack-integration#description
>> [4]: https://github.com/rdo-infra/ansible-role-weirdo-packstack
>> [5]: https://github.com/openstack/packstack#packstack-integration-tests
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>> David Moreau Simard
>> Senior Software Engineer | Openstack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>>
>> On Mon, Aug 1, 2016 at 11:21 AM, Arie Bregman <abregman at redhat.com
>> <mailto:abregman at redhat.com>> wrote:
>>> Hi,
>>>
>>> I would like to start a discussion on the overlap between tools we
>>> have for deploying and testing TripleO (RDO & RHOSP) in CI.
>>>
>>> Several months ago, we worked on one common framework for deploying
>>> and testing OpenStack (RDO & RHOSP) in CI. I think you can say it
>>> didn't work out well, which eventually led each group to focus on
>>> developing other existing/new tools.
>>>
>>> What we have right now for deploying and testing
>>> --------------------------------------------------------
>>> === Component CI, Gating ===
>>> I'll start with the projects we created, I think that's only fair :)
>>>
>>> * Ansible-OVB[1] - Provisioning Tripleo heat stack, using the OVB
>>> project.
>>>
>>> * Ansible-RHOSP[2] - Product installation (RHOSP). Branch per release.
>>>
>>> * Octario[3] - Testing using RPMs (pep8, unit, functional, tempest,
>>> csit) + Patching RPMs with submitted code.
>>>
>>> === Automation, QE ===
>>> * InfraRed[4] - provision install and test. Pluggable and modular,
>>> allows you to create your own provisioner, installer and tester.
>>>
>>> As far as I know, the groups is working now on different structure of
>>> one main project and three sub projects (provision, install and test).
>>>
>>> === RDO ===
>>> I didn't use RDO tools, so I apologize if I got something wrong:
>>>
>>> * About ~25 micro independent Ansible roles[5]. You can either choose
>>> to use one of them or several together. They are used for
>>> provisioning, installing and testing Tripleo.
>>>
>>> * Tripleo-quickstart[6] - uses the micro roles for deploying tripleo
>>> and test it.
>>>
>>> As I said, I didn't use the tools, so feel free to add more
>>> information you think is relevant.
>>>
>>> === More? ===
>>> I hope not. Let us know if are familiar with more tools.
>>>
>>> Conclusion
>>> --------------
>>> So as you can see, there are several projects that eventually overlap
>>> in many areas. Each group is basically using the same tasks (provision
>>> resources, build/import overcloud images, run tempest, collect logs,
>>> etc.)
>>>
>>> Personally, I think it's a waste of resources. For each task there is
>>> at least two people from different groups who work on exactly the same
>>> task. The most recent example I can give is OVB. As far as I know,
>>> both groups are working on implementing it in their set of tools right
>>> now.
>>>
>>> On the other hand, you can always claim: "we already tried to work on
>>> the same framework, we failed to do it successfully" - right, but
>>> maybe with better ground rules we can manage it. We would defiantly
>>> benefit a lot from doing that.
>>>
>>> What's next?
>>> ----------------
>>> So first of all, I would like to hear from you if you think that we
>>> can collaborate once again or is it actually better to keep it as it
>>> is now.
>>>
>>> If you agree that collaboration here makes sense, maybe you have ideas
>>> on how we can do it better this time.
>>>
>>> I think that setting up a meeting to discuss the right architecture
>>> for the project(s) and decide on good review/gating process, would be
>>> a good start.
>>>
>>> Please let me know what do you think and keep in mind that this is not
>>> about which tool is better!. As you can see I didn't mention the time
>>> it takes for each tool to deploy and test, and also not the full
>>> feature list it supports.
>>> If possible, we should keep it about collaborating and not choosing
>>> the best tool. Our solution could be the combination of two or more
>>> tools eventually (tripleo-red, infra-quickstart? :D )
>>>
>>> "You may say I'm a dreamer, but I'm not the only one. I hope some day
>>> you'll join us and the infra will be as one" :)
>>>
>>> [1] https://github.com/redhat-openstack/ansible-ovb
>>> [2] https://github.com/redhat-openstack/ansible-rhosp
>>> [3] https://github.com/redhat-openstack/octario
>>> [4] https://github.com/rhosqeauto/InfraRed
>>> [5] https://github.com/redhat-openstack?utf8=%E2%9C%93&query=ansible-role
>>> [6] https://github.com/openstack/tripleo-quickstart
>>>
>>> _______________________________________________
>>> rdo-list mailing list
>>> rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>>> https://www.redhat.com/mailman/listinfo/rdo-list
>>>
>>> To unsubscribe: rdo-list-unsubscribe at redhat.com
>>
>> _______________________________________________
>> rdo-list mailing list
>> rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
> 
> 
> 
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at redhat.com
> 

-- 
Graeme Gillies
Principal Systems Administrator
Openstack Infrastructure
Red Hat Australia