Nova is distributed from several sources in many different packaging formats. As it is a relatively new project, it lacks the installation ease and universal portability of more established open source projects like Apache Web Server. As such, it is not easily installable on every operating system distribution without significant administrative configuration. In this chapter, we will help you decide which version of the OpenStack code base is best suited to your deployment needs and show you how to obtain that version in your preferred packaging.
As Nova is a fast-moving and relatively young project, we need to make some decisions about the codebase that we want to use. There are two major decisions here:
What version do we want to use?
What form of packaging do we want to use to deploy Nova?
To adequately answer these questions, you need to ask yourself two tough questions:
How proficient am I with Python development, system administration, and Linux packaging?
How much stability am I willing to sacrifice to get the latest features?
To answer the proficiency question, you will need to honestly examine your skills across not just programming, but also system administration. If you don’t utilize the packaged versions of Nova, you will need to understand how Python applications are built and their dependent packages. If you want to use newer, non-production versions of the code, it is possible that you will run into bugs that you will need to troubleshoot or fix yourself. On the systems administration side, Nova has heavy dependencies of Linux networking and virtualization support. As stated earlier in the book, it is mostly a control framework for virtual machines, storage, and networks. To apply its advanced configurations or options, you will need to understand the trade-offs you will be making. Rules of thumb for classifying skill level could be as follows:
Relatively unskilled in Python programming, but has basic system administration skills in Linux virtualization (specifically KVM) and networking (understanding of iptables and ifconfig).
Beginner skills in Python (can read code, perhaps written basic Python scripts). Competent system administration skills, with advanced knowledge of key areas such as virtualization (perhaps deployed Xen or VMware at their company), storage (usage of iSCSI), and networking (understanding of VLANS and advanced switching).
Well-versed in Python, including working with large open-source Python projects, knowledge of popular libraries (SQL-Alchemy, amqplib, etc.), and experience with WSGI applications. Advanced system administration skills such as writing libvirt templates, defining new iptables or ebtables rules, and administering message queuing software.
As noted earlier in the book, Nova is a rapidly moving project that changes daily. Having said that, there are still regular releases, as with any normal software project. For the purposes of this book, we will look at three possible code releases that you might want to deploy:
This is the last “released” version of the codebase and is analogous to a product release. Released versions of the code are the most tested and polished versions of OS. Release versions are suitable for production environments. Releases are referred to by their version number or their release name. For example, “2011.2” or “Cactus” was the third release of Nova.
Between release versions, milestone versions are produced. These let leading-edge users familiarize themselves and test upcoming releases. Milestones are usually fairly stable, but probably only suitable for test and development environments. Milestones are referred to by the name of the upcoming release and the milestone number (such as “Diablo-3”).
Trunk refers to the most current version of the source code. After every update to the official Nova codebase (called a “commit”) from any developer on the project, trunk is updated. This is the most volatile, least-tested, but most up-to-date release of the code. On many workdays, the trunk will get updated multiple times. Trunk is only recommended for users who are actively developing Nova. Trunk versions of the code are referred to by their Launchpad commit revision number (or “revno”).
At the time of this writing (July 6th, 2011), the release version of Nova was “Cactus,” or 2011.2; “Diablo-3” was the current milestone version; and trunk was at revno 1245.
Table 5-1 provides some guidance on which version and packaging format you’ll be most successful at deploying depending on your proficiency and desired environment.
Table 5-1. Choosing Your Nova Version and Packaging
| Production | Proof of Concept / Test | Development | |
|---|---|---|---|
| Basic | Product (Release-based) | N/A | N/A |
| Proficient | Package (Release-based) | Package (Milestone-based) | N/A |
| Expert | Source (Release-based) | Source (Milestone-based) | Source (Trunk-based) |
Several of the cells within this table have been labelled “N/A” to indicate that these choices are not advised for the complexity of installation and skill level of the installer.