Tag Archives: openstack

The OpenStack Big Tent

I’ll be giving a presentation at LinuxCon next week about the ‘Big Tent’ at OpenStack. It’ll go something like this …

The OpenStack Big Tent

OpenStack is big and complicated. It’s composed of many moving parts, and it can be somewhat intimidating to figure out what all the bits do, what’s required, what’s optional, and how to put all the bits together.

The Problem

In the attempt to tame this confusion, the OpenStack Technical Committee defined what’s part of the Integrated Release and what’s not, so that you, the consumer, know what’s in and what’s out. One of the unintended side effects of this was that new projects were treated as second class citizens, and had trouble getting resources, developers, and a seat at the table at the developer summit.

As OpenStack continues to grow, this became more and more of a problem.

With the Liberty cycle, the Technical Committee has taken another look at what makes a project part of OpenStack, to make things better for the projects, as well as for the consumers.

Are You OpenStack?

The question that has been asked all along about any project wanting to be part of OpenStack was, is this thing OpenStack? To answer this question, a number of criteria were applied, including interoperability with existing bits, maturity, diversity (i.e., is this thing entirely developed by one company, or does it have broader participation?), and other things. This process was called Incubation, and once a project graduated from Incubation, it could be part of the integrated release.

As the stack grew, these questions became harder to answer, and more projects were getting left out of the tent, to everyone’s detriment, and to the growing confusion of the folks trying to use the software.

So, in recent months, the Technical Committee (TC) has decided to turn the question around. Rather than asking “Is thing thing OpenStack?” the new question is “Are You OpenStack?”

This changes how we look at making the determination on a few fronts.

OpenStack is People!

As Thierry Carrez Sean Dague said in their Summit presentation, OpenStack is composed of teams of people, working towards the betterment of the overall project. To that end, we’ll now welcome everyone to the table, if they are OpenStack.

So … how’s this defined?

Something is OpenStack if it:

1) Aligns with the OpenStack Mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.

2) Follows the OpenStack Way – Open Source, Open Community, Open Development, and Open Design. (More here)

3) Strives for interoperability with other things that are OpenStack.

4) Subjects itself to the governance of the Technical Committee

Tags

But while this solves one problem, it creates another. As a user of the OpenStack software, I really still need to know what’s in and what’s out.

There is no longer going to be a single release that is defined to be OpenStack, how do I know which bits I need, and which bits I can live without?

To help sort this out, a system of community-defined tags will be applied to the various pieces of OpenStack, starting with “tc-approved-release” which will, initially, just reflect what was already the integrated release. These tags will indicate project maturity, as well as other considerations. Packagers, like the CentOS Cloud Sig, can then use those tags to determine what they want to include in distributions.

Who’s In

As a result of this change, we immediately have several new projects that are part of OpenStack, that were previously held at arm’s length:

What’s Next?

People are still going to expect a release, and exactly what that means going forward is a little unclear. Every six months there will be a release which will include stuff tagged ‘tc-approved-release’. It will be opt-in – that is, projects can participate, or not, as they like. Or they can release on their own cadence, as was discussed about a year ago.

There are still some details to be worked out, but the overall benefit to the community seems like it’s going to be huge, as we include more great ideas, and more passionate people, inside the Big Tent.

Flavio Percoco, PTL of the Zaqar project

Zaqar (formerly called Marconi) is the messaging service in OpenStack. I recently had an opportunity to interview Flavio Percoco, who is the PTL (Project Technical Lead) of that project, about what’s new in Kilo, and what’s coming in Liberty.

The recording is here, and the transcript follows below.

 

FlavioPercoco

R: This is Rich Bowen. I am the RDO community liaison at Red Hat, and
I’m speaking with Flavio Percoco, who is the PTL of the Zaqar project.
We spoke two years ago about the project, and at that time it had a
different name. I was hoping you could tell us what has been happening
in the Kilo cycle, and what we can expect to see in Liberty.

F: Thanks, Rich, for having me here. Yes, we spoke two years ago, back
in Hong Kong, while the project was called Marconi. Many things have
happened in these last few years. We developed new APIs, we’ve added
new features to the project.

At that time, we had version 1 of the API, and we were still figuring
out what the project was supposed to be like, and what features we
wanted to support, and after that we released a version 1.1 of the
API, which was pretty much the same thing, but with a few changes, and
a few things that would make consuming Zaqar easier for the final
user.

Some other things changed. The community provided a lot of feedback to
the project team. We’ve attempted to graduate two times, and then the
Big Tent discussion happened, and we just fell into the category of
projects that would be a good part of the community – of the Big Tent
discussion. So we are now officially part of OpenStack. We’re part of
this Big Tent group.

We changed the API a little bit. The impression that the old API gave
was that it was a queueing service, whereas what we really wanted to
do was a messaging service. There is a fundamental difference between
the two. Our focus is to provide a messaging API for OpenStack that
would not just allow users to send messages from one point to another,
but it would also allow users to have notifications right away from
that API. So we’ll take advantage of the common storage that we’ll use
for both features, for different services living within the same
service. That’s a big thing, and something we probably didn’t talk
about back then.

The other thing is that in Kilo we dedicated a lot of time to work on
these versions of the API and making sure that all of the feedback
that we got from the community was taken care of and that we were
improving the API based on that feedback, and those long discussions
that we had on the mailing list.

In Liberty, we’ve dedicated time to integrating with other project, as
in, having other projects consume the API. So we’re very excited to
say that in Liberty a few patches have landed in Heat that rely on
Zaqar for having notifications, or to send messages, and communicate
with other parts of the Heat service. This is very exciting for us,
because we have some stories of production environments, but we didn’t
have stories of other projects consuming Zaqar, and this definitely
puts us in a better position to improve the service, and get more
feedback from the community.

In terms of features for the Liberty cycle, we’ve dedicated time to
improve the websocket transport which we started in Kilo, but didn’t
have enough time to complete there. This websocket transport will
allow for persistent connections to be made against the Zaqar service,
so you’ll just connect to the service once, and you’ll keep that
connection alive. This is ideal for several scenarios, and one of
those is connecting to Zaqar from a browser and having Javascript
communication directory to Zaqar, which is something we really want to
have.

Another interesting feature that we implemented in Liberty is called
pre-signed URLs, and what it does is something very similar – if folks
are familiar with Swift temp URLs –

http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

– this is something very similar to that. It generates a URL that
can expire. You will share that URL with people or services that don’t
have an username in Zaqar, so that they can connect to the service and
still send messages. This URL is limited to a single tenant and a
single queue, and it has privileges and policies attached to it so
that we can protect all the data that is going through the service.

I believe those are the two features that excite me the most from the
Liberty cycle. But what excites me the most about this cycle is that
we have other services using Zaqar, and that will allow us to improve
our service a lot.

R: Looking forward to the future, is there anything that you would
like to see in the M cycle? What is the next big thing for Zaqar?

F: In the M cycle, I still see us working on having more projects
consuming Zaqar. There’s several use cases that we’ve talked about
that are not being taken care of in the community. For instance,
talking to guest agents. We have several services that need to have an
agent running in the instances. We can talk about Trove, we can talk
about Sahara, and Murano. We are looking forward to address that use
case, which is what we built presigned URLs for. I’m not sure we’re
going to make it in Liberty, because we’re already on the last
milestone of the cycle, but we’ll still try to make it in Liberty. If
we can’t make it in Liberty, that’s definitely one of the topics we’ll
need to dedicate time to in the M cycle.

But as a higher level view, I
would really like to see a better story for Zaqar in terms of operations
support and deployment – make it very simple for people to go there
and say they want Zaqar, this is all I need, I have my Puppet
manifest, or Anisible playbooks, or whatever people are using now – we
want to address that area that we haven’t paid much attention to.
There is already some effort in the Puppet community to create
manifests for Zaqar, which is amazing. We want to complete that work,
we want to tell operations, hey, you don’t have to struggle to make that
happen, you don’t have to struggle to run Zaqar, this is all you need.

And the second thing that I would like to see Zaqar doing in the
future is to have a better opinion of what the storage it wants to
rely on is. So far we have support for two storages that are unicode
based and there’s a proposal to support a third storage, but in
reality what we would really like to do is have a more opinionated
Zaqar instance of storage, so that we can build a better API, make it
consistent, and make sure it is dependable, and provide specific
features that are supported and that it doesn’t matter what storage
you are using, it doesn’t matter how you deploy Zaqar, you’ll always
get the same API, which is something that right now it’s not true. If
you deploy Redis, for instance, you will not have support for FIFO
queues, which are optional right now in the service. You won’t be able
to have them because that’s something that’s related to the storage
itself. You don’t get the same guarantees that you’d get with other
storage. We want to have a single story that we can tell to users,
regardless of what storage they are using. This doesn’t mean that ops
cannot use their own storage. If you deploy Zaqar and you really want
to use a different storage, that’s fine, we’re not going to remove
plugability from the service. But in terms of support, I would like
Zaqar to be more opinionated.

R: Thanks so much for your time.

F: Thanks for putting this together.

 

RDO and CentOS

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.)

 

Geocaching at OpenStack Summit

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.

Geocaching in Vancover

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.

vancouver

 

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.

cryptoI’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.

 

 

What’s new in OpenStack Juno

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.

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.