ICO 2.5: Azure deployment

Here's a video I created going over some of the details of deploying through IBM Cloud Orchestrator 2.5 to the Microsoft Azure cloud.

Using a certificate with an Azure deployment in ICO 2.5

The ICO 2.5 documentation clearly states that you cannot create a service that uses certificates from ICO, and that is still true. HOWEVER, you can deploy into an EXISTING service that has a certificate associated. The trick here is that you have to first manually create the service in Azure, then manually attach the certificate in Azure. Then when you select the "Deploy cloud service into Azure region" Self-Service option, select the "Use an existing Cloud Service" option.

ICO 2.5: Deploy LAMP stack additional requirements

Once you get ICO 2.5 up and running, you'll have a few self-service offerings available in the dashboard, including "Deploy LAMP stack". This offering requires just a couple of additional configuration steps in addition to the documentation to get it to completely work.

1. You MUST have a flavor named "m1.medium" in your project and it must be large enough for your image named "linux_img".

2. Your linux_img needs to have the yum repositories available that provide httpd, mysql and php. On CentOS and RHEL, these packages are on the base DVD. To provide these to the VMs on my private network, I have these DVDs mounted under a central (private) web server's web root, and have these URLs configured in the appropriate /etc/yum.repos.d/*.repo files on my linux_img image.

3. The MySQL expects to have access to the file named:

/tmp/mysqlinstaller/world.sql

It runs this SQL script during install. You can download this file from

http://downloads.mysql.com/docs/world.sql.gz

I simply placed this file on my image so it's there for every VM created.

That's it.

A feature that I would love to see in OpenStack

A graphical user interface for the commands.

Yes, Horizon is pretty nice, but there are lots of things that it doesn't allow you to do. Additionally, the CLI commands are pretty intimidating. Here's the documentation for the current release: http://docs.openstack.org/cli-reference/content/openstackclient_commands.html . Notice how each command has at least 20 options, each with its own flags, etc. And Horizon doesn't actually call these commands. It uses the REST API (and/or other API), which is completely separate.

So what I'd like to see is something graphical that lets you first pick a command ('nova', 'glance', etc.), then you have a drop-down choice list for the next parameter, and the next, etc. Many of these commands require output from other commands as their input. So the idea would be that the interface is running each of the required commands to build the appropriate list of options. And after building the command, this tool could output that for you to use in scripts, etc.

If it was an easy task, it would already exist, and it doesn't. There's also quite a lot of movement in the code, so keeping this tool up-to-date would be quite a challenge. But I personally think it would be worth it.

ICO 2.5: Where does the heat template for the "Deploy LAMP stack" come from?

ICO 2.5 comes with a few samples in the Self-Service Catalog, including one named "Deploy LAMP stack" (under "Deploy customized cloud services"). Once you have your linux_img image configured correctly and your linux_key key pair created, you can request this offering to deploy a LAMP stack among three machines: Apache, MySQL and PHP. I found the heat template command logs on each machine in /var/log/cloud-init-output.log and /tmp/install.log, and wanted to find where exactly that template was coming from. It took me far too long to find it because it's an inline string in the JavaScript code that can be seen with Business Process Designer. Specifically, you can find it in the Embeddable Deploy Lamp Template service in the SCOrchestrator OpenStack Services toolkit, in the Build Parameters element on the diagram, here:

You can see it in the green text as part of the "Implementation" in the bottom panel.

ICO 2.5: Creating a Red Hat 6.5 image with Gnome for use with a VMWare vSphere cloud

Introduction

When creating your private OpenStack-managed vSphere cloud, you're going to need some "images" ("VM Templates" in VMWare terminology) so you can launch/deploy instances. The really sticky part about this configuration is that OpenStack has traditionally only supported the KVM hypervisor, which uses a different disk format than VMWare (KVM uses QCOW2 and VMWare uses VMDK). I found some great QCOW2 images here: http://docs.openstack.org/image-guide/content/ch_obtaining_images.html and some great CentOS VMDK images here: http://osboxes.org. I had some different hurdles with each of those and finally decided just to install RHEL 6.5 from scratch, then modify that VM to work, then create a VM Template that would be automatically discovered by OpenStack as an image. In this post I'll cover the highlights of this technique.

