The RDO Community is pleased to announce a new release of openstack-utils.

Changes:

• Drop now out-of-date openstack-db utility
• openstack-status: autodetect MySQL variant
• openstack-status: check LBaaSv2 agent status

Packages are already in RDO repositories.

Download sources on github

Please report issues/RFE on openstack-utils issue tracker

Openstack-utils is a collection of utilities for OpenStack Services on RDO. It includes:

• openstack-config: manipulate safely openstack configuration files.
• openstack-status: check your OpenStack services status.
• openstack-service: control OpenStack services.

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

Who is Testing Your Cloud? by Maria Bracho

With test driven development, continuous integration/continuous deployment and devops practices now the norm, most organizations understand the importance of testing their applications.

… read more at http://tm3.org/7k

Clearing the Keystone Environment By Adam Young

If you spend a lot of time switching between different cloud, different users, or even different projects for the same user when working with openstack, you’ve come across the problem where one environment variable from an old sourceing pollutes the current environment. I’ve been hit by that enough times that I wrote a small script to clear the environment.

Read more at http://tm3.org/7l

Connecting from your local machine to the TripleO overcloud horizon dashboard by Carlos Comacho

The goal of this post is to show how to chain multiple ssh tunnels to browse into the horizon dashboard, deployed in a TripleO environment.

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

Improving the RDO Trunk infrastructure by Javier Pena

Quite often, projects tend to to outgrow their initial expectations, and in those cases we face issues as they grow. This has been the case with our RDO Trunk repositories and the DLRN tool that builds them.

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

TripleO manual deployment of ‘master’ branch by Carlos Comacho

This is a brief recipe about how to manually install TripleO in a remote 32GB RAM box.

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

Launching a Centos VM in Tripleo Overcloud by Adam Young

My Overcloud deploy does not have any VM images associates with it. I want to test launching a VM.

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

Red Hat Summit in Review by Rich Bowen

Despite my best intentions of blogging every day at Red Hat Summit, time got away from me, as it often does at these events. There’s always 3 things going on, and it’s hard to find a moment between that first cup of coffee, and stumbling into bed at the end of the night.

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

Openstack & TripleO deployment using Inlunch by Carlos Camacho

Today I’m going to speak about the first Openstack installer I used to deploy TripleO. Inlunch, as its name aims it should make you “Get an Instack environment prepared for you while you head out for lunch.”

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

Networking sessions in Red Hat Summit 2016 by Nir Yechiel

I recently attended the Red Hat Summit 2016 event that took place at San Francisco, CA, on June 27-30. Red Hat Summit is a great place to interact with customers, partners, and product leads, and learn about Red Hat and the company’s direction.

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

Merging FreeIPA and Tripleo Undercloud Apache installs by Adam Young

My Experiment yesterday left me with a broken IPA install. I aim to fix that.

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

Tokens without revocation by Adam Young

PKI tokens in Keystone suffered from many things, most essentially the trials due to the various forms of revocation. I never wanted revocation in the first place. What could we have done differently? It just (I mean moments ago) came to me.

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

Liveness by Adam Young

The term Liveness here refers to the need to ensure that the data used to make an authorization check is valid at the time of the check.

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

TripleO Deep dive sessions #1 (Quickstart deployment) by Carlos Camacho

This is the first video from a series of “Deep Dive” sessions related to TripleO deployments.

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

Quite often, projects tend to to outgrow their initial expectations, and in those cases we face issues as they grow. This has been the case with our RDO Trunk repositories and the DLRN tool that builds them.

I had my first contact with the tool a bit more than a year ago, when I took the task of migrating it from the virtual machine it was running on to a more powerful one. Fast-forward to the present, we have 5 RDO Trunk builders, and the RDO Trunk repos are used by the TripleO, Kolla, Puppet OpenStack and Packstack CIs (maybe more!). This means we need to provide a more performant and resilient infrastructure than we used to have.

Our main issues

Considering our growth, we were facing several issues:

• Performance was suffering due to the many workers building packages at once. To make things worse, the same system building packages was also serving them, so any CPU or disk contention would affect any consumers of the repository.

• While we had a high-availability mechanism in place, it was quite rudimentary, and it involved running lsyncd to synchronize all repo contents to a backup server. With the huge amount of small files present in the system, lsyncd only contributed to making things slower.

