Continuing in the series about the RDO Meetup in Vancouver, in this recording we have Karsten Wade, of the CentOS project, talking about CentOS’s relationship with RDO, and with OpenStack in general. He talks about the CentOS build infrastructure, CI, package repos, and the CentOS Cloud SIG.
(If the player below doesn’t work for you, you can listen HERE.)
Last month at the RDO meetup in Vancouver, a number of topics were discussed. Jarda talked about RDO-Manager, the installation and management tool based on TripleO. Here’s just that part of the meeting.
If the embedded player below doesn’t work for you, you can listen HERE.
For additional information:
Well, I *planned* to go geocaching at OpenStack Summit, but it really didn’t work out. Almost every moment that I wasn’t working the expo hall, I was in my hotel room, in bed. Yes, I spent most of OpenStack Summit week sick, and didn’t get out of the hotel much.
However, I did get out to go Geocaching one morning on the way over to the convention center, and I found Canada Place Cache, my first cache in many moons, and my first cache in Canada.
I also looked for Barrel of Trees, which I didn’t find because the place was overrun with muggles and I never got a chance to go back.
What was really cool, though, was how many OpenStack enthusiasts approached me either at the event, or online, saying that they were also planning to go geocaching, and thanking me for making them think of it. I always like to find out the *other* hobbies of the people I know in the geek world. That is, their hobbies outside of the particular technical discipline we share. It makes people more human, and way more interesting.
So, stay tuned, and come geocaching with me at Red Hat Summit, and at OpenStack Summit in Tokyo.
Coming to the OpenStack Summit in Vancouver?
Like Geocaching?
It looks like there’s a lot of caches around the summit location. This map shows the 500 closest.
I keep meaning to spend a little time at conferences walking around the area and geocaching. Perhaps if I have a few folks with me I’ll see more of it, and meet some interesting people as well.
If you’re interested in Geocaching in Vancover, let me know, and we’ll try to set something up. I’ll be there from Sunday night (May 17th) through Thursday night (May 21st), and although I know it’s an incredibly busy week, I expect we can find an hour or two free in there somewhere.
I’ll also bring my new CryptoCard travel bug to drop off somewhere, since all of my other travel bugs have long since vanished.
I’m also hoping that by the time Red Hat Summit rolls around, I have some special Red Hat community project geocoins to accompany our geocaching outing. If this works out, I’ll try to make it a regular feature of my conference trips. So, here’s hoping.
Originally posted on opensource.com.
OpenStack is on a six-month release cycle, with each release given a code name starting with consecutive letters of the alphabet. On October 16th, OpenStack Juno will be released, with several new projects, and lots of new features.
Here’s a few of the things you can expect in the next release of
OpenStack. This isn’t intended to be comprehensive – just a taste of
some of the things that are coming.
Nova
As the core of OpenStack, Nova needs to be solid. But this doesn’t mean that it’s slow to change, with some significant changes coming in Juno.
* NFV
NFV – Network Function Virtualization – is a big deal lately, and you
can look to see lots of people working on it, as well as vendors talking about it.
* Live Upgrades
First introduced in Icehouse, live upgrades were still a little rocky.
You’ll see big improvements in this area in Juno.
* More
See more of what’s coming in Juno in Russell Bryant’s blog post at
http://blog.russellbryant.net/2014/07/07/juno-preview-for-openstack-compute-nova/
Ceilometer
Ceilometer is the metering/measurement component of OpenStack.
* Speed
Over the last few cycles, the Ceilometer team have identified some
poorly-designed parts of the project, and have taken a lot of time this cycle to pay down the technical debt to regain some of the performance lost to those decisions. So you can look for Ceilometer to be much more efficient, and faster, in Juno.
* Community reboot
The project management is moving from a top-down decision making process to a collaborative community decision making process, so that everyone has a voice in how decisions are being made.
Additionally, some controls are being put in place regarding the code freeze at the end of the cycle, so that people aren’t trying to rush new functionality in at the last minute, resulting in testing gaps.
* QA
Speaking of testing, there’s also an effort to ensure more Tempest and Grenade test coverage in Juno, which should ensure better code
reliability.
* More
See more of what’s coming in Juno in this interview with Eoghan Glynn of the Ceilometer community:
http://community.redhat.com/blog/2014/07/upstream-podcast-episode-10-rich-bowen-with-eoghan-glynn-on-openstack-juno/
Heat
Heat is the orchestration component of OpenStack, which can be used to set up and tear down infrastructure automatically in response to environmental events, or scripted.
* Rollback
In the past, if a Heat deploy failed, you just moved on, and maybe went back and cleaned up by hand. In Juno, it will be easier to roll back a failed deployment, and be sure that all of the various pieces have been cleaned up.
* Create resources without being admin
In Icehouse and earlier, certain types of resources could only be
created as admin. In Juno, creating users will still require that you be
admin, but you can then delegate privileges to that user so that they
can create resources without having to be admin.
* More
Read more about what’s coming in Juno for Heat at
http://www.zerobanana.com/archive/2014/07/10#heat-juno-update
Glance
Glance is “a service where users can upload and discover data assets
that are meant to be used with other services, like images for Nova
and templates for Heat.” This is a new mission statement in Juno, and some of the changes that are coming are:
* Artifacts
The scope is expanding in Juno to be more than just an image registry, to being a generic catalog of various data assets. This will allow for greater flexibility in how it can be used.
* More
Read more about what’s coming in Juno for Glance at
http://blog.flaper87.com/post/juno-preview-glance-marconi/
Marconi
Marconi (Now renamed to Zaqar) is OpenStack’s messaging and queuing system, and so is very important to all of the other components.
* Redis
In Juno, Zaqar will add a storage driver to support redis, and
support for storage engines is in the works. It will be possible to create and tag clusters of storage and then use them based on their capabilities.
* Queues migration
The Zaqar team will be adding support for queues migration between pools of the same type. Read more at
https://blueprints.launchpad.net/marconi/+spec/queue-migration
* More
Flavio’s article at
http://blog.flaper87.com/post/juno-preview-glance-marconi/ also covers Zaqar, as well as Glance.
Keystone
Keystone is the identity management piece of OpenStack, and has some big improvements coming in Juno.
* LDAP integration
Using Keystone against a database is ok, in that it does password
authentication. But what you really want is to integrate it with your
existing user authentication infrastructure. This often means LDAP. In Juno, you can configure Keystone to use multiple identity backends, and integration with LDAP will be much easier.
* Other security projects
The same community that works on Keystone is also very interested in other security related projects in the OpenStack ecosystem. Look for projects Barbican and Kite to be more active in the coming months.
* More
Nathan Kinder’s article at
http://redhatstackblog.redhat.com/2014/08/05/juno-updates-security/ covers more of what’s coming in Juno. See also this blog post: https://blog-nkinder.rhcloud.com/?p=130 for clarification of some of these goals.
TripleO
TripleO is a project about installing, upgrading, and operating
OpenStack clouds in an automated fashion. This is a big area of interest in Juno – making OpenStack easier to deploy and manage.
* High Availability
A big push in Juno is deploying HA clouds with TripleO. This will be the default behavior, which has the added benefit of getting everyone testing HA deployments, even on “clusters” as small as 1 node.
* Heat templates
TripleO uses Heat as part of the automation of deployment. So in Juno a lot of work has gone into the Heat templates that are used.
* More
Read more about what’s coming in Juno for TripleO in James Slagle’s blog post at http://blog-slagle.rhcloud.com/?p=235
Horizon
Horizon is the web admin interface for OpenStack. While many people will interact with OpenStack via the command line and APIs, the web interface is still the face of OpenStack for many OpenStack operators.
* Sahara (Hadoop)
Sahara is a new project that makes it easier to deploy Apache Hadoop or Apache Spark on OpenStack. This project has graduated, and so it’s now integrated into the dashboard, so you can deploy Hadoop clusters with a few mouse clicks.
* JavaScript unbundling
As good Open Source citizens, Horizon has moved to unbundling the
Javascript libraries that were previously copied into the Horizon source tree. This not only makes it easier to manage upgrades, but also complies with no-bundling requirements in certain Linux distros like
* More
See more about what the Horizon team is doing for Juno in Matthias
Runge’s blog post at http://www.matthias-runge.de/2014/09/08/horizon-juno-cycle-features/
See also
This is just a sampling of what’s coming in Juno. As well as reading all
of the excellent articles at https://openstack.redhat.com/Juno_previews
see also the YouTube playlist of PTL (Project Technical Lead) webinars.
And come to the OpenStack Summit in Paris to see what we’ll do for an encore in Kilo.
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
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.
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.
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.
A few weeks ago I was at the OpenStack Summit in Atlanta, Georgia, and I spoke with several Red Hat engineers about their work on OpenStack. Here’s a few of those conversations when I actually had the microphone running.
Listen to it HERE, or subscribe to my podcast to listen to it in your favorite podcast app.
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.
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.
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.