Monthly Archives: October 2011

Improving novaclient CLI. Boot server with specific key.

Before now there was only one way to specify ssh-key when booting a new server: by passing path to the public key file in the local machine (if you don’t specify that path then taking public key file from the /home/.ssh/ directory occurs). That way you couldn’t use keypairs which you have created earlier by nova add-keypair command. But starting from now you can do it!

$ nova boot <server_name> --image <image_id> --flavor <flavor_id> [--key_path [<path_to_the_public_key>], --key_name <keypair_name>]

As you can see you are free to use both methods (old and new) and it is up to you what the way you go.

Here is a sample sequence of commands to work with the new feature:

$ nova keypair-add key1 > private_key_file — save returned private key to the file.

$ chmod 600 private_key_file — only owner shoud have access to the private key (-rw-------).

$ nova boot <server_name> --image 3 --flavor 1 --key_name key1 — boot new server with specified image id, flavor id and also inject previously created private key by its name.

$ nova list – show available servers. Check the status of the newly created server and if it is BUILD (creating in progress) perform this command until the status becomes ACTIVE. After that you can connect to the server by ssh. Let’s say servers’s ip is (You can find out ip from the same table as the status).

$ ssh -i private_key_file root@ — it is done — you are in the created server’s shell.

You can see sources on

or binaries for RHEL

and for CentOS

How we build packages in Grid Dynamics (using Gear + Mock)

As we stated before we are building OpenStack RPM packages directly from Git repositories. All bug fixes and patches specific for our RedHat OpenStack distribution are committed into corresponding Git repos. The process of building is fully automated. You just need to setup a build system like we made.

Some details about our build system. All packages are built in a chroot, populated by Mock tool. It allows us to build packages in an isolated environment with minimal packages installed and only right repositories set for dependency resolution. For RHEL it is only repo from distribution ISO and Grid Dynamics repo itself. So to bootstrap we had to build many dependencies from sources.  That is not all the story. Having ready RPM specs and sources was not enough for good automated builds. It is also necessary to have a uniform mechanism for gathering everything into tarball: sources, patches, specs, scripts. We chose Gear as a tool for this purpose. It automates source code checkouts from Git and packs everything according to “gear-rules” which should be added to Git repo. We also improved Gear by adding integration with Mock, so we could produce a chroot-built SRPMs directly from Git. So basically commands to build Gear repo are the following:

  1. In the Git repo dir execute: gear-mock --root=<mock-chroot-config>
    (gear-mock is command introduced in our fork of Gear)
  2. Take SRPM and build it via Mock:  mock --rebuild <mock-chroot-config> <SRPM>

Summarizing benefits of using Mock and Gear:

  1. It is possible to build for different platforms (e.g. RedHat, CentOS, SL, Fedora)
  2. Built packages are independent of current host configuration
  3. Convenient source code updates (It is stored in Git, not tarballs)
  4. No more manual patch creation (Gear is able to generate .patch files from commits and put it into SRPM automatically)
  5. Uniform way to manage projects’ source code

RPM packages for Mock and Gear are also available at our YUM repository. You may try to do it yourself.

Using nova instead of eucatools while working with ssh-keys

There are two ways to manage OpenStack cloud: using EC2 API(Amazon compatible) and nova API (native). Using native API is preferred way. OpenStack has python-novaclient project for that aim. It is command line interface for managing OpenStack. Unfortunatly it doesn’t support working with ssh-keys and we need to use euca2ools for that.

Starting from now this issue is over. Now you can perform following commands:

nova keypair-add [--pub_key <pub_key>] — creates public (if the pass to it is not passed) and private keys, saves public key into database and prints the private key into console.

nova keypair-delete — deletes keypair if it exists.

nova keypair-list — shows user’s keypairs like the eucatools do.

You can see sources on

or binaries for RHEL

and for CentOS

Source code for Diablo packages

Today we have published OpenStack source code that was used to build RPM packages for Diablo release. Source code is the same for both CentOS and RHEL repositories. Please check it out on GitHub:

Among changes to source code you may also find RPM spec files and “.gear-rules”. All that is required  for our build system. We are going to describe it in a separate article: how we build packages from Git using Mock and Gear. Stay tuned.

CentOS build of Diablo (OpenStack-2011.3)

Because of many requests we prepare repository with CentOS packages:

To use this repo you should also use EPEL repository.

It is also necessary to use extra CR CentOS repository. That should resolve some problems with outdated dependencies.

CloudPipe – setting up VPN for projects

Cloudpipe is a method for connecting end users to their project instances in VLAN mode. You can read more about CloudPipe in the official Developer Reference.

A few notes for successful setup:

First you need to decide how many addresses you want to be reserved for the VPN clients, specify this number using --cnt_vpn_clients flag before creating network, if you alter this flag, existing networks won’t be affected by this change. IP addresses for clients marked as reserved in database and won’t be allocated to instances.

Second, although, official documentations says that you must specify image id in --vpn_image_id flag using ami-xxxxxxxx format, this image id should be specified using decimal number, without the ‘ami-‘ prefix, so if you use euca-describe-instances command you need to convert the image id from hexadecimal representation to decimal.

After changing nova.conf and restarting nova’s services you can start particular cloudpipe instance using

$nova-manage vpn run <project_id> <user_id>

command. I case of any problems with your CloudPipe instance you can always connect through ssh to this instance using key stored in /var/lib/nova/keys/[user_id]/[project_id]-vpn.pem file, where [user_id] and [project_id] is your user and project ids respectively.

Connecting to VPN is relatively easy, all required certificates and keys are bundled using

$nova-manage project zipfile <project_id> <user_id>

command, to connect you can use provided nova-vpn.conf file, just pass it to openvpn command

$openvpn --config nova-vpn.conf

RHEL build for OpenStack Diablo (2011.3) release is out

We are happy to inform you, that we have prepared RPM packages for RHEL. We tested packages for compatibility with Scientific Linux as well.

Differences from upstream:

  • Selinux for VM instances is disabled by kernel option
  • tgtadm is used for iSCSI managing instead of ietadm
  • GuestFS is used for files injection
  • Static network configuration can detect OS type (RHEL and Ubuntu are supported)
  • Files injection works with libvirt
  • Other bug fixes

Yum repo:

We are waiting for your questions/comments at our mailing list: