I love diving into numbers – especially when it has something to do with technology conferences.

But before I do that I would to bring to your attention my two sessions that I have submitted for the upcoming summit (Shameless Plug.. )

Me Tarzan, you Jane (or Operators are not Developers)

Welcoming Operators to the OpenStack Jungle.

A year ago I set out on a journey on trying to help the OpenStack developer community understand the other (and sometimes not well understood) side of the OpenStack community, its users.

Users is a subjective term, depending on who you ask - it could mean the end user using an API or a GUI to deploy a new instance but it also includes those who operate the cloud, maintain it and sweat blood an tears to just allow the end-user to do what he wants.

There is distinct separation today between the two entities - but the good part is that they are slowly coming together.

This talk will describe how you an Operator can make a difference - be it small or large - in OpenStack.

The topics we will go over here are:

• Initiatives
• User Committee
• WTE
• ISV
• Monitoring & Logging
• Large Deployments
• ... and many more....

Operator specific activities:

• Ops Tags
• IRC
• Heaven forbid - committing code

Expect some interesting stories, some horror stories but we are all aiming for the same thing.

The pot of gold at the end of the rainbow.

OpenStack - High Availability (as a Service) - Fact? Fiction (or maybe something in between)?

Installing an OpenStack cloud used to be a complex task. We have evolved over time and made this a lot easier and more palatable for operators. Operating an OpenStack cloud on the other hand is whole different ball game..

Operators want stable systems and resilient systems, and if the infrastructure services can scale that would only be an added benefit.

But today, OpenStack as a result of its culture, and its history, is a collection of parts, pieces and solutions using multiple different technologies, and architectures.

One of the pain points is naturally high availability for the services which are provided today in a number of different ways.

This talk will propose one possible future direction with which this could be addressed.

By providing a central HA service for all OpenStack projects.

This session will describe a proof of concept for such solution showing making use of cloud friendly technologies that can could take the level of operations to whole new dimension.

I did this kind of an exercise for VMworld a few years ago - By the Numbers - VMworld 2013 Session Voting, and I thought it would be interesting to see what the numbers are for this OpenStack Summit.

Of course without some insight as well – the numbers would be quite boring.

There are a total of 1504 sessions that you can cast your vote upon.

That is a huge number of sessions. Perhaps too many. There is no way to go over the list in a defined amount of time. I think that most of the people are going to vote only if they are sent directly to a specific link. Which means this will be targeted votes as a result of someone asking you specifically vote for a specific session. Not really an ideal process but I guess that is the price we all have to pay, as a result of OpenStack becoming more and more popular.

Here are the number of sessions submitted for each track:
(Please Note – these are based on the pure number of submissions – and not what has been accepted. This is not an exact science – there could be a number of reasons why they are ranked like this – but these are my thoughts and ideas on the data below)

What is the most popular track? 

Operations - the one part that the OpenStack community is still struggling to get their input back into the projects. For a number of reasons. Be it inclusion, methodology, culture or mindset.

For me this is / should be (also for everyone that is involved in OpenStack as well) a bright and shiny beacon. Claiming that this is either the most important aspect or the most pressing need that people want to hear about or want to talk about might be going a bit far, but it is way, way up there.

OpenStack Summits should be about the technology, not about how keep the bits and bytes up and running, deployed and working in an efficient manner.

Next up on the list. Community and How to Contribute. Way down there in at the bottom. Is that because people already know how to do it? Because people have given up on trying?

This is something that the community as a whole should invest more in making it part of the culture and making the bar much more accessible to all.

Hands on Labs. The number of sessions proposed as labs is growing. Maybe it is time to think about a centralized solution specifically for the summit?

Neutron (a.k.a. Networking). The hardest part about a cloud is the networking part. I have said this before and will continue to preach it from the rooftops.

I took the liberty of creating a word-cloud of from all the words in all the submissions according to recurrence.

It makes you think..   :)

You have only one more day to vote – go and make your voice heard!

I have submitted three different sessions for the upcoming Openstack Summit in Atlanta. This is the first time I have submitted content for an OpenStack Summit, and I am looking forward to attend the event.

I think the content of these sessions will be highly beneficial to all those who attend, and if you would like to hear some more about these topics at the Summit in May, I would appreciate your vote for one (or more) of the sessions.

Voting closes on Sunday, March 2nd, at 22:00 UTC.  You will need an OpenStack Community member account in order to vote.

Here are the three sessions I have proposed.

Deploying Redhat Openstack on UCS - Proposed Deployment Architecture

Deploying a robust OpenStack environment is critical in architectural design. If the foundation of your datacenter is not robust, redundant and scalable - you could encounter difficulties down the road.

In this session I will present a deployment architecture for OpenStack using Redhat OpenStack.

The topics covered in this session will include:

• What are the benefits gained by deploying on UCS?
• Why Control nodes should be deployed as virtual machines.
• When should you deploy a OpenStack Role on bare metal only.
• How the deployment with RHOS simplifies the process? (Foreman)
• Scaling the architecture.

Takeaway

It is best to plan your deployment upfront and dedicate proper consideration to how your datacenter will look like in the future. The complications of issues arising when your infrastructure grows could be averted by proper planning and design.

UCS and Openstack - The Integration

Cloud is about abstraction of resources - compute, storage, and network, and when consuming resources in the public cloud - you, the customer don't really care about the physical resources.

But as an cloud administrator - that is a whole different story, especially when it is about your private cloud.

At Cisco we have been working on integrating the physical with the virtual - taking your operations to a whole new level.

During this session you will see the some of the work done to integrate UCS hardware - directly into the Horizon dashboard.

The benefits are substantial:

• being able to control the virtual and the physical under a single interface
• being able to access a KVM console of a specific compute nodes when disaster attacks
• being able to dynamically assign more physical resources to your OpenStack cluster with absolute minimal overhead

That is the something every admin would like and Cisco is working to provide.

The session topics will include:

• Plugin development
• UCS API
• Integration into OpenStack

Takeaway

OpenStack admins are looking for integration of the a full stack, virtual and physical. The UCS plugin for OpenStack provides that insight into the physical resources, reducing TCO for your OpenStack deployments.

Deploying the Openstack Management Layer - the undercloud

Most of us assume that the underlying OpenStack infrastructure is always in place, but there always comes a time where you have to actually put it there.

There are several ways of doing this. PackStack, KickStack, Cisco even have there own implementation - COI.

But how many servers should you deploy on? 

Can they be virtual or do they have to be physical machines?

What are the benefits/drawbacks of either of the above?

During this session I will go over the advantages of actually deploying the management infrastructure as virtual machines or in other words "the undercloud". 

There are several complications and implications when going down this route. 

• How should you manage this environment?
• What virtualization platform should you use?
• Redundancy and high availability.

This talk will also touch on projects in incubation (i.e. Tuskar)

Takeaway

The management components are the most crucial in your OpenStack infrastructure. Learning how to deploy and protect them in an efficient way will assist you in providing the best service to your customers.