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

Graeme Gillies ggillies at redhat.com
Mon Aug 1 23:24:49 UTC 2016


On 02/08/16 09:16, Mohammed Arafa wrote:
> does this tripleo ui integrate into horizon like tuskar did?

The new TripleO UI is completely stand alone from horizon. I would
expect that once the UI reaches maturity we won't be using horizon on
the undercloud at all, but I'll let someone else more familiar with the
UI confirm.

> 
> and if i recall correclty rdo was _renamed_ to tripleO a few months back

That was "RDO Manager" which was the name we were using for TripleO. So
you still had two things, RDO (the distribution) and RDO Manager which
was the installer. We realised that having the installer called TripleO
in upstream (openstack.org), RDO Manager midstream (in RDO), and RHOS
Director downstream made no sense, so dropped the RDO Manager name. It's
now TripleO everywhere.

Hope this helps,

Regards,

Graeme

> 
> On Mon, Aug 1, 2016 at 7:10 PM, Graeme Gillies <ggillies at redhat.com
> <mailto:ggillies at redhat.com>> wrote:
> 
>     On 02/08/16 06:45, Mohammed Arafa wrote:
>     > 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
> 
>     Hi,
> 
>     Just to clear up some confusion here, RDO and TripleO are two very
>     different things.
> 
>     RDO Is an RPM distribution of Openstack that aims to track upstream
>     Openstack as closely as possible. We provide stable RPM trees for the
>     current stable releases of Openstack, as well as RPM trees of the latest
>     Openstack code as it's committed upstream (through DLRN).
> 
>     You can deploy and manage Openstack with RDO however you would like
>     including puppet, chef, ansible, saltstack, and RDO also works with some
>     of the complete installer projects like TripleO and even kolla (you can
>     see the containers created by kolla have centos/RDO options at [1]).
> 
>     TripleO is an Openstack project which Red Hat is largely involved in,
>     and aims to make an Openstack installer using Openstack itself. It
>     currently works best with RDO because that's where most of our effort is
>     focussed, but there is no technical reason it can't work with other
>     distros or Operating systems.
> 
>     Both of these pieces go into our downstream commercial Offering. RDO
>     becomes Red Hat Openstack Platform, while TripleO becomes RHOS Director.
> 
>     If you wish to consume RDO there is no reason for you to be forced to
>     use TripleO, and are welcome to use any other deployment method or tool.
>     We welcome people expanding RDO by utilising it however they please,
>     deploying it however they like.
> 
>     I would love to hear from more people in the community who are using RDO
>     and not using the default packstack/TripleO installers, as it allows us
>     to get a better understanding of users needs, and helps us learn more
>     about what tools and workflows work best for people.
> 
>     Regards,
> 
>     Graeme
> 
>     [1] https://hub.docker.com/u/kolla/
> 
>     >
>     >
>     > On Aug 1, 2016 2:01 PM, "Ignacio Bravo" <ibravo at ltgfederal.com <mailto:ibravo at ltgfederal.com>
>     > <mailto:ibravo at ltgfederal.com <mailto: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 <http://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>
>     >>     <mailto: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>
>     >>     <mailto: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>
>     <mailto: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 <mailto:rdo-list-unsubscribe at redhat.com>
>     >>>     <mailto:rdo-list-unsubscribe at redhat.com
>     <mailto:rdo-list-unsubscribe at redhat.com>>
>     >>
>     >>     _______________________________________________
>     >>     rdo-list mailing list
>     >>     rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>     <mailto: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 <mailto:rdo-list-unsubscribe at redhat.com>
>     >>     <mailto:rdo-list-unsubscribe at redhat.com
>     <mailto:rdo-list-unsubscribe at redhat.com>>
>     >
>     >
>     >     _______________________________________________
>     >     rdo-list mailing list
>     >     rdo-list at redhat.com <mailto:rdo-list at redhat.com>
>     <mailto: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 <mailto:rdo-list-unsubscribe at redhat.com>
>     >     <mailto:rdo-list-unsubscribe at redhat.com
>     <mailto: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 <mailto:rdo-list-unsubscribe at redhat.com>
>     >
> 
> 
>     --
>     Graeme Gillies
>     Principal Systems Administrator
>     Openstack Infrastructure
>     Red Hat Australia
> 
> 
> 
> 
> -- 
> 
> 	
> 
> <https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1>
> 
> 	
> 
> *805010942448935*
> <https://www.redhat.com/wapps/training/certification/verify.html?certNumber=805010942448935&verify=Verify>**
> 
> 
> 	
> 
> *GR750055912MA*
> <https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1>
> 
> 	
> 
> *Link to me on LinkedIn <http://www.linkedin.com/in/mohammedarafa>*
> 


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




More information about the rdo-list mailing list