Once again, OpenStack engineers met to design the Mitaka cycle. Here is a summary of the Security Project and relevant release mangement changes.

What is the OpenStack Security Project ?

Security issues, tooling, innovations and education within OpenStack are the responsibility of the Security Project. The Security Project undertakes technical and governance activities for the OpenStack community, aiming to provide guidance, information and code that enhances the OpenStack ecosystem’s security.

Bandit and Syntribos

The OSSP (OpenStack Security Project) discussed Bandit and Syntribos developpements.

• Bandit is a static analyser for python language whose purpose is to find trivial programing mistakes and to help enforce strong security guideline.
• Syntribos is an API testing framework that aims to facilitate fault injection tests through REST interfaces.

While Bandit is currently used as a gate job for Keystone, Syntribos is currently being developed and its usecases are still under constructions. Overall, roadmap’s goals are to get better reporting from the tools, more OpenStack projects on board and improved stability. Both etherpads used during design sessions are available here: Bandit worksession and Syntribos worksession

Governance Tag: vulnerability:managed

The vulnerability management team VMT introduced a new tag vulnerability:managed to help identify which projects are being supervised by the team. The incubation process for new projects is now described there and we are looking to have a few more project on board.

In order to help us scale for the big tent, a new downstream stakeholder mailing list will be created to ease advanced notification workflow (pre-OSSAs). This list would also be useful for projects that are not yet supported and to warn stakeholders about upcoming vulnerabilities.

Stable Release

Stable releases such as 2015.1.2 are now gone and will no longer be produced. Instead, projects will now be able to release new versions independly and security fixes should be tagged and released right after their merge. This is a great improvement for all upstream release users and stable release managers as the process is now streamlined.

Other improvements for release management are to be expected, such as automation of release notes with reno, a project explorer and a handy page of version numbers recap for the last release.

Once again, we have made great progress and I’m looking forward to further developments. Thank you all for the great OpenStack Mitaka Design Summit!

Tristan Cacqueray

OpenStack Vulnerability Management Team

What does RDO stand for?

The RDO FAQ has long said that RDO doesn’t stand for anything. This is a very unsatisfying answer to one of the most frequently asked questions about RDO. So, a little while ago, I started saying that RDO stands for “Rich’s Distribution of OpenStack.” Although tongue-in-cheek, this response emphasizes that RDO is a community driven project. So it’s also Radez’s Distribution of OpenStack, and Radhesh’s and Russel’s and red_trela’s. (As well as lots of people whose names don’t start with R!)

It also stands for “RPM Distribution of OpenStack.” And “Really Deploy OpenStack”, and “Rebuilt Daily OpenStack”, and a variety of other things.

So, that’s the thinking behind the tshirt that we’re giving out at our booth at OpenStack Summit here in Tokyo. We still have a few left, so drop by the Red Hat booth and get yours while they last.

Why ducks?

Well, as everyone knows, sometimes, the moment you ask a question out loud, the obvious answer occurs to you. And often, when explaining a problem to someone else, you understand it better yourself.

Red Hat has your back on this. We have ducks at our booth at OpenStack Summit in Tokyo this week. The benefits of using a rubber duck as part of your programming work flow are well documented.

So, come grab a duck, and learn more about RDO, in the OpenStack Marketplace at OpenStack Summit.

We are pleased to announce the general availability of the RDO build for OpenStack Liberty for CentOS Linux 7 x86_64, suitable for building private, public and hybrid clouds. OpenStack Liberty is the 12th release of the open source software collaboratively built by a large number of contributors around the OpenStack.org project space.

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 focus on delivering a great user experience for CentOS Linux users looking to build and maintain their own onpremise, public or hybrid clouds.

In addition to the comprehensive OpenStack services, libraries and clients, this release also provides Packstack, a simple installer for proof-of-concept installations, as small as a single all-in-one box and RDO Manager, an OpenStack deployment and management tool for production environments based on the OpenStack TripleO project.

QuickStart:

Ensure you have a fully updated CentOS Linux 7/x86_64 machine, and run :

sudo yum install centos-release-openstack-liberty
sudo yum install openstack-packstack
packstack --allinone

For a more detailed quickstart please refer to the RDO Project hosted guide.

For RDO Manager consult the RDO Manager page.

RDO project is closely tracking upstream OpenStack projects using the Delorean tool which is producing RPM packages from upstream development branches.

