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

Mohammed Arafa mohammed.arafa at gmail.com
Mon Aug 1 23:16:27 UTC 2016


does this tripleo ui integrate into horizon like tuskar did?

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

On Mon, Aug 1, 2016 at 7:10 PM, Graeme Gillies <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>> 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>
> >
> >
> >>     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
> >>>     <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>
> >
> >
> >     _______________________________________________
> >     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>
> >
> >
> >
> > _______________________________________________
> > 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
>



-- 

<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>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160801/bfc5e7a5/attachment.html>


More information about the dev mailing list