Tag Archives: openstack

RDO on CentOS 7

With CentOS 7 now available, I quickly put it on my OpenStack demo laptop, and started installing RDO. It mostly just worked, but there were a few roadblocks to circumvent.

As usual, I followed the RDO Quickstart, so I won’t duplicate those steps here, in detail, but it goes like:


sudo yum update -y && sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm && sudo yum install -y openstack-packstack && packstack --allinone

Comparison of string with 7 failed

The first problem occurs pretty quickly, in prescript.pp, with the following error message:

Comparison of String with 7 failed

This is due to the change in CentOS versioning scheme – the latest release of CentOS is version 7.0.1406, which is not a number. The script in question assumes that the version number is a number, and does a numerical comparison:


if $::operatingsystem in $el_releases and $::operatingsystemrelease < 7 {
...

This fails, because $::operatingsystemrelease is a string, not a number.

The solution here is to edit the file /usr/lib/python2.7/site-packages/packstack/puppet/templates/prescript.pp and replace the variable $::operatingsystemrelease with $::operatingsystemmajrelease around line 15.

While you’re at it, do this for every file in that directory, where $operatingsystemrelease is compared to 7.

See https://bugzilla.redhat.com/show_bug.cgi?id=1117035 for more detail, and to track when this is fixed.

mysql vs mariadb

The second problem, I’m not sure I understand just yet. The symptom is that mysql.pp fails with


Error: Could not enable mysqld:

To skip to the end of the story, this appears to be related to the switch from mysql to mariadb about a year ago, finally catching up with CentOS. The related bug is at https://bugzilla.redhat.com/show_bug.cgi?id=981116

The workaround that I used was:

# rm /usr/lib/systemd/system/mysqld.service 
# cp /usr/lib/systemd/system/mariadb.service /usr/lib/systemd/system/mysqld.service
# systemctl stop mariadb
# pkill mysql
# rm -f /var/lib/mysql/mysql.sock

Then run packstack again with the generated answer file from the last time.

However, elsewhere in the thread, we were assured that this shouldn’t be necessary, so YMMV. See https://www.redhat.com/archives/rdo-list/2014-July/msg00055.html for further discussion.

That’s all, folks

After those two workarounds, packstack completed successfully, and I have a working allinone install.

Hope this was helpful to someone.

UPDATE: The next time through, I encountered https://ask.openstack.org/en/question/35705/attempt-of-rdo-aio-install-icehouse-on-centos-7/

The workaround is to replace contents of /etc/redhat-release with “Fedora release 20 (Heisenbug)” and rerun packstack.

Turns out that this also fixes the mysql/mariadb problem above without having to go through the more complicated process.

OpenStack User Survey (Juno Summit)

Last month at the OpenStack Summit in Atlanta, the highly-anticipated OpenStack user survey results were released. For reasons of respondent anonymity, the raw data of the survey will not be released, but rather just a summary of the numbers. Even with that, the new numbers are very interesting.

It should be noted that the results of any survey like this have to be understood in the light of the respondent sample set. People answering this survey are those who are somewhat engaged with the OpenStack Foundation, and (obviously) aware that there even is a survey. When software is available freely, like OpenStack, there is simply no effective way to contact everyone that’s using it, so we’re necessarily seeing only a small percentage of the total population, and have to hope that it’s a representative percentage. There’s also a lot of marketing of the survey in the various “camps” in the OpenStack ecosystem, trying to get people to fill out the survey. Here, too, we have to hope that this is roughly fairly distributed, and does not itself skew the results.

That said …

The results of the survey are here: http://www.slideshare.net/ryan-lane/openstack-atlanta-user-survey

As the RDO community guy, of course my initial interest was in the distribution of deployment OS platform, as well as the deployment tools.

Let’s start with OS.

*Note: Graph corrected – I had the wrong numbers in this earlier*

Note that since the survey combines paid and non-paid Ubuntu, it seems reasonable to combine CentOS and RHEL deployments. I’m sure that there won’t be universal agreement that that’s the right thing to do. So be it.

Compare these to the numbers six months ago:

We’re not comparing apples to apples here, but here’s a graph of all the combined deployments across the categories, in the 2014 survey:

Several interesting conclusions that I draw from these numbers. Although, again, we’re not comparing apples to apples, so I’m sure that other folks will interpret differently.

Overall, the Ubuntu to RHEL/CentOS split moved from 55/34 to 47/39, indicating, overall, a movement away from Ubuntu towards CentOS and RHEL as the preferred platform for OpenStack deployments.

More interesting, looking at the breakdown into poc/dev/prod categories, there’s an even stronger motion towards CentOS (and RHEL) as a preferred platform for *new* deployments. Looking at the versions deployed in production, it’s clear that once folks have something deployed, they leave it alone, with a pretty high number of people running versions that are as far back as Essex, Diablo, or even earlier.

On the deployment tool side, I think that the question could stand to be clarified. I wonder, of the people who indicate that they are using Puppet or Chef to do their deployment, whether they’re using another tool such as crowbar or packstack to run those tools, for example, or if they’re actually writing their own Puppet/Chef scripts. I would also have expected, just anecdotaly based on various conversations, to see devstack much further out in front. Perhaps I’m just talking to a rather unrepresentative group – which is, of course, why surveys like this are so useful.

Also of great interest to me is the distribution of industries. I need to do more work on comparing the numbers side-by-side, but the academic sector (the #2 industry) has grown against the previous survey, from 11 to 13%, and some other industries have also grown a little. The fact that IT is still far and away the largest consumer of this stuff seems to confirm everyone’s impression that we’re still very early days in this stuff, and the more we see it grow in non-IT industries, the more we’ll know that it’s here to stay. (It also seems likely to me that people outside of the IT sector are unaware that there’s even a survey to fill out.) So that’s something to keep watching in the next time around.

Ceilometer API, Net::OpenStack::Ceilometer

A couple of weeks ago, I agreed to give a talk at Infrastructure.Next about the Ceilometer component of OpenStack. Immediately afterwards, I regretted this, simply because I’m not exactly an expert on Ceilometer. But I’ve often said that the best way to learn something is to teach it, and what better way to learn about Ceilometer than prepare a presentation about it.

I also find that the folks with the in-depth technical knowledge of a subject might not be the right ones to give intro talks, because they tend to get into the weeds before their audience can get a big picture.

And so I started on a quest to understand Ceilometer, get some basic reporting working, and put together a howto style presentation on reporting with Ceilometer.

It turns out that several things worked very strongly in my favor:

* Ceilometer is installed and enabled by default when you install RDO. So there was no difficulty in getting it installed and configured.

* The documentation has lots of examples in it, and the API works exactly as documented.

* My presentation is only a half hour, rather than the hour that I initially thought it was, so I ended up having to trim the content, rather than come up with additional examples.

Along the way, I got tired of trying to issue HTTP API requests from the command line, and parse the response. Being a Perl guy, I started to write some perl code around this, and before I knew it, I had a full module to do all of the stuff that I wanted for my presentation.

It’s up on Github at https://github.com/rbowen/NetOpenStackCeilometer and I expect I’ll put it on CPAN eventually, once it stabilizes a little. In particular, the statistics() method lacks a lot of the capabilities of Ceilometer’s statistics functionality, and does only what I needed for my talk. Also the interface is kind of icky.

I should note that there are some other OpenStack modules already on CPAN, and this one takes a very different approach. This is the main reason I haven’t put this on CPAN yet. The other modules, by Naveed Massjouni, use Moose, and I have not yet used Moose for anything. I’m reluctant to put my stuff on CPAN while it uses such a different approach.

Patches welcome. I’d love to hear if you find this at all useful.

Come see me at Infrastructure.Next.

Copyright statements in source files

Earlier today I was looking at a source file for the Ceilometer docs and noticed that there’s a copyright statement at the top.

Now, in no way do I want to pick on Nicholas. There are hundreds of such copyright statements in the OpenStack docs and code, and this is just the example I happened to be looking at.

(Note that my employer has its share of copyright statements in the OpenStack code. Pretty much every company participating in OpenStack does this. I think we need to stop.)

I sent a note to the OpenStack-docs list, and it has generated a thread of remarks.

As I understand it, people are encouraged to put copyright statements in contributed source code and documentation, and add copyright lines to files that they modify.

I believe this to be a very bad thing to do, for the following reasons:

* If I edit a file and it says at the top that the file is copyright BigCo, I am discouraged from editing that file, because of the implication that I’m treading on someone else’s toes. Files should not have any indication that they are “owned” by any one person or company. (See this by Karl Fogel for more on “owning” code.) This actively discourages people jumping in and fixing stuff.

* If N people contribute to a file, are we supposed to have N copyright statements in the file? This doesn’t scale over time. Imagine what these files will look like 10 years from now, and fix the problem now.

* Having author names in a file encourages people to contribute for the wrong reasons.

* Git keeps track of who contributed what changes. It’s not necessary to have explicit copyright statements.

The first of those reasons is, to me, the most compelling. Anything that discourages contribution, particularly from beginners, should be eschewed as much as possible.

I have had people ask me, when encountering a copyright statement in source code, whether they have to ask that person’s permission before submitting a patch. If we can avoid even one person asking this question, we’ve done a service to the project.

I also worry that companies that insist on copyright statements in their contributions understand neither copyright law nor Open Source. On the one hand, the audit trail in Git protects your record of contribution, and thus your copyright. On the other hand, if your copyright is that important to you, perhaps you shouldn’t be contributing it to an Open Source project. It’s anti-community to say to a project that they can have your contribution, but only as long as you get to assert that it’s your personal property. Open Source is about community and collaboration. If the building is owned by the community, what do you gain by insisting that a particular brick is yours?

At the Apache Software Foundation, we had this debate a decade ago, and decided that author tags in source code were anti-community, and thus discouraged. To quote from the thread of comments at the time, and, in particular, to quote Sander Striker:

At the Apache Software foundation we discourage the use of author tags in source code. There are various reasons for this, apart from the legal ramifications. Collaborative development is about working on projects as a group and caring for the project as a group. Giving credit is good, and should be done, but in a way that does not allow for false attribution, even by implication. There is no clear line for when to add or remove an author tag. Do you add your name when you change a comment? When you put in a one-line fix? Do you remove other author tags when you refactor the code and it looks 95% different? What do you do about people who go about touching every file, changing just enough to make the virtual author tag quota, so that their name will be everywhere?

There are better ways to give credit, and our preference is to use those. From a technical standpoint author tags are unnecessary; if you wish to find out who wrote a particular piece of code, the version control system can be consulted to figure that out. Author tags also tend to get out of date. Do you really wish to be contacted in private about a piece of code you wrote five years ago and were glad to have forgotten?

This is a slightly different issue (author tags rather than copyright statements) but makes exactly the same point. Do I add a copyright statement when I correct grammar or spelling in a doc? How about when I add a paragraph or reorder sentences for greater clarity? At what point do I remove your copyright statement because I’ve changed so much of that file?

And then of course, you should consider the bigger question – why do you care? What are you trying to protect against? If you’re trying to protect against your contribution being taken by the community and used for other purposes, perhaps contributing to an Apache-licensed code base isn’t the smartest thing to do.

OpenStack Meetup, Cincinnati

Last night I attended the OpenStack meetup in Cincinnati. It was a lot longer drive than I anticipated, as it was on the north side of Cincy. But it was worth the drive. There were only five people there including myself, and although there was nothing formal planned in terms of a presentation, we had a great conversation around what we do in our various jobs with OpenStack, and I think we all learned something new about the OpenStack world in the process.

If you’re in the Cincy/Louisville/Lexington area, and you’re interested in future meetups, please let me know (rbowen at red hat dot com), so that we can get you included in those announcements. I’d really like to do something in Lexington, so that I don’t have to drive so far. ;-) So if you’re in Lexington and are interested in, or are using, OpenStack, please ping me and we’ll set something up.

Flavio Percoco on OpenStack Marconi

Last week at the OpenStack summit in Hong Kong I talked with Flavio Percoco about the Marconi project, which is incubating in OpenStack.

You can listen to this conversation HERE, or subscribe to my podcasts to listen to it in your favorite podcast app.

Transcript:

Last week at the OpenStack Summit in Hong Kong, I had an opportunity to speak with a number of Red Hat engineers who are working on OpenStack.

This is a conversation with Flavio Percoco, who is working on the Marconi project.

Rich: I’m speaking with Flavio Percoco, and he is working on the Marconi project. First of all, what is Marconi?

Flavio: Marconi is a queue and notification service for OpenStack. It’s basically a really nice API on top of existing technologies, so we’re not trying to reinvent the wheel there. We are just putting an API on top of existing brokers like RabbitMQ, Qpid, or AMQ, or whatever broker is there. Even databases can be used as messaging tools within Marconi.

Rich: One of the policies of OpenStack is that core components be really pluggale. So I assume that’s a goal of Marconi as well.

Flavio: Yeah. That’s definitely a goal of Marconi, and one of the things we want to make sure we are respecting is the fact that Marconi shouldn’t be invasive in your infrastructure. So if you want to deploy Marconi you can easily install it and build it like using Lego bricks. You can pick whatever transfer you want to use – either use http or tcp or zeromq or whatever you want to use, and you can also choose what backend you want to use. It could be RabbitMQ, QPID, or MongoDB, or some mysql database if you prefer, because maybe you already have that deployed in your infrastructure, so you want to keep your data how you already have it and still use that.

Rich: And what are you doing in particular on the Marconi project?

Flavio: I started contributing to Marconi since the very beginning. I co-PTL’ed the project with Kurt until now, and now that Marconi is Incubated in OpenStack, Kurt is the official PTL, but we’re still doing that work together. We split the PTL duties, and we lead the development of Marconi and the whole team – keeping the priorities straight and making sure we’re doing the right thing for the project.

Rich: What else are you excited about that’s coming up in OpenStack?

Flavio: Marconi is definitely something I’m really really excited about. Solum looks like a very good project. TripleO – TripleO is really amazing. I think the effort Red Hat is putting there is definitely worth it. It’s the way to go. I think those three projects are the most intrigueing ones for me right now.

There’s many new features in existing projects that maybe are worth highlighting for people. For example, Glance has put a lot of effort in being able to be deployed as a public service, so that’s something that might be useful for some use cases. Like if you wanted share usage, or for Red Hat itself, sharing RHEL ditributions, it would be cool to be able to share them using Glance, for example.

Oslo now also has messaging. Basically we pulled out the whole RPC code to its own repository, and we started doing that with many other libraries that were incubating in Oslo. Oslo is definitely paying out right now. The whole process of incubating libraries and improving the API, and making sure they are stable enough to have their own repositories, so that’s something that is definitely cool about the current state of OpenStack.

Rich: Thank you very much. Thanks for talking with me.

Flavio: Thank you very much.