Since the previous OpenStack Kilo release, RDO is participating in the Cloud SIG and using CentOS provided infrastructure. Towards the end of developement cycle packages are imported into CentOS Cloud SIG buildsystem and get eventually published in Cloud SIG repositories.

Getting Help:

The RDO Project provides 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 website.

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.

To get involved in the OpenStack RPM packaging effort, see the “Get Involved” docs and the Cloud SIG docs Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter. And, if you’re going to be in Tokyo for the OpenStack Summit next week, join us on Wednesday at lunch for the RDO community meetup.

I’d like to thank all RDO developers and CentOS Project for their effort and support resulting in this release, especially

• dmsimard - for continuously improving RDO CI
• jpena - for keeping Delorean service up and running
• jruzicka - for the rdopkg auto-magic
• number80 - for countless reviews and packaging wisdom
• social - for puppet module mastery
• trown - for leading RDO Manager side of the show!

Special thanks to all the folks who helped with last minute testing in IRC #rdo channel !

Thanks,

Alan Pevec

Cloud SIG and RDO project member

We’ll be having an RDO community meetup during the upcoming OpenStack Summit in Tokyo. It will be during lunch time (12:45 - 14:00) in Sakura Lower Level S-1 and S-2.

As at previous Summits, we’ll be gathering to discuss progress during the last six months, and plans for the future. Please add discussion items to the agenda that you’d like for us to talk about.

A big thanks to everyone that participated in the RDO Test Day over the last 48 hours. Here’s a few statistics from the day.

29 people wrote 74 email messages to the rdo-list mailing list. (Of course, they weren’t all about the test day, but many of them were.)

42 participants sent a collective 1074 messages to the #rdo IRC channel on Freenode.net. (Likewise, not all about test day.)

We had 23 new issues opened in the ticketing system.

Some people have put their day’s experience in the etherpad and some have updated the Tested Scenarios page. If you didn’t put your notes anywhere, please do update one of those in the coming day or two, so that we don’t lose what we learned.

So, thanks to all of you. Particular thanks to trown for getting things rolling and herding the cats.

We plan to have a documentation and website hack day on October 15th. If you would like to participate, here’s what you need to do:

1) Get a working copy of the website by forking the Github repository

2) Look through the open issues list and pick something to work on.

3) Show up on #rdo on the Freenode IRC network on Thursday, ready to get started.

Here’s what RDO enthusiasts have been writing about over the past week.

If you’re writing about RDO, or about OpenStack on CentOS, Fedora or RHEL, and you’re not on my list, please let me know!

Scheduled! Scale or Fail: Containers on OpenStack with OpenShift 3 – #vBrownBag TechTalk at OpenStack Summit Tokyo by Diane Mueller

Come join us for lunch on Wednesday at noon in the Wakashiba room! We will also be live streaming (conference Internet willing). The session will be recorded and will be posted to our YouTube channel. The link below will turn into direct links to the videos.

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

What’s new in OpenStack Liberty: webinar recap by Steve Gordon and Sean Cohen

OpenStack “Liberty,” due for imminent release, represents the 12th release of the open source computing platform for public and private clouds. Recent OpenStack releases have focused on improving stability and enhancing the operator experience. This is still the case with Liberty, but there are still new features to consider.

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

Minimum Viable Cluster by Andrew Beekhof

In the past there was a clear distinction between high performance (HP) clustering and high availability (HA) clustering, however the lines have been bluring for some time. People have scaled HA clusters upwards and HP inspired clusters have been used to provide availability through redundancy.

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

Delorean: OpenStack packages from the future by Frederic Lepied

I have been doing some patches on Delorean lately so I thought it could be a good idea to describe it in this article as it is not a well known tool.

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

Scheduling and disabling Cells by Belmiro Moreira

In order to scale OpenStack Cloud Infrastructure at CERN, we were early to embrace an architecture that uses Cells. Cells is a Nova functionality that allows the partition a Cloud Infrastructure into smaller groups with independent control planes.

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

Running NTP in a Container Lars Kellogg-Stedman

Someone asked on IRC about running ntpd in a container on Atomic, so I’ve put together a small example. We’ll start with a very simple Dockerfile:

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

Multiple external networks with a single L3 agent testing on RDO Liberty per Lars Kellogg-Stedman by Boris Derzhavets

Following bellow is supposed to test in multi node environment Multiple external networks with a single L3 agent by Lars Kellogg-Stedman. However, current post contains an attempt to analyze and understand how traffic to/from external network flows through br-int when provider external networks has been involved

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

