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 tooAnd 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@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.IBOn Aug 1, 2016, at 1:07 PM, David Moreau Simard <dms@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe@redhat.com
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe@redhat.com
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe@redhat.com
_______________________________________________
rdo-list mailing list
rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe@redhat.com