When Derek Higgins started the tool to build OpenStack packages based on latest upstream aka “trunk” changes, the name Delorean seemed like a good choice: the tool is keeping older builds so you could “go back in time” like with a time machine, it’s geeky enough and there’s Irish connection.

Fast forward earlier this year, when this tool is used and maintained by the RDO team to build RDO trunk repositories, it was felt the time is right for the first release. And here is the first lesson when naming a (Python) project: check that name is available in PyPI and reserve it! Unfortunately, it turned that name Delorean was already taken by another project. Next, lesson two: check if there is an active company using that name to avoid any possibility of trademark issues! In this case, a new company got rights for the original DMC (TM).

On RDO community meeting we decided to start collecting new name proposals and came up with the list more or less in the same time travel and BTTF theme. The first proposal was fluzo by our Spanish-speaking folks but that was dismissed after finding out there is a company with exactly that name! Next was OUTATIME, the DeLorean time machine’s license plate text, but there’s actually a real movie with that name coming soon, so it was discarded to avoid confusion and possible trademark issues. Finally, staying with the license plate idea, DLRN was chosen: written as DLRN but you can read it Delorean.

The RDO community has already started work towards replacing mentions of “Delorean” in documentation, websites, code, and repositories. As a special case references mentioning “Delorean repository” will be renamed as “RDO trunk repository” to better describe the content.

P.S. The answer to the question in the title is dprince! 1

The RDO community is pleased to announce the general availability of the RDO build for OpenStack Mitaka for RPM-based distributions - CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds and Mitaka is the 13th release from the OpenStack project, which is the work of more than 2500 contributors from around the world. (Source)

See RedHatStack for a brief overview of what’s new in Mitaka.

The RDO community project curates, packages, builds, tests, and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a founding member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds.

All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first.

For a complete list of what’s in RDO, see the RDO projects yaml file.

Getting Started

There are three ways to get started with RDO.

To spin up a proof of concept cloud, quickly, and on limited hardware, try the RDO QuickStart You can run RDO on a single node to get a feel for how it works.

For a production deployment of RDO, use the TripleO Quickstart and you’ll be running a production cloud in short order.

Finally, if you want to try out OpenStack, but don’t have the time or hardware to run it yourself, visit TryStack, where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack

Getting Help

The RDO Project participates in a Q&A service at ask.openstack.org, for more developer oriented content we recommend joining the rdo-list mailing list. Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site.

