Simple OpenStack deployment with Kickstack

Kick Start

Step 2: Kickstack

The current version of Kickstack is available directly from GitHub [7] or PuppetForge [8]. Once the module and its dependencies are installed, you can begin.

The previously described node roles need to be distributed in a meaningful way to the available nodes. The example here follows a conservative approached to the distribution: Charlie becomes the network node that runs all Neutron components except the Neutron API, Bob represents the computing node and owns the appropriate role, and all other roles are assigned to Alice, who handles the lion's share of the work.

The following example assumes that the individual nodes have already been made part of the Puppet installation after installing Kickstack on the Puppet Master. In this case, they appear in the Puppet Dashboard under Nodes after the admin logs in.

Pressing Groups in the menubar at the top takes you to the only group that currently exists, named kickstack – nodes that take over tasks in the cloud in the context of Kickstack should be members of this group (Figure 3). Pressing this kickstack link followed by another click on Edit allows you to add nodes to the group.

Figure 3: The Puppet Dashboard with an overview of the important configuration parameters of the kickstack group and the participating nodes.

The editing window for the group also provides access to the main settings related to the OpenStack Cloud; for example, if you want to use full virtualization within OpenStack (i.e., Qemu without KVM), then the value in kickstack_nova_compute_libvirt_type is correct. Also of great importance are the entries that specify which network types reside on which network interfaces. OpenStack distinguishes between

  • kickstack_nic_management, the management network, which directly connects the individual services on the nodes (eth1 in this example),
  • kickstack_nic_data, the data network, which routes the traffic between VMs running in the cloud (eth2 here), and
  • kickstack_nic_external, the external network, which connects the virtual machines with the outside world (i.e., eth3 ).

If you are trying out Kickstack and OpenStack on virtual machines, it is a good idea to create the VM network interfaces so they match this scheme; if you are installing on bare metal, you might need to modify the parameters of the kickstack group. If the values cannot be modified uniformly for all nodes (e.g., because the network node uses a different NIC for the management network than the API node), you can also customize the parameters separately for each node in the next step.

The kickstack_cinder_lvm_pv parameter for the node that owns the Storage role (i.e., Alice in this example) is particularly important: Kickstack automatically converts the device stated here (/dev/sdb) into a logical volume in LVM to make it usable for Cinder. Once the configuration of the Kickstack group is correct, you can continue with the roles.

Step 3: Assigning Roles

Pressing Nodes in the menubar of the Puppet Dashboard takes you directly to the individual entries of nodes that Puppet knows. Clicking on a node name and then on Edit takes you to the configuration dialog for that node.

The penultimate box at the bottom marks the classes to which a node belongs: You can use autocompletion to assign the appropriate roles here. For Charlie, this is kickstack::node::network, for Bob kickstack::node::compute; all the other roles are assigned to Alice.

The end result is a series of calls to the Puppet agent on Alice, Bob, and Charlie. If the Puppet agents there are not running continuously in daemon mode, you might have to perform several Puppet runs consecutively to apply all the roles (remember, Puppet understands dependencies; in other words, it only performs those tasks in a Puppet run that are not prevented by an unfulfilled dependency).

After the final Puppet runs, you will see in the dashboard on the left-hand side that each role has been assigned once within the Kickstack class (Figure 4). OpenStack is already running: The OpenStack Dashboard (Figure 5) is accessible at http://<IP-of-dashboard-node>/horizon (e.g., on for Alice). The credentials required for logging in can be found in the openstackrc file, which resides in /root on the node with the auth role. Kickstack leaves one task to the admin: creating networks in Neutron, which can be done manually with scripts, or retroactively via the Dashboard. The same is true for importing an image – CirrOS [9] is recommended for testing.

Figure 4: After assigning all node roles, you can view the results in a pane on the left in the Puppet Dashboard's Class overview.
Figure 5: After installing OpenStack with Kickstack, you need to create a network for the admin tenant.


Kickstack is a welcome change for those who want try OpenStack but are wary of the time-consuming and complex installation. With Kickstack, you simply install Puppet and the required Kickstack modules. In fact, a basic Puppet setup with one master and several Puppet clients can be established relatively quickly. Additionally, configuring the individual nodes to create OpenStack machines is much more convenient in the built-in Puppet Dashboard than setting up the services manually (Figure 6). If you want to extend your OpenStack installation later to add more computers, you can do so at the push of a button in the GUI.

Figure 6: You can easily see the OpenStack services that originated with Kickstack.

However, this is not the end of the road for Kickstack in terms of desirable features: In particular, the solution still falls short when it comes to high availability. First, the OpenStack project has had to develop a concept of how it intended to implement high availability; second, typical HA tools such as Pacemaker are not very well integrated into Puppet right now.

Design Decision: Puppet or Chef?

The question of whether to rely on Puppet or Chef has taken on the quality of a religious war. Similar heated debates are otherwise only seen surrounding admin topics such as Vi versus Emacs, Debian versus Ubuntu, and Java or no Java. In the case of Kickstack, Florian Haas chose Puppet. Packstack, the Red Hat counterpart to Kickstack, also relies on Puppet. Why do the OpenStack developers and companies who work with OpenStack rely on Puppet and neglect Chef?

This can hardly be down to the fundamental design of the two solutions. Although Chef and Puppet take different approaches under the hood, they ultimately reach the same goal. Both systems rely on a client/server architecture, and both rely on their own syntax in terms of defining commands. Workflows differ somewhat, as well. For example, to resolve dependencies in Puppet, you define a corresponding entry in the manifest to stipulate that step A must be done before step B. In Chef, step A and step B need to be listed in the correct order in the Cookbook, otherwise Chef quits.

This system of eventual consistency has its proponents and declared enemies, but in the OpenStack context, the differences are barely visible, so it cannot be the decisive issue that has lead to OpenStack auto-deployment environments that currently only exist in the form of Puppet solutions. The reason is ultimately much more trivial: All told, Puppet integrates better with OpenStack because Puppet modules for all core components can be found on the Internet, are regularly maintained, and thus ultimately already cover most of the required functions.

Although modules exist for some of the core components in Chef, none of this code is official, and modules for important components, such as the Network Service Neutron, are missing. The the fact that extensions such as Packstack and Kickstack rely on Puppet, has very much to do with the fact that significantly more preliminary work has already been done in Puppet than in Chef. Don't panic, though: If do not want to make friends with Puppet and prefer to rely on Chef instead, you can look forward to a remedy by SUSE in the foreseeable future.

Along with some developers from Dell, SUSE is working hard on Crowbar [10], which builds on Chef and is also designated as a solution for automatic OpenStack deployment. Compared with Kickstack and Packstack, Crowbar even offers some additional components, such as a preconfigured Nagios.

The Author

Martin Gerhard Loschwitz is Principal Consultant at hastexo, where he is intensively involved with high-availability solutions. In his spare time, he maintains the Linux cluster stack for Debian GNU/Linux.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=