• Business Value
• Case Studies
• Community Building
• Ecosystem
• Getting Started
• Legal
• Operations Summit
• Project Updates

This is always a great way to put presenters and attendees in the same room to maximize the value of the conference. However, there is unofficial track that I consider to be among the most important: the “Hallway Track.” Loosely defined, the Hallway Track encompasses all of the conversations that occur in the hallway or other social gathering points throughout the conference. It is here that you get to hear the dirty details of what a particular group really thought about a presentation or idea. It’s here that the tough questions get asked, and mostly answered; questions that would have probably been better if asked during the actual presentation. It’s a safer venue, a smaller one, that is filled with trusted opinions. Large takeaways from presentations are commonly disseminated during the Hallway Track and those are the ideas that attendees take back to their respective companies (and likely include in their conference reports).

Key Discussion Topics

I’m not going to dive into the details of every Hallway Track session I attended, but I want to share some of the overarching themes that were discussed during these sessions:

• Essex adopters are running OpenStack clouds with production workloads today. There were two keynote sessions that highlighted users who got their first real taste of OpenStack during the Essex Summit: Comcast and HubSpot.
• Most talked about session. State of the Stack April 2013 presented by Randy Bias from CloudScaling was the most talked about session in Portland. It was raved about. It was an update on all the projects, their best parts, their not so great parts and some general thoughts on the current state of all OpenStack projects.
• Interoperability, oh my! Analyst sessions, panels, blog posts and snarky comments abound all week. A lot of the OpenStack community contingent still believes OpenStack interoperability will occur, but there were some very strong opinions floating around about OpenStack just being too large, having too many deviations and there being too many factors to truly bring the whole community to an interoperability consensus. One thing both camps agreed upon was the great potential of interoperability. Personally, I think it’s too early to make a judgment call, but after seeing so many products start to converge towards a more common codebase, it might not be a pipe dream.
• Whiteboards in design session rooms. This seems to come up every conference, but if a room is designated for a design session, it should include a whiteboard. Sure, mostly there is debate and healthy conversation with an etherpad, but sometimes a discussion calls for a whiteboard for architecture or process flow.
• If you’re not using SCM, you’re doing it wrong. The age of logging into servers or virtual instances is seemingly coming to an end. More and more companies talked about advanced automation and the replacement of instances rather than nursing them back to health.
• Federated Auth in Keystone. This is one item that is near and dear to Rackspace, as we have proudly been running OpenStack Grizzly code in production for weeks. But since we switched our cloud platform over to OpenStack (on Aug. 1, 2012) there were some key features that we ran differently than the community due to our legacy cloud customers. The biggest hurdle to fully adopting native OpenStack is authentication, as Rackspace is not running the community variant of Keystone, but a Rackspace-ified version. With federated authentication getting closer to reality, it will allow Rackspace to adopt Keystone fully into our platform and move that much closer to running native OpenStack code.
• There was not a Piston or a Nebula party. Let’s be honest here; when the agenda came out and both of these companies were missing from the evening events lineup, there was quite a stir. These companies know how to put on a great party and roughly 3,000 attendees were let down. Luckily, there were still a slew of great evening networking events hosted by Mirantis, PuppetLabs, HP, Red Hat and Rackspace; but it just wasn’t the same without Piston or Nebula putting their respective party spins on the OpenStack Conference.
• nova-conductor:  One of the new services in OpenStack Nova, there was plenty of talk about what it does, why it’s needed and the best way to implement it. Yun Mao wrote a great post right before the Summit that answered a lot of those questions, and it was commonly referred to throughout the week. You can find his blog post on his personal website here:  http://cloudystuffhappens.blogspot.com/2013/04/understanding-nova-conductor-in.html
• OpenStack Operations Guide. A key element of Jim Curry’s keynote presentation was that 2013 is the “year of the user” for OpenStack. Over the past two years we have all been part of a transition that started with a strong focus on developers and now adds a heavy dose of OpenStack users. While the development of OpenStack has never been stronger – there were 500-plus contributors to the Grizzly release; OpenStack has also experienced a tremendous spike in growth and adoption. Another signal that users are here and ready to play is the release of OpenStack Operations Guide. There are more options than ever to get OpenStack running in your data center, and knowing all of the components of OpenStack and how they interact has never been more important. Once you have a grasp of OpenStack, the next question that is “what is the best deployment model for me?” OpenStack Operations Guide answers that question. The book is absolutely free and can be found here. Even cooler, this entire guide was written in a five-day sprint before the conference.

OpenStack Products Abound

There was also a great deal of product talk at OpenStack Summit Portland, with many OpenStack players offering up new solutions. Check out NetworkWorld’s roundup of the hottest OpenStack products right now. Here’s a sampling of some of the products launched and discussed at the Summit:

• Rackspace announced the Rackspace Global Cloud Network: Rackspace revealed plans to expand its global cloud network through a program in which Rackspace will build and run interoperable public clouds for service providers around the world.
• RedHat announced RDO: RDO is a community-supported distribution of OpenStack that runs on Red Hat Enterprise Linux, Fedora and their derivatives. Red Hat hopes to do for OpenStack what it did with Linux.
• Project Savanna: Red Hat, Hortonworks and Mirantis will collaborate to contribute significantly to Project Savanna, Apache Hadoop on OpenStack for simpler and cost-effective transitions of big data workloads between public and private clouds.
• Nebula released Nebula One: Nebula finally came out of the darkness and released its long awaited product, Nebula One, a turnkey private cloud system that provides compute, network and storage services through a self-service interface and APIs, using industry-standard servers from vendors such as HP, IBM and Dell.
• CloudScaling announced Open Cloud System 2.5: CloudScaling launched Open Cloud System 2.5, which supports OpenStack Grizzly; 100 percent community OpenStack – no forks; virtual private cloud via Juniper Contrail technology with block storage snapshots; and runs on certified hardware from Dell, Cisco, Quanta, Juniper and Arista
• Mirantis FUEL: FUEL is the public open source release of Mirantis’ toolset for production deployments of OpenStack. It has been used in projects completed at NASA, PayPal, WebEx and others.
• Ceph is hot, Swift is not: A full replacement alternative for Swift, Ceph is an open source, distributed storage system that provides block and object storage fully integrated with OpenStack. You can find more information about Ceph on the Inktank blog about Ceph’s Cinder compatibility. That being said, SwiftStack put on another series of fantastic workshops that gave newcomers and grizzled veterans of the technology some hands-on time and theory around using Swift in production.

Overall, OpenStack Summit Portland was an excellent five-day look at the state of the project from nearly every perspective. Roughly 3,000 people showed up to shape, drive and learn more about OpenStack, and the energy and enthusiasm in the sessions, and the Hallway Track were infectious. One thing is for certain, OpenStack is here to stay. I can’t wait to do it all again in six months.

Parallel is a term straight from the high school nightmare: geometry class. Classically, it means two lines that are always equidistant to one another and therefore never cross. When applied to computing, these lines are usually metaphors for processes or computation work being done. Parallel computing takes advantage of every trick in the book to get more work done in less time. Fred Brooks (of The Mythical Man-Month fame) may and should disagree, but throwing more people at a manufacturing problem will obviously decrease the time it takes to assemble the final product, right?

Applications, especially web applications, have been built with synchronization baked in. This means that every action that is requested of the web application is lock stepped through the entire process. For example, when submitting a request to share text on a pastebin service, the web front-end taking pasted text needs to get a response from the database, the text parser and the URL shortener. Each one of these seemingly non-overlapping processes needs to converge before we, as the users of this service, get a response.

If it feels like this design goes against some of the other pillars we’ve already discussed (i.e. modular, agile); excellent! By using the other pillars, we’ve started to achieve parallelization already. By moving work into non-overlapping sections we can do more work at the same time rather than having some work wait for other work.

Let’s quickly visualize a more accessible example. Bucket brigades are used to move large amounts of sand bags to create dikes in the event of a flood. The process works quite effectively because every other person usually has a bag at the same time. Thus the number of bags being transferred at any given time is at least half the number of people in the bucket brigade. If we only allowed one sandbag through the brigade at a time, the process would obviously be much slower (have lower throughput) but be more indicative of an application designed with synchronization. This is also an excellent example of horizontal scaling to go with the modular design we desired in the previous example.

Achieving parallelism in an application has been studied for decades and is still being advanced all the time. Parallel computing requires communication of data between compute processes. Several communication patterns exist, but common ones used in cloud applications are one-to-one, one-to-any and one-to-all, all of which can easily be implemented using message queues (i.e. RabbitMQ, IronMQ, &c).

Parallelism buys us an incredible boon and creates the ability to service even more requests or more computation in less time. That’s why we saved it for last.

This concludes our tour through the five essential pillars of cloudiness; guidelines for designing applications for the cloud. It’s been a fun ride. Be sure to check out the other pillars and head over to the Rackspace DevOps Blog for deeper technical dives into each one. Now get out there and start building great apps on the cloud.

Alex Brandt, a Technical Trainer with Rackspace University, contributed to this article.

Here’s a recap:

The Pillars Of Cloudiness:

• Pillars Of Cloudiness: No. 5 – Security
• Pillars Of Cloudiness: No. 4 – Agility Returns
• Pillars Of Cloudiness: No. 3 – Scaling Horizontally
• Pillars Of Cloudiness: No. 2 – Modular Design

Technical Deep Dives:

• Security On The Open Cloud
• Agility In The Rackspace Open Cloud
• Scaling Horizontally: Handling Sessions On The Open Cloud
• Modular Application Design With Services

Systems have been growing in complexity since we started creating them. Best practices have dictated that we separate logic and break things down into smaller, simpler parts to re-build them back into massive dynamic data movers. All of these connected pieces can lead to a domino style cascade if a component fails. By using a modular design that’s loosely coupled we can mitigate these issues.

Traditional applications are tightly bound together. Web services communicate with databases directly with no decentralized communication. Every request made to the web server has to wait for the database to return information before the web server can respond to the user who made the original request.

This tight coupling leads to the aforementioned domino effect. Of course, when a failure occurs in such a system, it’s usually easy to troubleshoot and fix as the lack of response from downstream indicates where the problem is likely located. But this can be misleading at times depending on how tightly coupled the application really is.

Breaking applications apart into modular pieces alleviates the problem of catastrophic failure from a chain reaction failure of systems but also can make pinpointing the location of the failure more difficult. The benefit of modularizing and decoupling applications is an increased ability to scale horizontally, as we discussed last time.  Another benefit is the improved user experience we provide.

Needing to handle large numbers of asynchronous events, modern operating systems accomplish the speedy response we’ve all come to expect by handling as little as possible up-front. This separation is known as top-half and bottom-half processing and allows the system to quickly handle the next response if it can only handle one at a time (imagine what can be done if it can handle multiple events) as well as push the heavy lifting, the bulk of the processing, into the background where it can execute at its leisure.

With more modularity, there is more choice in where scaling of the system can occur. In classic applications, we have load-balanced web servers in front of a highly available database system. The database system is probably very hard to scale and the web servers very easy to scale (relatively speaking), but when we have more tiers, due to further modularization, we have more choice. We can scale the message queue, the NoSQL data store, etc.

The other advantage from cloud computing is the dynamic infrastructure that can keep up with fluctuations in the application and can be automated just as easily. This dynamic nature could be leveraged to create an auto-scaling solution that remains efficient with respect to compute usage, load handling and cost due to services utilized. Dynamic modular applications are the product and catalysts of agility.

As we begin developing applications for the cloud, we need to be sure we design these applications in a modular fashion. This lack of interdependency not only makes scaling and processing simpler but also makes the application pieces easier to maintain, which moves us towards the agility we discussed in with pillar of cloudiness four.

Tune in next week when we talk about the first pillar of cloudiness: parallel computing. Need more information about developing on the cloud? Be sure to check out our Rackspace Cloud API documentation and the Rackspace DevOps blog.

Alex Brandt, a Technical Trainer with Rackspace University, contributed to this article.

Applications have tracked user state for years. Entire technologies have come and gone to increase the consistency of sessions between parallel web servers. With state saved in sessions we can have a consistent user experience between several web server machines. Typically this is used in online shopping carts.

In most shopping cart applications, when a user adds an item to their cart and continues browsing the site, a session is created and stored somewhere (e.g. memcached, database, etc.). When looking to scale horizontally, a central storage location is typically used for sessions so all of the web servers have access to the same session information. Now we have several systems hitting a single system for information (not unlike data in databases) and adding more web servers is going to increase the session store’s system load. This centralized approach doesn’t scale as effectively as newer solutions. Cloud and stateless protocols have started changing the way we design applications to increase the effectiveness of horizontally scaling.

Representational State Transfer (REST) to the rescue! REST by definition is stateless. Without state we don’t have any session data to consider or store. Thus, using REST sessions become a non-issue. Technologies like AJAX and HTML5 work with REST to remove the necessity of sessions from applications. Without sessions to require centralization in our application we have a bit more flexibility and can be agile with our scaling methodology. This allows us to scale horizontally without the growth of system load we noticed earlier in our session store.

Not everything can be converted to behave correctly without state. The portions that still have state requirements typically need to provide immediate feedback about the actions that are taken and provide contextual information across multiple requests.

Stateless applications have less coupling among their components and allow horizontal scaling points to work independently of one another and scale independently of one another. With this added elasticity in the application we can increase our return on agility we discussed in the last article.

Tune in next week when we talk about the second pillar of cloudiness: modular design. Need more information about developing on the cloud? Be sure to check out our Rackspace Cloud API documentation and the Rackspace DevOps blog.

Alex Brandt, a Technical Trainer with Rackspace University, contributed to this article.

The cloud is constantly changing and if infrastructure can’t roll with the punches, applications and services aren’t going to survive long. Cloud is about being agile and letting applications float like a butterfly and deliver service like a bee.

Before the advent of the cloud, return on investment was the key decider in infrastructure planning. With the dynamic that the cloud brings to computing resources, the new deciding factor is return on agility.