RDO Liberty (RC2) DVR Neutron workflow on CentOS 7.1 by Boris Derzhavets

Per http://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ovs-dvr.html
DVR is supposed to address following problems which has traditional 3 Node deployment schema:-

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

Here’s what RDO enthusiasts have been writing about over the past week.

If you’re writing about RDO, or about OpenStack on CentOS, Fedora or RHEL, and you’re not on my list, please let me know!

Migrating Cinder volumes between OpenStack environments using shared NFS storage by Lars Kellogg-Stedman

Many of the upgrade guides for OpenStack focus on in-place upgrades to your OpenStack environment. Some organizations may opt for a less risky (but more hardware intensive) option of setting up a parallel environment, and then migrating data into the new environment. In this article, we look at how to use Cinder backups with a shared NFS volume to facilitate the migration of Cinder volumes between two different OpenStack environments.

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

RDO Liberty (beta) DVR Deployment (Controller/Network)+Compute+Compute (ML2&OVS&VXLAN) on CentOS 7.1 by Boris Derzhavets

Would you experience VXLAN tunnels disappiaring issue like it happens on RDO Kilo add following lines to ml2_conf.ini on each Compute Node

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

So, you’re an ATC. Let me tell you something by Flavio Percoco

It’s that time of the cycle - ha! you saw this comming, didn’t you? -, in OpenStack, when we need to elect new members for the Technical Committee. In a previous post, I talked about what being a PTL means. I talked directly to candidates and I encouraged them to understand each and every point that I’ve made in that post. This time, though, I’d like to talk directly to ATCs for a couple of reasons. First one is that Thierry Carrez has a great post already where he explains what being a TC member means. Second one is that I think you, my dear ATC, are one of the most valuable member of this community and of the ones with most power throughout OpenStack.

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

RDO Kilo DVR Deployment (Controller/Network)+Compute+Compute (ML2&OVS&VXLAN) on CentOS 7.1 by Boris Derzhavets

RDO Kilo DVR Deployment (Controller/Network)+Compute+Compute (ML2&OVS&VXLAN) on CentOS 7.1

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

How would work changing “enable_isolated_metadata” from false to true && openstack-service restart neutron on the fly on RDO Liberty ? by Boris Derzhavets

Can meta-data co-exist in qrouter and qdhcp namespace at the same time so that LANs without Routers involved can access meta-data ?

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

Haikel Guemar talks about RPM packaging by Rich Bowen

This continues my series talking with OpenStack project PTLs (Project Technical Leads) about their projects, what’s new in Liberty, and what’s coming in future releases.

… read (and listen) at http://tm3.org/2w

This continues my series talking with OpenStack project PTLs (Project Technical Leads) about their projects, what’s new in Liberty, and what’s coming in future releases.

If the audio player below doesn’t work for you, you can listen to the interview HERE or see the transcript below.

R: I’m Rich Bowen, I’m the community liaison for the OpenStack project at Red Hat. I’m speaking with Haikel Guemar, who is the Project Technical Lead (PTL) on the RPM packaging project at OpenStack. Thanks for taking this time to speak with me.

H: Thank you, Rich. I appreciate it.

R: This is a fairly new project, in terms of actually being part of OpenStack - is that right?

H: Yeah, exactly. We’ve been an official project for a few months, and we’re still in bootstrapping. There has been some discussion at the last Summit to converge packaging project to work together, upstream. After some discussion we discussion, we decided to split between two separate projects, one around Debian packaging, and one around RPM packaging. So we’ve been working with people from RDO, SUSE, and also some people from Mirantis, to work together on RPM packaging upstream.

By the way, I’m co-PTL of the project. I’m co-leading the project with Dirk Mueller from SUSE. Hats off to Dirk, if you’re listening to us. We’re trying to bring packaging into the heart of the project, because OpenStack is fairly good at trying to develop its own software pipeline, and the only bit that was missing was packaging - the last missing bit between the project and the end-user.

So, we’ve been trying to do that, and also help the upstream project to understand what are our needs upstream, because we have very specific requirements that we want them to hear.

R: How do you picture this project changing the downstream projects like RDO and Fuel? Do you think there will be a big impact on those, or will they go on as though nothing’s changed?

H: I think there will be some impact, because if all the downstream packages are working on this, at some point we will be able to produce multiple packagings. There will still be some differences, but what we are working on - trying to mitigate them and trying to share most of our workers.

