Source repository flexibility in OpenStack deployment using Fuel

When you're deploying OpenStack, you're dealing with a lot of code.  Some of it is part of OpenStack itself, some of it is part of host operating systems, and some of it is part of various other components, but all of it needs to come from somewhere -- often, a specific repository.  With the 6.1 release of Mirantis OpenStack, the configurations for operating system, OpenStack, and user definable custom repositories are exposed through the Fuel UI, making it easier for users to define specific repositories for packages used in their OpenStack deployment.

One benefit of this control is the ability to introduce a clean separation between different classes of packages, with a way to independently manage upstream Ubuntu repositories, Mirantis repositories, and user's custom repositories.  

But what if you don't want to be dependant on external repositories at all?  Mirantis OpenStack 6.1 also includes a brand new tool, fuel-createmirror, which enables you to download the necessary packages from configured public repositories to the Fuel Master node, creating a local repository mirror Fuel can then pull from.

Conveniently, the new tool will also update the repository URI configurations for new or undeployed environments to this new central repository within Fuel for you; you don’t have to manually change the configuration files anymore. In fact, Fuel also includes the ability to directly add repositories right from the UI, as in Figure 1.

Figure 1.  Fuel centralized repositories for Ubuntu and Mirantis OpenStack

Why a local mirror can be crucial for OpenStack deployment

There are many drivers that may push the need for a local, internal set of repositories. Maybe your data centers don’t provide access to the Internet for the compute clusters, or there is a requirement for added safety and validation in auditing downloaded packages first, then hosting repositories locally.  Or maybe you have the need to have custom package repositories for use in deployment.

Of course all this control doesn't do you much good if you need to choose a "one size fits all" strategy; fortunately, Mirantis OpenStack 6.1 includes the flexibility to provide different repository settings for different environments. For example, in a development environment, you might test new homegrown packages before wider distribution into production.

Whatever the driver, creating and maintaining an in-house repository has several benefits, including:

• Increased security and control provided by using packages downloaded and verified by internal audits and taking advantage of the latest bug and security fixes (Environments, like financial institutions, that have very strict compliance policies will appreciate this capability!)

• The convenience of being able to include your own custom packages for the repository

• Elimination of the requirement for OpenStack nodes to have Internet access

• Only downloading OpenStack update packages once for deployment to potentially hundreds of nodes

• Decoupling of the base operating system files, which helps the Mirantis OpenStack and Fuel installation ISO fit on a single 4GB USB flash drive (Think about how much more convenient this makes installing to bare metal!)

To get all of these benefits, all you need to do is run the fuel-createmirror command; offload and stage the packages in one fell swoop. For more information on the fuel-createmirror tool, read the documentation here.