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

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(a)ltgfederal.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > > > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > _______________________________________________ rdo-list mailing list rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com