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

Mon Aug 1 20:45:27 UTC 2016

I too am an end user and have a similar story. I had tried packstack all in
one but when it was time to deploy to actual servers I looked to Ubuntu
Maas. It was buggy so after a month or so of several attempts I went to
RDO. And was happy when I had my environment up. But it was not
reproducible. I spent months trying. And finally I looked elsewhere and was
told fuel.
With fuel I have ha and ceph and live migration with in 2 hours. And
repeatable too

And yes. When tripleo quick start showed up. I did not even look at it.
Information overload? Too much time spent evaluating and too little
building something productive? And now I hear of even more.

In honesty with the rename of RDO to triple o is there any need for an
installer?

/outburst over

On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo at ltgfederal.com> 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
>
>
> __
> Ignacio Bravo
> LTG Federal, Inc
> www.ltgfederal.com
>
>
> On Aug 1, 2016, at 1:07 PM, David Moreau Simard <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> 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
> 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
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160801/7d9506bf/attachment.html>