Speaking now with my RDO hat - I do hope that at some point, RDO will derive from our upstream RPM packaging. That’s what we want to do - be closer to upstream. That’s the point of RDO, not of the upstream project.

R: Looking forward to that time, what would then be the role of projects like RDO, and Fuel. Would they still be relevant, or do you see them going away long term.

H: Tough question. I think they will still be there, because at some point we will be targeting very different segments. For instance, RDO itself is the upstream for other downstream distributions of OpenStack. Like, obviously, the Red Hat one, or Cisco’s, or many others. I think that maybe RDO might disappear, maybe, but we still want to have some degree of integration. I hope that most of it will go upstream, because that’s where people are working, and we want to deal with before it reaches the users, not after we release.

R: In Liberty, and even more in future releases, with the integrated release kind of going away, and more reliance on tags, is the RPM packaging project going to package everything, or just a particular tag, or will that be up to the community.

H: That will be up to the community. The core upstream RPM packaging team will be working on core projects. We will be looking at Big Tent projects according to our own drive. But if people want to contribute any other Big Tent projects, they are welcome to do it. We are really looking forward to extending the comunity. We’re still a small team so we will be focusing on core OpenStack. Currently we’re working on clients because that’s what everyone needs to work with OpenStack, and when we’re done, then we’ll start working on services.

R: One of the things that RDO does is the CI effort within the CentOS infrastructure. And there’s obviously also a lot of that happening in the upstream OpenStack. Will the RPM packaging rely on the upstream for this?

H: We had some talks about it, and that was a funny discussion, because we discovered that our respective CI are more or less the same steps, and encounter the same issues. So we are willing to push more of the CI upstream.

I personally hope - but it’s not something that we agreed on - I hope that we will become part of the continuous delivery pipeline of OpenStack. That means that every commit from upstream would be packaged and then introduced into the CI, and then these patches would be usable for other CI, since we don’t have any concrete example, I will take one from RDO. We’ve been working with Puppet upstream CI recently, as they wanted to have come CI on CentOS, so we’ve been working on fixing staging issues that were affecting their CI so they could test properly Puppet upstream modules on CentOS. That was amazing because they helped us find many many issues that we were able to solve very early. And that’s what I hope for the upstream RPM project.

R: I noticed that they are no candidates for the PTL for the project in the coming election. Is that just because the project is so new, you’re not going to have turnover in that?

H: Yeah, that was the discussion just this afternoon about it. We’re still new, and we don’t want to confuse people with elections just now. We’re still building the community, and we’ve been working on that with Dirk. The project won’t be leaderless. It’s still difficult too, because we still have so much to do.

The main difference between the RPM packaging team and other teams is that we’re not solely dedicated to work on upstream tasks, like Cinder, Glance, or Nova. We have much more downstream-focused teams, so we wanted to stay focused. So we thought we would just keep the same PTLs for the next cycle. And then when we are more mature we will have candidacy.

R: As PTL … it’s been interesting talking with various projects, because the role of PTL can vary a great deal depending on the size and maturity of the project. I was wondering if you could tell us what your responsibilities are as PTL.

H: Our responsibility is ensuring that all the community team is aligned around the same goals. It means also trying to gather new members. For instance, being the PTL brings the attention on you, so people contact you so they can join the project. As we are still small, that was a critical path, and I have been trying to have them join the team, and make them active participants. I’ve been pretty happy that, for instance, Mirantis people reached out to me, and they’ve been able to join, and I appreciate that. One of the other things is to ensure that we are working together. I’m pretty happy that I am co-PTL with Dirk, because we can share the load. It is very tiring. We have to schedule meetings and gather people. Recently we had a hack day, to solve some of our impediments. We have to ensure that we have enough people, and we have the right people, to help. For instance, we have tooling issues, so I tried to get some people who would be likely to work on that aspect available for that day. I do not view the PTL as someone who decides everything. It’s more about being the coordinator.

R: Finally: if somebody does want to get involved in the project, where should they come? Is it to the mailing list, or IRC, or what?

H: We’re still using the openstack-devel mailing list with ‘RPM Packaging’ topics. We have an IRC channel on Freenode, which is #openstack-rpm-packaging. We have regular meetings every two weeks on Thursday. We sometimes have an additional meeting, at the same time. We keep logs of our agenda. And if you need anything else, just ping number80 or dirk on the channel, and we’d be happy to help you.

R: Thank you again for taking time to speak with me.

H: Thank you.