WIXLIB

TECH GUIDEOpenStack Installation:A Practitioner’s Guide

IntroductionTECH GUIDE:OpenStack Installation:A Practitioner’s GuideOne of the great things about OpenStack is all the optionsyou have for deploying it – from homebrew to hosted OpenStack tovendor appliances to OpenStack-as-a-service. Previously, Platform9 publisheda tech guide comparing various OpenStack deployment models. If you opt for a doit-yourself (DIY) approach, then you face the question of which tool to use. This guide willfamiliarize you with the landscape of OpenStack installation tools, including an overview of the mostpopular ones: DevStack, RDO Packstack, OpenStack-Ansible, Fuel and TripleO.OpenStack Architecture OverviewIf you’re new to OpenStack it may be helpful to review the OpenStack components. (Skip this section if you’re already familiar withOpenStack.) OpenStack’s design, inspired by Amazon Web Services (AWS), has well-documented REST APIs that enable a self-service,elastic Infrastructure-as-a Service (IaaS) cloud. In addition, OpenStack is fundamentally agnostic to the underlying infrastructure andintegrates well with various compute, virtualization, network and storage technologies.(identity)Basic StorageBasic LI / ToolsGlanceClarity UIBlockStorageFigure 1: OpenStack architecture is loosely coupled, and extensible to support any hypervisor / container, storage, and network system2

Plan to gethelp to install & manageOpenStack?NOWant to useexistinginfrastructure?NOYESNOYESHave budgetfor ProfessionalServices?YESPrefer toown infrastructure?YESBrownfieldEnvironment?YESUse OpenStackas-a-servicePlatform9NONeed highcustomization?YESDIY OpenStack installDevStackRDO al OpenStacklifecycle management?YESNOUse hostedOpenStackIBM BlueBoxRackspaceNOUse OpenStackvendor distroUse OpenStackas-a-serviceUse OpenStackvendor distroUse OpenStackas-a-serviceRed HatRackspaceMirantisPlatform9Red HatRackspaceMirantisPlatform9NOShorttimeline to build privatecloud?YESDIY OpenStack installDevStackRDO PackstackOpenStack-AnsibleFuelTripleONOAvoidVendor lock-in?YESUse OpenStackappliancesUse OpenStackas-a-serviceCisco MetapodStratoscaleZeroStackVMware VIOPlatform9Figure 2: How to choose an OpenStack Deployment Model3

How to Choose an OpenStack Deployment ModelThe primary question that drives the choice of deployment models is whether your IT team has the expertise, and the inclination, toinstall and manage OpenStack. Depending on the desire to host your infrastructure and avoid vendor lock-in, various deploymentmodels are available. If there’s a need for a high degree of customization, along with the flexibility to choose hypervisors, then a DIYinstall is probably the best option (see highlighted section of the flowchart on previous page).If you choose DIY install, there’s a wide choice of open source tools that are very easy to use and can create environments for use indevelopment, testing or production. These tools can deploy OpenStack on bare metal, virtual machines or even containers. Someeven install OpenStack in a production-grade, highly available architecture.But which tools are best suited for your requirements? Read on for an overview of some of the most popular tools, followed by ahandy comparison matrix to summarize the options. More detailed documentation is available on each tool’s dedicated website.¹OpenStack Installation: DevStackDevStack is a series of extensible scripts used to quickly bring up a complete OpenStack environment suitable for non-productionuse. It’s used interactively as a development environment. Since DevStack installs all-in-one OpenStack environments, it can be usedto deploy OpenStack on a single VM, a physical server or a single LXC container. Each option is suitable depending on the hardwarecapacity available and the degree of isolation required. A multi-node OpenStack environment can also be deployed using DevStack,but that’s not a thoroughly tested use case.For either kind of setup, the steps involve installing a minimal version of one of the supported Linux distributions and downloading theDevStack Git repository. The repo contains a script stack.sh that must be run as a non-root user and will perform the complete installbased on configuration settings.The official approved and tested Linux distributions are Ubuntu (LTS plus current dev release), Fedora (latest and previous release) andCentOS/RHEL 7 (latest major release). The supported databases are MySQL and PostgreSQL. RabbitMQ and Qpid are the recommended messaging service along with Apache as the web server. The setup defaults to a FlatDHCP network using Nova Network or asimilar configuration in Neutron.The default services configured by DevStack are Keystone, Swift, Glance, Cinder, Nova, Nova Networking, Horizon and Heat.DevStack supports a plugin architecture to include additional services that are not included directly in the install.Summary of the Installation Process1.2.3.4.5.6.7.8.Install one of the supported Linux DistributionsDownload DevStack from gitgit clone ke any desired changes to the configurationAdd a non-root user, with sudo enabled, to run the install scriptdevstack/tools/create-stack-user.sh; su stackRun the install and go grab a coffeecd devstack/stack.sh4

