Category Archives: Administration

Administration Tips and HowTo

Altai v1.1.1 is out

Hello everybody!

A new version of Altai Private Cloud for Developers 1.1.1 is ready to use. In this release, we support reliable updates from any previous Altai version..

This release is recommended to use for everyone instead of 1.1.0. Update procedure from any previous release is safe and automated – just follow our upgrade guide.

Other important changes:

  • guess root partition of virtual machine images for setting login credentials;
  • add script for LDAP configuration after Altai installation;
  • support instance live migration;
  • fix VNC security problem that occurs for deleted instances;
  • strong validation of Altai configuration parameters to determine installation/updating problems earlier;
  • bugfixes in UI;
  • correct adding records for NS servers on zone creation;
  • purge info about deleted instances from database.

Altai v1.1.0 with LDAP/AD support

Hello, everybody!

We are glad to announce a new version of Altai Private Cloud for Developers.

This update introduces out-of-the-box LDAP/AD support in Altai Cloud. It should help to manage cloud users and authorization in companies where LDAP or AD is used.

Useful links:


Altai v1.0.2 is out

Hello everybody!

A new version of Altai Private Cloud for Developers 1.0.2 is ready to use. In this release, we reviewed and cleaned up third-party packages and made bugfixes, primarily to user interface.

This release is recommended to use for everyone instead of 1.0.1. Update procedure is safe and automated – just follow our upgrade guide.

OpenStack Migration from Diablo to Essex

Alessio Ababilov's Blog

We use Openstack at Grid Dynamics for more than a year. It is the basis of our private infrastructure originally named Cloud For Grid Dynamics (C4GD) and now known as Altai. C4GD provided cheap and fast VM management for our developers’ needs with reliable support. We were using the Diablo release and were happy with it.

On 5 April 2012 a new shiny Essex was released not without Grid Dynamics initiative (you can even find me in the list of contributors). I was challenged to investigate and prepare migration scripts for our cloud.

I started from my old scripts for installing Diablo and began writing a set of tools that make easy both migration and installation from scratch for different releases. You can see the result of my work at Github. These scripts work with OpenStack packaged to RPMs at Grid Dynamics.

Generally, OpenStack migrates rather well…

View original post 1,186 more words

OpenStack EPEL: the Dependency Purgatory

Alessio Ababilov's Blog

When you develop a software system, you can choose any solution between two extreme approaches.

  1. Build and maintain all your dependencies.
  2. Rely on external repositories and build only your specific packages.

Having chosen the first approach, you can be sure that your users will use your great tuned packages of carefully chosen versions that are doomed to work properly. And when you see a problem in a dependency, you freely patch it and… congratulations, now you are a happy maintainer of a zoo of numerous packages containing software written in several languages!

The second way is clear: you build a dozen of your own packages and publish a relatively small repository. And when your third-party dependencies become unavailable, it will be a user’s problem.

Developing Altai, we started from the first solution: a user installs basic RHEL/CentOS and just adds our repository. Nowadays, we are moving to the second…

View original post 1,148 more words

YUM Repository Limit

Alessio Ababilov's Blog

Consider that we develop a project and we have an huge repo of different RPMs. We want to release new versions and publish them into new repos, but we know that usually only several packages are upgraded. Nobody wants to copy all unchanged packages to a new repo. However, we could keep only changed packages in the new repo and refer to both repos in .repo file: yum will choose the latest packages.

name=My Project 1.0

name=My Project 1.1

Looks nice, but how many repositories can be supported by yum? Will it crash or work extremely slow if there are hundreds of repositories with different packages? Let us check it up.

We will create 200 repositories with different versions of packages many-repos-a, many-repos-b, and many-repos-c. Repo #(2 * i) will contain packages many-repos-a-#i and many-repos-a-#(2 * i) and repo #(2 * i +…

View original post 362 more words

DNS management system for OpenStack

`nova-dns` package was developed to solve two tasks:

  • map instance’s hostnames to ip addresses in DNS
  • provide REST API to manage DNS

To solve first task service monitor message bus (RabbitMQ). For every started instance service add DNS record, for terminated – remove.  DNS name is choose in form hostname.tenant_name.root_zone. If zone for tenant_name doesn’t exists yet, it is created and populated automatically.

To solve second task service start REST API server on specified ip/port. REST API supports authentication against keystone and utilize keystone’s RBAC.

As a DNS backend PowerDNS is used, but other backends (for example for Bind) can be added later.

Next we are going to add support for PTR zones and  add ability to create personal zone for every started instance.


Billing plugin for Horizon

Now nova-billing has a Django-based web interface – horizon-billing (

horizon-billing is packaged to a homonymous RPM (path for RHEL:, for CentOS:

To enable it in dashboard, install the horizon_billing package and turn it
on in /etc/openstack-dashboard/local/

  • add ‘horizon_billing’ to INSTALLED_APPS tuple;
  • add ‘billing’ to ‘dashboards’ key in HORIZON_CONFIG.

After installation, a new “Billing” panel is added after “Project” and “Admin”.