Blue Box founder Proudman talks OSCON, OpenStack, IBM future!

When IBM announced in June that it had acquired Seattle-based Blue Box, which offers private clouds as a service via OpenStack, analysts and IT experts called it a step forward for IBM’s hybrid cloud capabilities.

Now more than a month into the relationship—and with OSCON fast approaching—we wanted to get a better idea of where Blue Box will fit in the IBM Cloud portfolio. We went back to the source, Blue Box founder Jesse Proudman, to see how the transition is going, and where they’re headed.

Thoughts on Cloud: Blue Box has been an IBM company now for a little over a month. What has that month been like for you and your team?

Proudman: It’s been a blur of ideas and action, fueled by a phenomenal integration team and lots of 5-Hour Energy. The more we dig into the details, the more we realize just how much sense this combination makes. Most importantly, I’m incredibly proud that we’ve been able to recruit 11 new team members to the Blue Box family in the first month under the IBM Cloud umbrella.

ToC: What does the future hold for Blue Box within IBM?

Proudman: We’re staying focused on the immediate future, on getting things done. The second half of 2015 has three priorities. First, we’ll complete the integration of our teams: engineering and go-to-market are the key priorities. Our engineering team will continue building the Box Panel suite of operations tooling that deploys and manages private clouds for our customers. At the same time, they’ll be working in the field to push Blue Box private cloud as a service into IBM client and SoftLayer data centers worldwide. Our marketing team will work with the broad IBM consulting organization to equip them with the knowledge and resources to help IBM customers and clients understand the role that OpenStack-powered PCaaS can play in their overall cloud strategy.

(Related: Jesse Proudman and other cloud experts offer insights in the webcast “Top ways to get the most from cloud management“)

ToC: Has anything surprised you since Blue Box became part of Big Blue?

Proudman: Both how insanely smart members of the IBM team are, and the breadth of expertise and knowledge that exists inside Big Blue. IBM is 430,000 strong, and I’ve been pleasantly surprised with the caliber of folks we’ve met.

ToC: You’re heading to OSCON next week. What are your expectations in terms of hot topics and trends heading in to the conference?

Proudman: OSCON is an odd duck in the roster of cloud conferences. It’s more about the philosophy and culture of open source than advocating or demonstrating new commercial technologies. In fact, it tends to be a great spot for recruiting engineering talent.

With that as a backdrop, we’re going to be looking for conversations about container management and container cluster management. Enterprises are obviously interested in how containers are managed and operated in production. They want tooling and support that helps them deliver containers reliably and in compliance with policies. Preferably, they’d like to do this within the cloud infrastructure they’re already running, rather than starting over with a new stack. This is a shift in the conversation, where names like CoreOS, Magnum, Rancher and Kubernetes are more important than things further down the stack like Docker itself. It’ll be interesting to continue to watch how this all plays out.

ToC: You recently wrote that you don’t believe there’s consolidation happening within OpenStack right now. Could you expand a bit on your view of why you think the opposite is happening?

Proudman: Consolidation can mean several things. In the context of OpenStack, the term been used recently to suggest that there is oversupply in the market. That’s ludicrous. What we see instead is a market maturing with new business models emerging to support the consumption patterns customers are embracing.

In my blog post about the failure of OpenStack distributions, I make the case that software distributions of OpenStack have failed because the vast majority of enterprises don’t want to touch OpenStack. Instead, they just want to consume it. So, early distro providers who’ve been acquired are helping larger companies build out a more comprehensive suite of services to meet the realities of a rapidly growing market.

That’s not a consolidation. It’s a realignment of resources in the face of an evolving market.

(Related: Read Jesse Proudman’s Thoughts on Cloud article “OpenStack: The myth of the middle“)

ToC: What do you think Blue Box brings to the table with its OpenStack offering that sets it apart?

Proudman: We make it possible to spin up dedicated private cloud resources in a nearly on-demand environment. We can do this in our data centers or yours, across an ever expanding geography. Customers are embracing it, and we’re excited to be building something that’s perfectly positioned for where the market is going. This is truly unique positioning in the marketplace.

ToC: You also wrote recently that “most enterprise buyers want OpenStack without having to touch OpenStack.” How are you addressing this unique challenge?

Proudman: We started by assembling an incredibly talented team of OpenStack and infrastructure experts coupled with a very robust management technology. Then, we combined forces with IBM, an organization with the resources to deliver OpenStack solutions that the market has been demanding since before they knew the name, OpenStack. Now together, we’re developing a highly competitive product roadmap that I look forward to sharing more about in a future interview.Blue Box founder Proudman talks OSCON, OpenStack, IBM future!

How to better service your OpenStack cloud

Co-authored by Thanh Lam and Ben Cao