Configuration OptionsDevStack provides a bunch of configuration options that can be modified as needed. The sections below summarize some of theimportant ones.local.confDevStack configuration is modified via the file local.conf. It’s a modified .ini format file that introduces a meta-section header to carryadditional information regarding the configuration files to be changed.The new header is similar to [[‘ phase ‘ ’ config–file–name ‘]]’, where phase is one of a set of phase names defined by stack.sh and config-file-name is the configuration filename. If the path of the config file does not exist, it is skipped. The file is processedstrictly in sequence and any repeated settings will override previous values.The defined phases are: local – extracts localrc from local.conf before stackrc is sourcedpost-config – runs after the layer 2 services are configured and before they are startedextra – runs after services are started and before any files in extra.d are executedpost-extra – runs after files in extra.d are executed[[post-config NOVA CONF]][DEFAULT]use syslog True[osapi v3]enabled FalseA specific meta-section local localrc is used to provide a default localrc file. This allows all custom settings for DevStack to be contained in a single file. If localrc exists it will be used instead to preserve backward compatibility.[[local localrc]]FIXED RANGE 10.20.30.40/49ADMIN PASSWORD secretLOGFILE DEST/logs/stack.sh.log5

openrcopenrc configures login credentials suitable for use with the OpenStack command-line tools. openrc sources stackrc at the beginningin order to pick up HOST IP and/or SERVICE HOST to use in the endpoints. The values shown below are the default values.OS PROJECT NAME demoOS USERNAME demoOS PASSWORD secret #The usual cautions about putting passwords in environment variables applyHOST IP 127.0.0.1 #Typically set in thelocalrc sectionSERVICE HOST HOST IPOS AUTH URL http:// SERVICE HOST:5000/v2.0#commented out by default# export KEYSTONECLIENT DEBUG 1# export NOVACLIENT DEBUG 1Minimal ConfigurationWhile stack.sh can run without a localrc section in local.conf, it’s easier to repeat installs by setting a few minimal variables. Below is anexample of a minimal configuration for values that are often modified. Note: if the * PASSWORD variables are not set, the install scriptwill prompt for values: No loggingPre-set the passwords to prevent interactive promptsMove network ranges away from the local networkSet the host IP if detection is unreliable[[local localrc]]ADMIN PASSWORD secretDATABASE PASSWORD ADMIN PASSWORDRABBIT PASSWORD ADMIN PASSWORDSERVICE PASSWORD ADMIN PASSWORD#FIXED RANGE 172.31.1.0/24#FLOATING RANGE 192.168.20.0/25#HOST IP 10.3.4.5# export NOVACLIENT DEBUG 1Service RepositoriesThe Git repositories used to check out the source for each service are controlled by a pair of variables set for each service. * REPOpoints to the repository and * BRANCH selects which branch to check out. These may be overridden in local.conf to pull source from adifferent repo. GIT BASE points to the primary repository server.NOVA REPO GIT BASE/openstack/nova.gitNOVA BRANCH master6

The installation directory defaults to /opt/stack and can be set by the DEST parameter.DEST /opt/stackLoggingBy default stack.sh output is only written to the console where it runs. It can be sent to a file in addition to the console by settingLOGFILE to the fully qualified name of the destination log file. Old log files are cleaned automatically if LOGDAYS is set to the number ofdays to keep old log files.DevStack will log the stdout output of the services it starts. When using screen this logs the output in the screen windows to a file.Without screen this simply redirects stdout of the service process to a file in LOGDIR. Some of the project logs will be colorized bydefault and can be turned off as below.LOGFILE DEST/logs/stack.sh.logLOGDAYS 1LOG COLOR FalseLOGDIR DEST/logsLogging all services to a single syslog can be convenient. If the destination log host is not localhost, the settings below can be used todirect the message stream to the log host.SYSLOG TrueSYSLOG HOST HOST IPSYSLOG PORT 516Database BackendThe available databases are defined in the lib/databases directory. MySQL is the default database but can be replaced in thelocalrc section:disable service mysqlenable service postgresqlMessaging BackendSupport for RabbitMQ is included. Additional messaging backends may be available via external plugins. Enabling or disablingRabbitMQ is handled via the usual service functionsdisable service rabbit7

Apache FrontendThe Apache web server can be enabled for wsgi services that support being deployed under HTTPD mod wsgi. Each service thatcan be run under HTTPD mod wsgi also has an override toggle available that can be set. See examples below.KEYSTONE USE MOD WSGI ”True”NOVA USE MOD WSGI ”True”Clean InstallBy default stack.sh only clones the project repos if they do not exist in DEST. This can be overridden as below and avoids having tomanually remove repos to get the current branch from GIT BASE.RECLONE yesGuest ImagesImages provided in URLS, via the comma-separated IMAGE URLS variable, will be downloaded and uploaded to glance by DevStack.Default guest images are predefined for each type of hypervisor and their testing requirements in stack.sh and can be overriddenas below.DOWNLOAD DEFAULT IMAGES FalseIMAGE URLS ”http://pf9.com/image1.qcow,”IMAGE URLS ”http://pf9.com/image2.qcow”Instance TypeDEFAULT INSTANCE TYPE can be used to configure the default instance type. When this parameter is not specified, DevStack createsadditional micro and nano flavors for really small instances to run Tempest tests.DEFAULT INSTANCE TYPE m1.tinyCinderThe logical volume group, logical volume name prefix and the size of the volume backing file are set as below.VOLUME GROUP ”stack-volumes”VOLUME NAME PREFIX ”volume-”VOLUME BACKING FILE SIZE 10250M8