Install Red Hat

Install the "Desktop" option. This will mean that you have to do a little cleanup later, but I'll cover that.

Install VMWare Tools

Go ahead and install VMWare tools just to make your life a little easier.

Configure Yum Repositories and Install Packages

If you're using Red Hat Subscription Manager, you don't have to go through these steps. If you're not using RHSN, you'll need to manually configure some repositories. I found for this exercise that the CentOS repositories, along with the EPEL repository, worked great. To configure the CentOS repositories, create a file named /etc/yum.repos.d/YOU_PICK_A_NAME.repo with the following contents:

[base]

name=CentOS-6 - Base

mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os

#baseurl=http://mirror.centos.org/centos/6/os/x86_64/

gpgcheck=0

#released updates

[updates]

name=CentOS-6 - Updates

mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates

#baseurl=http://mirror.centos.org/centos/6/updates/x86_64/

gpgcheck=0

#additional packages that may be useful

[extras]

name=CentOS-6 - Extras

mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=extras

#baseurl=http://mirror.centos.org/centos/6/extras/x86_64/

gpgcheck=0

#additional packages that extend functionality of existing packages

[centosplus]

name=CentOS-6 - Plus

mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=centosplus

#baseurl=http://mirror.centos.org/centos/6/centosplus/x86_64/

gpgcheck=0

enabled=0

#contrib - packages by Centos Users

[contrib]

name=CentOS-6 - Contrib

mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=contrib

#baseurl=http://mirror.centos.org/centos/6/contrib/x86_64/

gpgcheck=0

enabled=0

Then run 'yum repo-list' to verify the repositories were created. Now you can run the following commands:

yum -y epel-release

yum -y cloud-init

yum -y cloud-utils

yum -y heat-cfntools

Configure Networking

Since the "Desktop" option was chosen, the NetworkManager service was installed and enabled. You need to change that with these commands:

service NetworkManager stop

chkconfig NetworkManager off

service network start
chkconfig network

Now run the following commands so that eth0 will get configured properly:

sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0

echo -n > /etc/udev/rules.d/70-persistent-net.rules

echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules

Configure cloud.cfg

The default configuration will try to contact multiple non-existent IP addresses for metadata, and you don't need that by changing /etc/cloud/cloud.cfg. Add the following line to that file:

datastore_list: [ NoCloud, ConfigDrive, None ]

You *may* also want to set:

disable_root: 0

ssh_pwauth: 1

This will allow you to access the VM as root, and via ssh with a password.

Make a Template

Via the vSphere Web Client or vSphere Windows Client, clone the VM to a template. After you do this, wait a few minutes for OpenStack to "see" this new template as an Image.

Conclusion

Following the above steps should get you a working template from which you can explore the other capabilities of ICO and ICMWO.

How to reset your OpenStack services to "Up" in your IBM Cloud Manager dashboard for a vSphere cloud

While trying test and manage components in your vSphere cloud, you may see "Services Down" in some parts of the dashboard. For example, under "Host Aggregates":

I basically found that restarting all of the "nova*" services on my controller to be the answer to this problem.

The one-line answer is to log into your controller node as root and run the following:

for i in `systemctl -a | grep \.service | grep " active"| grep nova | awk '{ print $1 }'`; do systemctl restart $i;echo $i; done

So it's iterating through the results of the 'systemctl -a' command that contain active services containing the word "nova", and restarting each of those services. After you run the above, you should see that it shows "Services Up" for all availability zones on all hosts (since in a vSphere cloud, these services are all running on the controller node, rather than on the VMware nodes themselves).