Return on agility is the value provided by automatically and dynamically responding to the trends in consumption of a service. Return on agility is measured indirectly as dollars per request but more directly with time – time for innovation and further efficiency gains.

Here we’re concerned with how to be agile and the benefits that it provides, which allows us to determine what the particular return on agility for our systems might be.

Quickly reacting to events with infrastructure allows the whole system to be more flexible and handle spikes with finesse. Consumers of a service receive the best experience when the resources are pre-allocated, but in the world of reddit, where a traffic spike can hit at any moment, predicting provisioning targets is simply out of the question. Thus, the best solution is not worrying about up-front provisioning but to instead setup monitoring that notifies the services to scale out when a user experience threshold may be met in the near future — meaning within 15 to 30 minutes.

A reactionary approach to infrastructure planning closes the gap between resource provisioning and resource consumption. This reduces the gap between consumption and provisioning allowing for less time with reduced user experience and less time wasting computing resources. This reactionary provisioning also brings the amount spent into correlation with the consumption of the application.

The last way to be agile is knowing the weapons (products) and environment the application has to work with, allowing the application to fight whatever battles it will face. Using products made available by the provider and others boosts agility by increasing the time available for other tasks.

The following are tips to help keep current on the available cloud products:

• Read all of the high-level documentation about every cloud product in the provider’s portfolio; something might stick out that allows the infrastructure to require less management
• Read the technical documentation of any service your application might consume; this includes API documentation, FAQs and best practices – many others have struggled to overcome obstacles to complete their goals; learn from their mistakes and lessons learned by reading as much as possible
• Ask questions about the best way to configure services. Every application requires a little dirty work to best consume a service – a call or chat with your Fanatical Support team can do wonders and assist with building one of the world’s most complex and interesting applications

Now that we know a few ways to begin achieving the agility we desire, let’s talk about why we would be interested in achieving a higher level of agility.

We’ve alluded to the monetary benefit of agility already with the amount of time gained due to these practices, but there is also the innovation. The last benefit is the transformation of the application from an expense to a revenue generator.

The old adage states that time is money and IT is not an exception by a long shot. We constantly hear the plea for more time for projects so they can have higher quality, be easier to maintain and remain useful for a long time.

Through continuous integration, delivery and deployment, infrastructure as an operational cost becomes very streamlined. Also, the time for development shrinks as the application becomes more maintainable and deployable, which allows non-linear project planning and progress agility.

By leveraging agility with proper quality constraints, application development cycles can become shorter while providing just as many, if not more, bug fixes and features. The non-linear project motion allows innovation to head in the direction of creativity for the application.

Being able to let creativity run rampant while having confidence in application deployment lets the business channel the creativity into new revenue and allows new items or services to grow the customer base.

Thus, agility is key not only to business but also to IT, development and providing services or applications on a technology infrastructure.

Tune in next week when we talk about the third pillar of cloudiness: scaling horizontally. Need more information about developing on the cloud? Be sure to check out our Rackspace Cloud API documentation and the Rackspace DevOps blog.

Alex Brandt, a Technical Trainer with Rackspace University, contributed to this article.

One of the biggest misconceptions about cloud computing today is the perception that it’s insecure. The reality is that the risks traditional applications face are the same as those found in the cloud. The cloud, does, however, change the security conversation and security becomes, in part, the responsibility of both the application builder and the cloud hosting provider.

There are three common scenarios that describe cloud hosting: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). Each of these scenarios places the responsibility for its security in both the cloud hosting provider’s hands as well as yours.  As you move from IaaS to SaaS, your responsibility for security decreases.

For a deeper dive into security on the open cloud, check out the DevOps Blog.

IaaS is the foundational building block of the cloud. In an IaaS environment, the cloud-hosting provider supplies raw compute power. This puts the onus on you, the consumer, to implement the correct security protocols. When building on IaaS environments, one of the most commonly overlooked issues is system patching. As a new server is booted, it is likely already out of date when it comes to software patches. These images were built and exposed months, sometimes years, before being built into servers.

This is where software configuration management (SCM) tools such as Chef and Puppet can save the day. These tools help bring systems up to date on patches, and can also be configured to lay down configuration files you have hand-built to suit your applications needs.

PaaS adds to IaaS and provides the next building block of the cloud.  IaaS lays down an environment in which an application can be developed and housed.  PaaS doesn’t just provide raw compute but also libraries and frameworks for the environment it supports.  This lowers the liability and responsibility assumed by the consumer.

SaaS is considered the top level of cloud applications. A full application has been built, security has been baked in at every level and you now have the least amount of responsibility in ensuring application security. You are not relieved of all security management, this is just traditionally where the least amount of management has to occur, and that is enticing to many businesses.

A good rule of thumb is that the further down the stack a cloud offering is, the more responsible you are as a user for tactically implementing and managing security. Ultimately, security in the cloud is a shared responsibility between you and your cloud hosting provider. It is key to understand what each side provides in terms of security, as well as the legal and contractual aspects.

For a more detailed technical look at security, check out Racker Hart Hoover’s post on the DevOps Blog. Tune in next week when Wayne talks about the second pillar of cloudiness: being agile through product knowledge. Need more information about developing on the cloud? Be sure to check out our Rackspace Cloud API documentation and the Rackspace DevOps blog.

The OpenStack Conference on Thursday and Friday had its highlights as well, starting with the General Session that included marquee keynotes from speakers such as Nebula CEO Chris C. Kemp, HP Cloud Services Senior Vice President and General Manager Zorawar “Biri” Singh, Ubuntu Founder Mark Shuttleworth, Rackspace CTO John Engates and Rackspace Vice President of Product Mark Interrante.

Video recordings were made of all the keynote sessions, but they have not yet been posted. Once available, you will be able to find them at www.openstack.org. For review, I’ve added a synopsis and links to the session descriptions:

• Emergence of the OpenStack Ecosystem
     • Kemp of Nebula, Inc. provided an overview of the emergence, dynamics and structure of the OpenStack Ecosystem and how it will reshape the $3 trillion global IT industry.

• Ushering in the Open API Economy through HP Cloud Services and OpenStack
     • In this session HP’s Singh shared the company’s full vision behind HP Cloud Services, the advantages of designing the service with OpenStack technology at the core and shared how the company’s differentiated hybrid delivery model is ensuring development interoperability and workload portability.

• From Blue Skies to Big Deployments
     • Shuttleworth brought the perspective of lessons learned in Ubuntu, which is itself shifting gears from being a popular prototyping platform to being adopted as core infrastructure in large scale deployments.
     • At the end of his presentation,  Shuttleworth announced that Canonical will support OpenStack release back-porting into all long-term-support Ubuntu releases with Ubuntu 12.04 Precise Pangolin. For more information, please see the Canonical release statement for Precise Pangolin.

• OpenStack – The Revolution is Real
     • Rackspace’s Engates and Interrante, Vice President showcased the realities of OpenStack-based products and what they means for Rackspace and the industry.
     • The session featured a demo of next generation cloud from Rackspace which showcased Nova Compute scale, Cloud Networks, Cloud Block Storage and the new Rackspace Cloud Control Panel.

There was a great amount of OpenStack user stories that were also discussed at the Conference. I encourage you to check them all out as they are really pushing the boundaries of cloud computing and coming up with revolutionary ways to change the technology landscape. Customer stories included:

• Deutsche Telecom
• Radio Free Asia
• San Diego Supercomputer Center
• Enabling the X.commerce Cloud
• Argonne National Laboratory Magellan

And last but not least there were all of the “State of Project” sessions that covered OpenStack Core projects. Video recordings of these sessions will also be posted as soon as they are available. The videos will highlight:

• Swift - Object Storage
• Keystone - Identity
• Nova - Compute
• Horizon - Dashboard

There were great presentations and it was clear the momentum for OpenStack is still going strong. This year definitely showed that OpenStack is a maturing project and community, and the new technologies, companies and business strategies based on OpenStack are concrete proof that OpenStack is here to stay.

For a full listing of all Conference sessions, please see the following link.

I expected some good things to come out of the OpenStack Folsom Design Summit & Conference, but what I got was a TON of good things instead. There was clearly a different feel to this conference: the quality of the discussions was heightened; discussion of operations and community were highlighted; and security and high-availability had a laser focus. The past Summits have been focused on what OpenStack should look like and how to make it real, which was exactly what it needed at the time. This Summit was about putting all that effort into production and turning on the OpenStack engine for the world to see. All of this was augmented by more than 1,000 participants from 26 countries; 159 sessions during the Summit and 56 sessions during the conference; and more than 40 hours of intense discussions. This of course didn’t go without some quality relaxing and networking in the evenings — work hard play hard, the OpenStack community abides.

From the community perspective, Stefano Maffulli and Anne Gentle are truly OpenStack rock stars. Getting a community that has grown so rapidly to converge and work towards common goals while working towards the elimination of work duplication is no small task! In an effort to keep up the pace, there was a “Documentation Track” and also an “Ecosystem Track” at this year’s conference. A couple of community sessions that I attended included the “Folsom Doc’s Planning,” “Community Communication,” and “API Extensions.” Here are some highlights:

• Folsom Documentation Planning
     • At the Essex Design Summit, API documentation got the spotlight and over the past six months there has been the addition of api.openstack.org and countless docs which help developers write OSAPI targeting applications. This session discussed the needs for the next OpenStack release, Folsom, and how to contribute to the different documentation projects.