We also welcome comments and requests on the CentOS Mailing lists and the CentOS IRC Channels (#centos on irc.freenode.net), however we have a more focused audience in the RDO venues.

Getting Involved

To get involved in the OpenStack RPM packaging effort, see the RDO community pages and the CentOS Cloud SIG page. See also the RDO packaging documentation.

Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter.

And, if you’re going to be in Austin for the OpenStack Summit two weeks from now, join us on Thursday at 4:40pm for the RDO community BoF.

Here’s what RDO enthusiasts were blogging about this week:

St. Louis OpenStack Meetup by Rich Bowen

On Tuesday evening I had the privilege of addressing the St. Louis OpenStack Meetup group. I gave an Introduction to OpenStack presentation to about 30 attendees, many of whom were indeed OpenStack beginners, or just beginning to research what this OpenStack thing is all about.

… read more at http://tm3.org/60

Upcoming events in OpenStack and RDO by Rich Bowen

I love this time of year - the energy and passion that swells right around an upstream OpenStack release, and the weeks before an OpenStack Summit. Most of the year, people are heads down working on their particular part of the project, but as we near a release, there’s a lot of interest in what’s going on in the larger upstream.

… read more at http://tm3.org/61

Extending OpenStack Disaster Recovery to Google Cloud Storage by Sean Cohen

The OpenStack Cinder Backup service was introduced in Cinder in the Grizzly release to allow users to create backups from their volumes and store it to their Swift object storage system (still very common use case in OpenStack private clouds to date). Since then, the Backup API continued to mature with every release.

… read more at http://tm3.org/62

I love this time of year - the energy and passion that swells right around an upstream OpenStack release, and the weeks before an OpenStack Summit. Most of the year, people are heads down working on their particular part of the project, but as we near a release, there’s a lot of interest in what’s going on in the larger upstream.

There’s also a huge surge in things to announce around the RDO community, as well as the upstream OpenStack community:

• The upstream release of Mitaka is this week. Stackalytics lists over 2500 people who have contributed to this release.

• We’ll be conducting a test day for RDO Mitaka on April 13th and 14th.

• OpenStack Summit is just 2 weeks away, and we’ll be having an RDO BoF (Birds of a Feather) gathering there.

• If you have something you’d like to demo in the RDO booth at OpenStack Summit, add your idea to the booth schedule etherpad.

And, as every week, there are lots of OpenStack Meetups all over the world this week. Especially don’t miss Perry Meyers’ RDO Q&A at the Morgantown OpenStack Meetup.

Here’s what RDO engineers are blogging about lately

Who can +2 a patch? by Adam Young

You are trying to push along a patch…and it dawns on you that you have no idea who to ask. The answer is out there.

… read more at http://tm3.org/5s

The OpenStack Schizophrenia by Julien Danjou

When I started contributing to OpenStack, almost five years ago, it was a small ecosystem. There were no foundation, a handful of projects and you could understand the code base in a few days. Fast forward 2016, and it is a totally different beast. The project grew to no less than 54 teams, each team providing one or more deliverable. For example, the Nova and Swift team each one produces one service and its client, whereas the Telemetry team produces 3 services and 3 different clients.

… read more at http://tm3.org/5t

Improving QEMU security part 1: crypto code consolidation by Daniel P. Berrangé

This blog is part 1 of a series I am writing about work I’ve completed over the past few releases to improve QEMU security related features.

… read more at http://tm3.org/5u

Improving QEMU security part 2: generic TLS support by Daniel P. Berrangé

This blog is part 2 of a series I am writing about work I’ve completed over the past few releases to improve QEMU security related features.

… read more at http://tm3.org/5v

Improving QEMU security part 3: securely passing in credentials by Daniel P. Berrangé

This blog is part 3 of a series I am writing about work I’ve completed over the past few releases to improve QEMU security related features.

… read more at http://tm3.org/5w

Improving QEMU security part 4: generic I/O channel framework to simplify TLS by Daniel P. Berrangé

This blog is part 4 of a series I am writing about work I’ve completed over the past few releases to improve QEMU security related features.

… read more at http://tm3.org/5x

St. Louis OpenStack Meetup by Rich Bowen

On Tuesday evening I had the privilege of addressing the St. Louis OpenStack Meetup group. I gave an Introduction to OpenStack presentation to about 30 attendees, many of whom were indeed OpenStack beginners, or just beginning to research what this OpenStack thing is all about.

… read more at http://tm3.org/5y

FreeIPA for Tripleo by Adam Young

My last post showed how to allocate an additional VM for Tripleo. Now I’m going to go through the steps to deploy FreeIPA on it. However, since I went through all of the effort to write Ossipee and Rippowam, I am going to use those to do the heavy lifting.

… read more at http://tm3.org/5z

Setup Docker Hypervisor on Multi Node DVR Cluster RDO Mitaka by Boris Derzhavets

DVR && Nova-Docker Driver (stable/mitaka) tested fine on RDO Mitaka build 20160329) with no issues described in previous notice for RDO Liberty

… read more at http://tm3.org/5-

On Tuesday evening I had the privilege of addressing the St. Louis OpenStack Meetup group. I gave an Introduction to OpenStack presentation to about 30 attendees, many of whom were indeed OpenStack beginners, or just beginning to research what this OpenStack thing is all about.

@rbowen speaking at tonight's #OpenStack meet up hosted at CenturyLink's new cloud dev center pic.twitter.com/6Rxuvz3phe

— OpenStack St.Louis (@openstackstl) March 30, 2016