The solution

With the help from kbsingh and dmsimard, we came out with a new design for the RDO Trunk infrastucture:

• A server inside the ci.centos.org infrastructure is used to build packages. That server is not publicly accessible, so we need a way to make our repositories available.

• The CentOS CDN is used to distribute the repositories that successfully passed CI tests, using several directories in the CentOS Cloud SIG space. That gives us a fast, highly available way to make the repos available, specially for end-users and the RDO Test Days, when we need them to be 100% ready.

• In addition to that, we still need CI users and packagers to be able to access the individual repositories created by DLRN when a package is built. To accomplish this, another server is providing those via the well known https://trunk.rdoproject.org URL.

We needed a way to have the build server push each repo to the public-facing server, and the old lsyncd-based method was not working well for us. Thus, we had to patch DLRN to add this feature, which seems to be working quite well so far.

Future steps

This architecture still has some single points of failure: the build server can fail, and the same could happen to the public-facing server. In both cases, there are mitigation measures in place to minimize the impact (we can quickly rebuild the systems using our Puppet modules), but still, there is work ahead to do.

Do you want to help us do it?

The first day at Red Hat Summit in San Francisco was, as always, very busy, with hundreds of people coming by the Community Central area of the exhibit hall to learn about RDO, as wlel as other community projects including ManageIQ, Ceph, CentOS, and many others.

Due to the diverse nature of the audience, and their many reasons for attending Red Hat Summit, perhaps half of these attendees hadn’t heard of RDO, whild most of them were familiar with OpenStack. So, we have many new people who are going to look at RDO as a way of trying ot OpenStack at their organizations.

If you’re at Red Hat Summit, do stop by. We have lots of tshirts left, and we also have TripleO Qu ickStart USB thumb drives so that you can try out RDO with minimal work. We’re in Community Central, to your right as you enter the front doors of the Partner Pavillion.

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

Skydive plugin for devstack by Babu Shanmugam

Devstack is the most commonly used project for OpenStack development. Wouldn’t it be cool to have a supporting software which analyzes the network infrastructure and helps us troubleshoot and monitor the SDN solution that Devstack is deploying?

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

ANNOUNCE: libvirt switch to time based rules for updating version numbers by Daniel P. Berrangé

Until today, libvirt has used a 3 digit version number for monthly releases off the git master branch, and a 4 digit version number for maintenance releases off stable branches. Henceforth all releases will use 3 digits, and the next release will be 2.0.0, followed by 2.1.0, 2.2.0, etc, with stable releases incrementing the last digit (2.0.1, 2.0.2, etc) instead of appending yet another digit.

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

Community Central at Red Hat Summit by Rich Bowen

OpenStack swims in a larger ecosystem of community projects. At the upcoming Red Hat Summit in San Francisco, RDO will be sharing the Community Central section of the show floor with various of these projects.

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

Custom Overcloud Deploys by Adam Young

I’ve been using Tripleo Quickstart. I need custom deploys. Start with modifying the heat templates. I’m doing a mitaka deploy

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

Learning about the Overcloud Deploy Process by Adam Young

The process of deploying the overcloud goes through several technologies. Here’s what I’ve learned about tracing it.

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

The difference between auth_uri and auth_url in auth_token by Adam Young

Dramatis Personae:

Adam Young, Jamie Lennox: Keystone core.

Scene: #openstack-keystone chat room.

ayoung: I still don’t understand the difference between url and uri

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

Scaling Magnum and Kubernetes: 2 million requests per second by Ricardo Rocha

Two months ago, we described in this blog post how we deployed OpenStack Magnum in the CERN cloud. It is available as a pre-production service and we’re steadily moving towards full production mode.

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

Keystone Auth Entry Points by Adam Young

OpenStack libraries now use Authenication plugins from the keystoneauth1 library. One othe the plugins has disappered? Kerbersop. This used to be in the python-keystoneclient-kerberos package, but that is not shipped with Mitaka. What happened?

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

OpenStack Days Budapest, OpenStack Days Prague by Eliska Malikova

It was the 4th OSD in Budapest, but at a brand new place, which was absolutely brilliant. And by brilliant I mean - nice place to stay, great location, enough options around, very good sound, well working AC in rooms for talks and professional catering. I am not sure about number of attendees, but it was pretty big and crowded - so awesome!

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