• Community Communication
     • There were a lot of talks about how to bring all the OpenStack contributors of the world together to continue and improve the process of making OpenStack great. Mailing lists, IRC (Internet Relay Chat), Forums and other communications mediums were discussed as ways to  improve and how to maximize reach.

• API Extensions
     • API extensions are a standard way to extend the functionality of APIs and expose them to users. This discussion was about creating and supporting an extension mechanism that would be simpler and easier to use.

You might have heard about both the “OpenStack Design Summit” and “OpenStack Conference.” These are in fact two different events that are placed back to back to increase attendance and cater to all OpenStack audiences. The Design Summit is typically the first three days of the week, Monday through Wednesday, and is more focused on design, architecture, code and the intricacies of OpenStack from a technical level. The Conference typically follows on Thursday and Friday and is more focused on the business and customer stories and use cases of OpenStack.

The Design Summit to me had a very production ready feel to it. Many of the talks were based on how to deploy, optimize and secure OpenStack. With 159 sessions total during the Summit, it’s really hard to pick just a few, so I’ll group topic areas together which should give an overall feel:

Security

• Nova Security In Folsom
     • This session discussed security architectural improvements that could be pushed during the Folsom timeframe. This includes discussion of encrypted internal communication and further improvements to make the rootwrap less permissive.

• Role Based Access Control
     • Starting with an overview of what is now available with the Policy mechanism; this topic discussed initial and early API access to allow application of Policy against existing services.

• Trust Delegation & Cloud Federation
     • This crosses on a number of topics; the intent is to allow for multiple instances of Keystone and/or multiple instances of service endpoints, sharing and/or delegating trust to relevant systems.

Deployability

• Quantum OpenStack Networking Track
     • Instead of focusing on just one session, I wanted to highlight the entire Quantum track. Networking across OpenStack is very important and all of the work going into it is key to its ultimate adoption by the masses. From internal only clouds to clouds that are federated across geographical locations, Quantum is being looked upon as the potential answer.

• Folsom Gets DevOps Team
     • DevOps is a hot topic in the IT world today, and it’s also an important aspect to the future success of OpenStack. OpenStack needs developers and OpenStack needs Operations to meet its lofty expectations. This session begins to lay the foundation for bringing the two camps together.

• Operations Pain Points
     • Operations are becoming more important as OpenStack is growing. As adoption continues to ramp up, getting a clear view of how to operate and administer OpenStack is on the minds of many individuals and companies. This session discussed problems the community sees and how to fix them.

High-Availability

• Folsom HA
     • A brainstorm session for discussing ideas to achieve true high-availability for OpenStack components. There are many pieces of OpenStack, some pieces have been solved and others have yet to be addressed. This session lays out the plan to make all appropriate pieces HA.

• Compute Cells
     • In past Summits this was called, “Zones.” Compute cells are thought to be used for geographic distribution of load but can also be used for hypervisor specific workloads, e.g., a task that favors KVM versus Xen or vice versa.

• Federated Zones With Service Catalogs
     • Create a unified concept of zones across all of the projects so that deployments, operators and clients can use them to describe arbitrary geographic delineations and provide cross-project affinity between resources.

These are just some of the highlights from the Folsom Summit, and I’d like to wrap this part up from a quote from OpenStack Release Manager Thierry Carrez’s blog: “With OpenStack growing, developers can no longer follow every session and give their opinion on every subject: they have to pick their fights, and trust the other developers to come up with the right design in sessions they can’t attend. So sessions had a lot less advice-giving people and a lot more people actually signing up to do work. The topics were much more deployers-oriented and much less about changing to the latest shiny stuff. Even less glamorous sessions like bug triaging, documentation, internationalization or stable branch maintenance saw a lot a participants present, and signing up to help.”

This is nothing but good news for OpenStack, and I’m personally excited to see what the Folsom release brings in terms of the aforementioned focus points!

Be sure to check back tomorrow to see part two of Wayne Walls’ recap of the OpenStack Design Summit & Conference.

We kicked it off with some general Q&A. We had a group around 10 and it was clear the group we spoke to was well versed in virtualization technologies and wanted to dive right into OpenStack specific conversation. I began the session with an update about the OpenStack Foundation – from the Foundation’s creation announcement six months ago to the latest news that Red Hat and IBM have pledged their support for the project. The questions ranged from “What happens to the OpenStack code if the Foundation stops getting funding?” to once again hearing “Why would Rackspace relinquish control of the OpenStack project?” Both questions have related answers: it’s all about what is best for OpenStack. Rackspace leaders and the OpenStack community have done a stand up job of getting the Foundation’s organization in order and have set it up for success. Here are a few key points that should be known about the Foundation’s current proposed structure:

• There are multiple levels of membership
     • Individual
          • Participate on their own or as part of their paid employment — free to join
     • Platinum
          • $500,000 per year paid annually with a three-year commitment
          • Will provide operational resources to the Foundation such as staffing or development environment infrastructure
     • Gold
          • Fund an amount equal to total company revenue times .025 percent, with a minimum of $50,000 and a maximum of $200,000
     • Corporate
          •$25,000 per year paid annually
     • Start-Up
          • $10,000 per year paid annually

Along with financial contributions, all members will have access to OpenStack logos for commercial usage; designation of membership and a corporate logo in the Supporters section on OpenStack.org; custom profiles detailing support of OpenStack; as well as a number of additional benefits all of which can be found on the OpenStack Governance Funding web page.

• Foundation establishment is a community process, all being done in the open:
     • Funding
          • A deeper dive into how OpenStack will be funded and how individuals and companies can contribute to the long-term success of the project

     • Mission
          • “The OpenStack Foundation is an independent body providing shared resources to help achieve the OpenStack Mission by Protecting, Empowering, and Promoting OpenStack software and the community around it, including users, developers and the entire ecosystem.”

     • Structure
          • Foundation Creation
               • What OpenStack looks like today
               • Transition
               • Approach
          • Project Governance
               • Project Technical Leads (PTL)
               • Project Policy Board -> Technical Committee
          • Corporate Governance
               • Membership
               • Board of Directors
               • Code of Conduct & Member Agreements
               • Additional Committees
          • Operations
               • Foundation Roles
               • Funding

The Foundation was the focal point of the session for sure, but we did get to dive into the state of OpenStack today and even got down and dirty with some API discussion. As I’ve echoed throughout the meet-ups on the way home from the OpenStack Design Summit & Conference, OpenStack had an entirely different feel to it this time around. The sheer number of attendees and emergence of the Deploy/Ops Track painted the picture for me. OpenStack is no longer viewed as a cool open-source project that might catch some looks; it’s now seriously being considered for production deployments. Companies are no longer just looking at OpenStack as proofs-of-concept, they are investigating how they move production workloads, what the migration path is, and most importantly when. With the Essex release, I believe we’re over the hump, and with the discussion about the Folsom release it’s clear the OpenStack community is on the right path. There is surely plenty of room to debate what “the right path” is, but the overall take away from the Design Summit for the Folsom release revolved around three key topics:

• Security
• Deployability
• High-Availability

Each of these topics had numerous sessions and candid discussion. To go along with these sessions was a very high level of involvement. More attendees were interested in signing up to help rather than just give their opinions. Probably the most encouraging outcome of the Summit was the so called “less sexy” parts of OpenStack: documentation, bug triaging and internationalization all had long lists of people signed up and raring to contribute. Seeing this level of involvement across the entire OpenStack project was truly eye-opening. Enough good things cannot be said about the OpenStack community and all those that work tirelessly to coordinate this global project including Stefano Maffulli, OpenStack community manager; Anne Gentle, OpenStack documentation czar; Theirry Carrez, OpenStack release manager; and countless others that coordinate events, contribute code and help ensure the community and the project keep on flowing with a good vibe for all participants.

We closed up the Dallas meet-up with a short discussion around the OpenStack API. Lucky for everyone, we had Glen Campbell in attendance from Rackspace to really bring the heat. Glen had a session at the Design Summit named, “API Extensions: the good, the bad, and the ugly,” so he was able to really dig deep and answer questions around API portability, extensibility and what it takes to be an industry standard. Most of the questions came from the students in attendance, and I think that speaks a lot to open-source and academia. We are seeing more and more thesis and dissertation reports based on open-source technologies and that speaks volumes to the interest in the adoption of these into the mainstream. As more and more enterprises look at alternative technologies to help move away from software and hardware lock-in, open-source technologies are one of the first places to explore. This has been evidenced with OpenStack in the cloud software stack and we have the OpenCompute Project that takes direct aim at the hardware space. It’s a great time to be in tech. Everything is moving 1,000 mph and it’s moving in the direction of progress. It’s still early in the game, so don’t think you’ve missed your chance to get involved. Established, growing and yet-to-be-announced projects are all looking for contributors, and that will allow you to put your mark, no matter how big or small, on OpenStack!

Alas, we arrived at our location at the DaVinci Institute, which was launched in 1997 as a non-profit futurist think tank. The DaVinci Institute has emerged as a center of visionary thought, attracting both a national and international following of inventors, innovators, idea junkies and business leaders alike. The audience in Boulder was a highly technical bunch, of which many have played with OpenStack in some form or function, and/or were current Rackspace and Dell customers already! It’s always nice to get out and meet customers face to face; they always offer candid feedback and that’s the type of stuff we love to hear. It’s the job of all Rackers to hear out problems and engage the right people to get problems solved! This time around we had representatives from HP, Level3, OpsCode, various government agencies and many local start-ups — about 40 total in attendance — our biggest turnout yet!

