Support: 1-800-961-4454
1-800-961-2888

Building Trust, Interoperability At OpenStack Summit

The OpenStack Summit is about relationships. As developers, we meet up twice a year at the Summit and then return home and resume communication via IRC and email. Spending time in person with other members of the community gives you the opportunity to form a bond and, more importantly, build trust – a community without trust can’t thrive.

Over the past few weeks, I’ve had time to reflect on OpenStack Summit Atlanta. Here, I’d like to share some of my thoughts.

One of the best things I’ve heard said about Rackspace Cloud Architect Troy Toman’s OpenStack Summit keynote was that he didn’t give a vendor or product pitch. Instead, he offered a rallying cry for the community; talked about how we can build a planet-scale cloud; and highlighted what needs to change about OpenStack to enable it. One of the key components of that is trust among vendors, developers and community members, especially as the number of OpenStack installs grows and the number of people who actively use OpenStack and are interested in keeping it up and running starts to outnumber the developers.

Like a puzzle, the pieces of OpenStack need to fit together more closely. While we once had very few large pieces, OpenStack is now a collection of much smaller pieces needed to form an even larger picture.  How can we better mediate the growth of projects and clouds?

Inside of OpenStack, there were several disparate discussions about the same thing: Eventing. How do the individual projects pass events between one another. Initially, it was just Nova passing events inside of itself. Then Ceilometer came along and gathered the Nova events for billing. Now Heat and Horizon and many more projects want events from each of the individual OpenStack projects… and users want this as well.

Orchestration continues to grow more important for OpenStack users. In March, Rackspace launched the Cloud Orchestration API: the first public installation of Heat, the OpenStack cloud orchestration platform. Heat allows you to upload a template for the software install you want to see instead of requiring that you create individual servers, volumes, networks and software installations as a long sequence of manual steps.

Any interested parties can submit tasks for discussions, but they need to be prepared to facilitate their session. Racker Randal Burt found himself facilitating many of the Heat sessions, joined by technologists from HP, Red Hat and eNovance.

We’re looking to build even more layers of software. Now that OpenStack is incubating Solum to deploy software installs at a higher level and Murano as a catalog of installable applications; how do they fit together? We had long discussions about how to avoid re-writing the same feature in different OpenStack projects and where the boundary lines should be drawn.

Furthermore, how does Heat need to change as people demand more from of it? Features that the OpenStack-on-OpenStack people require to roll out large hardware multi-hour deploys. Sometimes you realize that a hardware node has failed, which would require you to re-run a multi-hour deploy.  This is the same concern as what Rackspace Cloud customers need when they use Heat to not just deploy a configuration but to ensure that if the software you are deploying requires five database servers that you will always have five database servers, even after months of entropy that cause one of your database servers to crash.

Instead of the current model where Heat generates a workflow and the workflow either succeeds or fails, we’re moving towards a continuous convergence-based model. In this model, the Heat engine repeatedly examines what still needs to happen to continue to converge your install towards the desired state. It also provides the ability to replace a failed hardware node in the OpenStack-on-OpenStack model and enables you to adjust the size of your auto scaled group as demand changes without waiting for the previous operation to finish.

Troy talked about how we used to define OpenStack contributions solely in terms of code. As we grow, we need to value the contributions that enable code creation. Moving Heat to a convergence-based model is an effort across corporate and team boundaries. It requires the people involved to trust each other.

The most impactful product produced at the conference is not the bits of coding dashed off between parties, but the trust that something we have kind of discussed already as a possibility is actually something that we are ready to build – it’s a reality.

I’m excited to see what’s coming next for the world of increasingly intelligent OpenStack clouds.

About the Author

This is a post written and contributed by Ken Wronkiewicz.

Ken works to make the cloud better through new services and features. He’s worked on cloud monitoring as a service and is in the process of developing exciting new features for the Rackspace Open Cloud. He’s also “the bike guy,” responsible for making Rackspace’s San Francisco office an award-winning bicycle-friendly work place.


More
Racker Powered
©2014 Rackspace, US Inc.