[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