Jim Plamondon started us off again with his “Cloud 101″ deck to ensure everyone was on the same page when it came to cloud computing. This went pretty flawlessly, as the audience had a fairly solid understanding of cloud already. But something I liked was a guy sitting next to me whispering, “Oh, that’s a good point.” This was one of the most technical guys in the room, and it just goes to show that reviewing the basics rarely ever hurts.

As we moved into the second part of the presentation, the agenda was simple: OpenStack Foundation, Rackspace adoption of OpenStack and lastly bits and pieces from the Folsom Design Summit & Conference. Off the bat, there was a slew of questions about the Foundation. This has been a pretty hot topic of late, especially with the news last week that Red Hat and IBM joined the Foundation as Platinum sponsors. The questions ranged from “What do you expect Red Hat’s role to be with their current slate of open-source cloud products?” to “What license is OpenStack governed by?” to “Why would Rackspace want to move OpenStack into a standalone foundation?” The answers were simple: Red Hat has an enterprise interest with its Red Hat Enterprise Linux (RHEL) distribution, so it will likely look to enter the OpenStack world with a similar product, as Red Hat stated in a press release FAQ about its membership to the OpenStack Foundation.

Transitioning into Rackspace’s adoption of OpenStack into our next generation cloud was a fun topic that created lots of stir. Rarely outside of the OpenStack Conference can you refer to OpenStack projects by their codenames only and everyone knows what you are talking about, e.g., Nova as Compute, Keystone as Identity Service, etc. Much of the crowd knew  these details, and knew what it means that Rackspace now runs these projects in some sort of production or limited availability today. It means that OpenStack and its projects are real. Two years ago some of these projects did not even exist — except as some scribbles on a whiteboard. To go from whiteboard scribble to an enterprise productized solution is a huge win for OpenStack and anyone who plans to use it for either business or personal gain.

The biggest part of the discussion was around how people would start to use the projects to build their own clouds. There was a misconception that all of the code Rackspace uses today is available for download. Due to each company having its own use cases and business practices, there will always be a part of code that will be have to be catered to one’s use. The load balancer as a service project, Atlas, was wholly written by Rackspace developers and open-sourced. The integration code to our systems and our special sauce (billing, monitoring, etc.) are of no use to others with systems that are totally different. This meant that around 80 percent of the code was released to the public, which then allows the community to make infrastructure of software choices that best suit them.

The last part of the presentation was dominated by conversations around community, deployment and stability. There were many folks in the crowd that had hands-on experience with OpenStack and they shared many of the pain points I’ve heard at some of the other OpenStack meet-ups I’ve attended over the past couple years: Documentation is scattered; it’s not easy to setup an OpenStack cloud; and if you do happen to get it deployed, it’s hard to migrate to a new release. From the documentation and communication standpoint, there was a good amount of progress made at the Summit. All documentation will now be hosted on GitHub and will be able to use the benefits of the version control software. Discussion around mailing list clean-up and Internet Relay Chat (IRC) reorganization was positive and will help people focus more on the things that they want to work on and not drown in the sea of information that OpenStack produces.  Overall, I felt the communication changes will be good for the project and I’m looking forward to the leaps of progress we’ll see due to these changes.

The conversation then turned to deployment — a topic dear to my heart. OpenStack is growing at such a rapid pace that it’s hard to keep deployment guides, best practices and reference architectures up to date. What if there was a single tool that would deploy a cloud for you, using packages that have been thoroughly tested and known to work? Say hello to Crowbar, an OpenStack installer written and open-sourced by Dell. Teaming up with Rackspace, Dell is deploying fully operational OpenStack clouds on bare-metal servers. If you’ve been to any major cloud conferences in the past 18 months or so, you may have seen Crowbar do its magic live. If not, you can check out the latest recorded Crowbar demo from Austin DevOpsDays 2012.

We ended the session discussing stability and upgrade paths, two topics that have become increasingly important as OpenStack moves towards more production deployments. There was a lot of news in this department — there was a dedicated session to discuss proper packaging across Linux distributions along with an announcement from Mark Shuttleworth from Ubuntu that Ubuntu will backport future releases of OpenStack into its LTS release. I was also pleasantly surprised to see a “Deploy/Ops” track at this Summit. It is no longer a matter of if but when.

The momentum behind OpenStack has clearly increased as the aforementioned events illustrate. We are watching a revolution happen, and it’s one heck of a show, but I still say we’ve barely seen anything yet!