There were roughly 30 people in attendance, and questions ranged across a variety of topics, including ease of deployment, ongoing support, and the upgrade path for future versions.

A huge thank you is due to CenturyLink, who hosted the meetup in their beautiful office facility, and to Ranga Chakravarthula, who coordinated everything.

Here’s what RDO enthusiasts have been blogging about in the last week:

Tie Your Rabbit Down by Adam Young

I’ve been running the Tripleo Quickstart to setup my development deployments. While looking into the setup, I noticed that the default Rabbit deployment is wide open. I can’t see anything other than firewall port blocking in place. I dug deeper.

… read more at http://tm3.org/5l

Red Hat confirms over 35 sessions at OpenStack Summit, Austin – Have a look! by Jeff Jameson

As this Spring’s 2016 OpenStack Summit in Austin, TX nears, the Foundation has posted the final session agenda, outlining the week’s schedule of events. I am pleased to see that based on your voting, Red Hat continues to remain in sync with the current topics, projects, and technologies the OpenStack community and customers are most interested in. With the expectation of the largest attendee crowd yet, and some exciting advancements around containers, storage, networking, compute, and more, we look forward to sharing the 35+ generally accepted sessions, workshops, and BoFs that will be included in the weeks agenda.

… read more at http://tm3.org/5m

Dependency Injection in Python applied to Ossipee by Adam Young

I reworked my OpenStack API based cluster builder Ossipee last weekend. It makes heavy use of dependency resolution now, and breaks apart the super-base class into properly scoped components.

… read more at http://tm3.org/5n

Convert a keystone.rc from V2 to V3 by Adam Young

Everything seems to produce V2 versions of the necessary variables for Keystone, and I am more and more dependant on the V3 setup. Converting from one to the other is trivial, especially if the setup uses the default domain.

… read more at http://tm3.org/5o

Long Term OpenStack Usage Summary by SilverSkySoft

Its been about 9 months since we first kicked off a limited production install of OpenStack. There were few variables we were very interested in: How much specialized support was needed to maintain a small OpenStack and stability.

… read more at http://tm3.org/5p

Learn what’s coming in OpenStack “Mitaka” by Jeff Jameson

As the fastest growing open source project in history, OpenStack releases fairly rapidly, with new releases twice per year. Each time, around April and October of every year, a whole plethora of new features and functions move from incubated development status to fully-baked features and accepted into the “core” OpenStack release. Rapidly approaching is the new “Mitaka” release, the 13th release of OpenStack, filled with some great new features.

… read more at http://tm3.org/5q

Attempt to set up RDO Mitaka (RC1) at any given time (Delorean trunks) by Boris Derzhavets

“The RDO project has a continuous integration pipeline that consists of multiple jobs that deploy and test OpenStack as accomplished by different installers. This vast test coverage attempts to ensure that there are no known issues either in packaging, in code or in the installers themselves.Once a Delorean consistent repository has undergone these tests successfully, it will be promoted to current-passed-ci. Current-passed-ci represents the latest and greatest version of RDO trunk packages that were tested together successfully”

… read more at http://tm3.org/5r

I was traveling much of last week, so we have two weeks of blog posts to catch you up on, and there’s some really good ones in here.

“RDO Manager” is now “TripleO”, by K Rain Leander

Because of its unique branding and name, one might assume that “RDO Manager” is not TripleO - perhaps it has additional downstream patches or maybe they’re entirely different projects. You would not be alone because the community, the users and the developers alike have shared their confusion on this topic.

… read more at http://tm3.org/58

Creating an additional host for a Tripleo overcloud, by Adam Young

I’ve been successful following the steps to get a Tripleo deployment. I now need to add another server to host the Identity Management and Federation services. Here’s the steps:

… read more at http://tm3.org/59

OpenStack Montreal: A talk about CI in OpenStack and RDO, by David Moreau Simard

OpenStack Montreal is a meetup that happens around every 2 months in Montreal. We talk and discuss about different OpenStack topics with interests for developers, users and operators. If you’d like to keep up with the event, attend (or present a topic!), please subscribe to the mailing list to be notified when something’s going on.