Embracing the world of cloud computing can be a nebulous experience. You go through a maze of services. The challenge is to provide all these services that cover everything from setting up a cloud infrastructure to creating a virtual machine. What if you could connect the service user interfaces to an existing cloud environment, like OpenStack?

Using OpenStack, you always look for the best way to scale up your cloud while maximizing the various services and features it offers. Horizon, the OpenStack dashboard project, has a native user interface that is a good place to start, but it lacks some key management features such as approval, billing and expiration policies. To address this, IBM Cloud Manager with OpenStack includes a self-servicing portal– in addition to Horizon– to empower its users with a more complete experience.

In this post, we will show you three simple steps to start servicing an OpenStack cloud with the IBM Cloud Manager with OpenStack self-service portal.

1. Setting up the self-service portal

To get all those extra services, the self-service portal software has to be installed first. The software comes with the Cloud Manager with OpenStack package. However, the self-service portal has to be deployed onto a node at installation. You can try a trial of Cloud Manager with OpenStack to get a feel for things. After installing the deployment server, you have a Chef server that helps you manage the nodes in a cloud infrastructure.

The “self-service portal enable” property setting is defined in a JSON file that presents Cloud Manager with OpenStack environment configurations. You can edit the JSON file, and then upload it to the Chef server. Or, if the environment is already uploaded but you forgot to enable the service, you can edit the environment settings dynamically. The procedure is the same as changing the value in a text editor. List the environments and find yours as in the following screenshot.

Servicing OpenStack cloud

The screenshot also shows the command to dynamically edit the environment, which is put into an editor. Your first search for the text string ibm-sce points at the ibm-sce cookbook version: ibm-sce”: “~> 0.1.7.

The next search for ibm-sce jumps to the beginning of the ibm-sce definition section, which contains the attributes for os, config, user and so on. At this point, search for the text string service to find the ibm-sce service enable attribute setting. Change the default value false to true, and then save to exit the editor.

Prepare the topology in a file and make sure role[ibm-sce-node] is in the runlist of the controller node. Now you can run the deploy node command as described in the Cloud Manager with OpenStack Administration Guide.

For a quick start guide with installation steps, go to the Cloud Manager with OpenStack Wiki. A sample of the environment and topology files in JSON format is also provided here.

Servicing OpenStack cloud 2

Servicing OpenStack cloud 3

2. Self-service portal validation

The self-service portal is a server application that listens to requests and transfers them to the component for responses. For the self-service user interface to work, the portal has to be running all the time. Therefore, the node deployment script sets up the server process as a service.

After successful deployment of the controller node, the self-service portal is started automatically. You can verify the service status with the service command. The same service command is also used for stopping, starting or restarting the service. Stopping the portal is a quick way to stop new user requests in case you need to have a maintenance window, for example.

Servicing OpenStack cloud 4

The portal server is built on top of the Open Services Gateway initiative (OSGi) that provides a framework for supporting the services. Administrators can interface with the framework by using the command-line interface, which talks to OSGi through a telnet port. To find the port number, use the common command ps –ef. Port number 7777 is revealed in the following screenshot. You need to filter out all the texts to spot the localhost telnet port 7777.

Servicing OpenStack cloud 5

The telnet command lets you enter the osgi> command console as shown in the following screenshot. Be aware that no password is required to log in. To give you peace of mind, this command-line interface is limited to the local host only. Before you complain about the limitation, this is an administration tool, which can cause lots of damage if someone with malicious intention had access.

Servicing OpenStack cloud 6

3. Connecting the self-service portal to an OpenStack cloud

The portal does not have virtualization resources to start with. You can create projects and users. The most important next step is to connect the portal with one or more virtualization environments, which are the sources for cloud resources. The cloud status is right on the front page of the self-service user interface.

IBM Cloud Manager with OpenStack

Choose Cloud settings to go to the cloud configuration page. You can see that you have no cloud. Before you can add a cloud by creating a connection to a virtualization environment, you need to define the infrastructure as a service gateway. This gateway is the interface into the OpenStack drivers that communicate with the virtualization environments. See the Cloud Manager with OpenStack Administration Guide for setting values.

In summary of step three, a common pattern runs through the forms where you enter the setting values. For the self-service portal to be able to connect, make sure you enter the correct value for:

• Host name or IP address of the OpenStack controller node
• Port number to connect to
• User ID of the administrator who has access to OpenStack controller node
• Password
• Some exceptions

There is a good reason that the Test Connection button is available on each of these forms.

If you want a lab environment to try out Cloud Manager with OpenStack, IBM Technical Training has a course you can take on different architectures.

That’s it! You can now start managing your OpenStack cloud with the self-service portal. If you have any questions regarding Cloud Manager with OpenStack, please visit our community forum. Also, don’t hesitate to connect with us through Twitter @ThanhLamV and @mrBenCao.