OpenStack Day - Budapest, 6th June 2016

It was the 4th OSD in Budapest, but at a brand new place, which was absolutely brilliant. And by brilliant I mean - nice place to stay, great location, enough options around, very good sound, well working AC in rooms for talks and professional catering. I am not sure about number of attendees, but it was pretty big and crowded - so awesome! I really can say that it was awesome experience for me (please accept my apology for using word “awesome” too often here). I brought 2 banners - RDO + OpenStack, RDO stickers, TripleO stickers with the Owl, RDO/CentOS beermats, cheat-sheets, leaflets and few t-shirts. It was only RH booth at the beginning, but I changed it a bit into RDO by adding those promo stuff. It was distributed very well. The problem of this OSD is (and I was warned in advance by Ondrej Marek) that there are mostly Hungarian people, who are not very open to have some discussion or ask many questions. I was at a booth between talks anyway. Also I joined many talks, had a nice discussion with Marketing guys on the booth and meet also one RH Sales guy Miroslaw Pawlowski (from PL).

It was very nice, very well organised OSD. Lovely food, lovely place, great people, nice talks, it was a bit more quiet than on FOSDEM or Devconf.cz. But that is probably something related to the nationality, as Ondrej mentioned.

Hugh Brock from our team had a great TripleO talk, received some questions after a talk. It was very nice talk with cool jokes.

OpenStack Day - Prague, 8th June 2016

This event was 1st OpenStack Day in Prague. According to that I was really surprised how well organised and placed it was. For this event we were at DOX gallery, which is very modern, beautiful and quiet and also at a perfect distance from bus station. So we had a lot of space to go around, have a coffee, conversation or a good meal. At the entrance some OpenStack swag was distributed - OS sticker, super cool OpenStack glasses, some info leaflets and map of the area, also awesome bag saying “OpenStack Prague” which I now use for shopping and feel so cool now. Attendance was pretty large, we really filled that area with attendees. I meet there Zdenka Van Der Zwan and Ondrej Marek, that was just great to meet them in person. Also many people which I met in Budapest. I provided to Ondrej the info about OSD in Budapest and also we had a chance to discuss the swag, or what could I do to motivate people to attend a bit more, and also we agreed to be in touch to see in advance some more possibilities for future events.

I met also Jirka Kolář from TCP Cloud and also Aleš from Elostech and few other guys I know from local community. Ondrej confirmed that the community meetups are a bit silent, still but again - let’s see how it will go.

We had there a beautiful Red Hat booth, with fancy RH promo stuff - free to take. Also you could win a quadricopter (if you were not a RH employee of course) by filling up a survey. I brought some RDO things, to refresh the RH booth. I took RDO banner, OpenStack banner, RDO stickers, beermats (super successful), cheat-sheets, TripleO stickers. I have great muscles now :D thanks to carrying heavy backpack and two banners, lol.

Angus Thomas had a talk (the same that Hugh Brock had in Budapest OpenStack day) and we also had a chance to chat a bit and enjoy a lunch together. It was very nice. Hugh couldn’t attend this OSD due to Dublin management meeting. It is a shame that not many people from our team were present at this Day. I met some technical writers (Radek Bíba, and his colleague whose name I forgot), Angus, few guys from Marketing. There was no one from HR - Tyler Golden couldn’t attend. I met many familiar faces from Budapest there, but from our teams there was only me and Angus and Flavio Percoco, who traveled from Italy. I hope that next year there will be more attendance from our local team members.

For a next OSD in Praha, I will advertise it much better. My vision is to travel there as a team and maybe have some nice dinner together? Let’s see. But for a next time I would definitely ask people directly myself.

OpenStack swims in a larger ecosystem of community projects. At the upcoming Red Hat Summit in San Francisco, RDO will be sharing the Community Central section of the show floor with various of these projects.

We’ll have a series of presentations featuring various projects running througout the event, including OpenStack, oVirt, Ansible, Ceph, Gluster, CentOS, and more.

For the full schedule of community talks, see the Red Hat Summit schedule.

We hope to see you in San Francisco. If you haven’t registered yet, use the discount code UG2016 for a $500 discount on your registration.

Here’s what the RDO community has been blogging about recently:

TripleO partial stack updates by Steve Hardy