… read more at http://tm3.org/5a

Packstack gates against itself by David Moreau Simard

Today I made an announcement on both openstack-dev and rdo-list that Packstack was going to gate against itself.

… read more at http://tm3.org/5b

RDO Kilo ML2&OVS&VLAN Mutti Node Deployment on Fedora 23 by Boris Derzhavets

To complete packstack run for two nodes Controller/Network and Compute setup I had to apply as pre-installation following patches, otherwise neutron puppet crashed on Fedora 23 :-

… read more at http://tm3.org/5c

How i started contributing to the RDO Project by Chandan Kumar

During my internship period at Red Hat, Kushal used to play with OpenStack and got a problem that a created instance is not able to get a public IP address so that he can access it from outside.

… read more at http://tm3.org/5d

What Can Talk To What on the OpenStack Message Broker by Adam Young

If a hypervisor is compromised, the Nova Compute instance running on that node is also compromised. If the compute instance is compromised, then its access to the Message Queue has to be considered tainted as well. What degree of risk does this pose?

… read more at http://tm3.org/5e

Status of Python 3 in OpenStack Mitaka by Victor Stinner

Now that most OpenStack services have reached feature freeze for the Mitaka cycle (November 2015-April 2016), it’s time to look back on the progress made for Python 3 support.

… read more at http://tm3.org/5f

Setup DVR on RDO Liberty Controller && 2(x)Computes ML2/OVS/VLAN landscape by Boris Derzhavets

Just a reminder in Juno and Kilo DVR was available for deployments using VXLAN tunneling and required l2population activation on all nodes. One of new features of Liberty is DVR compatibility with ML2&OVS&VLAN deployed landscapes. On RDO Liberty packstack doesn’t play so nicely doing VLAN deployment as in case of VXLAN tunneling. Attempt to use old templates for answer file just does all configs properly only on Controller/Network Node.

… read more at http://tm3.org/5g

OpenStack Infra: Jenkins Jobs by Arie Bregman

A few days ago, while adding a new job to OpenStack Infra, I realized how difficult it must be for newcomers ( to OpenStack) to understand how OpenStack CI works and make new changes. The OpenStack Infra documentation coverage of each project is great and very detailed , but connecting the dots, which assembles the complete work-flow can be a complex task for anyone.

… read more at http://tm3.org/5h

Glance Mitaka: Passing the torch by Flavio Percoco

I’m not going to run for Glance’s PTL position for the Newton timeframe. There are many motivations behind this choice. Some of them I’m willing to discuss in private if people are interested but I’ll go as far as saying there are personal and professional reasons for me to not run again.

… read more at http://tm3.org/5i

HA support for DVR centralized default SNAT functionality on RDO Mitaka Milestone 3 by Boris Derzhavets

Verification been done bellow is actually targeting conversion of HAProxy/Keepalived (Active/Active) 3 Node Controller which design was suggested for RDO Liberty in https://github.com/beekhof/osp-ha-deploy/blob/master/HA-keepalived.md to be able support Compute Nodes running in DVR mode. The core issue on Liberty was resolved for Mitaka , see upstream record [RFE] Unable to create a router that’s both HA and distributed General concepts (DVR/SNAT) are explained here Distributed Virtual Routing – SNAT

… read more at http://tm3.org/5j

During my internship period at Red Hat, Kushal used to play with OpenStack and got a problem that a created instance is not able to get a public IP address so that he can access it from outside.

From there I got introduced to OpenStack. I started by trying to install OpenStack (Icehouse) following the upstream documentation, to reproduce this problem. There, I found the steps were wrong, and from there I sent my first patch to the OpenStack docs which is when my contribution to OpenStack begins. I tried devstack, packstack, and other installers to deploy OpenStack.

