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

Pedro Sousa pgsousa at gmail.com
Mon Aug 1 23:40:57 UTC 2016


HI Graeme,

I'm more interested in following RHEL OSP approach, so  I install both
Director or TripleO depending on my customers, but I'll take a close look
on Kolla.

I have a question (I know it's out of scope) but if you can answer me, I
appreciate it. For overcloud nodes images do we still need delorean repos?
Or can we just install a clean Centos image with SIG repositories? I want
the images to be as stable as possible.

Thanks







On Tue, Aug 2, 2016 at 12:27 AM, Graeme Gillies <ggillies at redhat.com> wrote:

> On 02/08/16 08:01, Pedro Sousa wrote:
> > My 2 cents here as an operator/integrator, since I've been using the
> > CentOS SIG repositories (mitaka) and following the RHEL Oficial
> > Documentation, I've managed to install several baremetal tripleo based
> > clouds with success. I've not tried tripleo quickstart,
> >
> > I've also tried Fuel in the past and it works pretty well with the
> > plugin architecture and the network validation among other things, but
> > still I prefer tripleo, it gives me more flexibility to setup the
> > network the way I want it, and using ironic to provision the baremetal
> > hosts is pretty cool too. Also personally I prefer to use Centos than
> > Ubuntu as O.S base system, I find it more stable.
> >
> > Still tripleo lacks the ease of installation that Fuel has, and an UI
> > would be great. Also, I'm not sure that using heat templates is the best
> > approach, specially when someone makes a mistake editing the yaml files
> > and stack returns an error. This could happen when you try to update the
> > overcloud nodes, scaling the compute nodes for example. It's not easy to
> > revert the heat stack when you make a mistake.
> >
> > There's a lot of room to improve, specially in terms of complexity of
> > installation and update. Maybe containers (kolla) could be a good
> > approach in the future?
>
> Hi Pedro,
>
> As an Operator and long time user of TripleO, I sympathise with you that
> the combination of heat templates and puppet are difficult to learn and
> don't have the mature tooling to help you understand and test how
> changes to the code will reflect in the real environment.
>
> One thing I will point out is that if you do a stack update that fails,
> more often than not it's not the end of the world. If you go on your
> controller plane and make sure pacemaker and all services are up and
> running, the state of the stack in heat on the undercloud doesn't really
> matter as much.
>
> This way we always try to "fail forward". If we do a bad stack update,
> we make sure the environment is stable again, and then push a new stack
> update with the fixes.
>
> Having a staging or test environment you can utilise to perform changes
> on first in order to identify these problems is also beneficial. We try
> and get all our Operators to have a virtual tripleo setup on a desktop
> for them to "develop" changes on, as well as a shared staging
> environments to do final testing of any proposed change before rolling
> into production.
>
> If you are interested in understanding our full development/rollout
> process I can go into more detail.
>
> Also kolla already supports centos/RDO, so you can head over to the
> kolla project and follow their documentation if you are interested in
> giving it a go. You are able to use Centos and RDO with containers right
> now, no need to wait for anything in the future.
>
> Regards,
>
> Graeme
>
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 1, 2016 at 9:45 PM, Mohammed Arafa <mohammed.arafa at gmail.com
> > <mailto:mohammed.arafa at gmail.com>> 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
> >
> >
> >     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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160802/d45089e8/attachment.html>


More information about the dev mailing list