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