But I exactly don’t remember how I got involved with RDO Project. As per Gerrit Hub Review history, I made my first contribution to the RDO packages in March 2015. Since last year, I started attending RDO meetings regularly. In the beginning, I just used to read the meeting logs and try to find out what is happening in the community. But later on, I started taking action items and tried to prepare for next meeting. I failed a lot of times in the beginning and worked with the motive to complete the tasks properly. One day, I accidently raised my hand for chairing RDO meeting and it was a nice experience. Now I usually volunteer for chairing the RDO meeting.

During the starting of liberty release, the RDO CI used to break due to missing packages. It was then I learned about RPM packaging and started fixing those packages. Currently, I am maintaining 16 Fedora packages and have learned a lot on how to fix packages when things went wrong.

At the same time, I had started sending out RDO Bug Statistics to the RDO mailing list. It’s a plain text report of how many new bugs were filed for different component, linked with the RDO product from Bugzilla, with comparisons to the previous week. You can look out for RDO bug statistics email on every Wednesday on the RDO mailing list.

I am also involved in Python3 porting and including test requirements for RDO packages, which are still in progress. I learned how to help other package maintainers to improve their packages, which are consumed as a dependency in RDO.

In last three months, I worked with the CERN guys to package Magnum and Magnum client, where I learned how a new OpenStack service is packaged and imported in RDO.

Apart from that, I am contributing to the Delorean Project which powers the RDO CI and the RDO website during DOC and RDO test days. I’ve been also maintaining 4 RDO packages.

So, is contributing to RDO easy? Yes.

• Are you a newcomer (want to dive into OpenStack)?
  • First try and test it using RDO Project quick start guide and get your cloud running in 15 minutes.
  • Next, try out different scenarios and configure OpenStack services using RDO website documentation, look for anything wrong or enhancements that can be made in the documentation. RDO Project website source is on Github and requires Markdown, so feel free to create an issue and send a pull request.
• Participate in weekly RDO meeting every Wednesday on #rdo channel on Freenode. Take action items and participate in the conversation. It will help you to know what is happening in the community and what’s new coming.
• Check the RDO Bug stats each Wednesday and help them in getting it traised.
• Participate in RDO Docs day and Mitaka RDO test days.
• Help in answering OpenStack Questions on ask.openstack.org
• Learn RPM packaging and start reviewing new package review bugs and fix the spec of RDO Packaging.
• Know Python, contribute to Delorean and rdopkg which powers the RDO packages development.
• Look for issues in the OpenStack services and feel free to report the issue to the OpenStack upstream.

Lastly, contributing to RDO Project helps you to contribute to OpenStack upstream and also helps growing the RDO Community.

Thanks to apevec, number80, rbowen, jpena, dmsimard, EmilienM, mrunge, jruzicka and many more who helped me with fixing my silly mistakes and encouraging me to contribute more.

Because of its unique branding and name, one might assume that “RDO Manager” is not TripleO - perhaps it has additional downstream patches or maybe they’re entirely different projects. You would not be alone because the community, the users and the developers alike have shared their confusion on this topic.

The truth is “RDO Manager” really is “TripleO”. There is no code or documentation difference. The only thing that is different is the strategy around how the RDO community tests TripleO to ensure the stability of RDO packages but even this strategy is in the process of being sent upstream because we’re convinced it’s the best way forward.

Historically, RDO Manager and TripleO were different projects. Today this is no longer the case and we plan on keeping it that way.

Further, there is no other project in RDO that is renamed or rebranded. OpenStack Nova is referenced as Nova within the RDO project. Even the TripleO packages in RDO have the same naming as the upstream projects.

With this in mind, on Wednesday, 24th, February, 2016, the RDO community discussed and voted to drop the “RDO Manager” brand and use TripleO instead. This will clear the confusion surrounding the topic of what IS RDO Manager as well as strengthen the TripleO name. It is our hope that a clear 1:1 mapping between the projects will result in more integration with upstream on the CI side as well.

Over the course of the next few weeks, the RDO community will work towards replacing mentions of “RDO Manager” in documentation, web sites, code, and repositories. If you’d like to help with this, please join us on irc Freenode #rdo.