Recently I was asked if it’s possible to do a partial update of a TripleO overcloud - the answer is yes, so I thought I’d write a post showing how to do it. Much of what follows is basically an update on my old post on nested resource introspection (some interfaces have changed a bit since I wrote that), combined with an introduction to heat PATCH updates.

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

The bad practice in FOSS projects management by Julien Danjou

During the OpenStack summit a few weeks ago, I had the chance to talk to some people about my experience on running open source projects. It turns out that after hanging out in communities and contributing to many projects for years, I may be able to provide some hindsight and an external eye to many of those who are new to it.

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

In case you missed it, the June RDO newsletter is now available.

If you’re not receiving the RDO newsletter, you can subscribe by sending email to rdo-newsletter-subscribe@redhat.com. The newsletter is sent the first week of every month, and covers what’s been going on in the RDO community, and what’s happening in the coming weeks.

Here’s what RDO engineers have been blogging about over the last few weeks.

[Event Report] RDO Bug Triage Day on 18th and 19th May, 2016 by Chandan Kumar

As the RDO development continues to grow, the numbers of bugs also grow. To make the community robust and heavy, it is also necessary to triage and fix the existing bugs so that product will be more valuable.

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

How to fix a FTBFS using DLRN by Frederic Lepied

DLRN is the tool used by the RDO project to build RPM packages for every commit from the OpenStack projects. See http://blogs.rdoproject.org/7834/delorean-openstack-packages-from-the-future for more details on how DLRN works. These commits from the upstream OpenStack projects can introduce changes that break the packaging. We call these FTBFS (Failure To Build From Source).

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

Gnocchi talk at the Paris Monitoring Meetup #6 by Julien Danjou

Last week was the sixth edition of the Paris Monitoring Meetup, where I was invited as a speaker to present and talk about Gnocchi.

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

OVB: TripleO on a Public OpenStack by Gonéri Le Bouder

In order to deploy an OpenStack cloud with the TripleO installer ( http://tripleo.org/ ), one needs at least 2 nodes for a basic setup. If one is interested in deploying more complex topologies, more nodes might be required, for an Highly Available (HA) setup, 4 nodes are required.

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

Reviews for RDO packages by Adam Young

We are in the process of getting the docs straightened out for reviewing RDO packages. As we do, I want to record what I have working.

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

Newbie in RDO: one size doesn’t fit all by amoralej

As a new contributor to the RDO project, one of my first tasks was to understand what is actually being produced by the project. According to RDO faq, the main goal is to maintain a freely-available, community-supported distribution of OpenStack based on RPM packages able to run Red Hat Enterprise Linux, CentOS, Fedora, and their derivatives. But the RDO community is diverse and different use patterns have been found over the time with different requirements:

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

Newbie in RDO (2): RDO Trunk from a bird’s eye view by amoralej

Time goes fast as a RDO newbie and once I understood what the RDO Trunk and CloudSIG repos provide (read my previous post if you still have doubts), my next goal was to have a clear high-level perspective of the entire delivery workflow followed in the project.

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

Evolving the OpenStack HA Architecture by Andy Beekhof

In the current OpenStack HA architecture used by Red Hat, SuSE and others, Systemd is the entity in charge of starting and stopping most OpenStack services. Pacemaker exists as a layer on top, signalling when this should happen, but Systemd is the part making it happen.

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

RDO @ Red Hat Summit by Rich Bowen

Red Hat Summit is just a few weeks away, and it’s a great place to learn about RDO, and deploying OpenStack on Red Hat Enterprise Linux or CentOS. If you’re coming, be sure to drop by the RDO booth in the Community Central section of the exhibit hall. Grab an RDO tshirt, watch demos of what people are doing on top of RDO, and we’ll have experts there to answer your questions.

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

ARA: One month and 200 commits later by David Moreau Simard

On May 21st, I wrote a blog post about ARA, an idea to store, browse and troubleshoot Ansible playbook runs. Let’s rewind a bit further back in time.

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

SAML Federated Auth Plugin by Adam Young

SAML is usually thought of as a WebSSO mechanism, but it can be made to work for command line operations if you use the Extended Client Protocol (ECP). When we did the Rippowam demo last year, we were successful in getting an Unscoped token by using ECP, but that was not sufficient to perform operations on other services that need a scoped token.

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