Openstack Training On Cloud & Bigdata Analytics

OPENSTACK TRAINING ON CLOUD & BIGDATA ANALYTICS
12-5-2015 &
13-5-2015
TEQIP II Sponsored Faculty Development Programme

On
Hands on Cloud & Big Data Analytics
12.5.2015 to 25.5.2105
ORGANIZED BY
DEPARTMENT OF INFORMATION TECHNOLOGY
ANNA UNIVERSITY, BIT CAMPUS TIRUCHIRAPPALLI-620024
Web:www.annauniv.edu/www.aubit.edu.in
Chief Patron
Dr. M. Rajaram, Ph.D.,
Vice-Chancellor, Anna University, Chennai.
Patron
Dr. S. Ganesan
Registrar Anna University, Chennai.
Chair
Convener
Dr. T.Senthilkumar
Mr. D. Venkatesan
The Dean, BIT Campus, Anna University,
Professor and HoD IT/CSE,
Tiruchirappalli.
BIT Campus, Anna University, Tiruchirappalli.
Coordinators
Organizing Committee Members
Mrs. S. Usha , Mrs. C. Usharani
Mr. T. JaisonVimalraj, TF
Assistant Professors, Department of CSE/IT ,
Mr. R. Nandhikesavan, TF
BIT Campus, Anna University, Tiruchirappalli.
Mr. R.DeepanChakkaravarthy, TF
Resource Person
(Cloud Openstack Session on 12-May-2015 and 13-May-2015)
Mr.D.Kesavaraja M.E ,M.B.A,(PhD),MISTE,AMIE
Assistant Professor/CSE ,
Dr.Sivanthi Aditanar College of Engineering ,Tiruchendur
Mail : admin@k7cloud.in
Mobile : +91 9865213214
Website : www.k7cloud.in
Presented By Mr.D.Kesavaraja; Organized By DEPARTMENT OF IT ,ANNA UNIVERSITY, BIT CAMPUS TIRUCHIRAPPALLI
Page 1
12-5-2015 &
13-5-2015
OPENSTACK TRAINING
ON
CLOUD & BIGDATA ANALYTICS
[Live Hands On Openstack Juno version with Packstack , Rdo , Nova , Swift And Neutron ]
12-May-2015 and 13-May-2015

Objectives (TwoDays Hands on Session):
Describe the Basic Structure of Cloud

Implement OpenStack in Cent OS -7 (GNOME or KDE)
Describe the architecture of an Open Stack Cloud deployment
Installation PackStack and RDO
Open Issues Discussion and Workaround
Define the key features of Open Stack
Identify suitable use-cases for Open Stack
Implement and use Image, Identity, and Dashboard services
Create and manage images and instances
Create and manage roles, users and quotas
Find additional Open Stack help and support resources
Use the CLI and Dashboard
Nova, SWIFT and Neutron Hands on Demo on Single Node Openstack
AGENDA
Day 1 (12-May-2015)
SESSION 1 [Open Stack Introduction ] TIME: 10:00 AM TO 12:30 PM
What is OpenStack?
Case Study (Real Time)
What are three Service models and OpenStack IaaS?
Juno , Kilo
OpenStack Components
OpenStack Arhitecture
OpenStack Releases
OpenStack Network Model
Hands on - Cent OS 7 GNOME or KDE Installation
Hands on - Firewall Configuration , GRUB Config
Hands on - DHCP / Static IP Configuration
Hands on - Firewall Access to Enable Port
Nova architecture overview

Overlays vs Physical Networks
Network Abstractions at Different Layers
Neutron: The OpenStack Networking
Application-centric Abstractions for Neutron: Policy Extension Framework
Application-centric Network Policies
Hands on - Installing Open Stack with Pack Stack and RDO
SESSION 2 [Open Stack Deployment PackStack and RDO , Key Stone]

TIME: 1:30 AM TO 4:30 PM
Page 2
12-5-2015 &
13-5-2015
Hands-on Setting and Configuring your own Cloud

Hands on -Add the dashboard
Hands on - Install and configure - Verify
operation .
Hands on - Open Issues and Workarounds
Practices
Hands on - KeyStone
Hands on - Key Creation rsa [Public and Private Key]
Day 2 (13-May-2015)
SESSION 3 [NOVA , GLANCE & SWIFT ] TIME: 10:00 AM TO 12:30 PM
Dashboard walkthrough
Add the Block Storage service - OpenStack Block
Storage
Hands on - Install and configure controller node
Hands on - Install and configure a storage node
Hands on - Verify operation
Hands on -Add Object Storage - OpenStack Object Storage
Hands on - SSH , CURL , VNC , RDesktop
Hands on - Add the Identity service
Hands on - Add the Image Service
Hands on - Add the Compute service
Hands on - Replication - SWIFT
Demo - Security/ACLs
SESSION 4 [Modeling application connectivity in Nova vs Neutron]
TIME: 1:30 AM TO 4:30 PM
Hands on -Configuring Router from the CLI

Hands on - Configuring Router from the
Dashboard
Hands on - Provisioning router interfaces
Hands on - Exploring the OpenStack
integration
Hands on - Distributed Virtual Routing Service
Distributed InTRA-Tenant Routing
Hands on - Adding ip interfaces to tenant router
Hands on - Hybrid Solution
Network Abstractions at Different Layers of the Stack
Hands on Java and Python Deploying Application
Hands on - Live Experiments
E-Resources , Forums and Groups.
Discussion and Clarifications
Knowing is not enough

We must apply
Willing is not enough
We must do
More Details Visit : www.k7cloud.in

: http://k7training.blogspot.in
Page 3
12-5-2015 &
13-5-2015
TUTORIALS:
1. Adding New Custom Boot Images
2.
Launching a VM from a Boot Image
3.
Creating a Block Storage Volume
4.
Attaching and Using Volumes
5.
Creating new VM Flavors
6.
Setting Up a project
7.
Murano in a Minute
8.
Mirantis OpenStack Express VPN-as-a-Service
9.
Running OpenStack from the Command Line
10.
Automating VM Launch and Apache Installation
11.
Intro to Object Store
12.
REST Access to Object Store
13.
Intro to Heat Orchestration
14.
Installing OpenStack CLI Clients
Page 4
12-5-2015 &
13-5-2015
RDO Quickstart
Deploying RDO is a quick and easy process. Setting up an OpenStack cloud takes
approximately 15 minutes, and can be as short as 3 steps.
Below, we'll explain how to set up OpenStack on a single server. You'll be able
to add more nodes to your OpenStack cloud later, if you choose.
If you just want to try it out without installing anything, check out TryStack. See
also Installation for alternate deployment methods.
These instructions are to install the current ("Juno") release.
Step 0: Prerequisites
Software: Red Hat Enterprise Linux (RHEL) 7 is the minimum recommended
version, or the equivalent version of one of the RHEL-based Linux distributions such
as CentOS, Scientific Linux, etc., or Fedora 20 or later. x86_64 is currently the only
supported architecture. See also RDO repository info for details on required
repositories. Please name the host with a fully qualified domain name rather than a
short-form name to avoid DNS issues with Packstack.
Fedora 21 is still in development and running RDO Juno on Fedora 21 is
not recommended at this time. A separate announcement will be made on
the rdo-list mailing list when RDO Juno on Fedora 21 is ready.
Hardware: Machine with at least 2GB RAM, processors with hardware virtualization
extensions, and at least one network adapter.
In case your system is running with NetworkManager, you need to disable it.
Stop and disable NetworkManager:
systemctl stop NetworkManager
systemctl disable NetworkManager
systemctl enable network
Make sure devices are named properly for the network daemon: i.e. the following
line must be present in /etc/sysconfig/network-scripts/ifcfg-<interface_name>
DEVICE="<interface_name>"
where <interface_name> is usually "eth0" or "em1".
Take down all interfaces (but the one via you're connected to the machine) with:
ifdown <interface_name>
Start the network daemon:
ifdown <interface_name> && systemctl start network
Step 1: Software repositories
Update your current packages:
sudo yum update -y
Setup the RDO repositories:
sudo yum install -y https://rdo.fedorapeople.org/rdo-release.rpm
Looking for Icehouse? Use http://rdo.fedorapeople.org/openstack-icehouse/rdorelease-icehouse.rpm instead. Looking for an older version?
See http://rdo.fedorapeople.org/ for the full listing.
Page 5
12-5-2015 &
13-5-2015
Step 2: Install Packstack Installer

sudo yum install -y openstack-packstack
Step 3: Run Packstack to install OpenStack
Packstack takes the work out of manually setting up OpenStack. For a single node
OpenStack deployment, run the following command.
packstack --allinone
If you encounter failures, see the Workarounds page for tips.
If you have run packstack previously, there will be a file in your home directory
named something like packstack-answers-20130722-153728.txt You will probably
want to use that file again, using the --answer-file option, so that any passwords
you've already set (eg, mysql) will be reused.
The installer will ask you to enter the root password for each host node you are
installing on the network, to enable remote configuration of the host so it can
remotely configure each node using Puppet.
Once the process is complete, you can log in to the OpenStack web interface
"Horizon" by going tohttp://$YOURIP/dashboard. The username is "admin". The
password can be found in the file keystonerc_admin in the /root/ directory of the
control node.
Next Steps
Now that your single node OpenStack instance is up and running, you can read on
about running an instance, configuring afloating IP range, configuring RDO to work
with your existing network, or about expanding your installation by adding a
compute node.
Mirantis OpenStack Express
Mirantis Private Cloud as a Service is the fastest way to get your hands on a
fully-functional, optimally-configured, private OpenStack cloud, running on hosted
bare metal and able to scale on demand.
Basic Cloud Operations: Adding New Custom Boot Images
Step by Step
Getting into Mirantis OpenStack Express is simple: just log in the home screen
shows server usage and cluster locations, and provides links and authentication for
the Horizon console associated with each of your OpenStack clouds.
Page 6
12-5-2015 &
13-5-2015
The Mirantis OpenStack Express 2.0 Dashboard shows your clouds

location(s) and provides authentication and links into the Horizon user
interfaces used to manage them.
OpenStack Express 2.0 comes with several default cloud server images already in
place, that work with the default Q-Emu hypervisor. The default images are useful
variations on the Ubuntu 14.04 LTS cloud image maintained by Canonical. Most are
in QCOW2 format that Q-Emu supports. The Xen and KVM hypervisors can also boot
VMs from QCOW2 images, as can Oracle VirtualBox and other desktop virtualization
frameworks.
Mirantis OpenStack Express Horizon UI shows pre-configured Ubuntu

14.04 LTS and other images, ready for convenient use.
Its also easy to add new cloud server images from .img, .iso, and compressed tar.gz
files maintained by Linux providers and communities. These can be retrieved by
Horizon via URL and imported into OpenStack Express. The versions linked
at OpenStack Documentation Chapter 2, Get images should work well with
OpenStack Express. Images linked here have been built with cloud-init, a component
that enables SSH key and user instance data injection so that instances made with
Page 7
12-5-2015 &
13-5-2015
this image can be configured at launch. Well see this process in our next blog post
on Mirantis OpenStack Express, where well launch an instance from an image.
OpenStack documentation offers a chapter on Getting Images, where links

to compatible image files can be found.
For our current purpose importing an image well use CirrOS, a very light,
cloud-oriented Linux distro, useful for testing. Well start by right-clicking the URL
and copying it. Then well return to Horizon console for our Mirantis OpenStack
Express 2.0 cloud and choose Project -> Images -> Create Image. A simple dialog
box appears.
A simple dialog box lets you configure and import a new image file from a
remote target URL.
Name your image, then paste the source URL into the Image Location slot provided.
MOX 2.0 Horizon can consume images in .iso, .img, and tar.gz compressed file
formats.
Page 8
12-5-2015 &
13-5-2015
The import system can handle a range of common image file formats, both
uncompressed and compressed.
Paste the remote image location URL into the slot provided.
Pick the image hypervisor format from the Format dropdown In this case, were
picking QCOW2.
Page 9
12-5-2015 &
13-5-2015
A wide range of image formats is supported. In this case, were picking

QCOW2 the QEMU Copy-On-Write dynamic format, recommended for
use with the QEMU hypervisor.
Identify minimum disk and RAM sizes to let this image run comfortably, click Public
availability, then Create Image and let MOX download, store and create your new
guest image.
Fill in remaining fields with reasonable minimum values for RAM and
ephemeral disk space, then click Create Image to begin the import
process.
Page 10
12-5-2015 &
13-5-2015
Depending on image file size, import and conversion may take a few
seconds to a few minutes.
Depending on the size of the source file and download time, this can be very rapid
larger boot images take a couple of minutes to transfer and become available.
A successful import concludes, leaving us with a functional Cirros image

that we can now use to configure and launch VM instances.
Page 11
12-5-2015 &
13-5-2015
Launching a VM from a Boot Image

Step by Step
The OpenStack Horizon UI accessible under MOX 2.0 makes it very easy to configure
and launch VM instances. Just go to Projects -> Compute -> Access and Security,
click the Keypairs tab, and you can name and generate a new SSH keypair on the
fly, downloading the .pem file, containing the private key, to your desktop.
Mirantis OpenStack Express 2.0 instances are generally accessed via SSH
using keypair authentication, rather than username/password login. MOX
2.0 Horizon can generate an SSH keypair for you, letting you download the
Private key for use with your SSH client.
MOS Horizon will record the keypair and present its name and fingerprint. Keypairs
stored here will be offered in a popdown list, letting you select from among them to
configure authentication on new instances at time of creation.
Page 12
12-5-2015 &
13-5-2015
Mirantis OpenStack Express 2.0 Horizon stores your keypairs, so they can
be associated with single or multiple instances at launch.
If you use Linux with openssh, you can use the ssh-keygen command to generate a
keypair.
You can also create your own keypairs and upload them. In Linux with
openssh, this is done using the ssh-keygen command.
Page 13
12-5-2015 &
13-5-2015
Then open the plaintext public key file and copy the contents.
Open the plaintext public key file and copy its contents. Here, were using
gedit.
Then choose Import Key to name the keypair and copy the public portion to Horizon.
Page 14
12-5-2015 &
13-5-2015
Name your keypair and copy the public key to Horizon. MOX 2.0 Horizon
will import your key and add it to the tabs and popdowns for configuring
authentication on new instances.
Now that youve taken care of access security, you can launch a new VM instance
from your image. Click on the Launch button, pick a name, and pick a flavor for this
VM. Flavors are a quick way to select disk and RAM sizes and number of vCPUs. You
can create custom flavors.
Click launch against your image to begin the process of configuring and
launching a VM instance.
Page 15
12-5-2015 &
13-5-2015
The first tab of the Launch dialog lets you name your instance, and set
basic parameters, including choosing a flavor for your VM. Flavors are a
way of packaging platform model criteria like amount of RAM and number
of vCPUs, and you can create your own. Note that Horizon will not display
available flavors that dont satisfy image minimum requirements.
On the Access and Security tab, specify the SSH keypair you want to use to access
this instance.
Page 16
12-5-2015 &
13-5-2015
On the Access and Security tab, select the keypair you want to use to
authenticate to the instance.
On the Networking tab, drag and drop the basic networking model, which will
connect the new VM to the internal network, but not give it a public-facing IP
address.
On the Networking tab, drag and drop the basic networking model.
Page 17
12-5-2015 &
13-5-2015
Click Launch. In just seconds, your new instance will be spawned.
Click Launch. Your new instance will begin to spawn and will normally
become Active within a few seconds.
To prepare to access your new instance from the public internet, you begin by
associating a Floating IP address with it, via the topmost option in the instances
More menu. The new IP address appears in the list of IPs associated with the
instance.
Page 18
12-5-2015 &
13-5-2015
Associate a floating IP with your instance, visible from the public net.
Select from available floating IPs to associate one to your instances base
port.
Page 19
12-5-2015 &
13-5-2015
The newly-associated IP is displayed with the instance, for easy reference.

To log into your VM instance, you can use SSH, the associated keypair, and the
default username for this image in this case, thats cirros pointing SSH to the
floating IP address youve just assigned.
Page 20
12-5-2015 &
13-5-2015
Use SSH to access your instance. Here, were using the standard Linux ssh
client with the -i flag and your keypair. Aim for the default username for
your instance, using your public-facing floating IP.
To do this from a Windows PC using the popular free SSH client, PuTTY, begin by
using the companion application, PuTTYGen, to load the .pem file, then save the
private key in PuTTYs .ppk format, as shown here.
To access from a Windows PC running PuTTY, begin by loading and

converting the downloaded .pem file to .ppk format, with the PuttyGen
utility.
Then configure a PuTTY session, using the floating IP address as the target, then
click Auth and browse to the .ppk file. Launch PuTTY, and your session will
authenticate. Enter cirros as the username.
Page 21
12-5-2015 &
13-5-2015
Configure a PuTTY session, aimed at the floating IP of your instance.
Browse to the .ppk file created above under the Auth heading of the SSH
menu, under Connection, to set your private key.
Page 22
12-5-2015 &
13-5-2015
Click Open and PuTTY will authenticate to your instance. Were here using
cirros as the username.
You can also access Cirros and other appropriately-configured instances from the
Horizon VNC console, with username/password authentication. In this case, the
default username is cirros and the default password is cubswin:).
Page 23
12-5-2015 &
13-5-2015
You can also log into appropriately-configured instances using Mirantis

OpenStack Express Horizons VNC console, username/password
authentication.
Now that we know how to configure and launch an instance from an image, and
how to access it securely afterward, our upcoming videos will examine Mirantis
OpenStack Express 2.0 features for configuring and attaching block storage volumes.
Step by Step
To create a new block storage volume, well use Mirantis OpenStack Express Horizon
well go to Projects -> Volumes -> Create Volume and pull up the dialog.
Mirantis OpenStack Express 2.0 lets you easily create block storage
volumes and manage them separately from instances. By creating,
attaching, modifying and snapshotting storage volumes, you can create a
library of building blocks for applications.
Name your volume, then ignoring the Type field specify the size in GB. As you
can see, Mirantis OpenStack Express/Horizon keeps track of your usage, and the
number of volumes youve defined.
You can specify the contents of a volume by uploading an .iso image. But since this
is a new volume, well create it empty.
Well add the volume to the nova-compute availability zone, so we can attach it to
instances running there, like our Cirros VM.
Once the volume is created, you can see it in the Volumes table.
Page 24
12-5-2015 &
13-5-2015
You can keep track of all the volumes youve created in Horizons Volumes
table.
Now that we know how to create a volume, our next video will explore attaching it
to an instance, configuring it for use, and using snapshots to store its state.

Step by Step
To create a new block storage volume, well use Mirantis OpenStack Express Horizon
well go to Projects -> Volumes -> Create Volume and pull up the dialog.
Page 25
12-5-2015 &
13-5-2015
Mirantis OpenStack Express 2.0 lets you easily create block storage
volumes and manage them separately from instances. By creating,
attaching, modifying and snapshotting storage volumes, you can create a
library of building blocks for applications.
Name your volume, then ignoring the Type field specify the size in GB. As you
can see, Mirantis OpenStack Express/Horizon keeps track of your usage, and the
number of volumes youve defined.
You can specify the contents of a volume by uploading an .iso image. But since this
is a new volume, well create it empty.
Well add the volume to the nova-compute availability zone, so we can attach it to
instances running there, like our Cirros VM.
Once the volume is created, you can see it in the Volumes table.
Page 26
12-5-2015 &
13-5-2015
You can keep track of all the volumes youve created in Horizons Volumes
table.
Now that we know how to create a volume, our next video will explore attaching it
to an instance, configuring it for use, and using snapshots to store its state.
Creating New VM Flavors
Step by Step
Mirantis OpenStack Express lets you define flavors from the Admin menu.
As you can see from the illustration, OpenStack defines five standard machine
flavors for you, ranging from an m1.tiny model with 1 vCPU, 512MB RAM and a 1GB
root disk, to an m1.xlarge with eight virtual processors, 16GB RAM and a 160GB
disk.
Page 27
12-5-2015 &
13-5-2015
Mirantis OpenStack Express 2.0 lets you create custom flavors: templates
for defining the VMs in which you can launch images. Five basic flavors are
predefined: from an m1.tiny minimal machine, to a m1.xlarge
multiprocessor VM with lots of RAM and hard disk.
These are useful for many straightforward applications. But a little imagination can
show why having the ability to add custom flavors can be important.
Suppose you want to create a platform for an application that needs lots of
compute, RAM and scratch space while its running, but doesnt need to maintain
stored data once an instance is terminated. Data-analysis, media transcoding,
bioinformatic apps might fit this profile.
You can use flavors to create a new machine type for this hypothetical application.
Click Create New Flavor, and give it a name lets call it m1.amnesia-engine.
Page 28
12-5-2015 &
13-5-2015
To create a new flavor, state your requirements in the dialog. Here, were
defining a flavor called m1.amnesia-engine a multiprocessor machine
with lots of RAM, but no root or swap space in volumes. Instead, were
giving our flavor 50GB of ephemeral storage, which will vanish if an
instance created with this flavor is terminated. This hypothetical flavor
might be useful for highly-parallelized data analysis.
Well give it 8 multi-core vCPUs so it can run all our vectorized code. 16GB of RAM,
so it has plenty of room to work in. Well give it no root disk, and no swap disk. But
well give it 50GB of Ephemeral disk, which is a block file storage entity that survives
restarts, but goes away when an instance is terminated: exactly what we want. This
storage will be attached to /dev/vdb of an instance launched with this flavor
template, and our app will need to quickly make a file system there and mount the
device to use it.
On the second tab of the Create Flavor dialog, we can associate this flavor just with
certain projects running on our cloud a good thing if you want to keep exotic VM
formats restricted. In this case, though, well leave this blank so the flavor is
available to all.
Page 29
12-5-2015 &
13-5-2015
The second tab of the Create Flavor dialog lets you privilege only certain
projects to use your new flavor.
Our new flavor now appears in the list. The system has assigned an ID to
it.
Now well launch a boot image with our new flavor. First, lets try to launch using the
CirrosVM image we created several lessons back. As you may recall, when we
Page 30
12-5-2015 &
13-5-2015
imported this image, we set a minimum root disk size of 2GB. OpenStack sees this,
and will not let us apply our amnesia-engine flavor to this image: an important
protection against launching things that will not work.
OpenStack will stop us from trying launching an image whose

requirements dont match those of the flavor we wish to assign to it. Well
assign different requirements to images we create, based on OS, version
and configuration.
Now lets try launching an amnesia-engine machine using an image with no
minimum root disk requirement set. We name it, we pick our new flavor, and
OpenStack approves: showing us the configuration of the instance were about to
launch. Set authentication and network parameters, and go.
Page 31
12-5-2015 &
13-5-2015
Here, a CirrOS image with no minimum root disk requirement set is an

acceptable match for our m1.amnesia-engine flavor, which uses only
Ephemeral storage.
Theres our AmnesiaEngine, ready for work. Log in with the Console
And we can execute a cat /proc/cpuinfo command to see all of the many processors
we have available.
Page 32
12-5-2015 &
13-5-2015
Visiting our new VM in Console, we can see that the flavor has resulted in
our launching an eight-processor machine.
A sudo fdisk -l command shows us the 50GB Ephemeral disk this flavor comes with,
ready for partitioning, file system creation and usage.
And we can see that our Ephemeral storage has been made accessible, on
/dev/vdb, ready for partitioning and other operations before use. Since
this is Ephemeral storage, our application will need to prepare its volume
this way, each time it starts.
Now that weve explored flavors, our next tutorial will cover higher-level
administrative tools for creating Projects and adding Users.
Setting up a Project
Step by Step
projects sometimes also called Tenants or Accounts are organizational units
that let you control access to cloud resources and manage their consumption. You
can equip project environments with specialized networking, create custom images
for their exclusive use, and perform other task-appropriate customizations.
Lets start by logging into Mirantis OpenStack Express Horizon as the admin,
navigating to Projects in the Identity Panel subtab of the Admin menu, and clicking
on Create Project.
First, give your project a name and an optional Description. Youll see a checkbox
that gives you the choice of initializing your product in an Enabled state, or not.
Thats useful if you have administrative work to do inside the project before granting
associated users access. Disabling an active project something you might try later
on can be used to bar users temporarily from accessing project resources without
terminating running instances.
Page 33
12-5-2015 &
13-5-2015
To create a new project, start by giving it a name. Note the Enabled

checkbox that lets you set whether your project will be created in a fullyenabled (thus available to users) state or not.
When you create a new project you can assign quotas for various resources:
OpenStack will prevent users of the project from going over these limits. But these
arent the only quotas OpenStack makes available for customization and fine-tuning:
you can access more from the command-line interface. Users, too, can be given
quotas with respect to projects well cover quotas in detail in a future tutorial.
Meanwhile, the defaults Mirantis OpenStack Express puts in place are generally
sensible they make some resource allocations fixed and others not the latter
are parameterized with a -1.
Page 34
12-5-2015 &
13-5-2015
The Quota tab lets you set project quotas though these are just a subset
of quotas that can be set from the command line. Using the command line,
users, too, can be given quotas with respect to projects. In enforcing
overlapping quotas, OpenStack resolves differences, insuring that the
most-restrictive relevant quota is applied in any situation.
You can also assign users to the project from the project Members tab. For now,
were going to make sure the admin user has access. In a moment, well create a
new user and add them to the project. Meanwhile, lets finish creating the project.
Page 35
12-5-2015 &
13-5-2015
Adding users to your new project. Here, we add the admin user less, in
this case, as a permission, and more to permit accurate usage recordkeeping.
Youll notice that OpenStack seems to throw an error here, though it also reports
successful project creation. This simply means that we left the default quotas in
place, some of which were specified as unlimited.
Page 36
12-5-2015 &
13-5-2015
Our project is created. Note that OpenStack throws what appears to be an

error message, here, because we left certain project quotas set to permit
unlimited usage. In Mirantis OpenStack Express, default quotas are set
sensibly, however, with critical resources automatically parceled out
among projects fairly.
Now that we have a project, lets go to the Users tab and create a user. Give the
user a name, insert their email, and specify a password. Associate them to the
project we just created, and give them a Member role. The + button, here, raises
the Create Project dialog: we can create projects from the Create User interface.
Click create user.
Creating a new user. We can add them to a project at this step.

Now lets switch to our new project as the admin user, by clicking on the popdown in
the upper left.
As you can see, the Horizon display is now a little different. We dont have access to
high-level administrative functions. No instances are active yet. Were seeing a
more-limited view of the system.
Page 37
12-5-2015 &
13-5-2015
Switching to our new project as the admin user. In Overview, we now see
the projects activity (none yet), rather than the clouds as a whole.
Certain things are in place for us. For example, Mirantis OpenStack standard boot
images are all defined as Public, so we can use them.
But we switch to the Network tab, look at topology, and see that we have no
network, except for the net04_ext external, public network, owned by the Admin.
Thats a problem, because we cant start VMs without a local network and a subnet.
And we cant do much with VMs unless we can reach them from the internet.
So were going to quickly make a new network under Neutron thats functionally
identical to the default network at toplevel configured by Mirantis OpenStack
Expresss Fuel installer, when our cloud was deployed.
Page 38
12-5-2015 &
13-5-2015
Though we have access to resources shared by admin with our project,

and to resources designated Public, such as Mirantis OpenStack Express
default boot images (or shared by admin with our project), our project still
starts up unconfigured. Here, we see that the project has access to the
net04_ext shared external network. So we need to build a local network
for VMs, and attach it to the external network via a router.
Page 39
12-5-2015 &
13-5-2015
Starting to create a new network the Create Network button is also

available from the Network Topology display.
First, we go to Networks, and we create a new network, giving it a name.
Naming our new local network.

Then well specify a subnet, naming that as well, and specifying a local IP address
range thats convenient, using CIDR notation. The conventional choice here is
something like 192.168.0.0/24.
Since we want our VMs to have internet access, well also configure a gateway
address the corresponding default is 192.168.0.1, which Horizon will use if we
leave this field blank.
Page 40
12-5-2015 &
13-5-2015
Creating a subnet and setting IP address ranges and the gateway address.
We could add additional configuration details, but theyre not needed for
the simple network were creating.
Page 41
12-5-2015 &
13-5-2015
Our network and its associated subnet are created.

Now well create a Router to connect our local subnet to the shared external
network. Here, all we have to do to start is give it a name, to start.
Creating a router: start by giving it a name.

Then we can click the Set Gateway button, and point it to the net04_ext external
network.
Page 42
12-5-2015 &
13-5-2015
Use the Set Gateway button to pop a dialog letting you point the router
towards the external network.
You can see the accessible external network in the popdown.

And finally, we can click the Routers name and add an interface to our local
network, bridging that to the external one.
Page 43
12-5-2015 &
13-5-2015
Click the name of your new router to view its detail page and create
interfaces.
Click the Add Interface button to create a new interface, connecting the
router to our local network.
Page 44
12-5-2015 &
13-5-2015
We can select our local network from the dialogs popdown.
The Network Topology display now shows our local network, connected
via router to the net04_ext external network.
One last step, which can save you some head-scratching. When a project is created,
it inherits the default security group with only the default settings. So to make VMs
accessible via SSH from the internet, youll need to visit Access & Security->Security
Page 45
12-5-2015 &
13-5-2015
Groups and edit the default groups rules, adding an inbound rule that allows traffic
on port 22.
We still cant access VMs from the internet, though, until we modify the
new projects plain vanilla Security Groups rules.
Adding a new Ingress rule, permitting traffic on port 22 (SSH).

Page 46
12-5-2015 &
13-5-2015
Our new rule is added to the default security group rule-set.

Now we can make VMs nternet accessible by giving them floating IP addresses from
the external network pool. Does it work? Lets start a VM, give it a floating IP, and
see if we can connect to it. Success!
Page 47
12-5-2015 &
13-5-2015
Now that weve done all our housekeeping, appropriately-configured VMs

launched within the project and given a floating IP address can be
accessed remotely via SSH, with the appropriate keypair.
Finally, lets log out of Horizon, and then back in, as the project user we created. As
you can see, were taken directly to the projects Overview, and have no option to
switch projects: this is now our environment.
Logging into Horizon as our new project user, we can see the more-limited
view users have of our cloud.
Murano (Application Catalog) in a Minute
Step by Step
Murano comes installed and ready to use by default in starter Mirantis OpenStack
Express clouds, and can be deployed by Fuel automatically in any further clouds you
create in your Mirantis OpenStack Express datacenters.
Page 48
12-5-2015 &
13-5-2015
The Fuel deployment engine makes it easy to add Murano when creating
new clouds on Mirantis OpenStack Express.
It lets cloud operators or application makers package up the applications, installation
and configuration details, and prepare a range of lightly-modified cloud images to
host them thats the complicated part.
Page 49
12-5-2015 &
13-5-2015
Available Murano application packages for this installation appear in a

table. New packages can be composed offline and uploaded.
Specially-created images incorporating the Murano client and other

configurational optimizations must be provided to interoperate with
Murano for automated application deployment and management. Tools
like guestfish can be used to create these images, before uploading to
Glance.
And then it offers a UI that lets almost anyone assemble an application platform out
of these component parts, creating a so-called environment, and then deploy this
environment as an instance, and use it.
That makes Murano pretty great: Its a tool for automation; for self-service
provisioning; and in principle, its also a pathway for getting open source applications
to people in immediately-usable forms.
To install Murano on a Mirantis OpenStack Express cluster, you can select it from
Fuels special projects menu as shown above. Deployment details are managed
automatically.
Inside the Horizon console of an OpenStack Express cloud, Murano is accessed from
a tab at the very bottom of the left-hand menu.
Page 50
12-5-2015 &
13-5-2015
A tab at the bottom left of the Horizon administration menu gives access
to the Murano system.
Click the applications tab. Applications currently available in Mirantis OpenStack
Express Murano are still somewhat limited, but include components of standard web
development environments, the PostGre database and some other useful tools. More
applications are on the way.
Page 51
12-5-2015 &
13-5-2015
Applications presently available in Murano comprise basic tools for web

server and development platform creation. Apps can be Quick-Deployed
into new Environments at the touch of a button.
Apps in the Murano catalog can be quick-deployed on an individual basis as
components of Murano environments. Lets make an Apache web server by clicking
the Quick Deploy button. Give the Apache component a name, and select options.
Here, well choose to install PHP with Apache, and configure the component to
assign a floating IP address to an instance created with it, so we can reach our web
server from the internet. We could do this post-deployment as well on the instance,
itself.
Page 52
12-5-2015 &
13-5-2015
Beginning the Quick-Deploy process, we provide a name for the Apache

component, and indicate that we want PHP installed, and that when
started as an instance, this environment should be given a floating IP for
internet access.
On the next dialog, choose a VM flavor note that were prompted to choose the
m1.medium flavor or higher. And choose a deployment image: our only choice here
is the Ubuntu 14.04 LTS image provided in MOX by default this image has been
preconfigured with Murano client components. You can create your own Muranocompatible images and upload them to Glance.
Page 53
12-5-2015 &
13-5-2015
In the next dialog, we choose a VM flavor and provide other information

defining our requirements for virtual machines on which this environment
should be deployed.
Once the component is created, we see its become a component of a Murano
environment created to hold it, called quick-env-1. The Topology tab shows us an
in this case, very basic diagram of our Apache/PHP components relation to its
proposed host.
Page 54
12-5-2015 &
13-5-2015
Our Apache webserver is now deployed as a component of a new, autocreated Murano environment, called quick-env-1.
The Topology tab shows us an elastic diagram of the relationship between

our component and the infrastructure it runs on.
Lets look at the quick-env-1 environment. Despite the Configuring label, this
environment is now ready to deploy as an instance. As the environments right-hand
Page 55
12-5-2015 &
13-5-2015
menu also shows, we can review a table of existing deployments of this environment
as a management tool.
We can now deploy this environment, creating a usable Apache webserver

on Ubuntu.
Click Deploy Environment and an instance is created for us. This takes some time, as
the software is installed and configured.
Page 56
12-5-2015 &
13-5-2015
Deployment is successful: our environment is now spun up as an instance,

visible in the instance table.
When deployment finishes, we can access our servers floating IP from the table of
running instances. Visiting it in a browser demonstrates that Apache has been
installed and is running correctly.
Once our instance enters the Active state, we can browse to its floating IP
address, which will display the Apache start page for Ubuntu installations.
In a near-future tutorial, well explore using Murano to create more complex
environments, and eventually explore how to add new applications to the Murano
catalog.
VPN-as-a-Service (VPNaaS) Step by Step
Page 57
12-5-2015 &
13-5-2015
Step by Step
To demo this capability, Ive set up two, completely-separate OpenStack
environments in MOX one representing the premise datacenter, the other a
hosted cloud. In a future demo, Ill show how its now also possible to link an actual
on-premise OpenStack cloud to a Mirantis OpenStack Express cloud, though this
currently requires use of neutron command-line or REST functions, and is ideally
done with the help of scripts to simplify the process.
Mirantis OpenStack Express, meanwhile, has made it simple. Within each
environment, Ive set up a Project also called a Tenant. Thats an OpenStack
construct for isolating tenant resources and activities inside a cluster. You can use a
Project to give your users access to designated resources, to give them roles that
define their powers and to prevent them from seeing parts of the Project and cloud
theyre not permissioned for. Under most OpenStack networking regimes (other than
the simplified, flat model these environments use Neutron VLAN-based
networking), a project can have its own private networks, subnets, and router
gateways.
Thats what Ive built here, in each cluster. First, I created a Project we have
DemoProject 1 on Environment 1, and DemoProject 2 on Environment 2. Then I
made the Admin user of each environment a member of the respective Project and
gave each of them the admin role within that Project. This is important for setting up
VPNaaS, since router gateway IP addresses and other info youll need to set up your
VPN connection are visible only to the admin user.
To demo VPNaaS, I created two OpenStack clouds on Mirantis OpenStack

Express, and in each of them, created a Project, and added the admin user
to the Project in the Admin role. This insures that, when Im inside the
Page 58
12-5-2015 &
13-5-2015
project as the Admin, Im permissioned to see everything I need to see, to

set up the VPN connection (e.g., router external gateway IP addresses and
other details). This is Cloud A/DemoProject1s User table.
This is Cloud B/DemoProject2s user table. Note the admin user.

Then, switching to each project as the admin user, I built a simple local network for
it. You can see these networks from each projects Network Topology view. Each
projects network has a defined subnet, letting it serve a range of local IP addresses.
And each network has a router connecting it to the clouds public external network.
This is a plain-vanilla network setup that lets machines talk to each other and the
internet. And what VPNaaS will do is make an encrypted connection between the
public IP addresses of each tenants gateway router, so that machines in
DemoProject 1 can see machines in DemoProject 2, and vice-versa, while securing
the traffic between the two projects from prying eyes.
Page 59
12-5-2015 &
13-5-2015
Within each Project, Ive set up a basic local network, bridged to the
cloud-wide public network (and the Internet) with a router. OpenStack
Express Horizon (and Neutron networking) makes this very easy. Heres
DemoProject1s network, on Cloud A.
And here is DemoProject2s network, on Cloud B. Note the IP address

range given to the local subnet: it does not overlap with the IP address
Page 60
12-5-2015 &
13-5-2015
range on DemoProject1s local subnet (see above). This is a requirement

for VPNaaS to work.
For VPNaaS to work in connecting these subnets, the subnets need to have nonoverlapping IP address ranges. As you can see here, Ive given each subnet an
arbitrary CIDR range assignment that doesnt overlap with that of the tenant in the
other cloud. Each range contains 256 IPv4 addresses.
Once your VPN is connected, youll probably want to use a range of apps and
methods to communicate across it. So you need to be aware that when you first set
up a Project in Mirantis OpenStack Express, it gets assigned the default security
group for the cluster in its default form, which is usually restrictive. So youll
probably need to create a few additional rules in each Projects default security
group: like a general ICMP rule, enabling pings, and a port 22 TCP rule, enabling
SSH.
I also added some Ingress rules to each Projects default Security Group,
to allow pings (ICMP) and SSH traffic (TCP, port 22) to go back and forth.
Doing this first saves head-scratching later, when the VPN goes Active,
but you cant communicate.
Set up VPNaaS on Cloud A
Now lets start building our VPN hookup by clicking on VPN under Compute>Network. We get four tabs that let us set up the four elements of a VPN link: an
Internet Key Exchange (IKE) policy, an IPSec policy, a VPN Service, and an IPSec
Site Connection. We need to fill out these tabs under each Project to make the VPN
work. Protocol and policy details need to match the defaults offered are mostly
optimal. And to fill out the IPSec Site Connection tab, well need to provide each side
Page 61
12-5-2015 &
13-5-2015
of the VPN with info on the other sides public gateway IP address, and its subnet IP
address range.
Well do all of this first for DemoProject 1 on Cluster A:
Create the Internet Key Exchange Policy: The only thing recommended to
change, here, is the Encryption algorithm, which should be set to aes-256.
Setting up the Internet Key Exchange (IKE) policy for

DemoProject1/Cloud As side of the VPN connection. The only change
from the defaults is to select the recommended 256-bit AES encryption.
Names assigned to policies are arbitrary and need only be locally unique,
so Ive used the same names for components on both clouds.
Create the IPSec Policy: Same thing. The defaults are fine, though its
recommended to use aes-256 encryption.
Page 62
12-5-2015 &
13-5-2015
Setting up DemoProject1/Cloud As IPSec policy. Again, were going to use

the recommended AES-256 encryption.
Create the VPN Service: Heres where we select a router that will work as our
VPN gateway thats the local router; and picking a subnet to make visible at the
other end: thats our local subnet. As noted, the main thing to remember is that VPN
will not work if the subnets at both ends overlap.
Page 63
12-5-2015 &
13-5-2015
Adding the VPN Service definition for DemoProject1/Cloud A selecting

DemoProject1s local router and subnet range from the popdowns. Well
do the analogous thing on the other cloud.
Create IPSec Site Connection: This is the only mildly-tricky thing about setting
up a VPN using VPNaaS. We start by identifying our VPN Service, our IKE Policy and
our IPSec Policy, defined just a moment before thats easy. To finish, however,
well need to get some information about the network in DemoProject 2. So lets flip
to DemoProject 2s Horizon, making sure were logged in as the admin, so we can
see the info we need to know.
Starting to set up DemoProject1/Cloud As IPSec Site Connection. We

begin by selecting the VPN Service, IKE and IPSec policies weve just
created.
The first thing we need is the Peer gateway public IPV4 address or fully-qualified
domain name for DemoProject2s router. This can be found by going to
DemoProject2s Network tab, clicking on router, the router name, and copying the IP
address shown for the external gateway interface: its 198.11.214.23. This is the
thing you wont be able to see if youre not in the admin role for this project.
Page 64
12-5-2015 &
13-5-2015
To finish filling out DemoProject1/Cloud As IPSec Site Connection, we

need two pieces of information from DemoProject2/Cloud B. The first is
the external IP address of DemoProject2s router. We can find this by
going to DemoProject2/Cloud Bs Horizon, clicking on Routers, clicking on
the router name, and finding the IP address in the routers interface table.
This IP address goes into two slots in the IPSec Site Connection edit dialog for
DemoProject1: the first marked Peer gateway public IPv4/IPv6 Address or FQDN,
and the second marked Peer router identity for authentication (Peer ID).
Page 65
12-5-2015 &
13-5-2015
The router IP goes into two slots in DemoProject1/Cloud As IPSec Site

Connection dialog.
The second piece of info is the CIDR range for DemoProject2s subnet. Again, go to
DemoProject2s Horizon, click the Network tab, click on network, and copy the
subnet CIDR range, which is 192.168.111.0/24.
Page 66
12-5-2015 &
13-5-2015
The second piece of info we need is the IPv4 subnet address range for
DemoProject2/Cloud Bs local network. We can find that in
DemoProject2/Cloud Bs Horizon, under Networks, next to the network
name.
Well put that into the Remote Peer Subnet slot on DemoProject1s IPSec Site
Connection dialog. Then to finish setting up DemoProject1s IPSec Site Connection,
well provide a pre-shared key password same on both sides for authentication.
The rest of the parameters can be left as defaults if you change them, they
should match on both sides of the connection.
We put DemoProject2/Cloud Bs local subnet range into the Remote Peer

Subnet slot in DemoProject1/Cloud As IPSec Site Connection Dialog. We
finish by entering a pre-shared-key password, which will be the same on
both sides of the connection.
Set up VPNaaS on Cloud B
Now lets quickly set up the other end of the VPNaaS connection, over on
DemoProject 2. Well make sure protocol details and policies match.
On DemoProject2s IPSec Site Connection tab, well provide in two places the
peer gateway public IP address for DemoProject 1s router, and DemoProject 1s
subnet IP address range.
Page 67
12-5-2015 &
13-5-2015
Now we set up the same components on DemoProject2/Cloud B. Setting

up IKE Policy, IPSec Policy and VPN Service are simple. For the IPSec Site
Connection, well need the same two pieces of info from
DemoProject1/Cloud A that we needed for DemoProject2/Cloud B. Here,
were grabbing DemoProject1/Cloud As external router IP address.
Page 68
12-5-2015 &
13-5-2015
And here, were grabbing DemoProject1/Cloud As local network IP

address range.
We drop the router IP into two slots of DemoProject 2/Cloud Bs IPSec

Site Connection dialog, and supply the shared password. Then we click
Add, and the VPN sets itself up.
Once you click Add on the IPSec Site Connection tab, youll have to wait a little bit
for your VPN to go to Active status. If that doesnt happen within a few minutes,
theres probably something wrong with your settings.
If this happens, check to make sure that protocol details on both sides match, that
correct router gateway and subnet address range info for each side has been
provided in the other sides IPSec Site Connection tab, that PSK passwords match,
and that subnet IP address ranges dont overlap.
Page 69
12-5-2015 &
13-5-2015
Were connected! The IPSec Site Connection shows as Active at both ends.
Testing VPNaaS
Now, lets test. Ive created two VMs, one in each Project, and associated them with
floating IPs so I can SSH into them from my desktop. Lets look at the internal IP of
the VM on DemoProject2 (Cloud B) And then lets log into the VM on
DemoProject1 (Cloud A) and ping our new VPN friend on that internal IP address.
Remember, we set each Projects security group rules to admit ICMP traffic.
Page 70
12-5-2015 &
13-5-2015
Id previously launched two minimal VMs, one on each cloud, and given
them floating IP addresses for open net access. Here, Im picking up
the internal IP address from the VM running in DemoProject2/Cloud Bs
project.
To do that, were going to log into TestVM1, on DemoProject1/Cloud A, via

its floating IP address thats what were grabbing, here.
Page 71
12-5-2015 &
13-5-2015
It works! We log into TestVM1 on Cloud A, and we can ping

the internal (not public) IP of TestVM2 on Cloud B. That proves our VPN
can carry ICMP traffic.
Success! Finally, lets log into our friend using SSH with user/pass authentication and
pass some TCP traffic.
Page 72
12-5-2015 &
13-5-2015
Running OpenStack from the Command Line

Why the Command Line?
Why access your Mirantis OpenStack Express cloud from the command line? One
reason is to exploit the hundreds of powerful commands not available through
Horizon. (There are hundreds of commands in the complete OpenStack CommandLine Reference.)
Just as important, accessing OpenStack from the command line, and ultimately via
its REST APIs, gives you the power to automate operations. This can save you time,
and opens the door to applications like continuous-integration/continuous-delivery
(CI/CD).
Thats why Mirantis OpenStack Express gives you full root access to your private
OpenStack environments something most cloud-as-a-services dont do.
Step by Step
The fastest way to get to your clouds command line is by leapfrogging: SSH into
your Fuel Master Node, then use its authentication to log directly into your controller
node as root.
Three preparatory steps are required:
First, get the IP address of the Fuel server, plus credentials, from the
Mirantis OpenStack Express Dashboard:
From your MOX dashboard, click the Credentials link. At the bottom of the popup,
youll see an IP address for the Fuel Master Node, plus login details, for SSHing into
your Fuel server.
Page 73
12-5-2015 &
13-5-2015
You can SSH into your datacenters Fuel Master Node using the URL and
credentials on your Mirantis OpenStack Express Dashboard.
Next, use Fuel to find the fully-qualified internal domain name (FQDN) of
the controller node of the cloud you want to access:
On the same popup, right above the SSH IP, youll see a link to Fuel, along with
login details. Click the link, and if necessary, supply the username and password.
At the Fuel homepage, click the icon corresponding to the cloud you want to
access.
Under the Nodes tab, find the Controller node, and click the gear icon to the
right. This pops up a summary dialog of this nodes characteristics.
Find the FQDN of the Controller node: on my cloud, this is node-3.
The FQDN of your controller node can be found in Fuel. From the
Environments homepage, click on the cloud you want to access. Then
under Nodes, click the gear icon of the Controller. The popup that appears
will show the domain name of the Controller.
Finally, from Horizon, get the OpenStack remote control or RC script youll
use to authenticate to the OpenStack API:
Get the script by going to our clouds Horizon interface, clicking Project, Access &
Security, clicking the API Access tab, and clicking the button on the upper right,
marked Download OpenStack RC File. The toplevel RC file is called admin-openrc.sh.
Page 74
12-5-2015 &
13-5-2015
You can download an RC file to authenticate you to the OpenStack API by

downloading it from the Access & Security menus API Access tab. Each
Project (tenant) has its own.
Heres what it looks like (see below). In fact, this step is optional, since an identical
openrc script is automatically saved for you in the root directory of your Controller
node by Fuel. But were going through the process anyway, so you can see how it
works in other spins of OpenStack you may encounter, and later, if you want to
authenticate in the context of tenant projects.
Page 75
12-5-2015 &
13-5-2015
The RC file sets authentication parameters into your environment when

youre on the Controller node, so you dont have to enter them for every
command. We dont actually need this file to administer our cloud from
toplevel, because an identical file is saved in the root of the Controller by
Fuel at deployment time, for your convenience. Knowing about obtaining
and moving RC files, however, will help if you want to authenticate in the
context of specific projects, as users other than Admin.
The next steps involve leapfrogging via SCP and SSH from your desktop to the Fuel
server, and then from the Fuel server to your clouds Controller node, as root.
Using the IP address, login (fuel) and password we retrieved from the Credentials
popup, we start by SCPing the RC file to the Fuel servers current working directory.
Page 76
12-5-2015 &
13-5-2015
Leapfrogging begins. Here, we SCP the admin-openrc.sh file to the Fuel

Master node.
Note the addition of :. to the end of the IP address to denote the CWD. Youll need
to provide the fuel accounts password.
Then we SSH to the same place, again supplying the fuel accounts password.
Next, we SSH to the Fuel Master Node, using the password to log in.
Page 77
12-5-2015 &
13-5-2015
Now for our second leapfrog jump. First, we SCP the RC file to the CWD of the root
account on the Controller server.
Our second leapfrog jump entails SCPing the admin-openrc.sh file to the
root account of the Controller node. Here, we dont need to supply a
password, because Fuel is pre-authenticated.
Finally, SSH to the Controller server.
Page 78
12-5-2015 &
13-5-2015
We SSH into the Controller node as root, completing the leapfrog access
path.
And youre there! Now we can authenticate to OpenStack by sourcing our RC file.
We could also have sourced the openrc file already in place, and avoided all the scp
file transfers.
We authenticate to the API by using source on the RC file we brought in.

Then, to show that the default openrc file is also in place, we source to
that.
Now we can issue a test command to see if were hooked up. The
command keystone tenant-list will produce a list of tenants (projects) currently
active in our cloud.
Page 79
12-5-2015 &
13-5-2015
The command keystone tenant-list produces a list of projects (tenants)

currently active in our cloud.
Now go on to our next post in this series and learn how to put your newfound
OpenStack CLI skills to work by defining and launching a VM, and installing Apache
on it automatically.
Automating VM Launch and Configuration
Step by Step
To start, log into your clouds Controller node (following the instructions in our prior
post and issue the commandsource openrc to authenticate.
Now we can begin to gather the information and prepare the resources we need to
use the nova boot command to launch and install Apache on our VM.
First, well get the image ID for an appropriate image, using the command glance
image-list. Well grab the ID for the Ubuntu 14.04 x64 LTS dev image thats available
by default in Mirantis OpenStack Express.
Page 80
12-5-2015 &
13-5-2015
The command glance image-list lists the images we have available. Well
use the Ubuntu 14.04 LTS dev image, so well need its ID.
Then well set up the following script in the root of our Controller node, using vi,
calling the script install-apache.sh:
#!/bin/bash
/usr/bin/apt-get -qy update
/usr/bin/apt-get -qy install apache2
echo "<h1>Hello world!</h1>" > /var/www/html/index2.html
Page 81
12-5-2015 &
13-5-2015
Our user-data post-boot script will be passed to the VM we launch for

execution. As you can see, it runs an update, installs Apache, and creates a
one-line index file, called index2 to avoid conflict with the default
index.html file Apache installs.
As you can see, this is the script we want to execute post-boot, to run update on our
VM, install Apache2, and create an index.html file. The reason we call that file
index2 is that we dont want to conflict with the default index.html Apache installs.
Now we can check out the VM flavors available to us by entering nova flavor-list.
Well pick the medium flavor for our instance, which is index 3.
We can also remind ourselves of the keypairs we have available by executing nova
keypair-list. Well need the name of a key to launch our instance.
Page 82
12-5-2015 &
13-5-2015
Well use nova commands to see what flavors we have available, picking
m1.medium, index 3 for our instance. Well also check to see what
keypairs weve created.
Well find IDs for the networks we have available by executing nova network-list.
Well attach this VM to the toplevel internal network, net04. Later, well go to
Horizon to give it a floating IP to make it accessible from the internet.
Page 83
12-5-2015 &
13-5-2015
Well use nova network-list to find IDs for available networks, and attach
our instance to the net04 internal network.
Finally, well take all the information weve assembled and include it as arguments to
the nova boot command, which will launch our instance and install Apache. Note the
way arguments are referenced: argument flags and data types are consistent
throughout the OpenStack CLI.
The command nova boot will be used to launch our instance. Note the way
arguments are referenced: argument flags and data types are consistent
throughout the OpenStack CLI.
Nova compute gives us back a table of VM parameters and status info.
Page 84
12-5-2015 &
13-5-2015
The command gives back a table of VM details and status fields.

Now lets go to Horizon for this cloud, and look at the instance list. Theres our new
VM. Lets give it a floating IP by popping down the More menu and associating one
of the floating IPs we have available (I only have two assigned to this demo cloud).
Our test VM is Running in Horizon. Weve supplied it with a floating IP, so

it can be accessed via the Internet.
Page 85
12-5-2015 &
13-5-2015
And now, lets browse to that IP address and filename, and see if Apache is working.
It is!
Our fancy custom index2.html file has been created on our test server, and
is served by Apache.
This is just the beginning. In future tutorials, well be digging much deeper into
OpenStack command-line functions. Stay tuned!
Intro to Object Store
Whats the Object Store?
The OpenStack Object Store is a facility that lets applications store and retrieve
binary objects using the RESTful methods of the Swift API this scales better than
OS-level access to block storage and conventional file systems.
The Swift engine is the default back-end for the Object Store, and is also used by
Glance for storing images in HA deployments. But Mirantis OpenStack Express users
can also deploy clouds that use Ceph as a back-end for Glance and the Object Store
(via Cephs implementation of a subset of the Swift API), as well as block and
filesystem storage (for Cinder and other components requiring these services). For a
comparison of Swift and Ceph, this blog post by Dmitry Ukov is a great resource.
The Object Store is exposed in Horizon so that admins can create object containers
for projects (tenants), upload objects, and manage them. Containers and objects
can also be created using the (soon to be deprecated) Swift CLI, and using REST
functions from authenticated endpoints.
Well look at all three methods. But first, well modify the default configuration of the
Swift proxy in MOX to permit use of Public containers and objects.
A Quick Tweak
Page 86
12-5-2015 &
13-5-2015
Public containers are a useful feature of Swift Object Storage: they let you save stuff
and share it with anyone by giving them a URL. In combination with helper software,
they also permit creation of static websites. But theyre a potential security risk, so
theyre turned off by default in OpenStack clouds that use Keystone authentication
(though theyre on by default in clouds that use TempAuth authentication mdash; a
deprecated mechanism).
Lets see what happens when we create a Public container on a default MOX cloud,
put something in it, and try to access it RESTfully. In Horizon, go to Project ->
Object Store -> Containers, click the Create Container button, give your container a
name, and set it to Public with the popdown.
To start, lets create a container, give it a name (DemoContainer) and set

it to Public for open access via URL alone.
Then click on the container name, click the Upload Object button, and upload an
object: any random image (that you dont mind exposing to the public internet) is
fine.
Page 87
12-5-2015 &
13-5-2015
Next, well upload an arbitrary binary file: in this case, an image that well
call image.png.
Now click the View Details button, and copy the Public URL for the container.
Looking at info for our new object, we see that it has a Public URL: a fourpart construct comprising the Storage URL, tenant ID, container name,
and object name.
Page 88
12-5-2015 &
13-5-2015
Then create a complete URL for the contained object (in my case, thats image.png)
by appending the object name.
http://23.246.243.215:8080/v1/AUTH_928c39946889488283da99126148cc3f/Demo
Container/image.png
which has four parts:
1. The Storage URL: http://23.246.243.215:8080/v1
2. A composite ID identifying the tenant (project): In Swift, this is AUTH_
followed by the tenant ID
3. The container name
4. The object name
You can, in an appropriately-configured OpenStack cloud, use the above URL in any
browser to access a Public resource. But if we try that with our cloud, it wont work:
we get a page back with the message Authentication required.
But because Mirantis OpenStack Express is default-configured with Public

URLs off (because it uses Keystone authentication), this Public URL
doesnt work for us, unless me make a small tweak in Swifts proxy server
configuration.
Theres a quick fix, however, thanks to our ability to access the OpenStack controller
as root. Please note that this change enables access to containers and objects
already designated Public (but not functioning as such in the default configuration).
We recommend evaluating the status of existing containers and contents before
making this change, so that private data is not inadvertently exposed.
Step by Step
Lets check the IP address and password for our Fuel server under the Credentials
popdown of the Mirantis OpenStack Express dashboard. Then lets pop a terminal
Page 89
12-5-2015 &
13-5-2015
window, SSH into the Fuel Master node, then SSH to our Controller node using its
FQDN or Fully Qualified Domain Name (in the case of my demo cloud, thats node5). Finally, lets source openrc so we can access the OpenStack CLIs.
To do this, we start by logging into our Controller, by leapfrogging across

the Fuel Master Node, then issue the command source openrc to put
authentication info in our environment for the OpenStack client CLIs.
Now lets tweak the configuration of Swifts proxy server. Lets use vi to
edit /etc/swift/proxy-server.conf.
Lets search for the configuration variable delay_auth_decision, which is
under [filter:authtoken], and change its value from 0 to 1. Then save the file and
exit.
Page 90
12-5-2015 &
13-5-2015
Now we use vi>/i> to edit the file /etc/swift/proxy-server.conf, changing

the value of variabledelay_auth_decision from 0 to 1.
Finally, lets restart the proxy by issuing the command /etc/init.d/openstack-swiftproxy restart.
Page 91
12-5-2015 &
13-5-2015
Then we restart the Swift proxy with /etc/init.d/openstack-swift-proxy

restart. Now, our Public URL will work from any browser to display our
image.
Lets go to a browser and try accessing our object again, using the Public URL. It
works!
Going Private
Now, lets go back to Horizon and make our container private by clicking the More
button, and choosing Make Private.
Next, we make our container Private by clicking on Make Private in the

More menu.
If we check View Details again, we see the Public URL has vanished.
Page 92
12-5-2015 &
13-5-2015
Now that the container is private, it no longer displays a Public URL.

But since were the admin and the owner of this container we can still access
it, though. Lets start by using the Swift client CLI and issuing the command:
swift stat DemoContainer
We get info back about the container, the number of objects it contains, and the
Account (ours, the admin account) that it belongs to. We know the container is
private, because its Read ACL, or Access Control List, is blank.
Page 93
12-5-2015 &
13-5-2015
The command swift stat DemoContainer shows us information about our

now-private container, including the blank Read ACL (Access Control List)
that shows its now private.
We can also do:
keystone tenant-list
to see the admin tenants ID, and compare with the Account that owns the
container. As you can see, the Account is just AUTH_ with the tenant ID appended.
Page 94
12-5-2015 &
13-5-2015
The Account identifier shown by swift stat DemoContainer is just AUTH_,

prepended to the admin accounts Tenant ID, as keystone tenantlist shows.
Now that its private, we need an authentication token to access this object. As the
admin, a quick way to get this is to issue the Swift client command:
swift stat -v
which gives us the StorageURL for our containers (with the Account ID
appended), and also shows an Auth Token. In a standard OpenStack
implementation, this kind of token expires in an hour. The swift stat -v command
actually gives us a new token each time we call it.
Page 95
12-5-2015 &
13-5-2015
The command swift stat -v returns information about your Object Store:
topmost is the public Storage URL, followed by an (unscoped) Auth Token
that can be used to access private objects.
Using this information, we can compose a REST expression that will authenticate us
to Swift and let us access our stored object.
curl -H 'X-Auth-Token: 3382b9fa101648c2bcf8477420217bb8'
http://23.246.243.215:8080/v1/AUTH_928c39946889488283da99126148cc3f/Demo
Container/image.png > myimage.png
We use the cURL utility to issue the request. The -H option lets us include a request
header, which is X-Auth-Token, plus our authentication token that tells Swift who
we are. The remainder is just the StorageURL, the account name, container name,
and object name. We vector the returned data into a file so it doesnt fill our
terminal screen with scary graphics.
Page 96
12-5-2015 &
13-5-2015
The Storage URL and Auth Token can be combined into a REST command
to access an object stored in a private container.
The object (in this case, an image) is downloaded as binary. A few SCP
commands pull it off the Controller node and onto the desktop, where it
can be opened.
Page 97
12-5-2015 &
13-5-2015
In our next tutorial, well show how applications can authenticate with Keystone
RESTfully, obtain tokens, and access their Swift objects.
REST Access to Object Store
Step by Step
Developers who want to write applications that access OpenStack APIs are mostly
going to work with one of the many SDKs available weve linked a list of these at
the end of this article. When starting out, though, its interesting to play with
OpenStack REST functions via a terminal, using a tool like cURL that allows rapid
iteration.
To start this exercise, lets log into our MOX clouds controller node as root by
leapfrogging in using Fuel. On our Dashboard, click the Credentials link, grab the
Fuel Master Nodes IP address, and SSH to fuel@(that IP). Supply the password.
Then look in Fuels GUI for the Fully-Qualified Domain Name (FQDN) of your clouds
Controller: mine is node-5. SSH from Fuel to root@(FQDN) no password is
required this time. Then enter source openrc to align your shell session with the
OpenStack APIs.
Log into your Controller node as before, by leapfrogging in via the Fuel
Master Node using the IP address in your Mirantis OpenStack Express
dashboards Credentials tab. SSH from Fuel to the Controller. Then
enter source openrc to copy authentication into your environment for the
CLIs and clients.
Last time, we used the CLI Swift client command swift stat -v to get info about the
Public URL of our container and its Swift Storage URL. This time, were going to
authenticate RESTfully, straight to Keystones internal address from the Controllers
command line.
Page 98
12-5-2015 &
13-5-2015
The swift stat -v command returns your StorageURL and an Auth Token.
But its also possible to authenticate to Keystone directly, using a REST
command, and recover both a token and the service catalog.
We can find the internal IP address of Keystone through Horizon, by clicking on
Admin, then on System Info, and bringing up the Services tab
Page 99
12-5-2015 &
13-5-2015
You can find the internal address of your Keystone in Horizon, under
System Infos Services tab.
Now lets compose the command well use to authenticate. The simplest way to
request a token is to get one thats unscoped meaning that it lets us do anything
our account is permissioned to do. This is okay for querying Keystone, but its
dangerous to use an unscoped token to access storage and other important
subsystems. So instead, were going to use a longer form authentication request that
lets us get back a project-scoped token mdash; one that will let us access and
modify objects belonging to the admin project, but not those belonging to other
projects.
This is the cURL expression well use:
curl -D "headers.txt" -H "Content-Type: application/json" -d '{ "auth": {"identity":
{"methods": ["password"],"password": {"user": {"name": "admin","domain": { "id":
"default" },"password": "secretsecret"}}},"scope": {"project": {"name":
"admin","domain": { "id": "default" }}}}}' http://192.168.0.10:5000/v3/auth/tokens
| python -mjson.tool > pretty.json
The auth function were invoking is going to hand us back our token in the header of
the response, assigned to the variable X-Subject-Token. So we use the -D command
to designate a separate file in which curl will save headers.
The -H command includes a header with the request, identifying the kind of
response payload we want to get back: json data.
The -d command identifies the json dataset were sending to Keystone. Note that
this is an expanded form of the json for a default token: it conveys the username,
password, and the project since were admin, thats called admin.
At the end, we put the internal URL for Keystone and the port (5000), appending to
this URL /v3/auth/tokens the function were calling. Finally, were piping the
response body (just the json we get back) to a handy python tool (which youll find
already present on your Controller node) that parses json data and pretty-prints it
were going to save this output in the file pretty.json, for review.
Returned Data
We can extract our token from the saved header file.
Page 100
12-5-2015 &
13-5-2015
Issuing an appropriate cURL command nets you a project-scoped Auth

Token, passed back in the X-Subject-Token header of the response.
And if we read down the json body, we can also find the Public URL for the objectstore. Or we can extract the Public URLs for all components with grep and awk, or
parse the json with whatever language were using.
Page 101
12-5-2015 &
13-5-2015
Weve saved a formatted version of the JSON response body, which

contains the service catalog. Its easy to scroll down and find the Public
URL for your Object Store.
Composing a cURL expression with token and Storage URL, appending the name of
our container (DemoContainer) gets us a listing of the containers contents: our
image file, image.png.
Given the token and the Public URL, you can compose a cURL command to
list the contents of any container in your project.
In our next tutorial, well dive deeper into Mirantis OpenStack Express VPNaaS.
Thanks for watching!
Intro to Heat Orchestration
Step by Step
To see Heat in action, lets start by launching a stack that does something simple.
(You can find stacks and snippets like this throughout the OpenStack Heat
documentation and across the web. One blog at Technology Chronicle, discussing
how to associate a floating IP with a port, gets a shout-out below.) You can find the
Heat interface in Horizon under Orchestration in the left-hand menu.
Click Launch Stack, and youll see a dialog that lets you pull in a template by URL,
upload it from a file, or simply cut and paste it into an editable dialog. Thats lots of
flexibility for working with various kinds of source-code control systems for
versioning and maintaining template and template-snippet libraries. Well just pick
Direct Input, and Ill cut and paste my template into the box. Well look at the
template itself in a moment but first, well look at what it does from the
perspective of a user.
Page 102
12-5-2015 &
13-5-2015
The Heat interface in Horizon gives administrators lots of ways to input

template code from URLs, files, or cut-and-paste sources making it easy
to run stacks from source-code control.
Hit Next. The template is read in, validated, and executed. In response, Horizon
throws up a dialog that asks for input parameters: it looks a little like the dialog used
to launch a VM. You can supply a name for a new instance, hook it up with an SSH
keypair, pick a flavor from a popdown list, and supply the name of a boot image.
Then, youre asked to specify resource IDs identifying the internal network and
subnet you want to put the VM on, and the external network you want to connect
the instance to, using a floating IP. Except for the instance name, defaults are
supplied for all these values.
Page 103
12-5-2015 &
13-5-2015
Executing Heat templates in Horizon can be powerful. The Horizon

integration with Heat APIs turns template input requisites into web UI,
complete with popdown menus to constrain choices, and pre-seeded
default values for error-free input.
Click Launch, and after a few seconds, theres our new instance, with its internal and
floating IPs, its SSH keypair and other details.
Page 104
12-5-2015 &
13-5-2015
Our simple HOT template has built us a server, attached it to networks,

given it a floating IP address and an SSH keypair for access.
Going back to the Orchestration tab, we can click on the name of our stack to show
a tabbed display of its inputs and outputs; a manipulable graphic display of its nodes
with popup information; a list of its resources; and a list of the events involved in its
creation. Very useful to have all this info in one place.
Click the name of an active stack to review details, topology, and find
resource IDs all the info needed to administer the stack, all in one place.
Page 105
12-5-2015 &
13-5-2015
The topo view shows our server with a single port bound to internal and (by
means of a floating IP address) external networks.
Now lets quickly take a look at the HOT template file used to create this stack. It opens with
a header that identifies the template version: this date means the template may contain
Icehouse-era Heat features.
heat_template_version: 2013-05-23
description: >
HOT template - deploys server with user-provided name, image, key, flavor
Attaches to private network, and obtains floating IP on public network
Following the header is a list of the templates input and output parameters, with optional
default values and constraints placed on the inputs. The flavor value, for example, is
constrained to a list of permitted flavors the Horizon interface with Heat will see this
constraint table and present it as a pop-down menu.
parameters:
server_name:
type: string
description: Name of your new server
key_name:
type: string
description: Keypair name
default: dkp
image:
type: string
description: Image name
default: TestVM
flavor:
Page 106
12-5-2015 &
13-5-2015
type: string
description: Flavor
default: m1.small
constraints:
- allowed_values: [m1.tiny,m1.small,m1.medium,m1.large,m1.xlarge]
public_net_id:
type: string
description: ID of the external network
default: 73e8560d-51bb-4e38-ae47-4252263fb10a
private_net_id:
type: string
description: ID of the internal network
default: 704c8034-5bcf-4151-bf69-b5d9791b6eb4
private_subnet_id:
type: string
description: ID of private sub network into which servers get deployed
default: a9d6fd47-6c3c-46e5-a44a-ede76877934b
Next is a more-complex section of the template describing cloud resources: the server itself,
its network port, floating IP address, security group, and so on. Each resource descriptor
references a type and provides values for required properties. In this template, values for
properties are supplied as literals, obtained directly from the user (using the get_param:
directive) or derived indirectly by referencing another resource descriptor (using the
get_resource: directive). Heat offers several other ways to pull data into templates, as well:
including reading from files, concatenating and manipulating strings.
resources:
server:
type: OS::Nova::Server
properties:
name: { get_param: server_name }
image: { get_param: image }
flavor: { get_param: flavor }
key_name: { get_param: key_name }
networks:
- port: { get_resource: server_port }
server_port:
type: OS::Neutron::Port
properties:
network_id: { get_param: private_net_id }
fixed_ips:
- subnet_id: { get_param: private_subnet_id }
security_groups: [{ get_resource: server_security_group }]
server_floating_ip:
type: OS::Neutron::FloatingIP
properties:
floating_network_id: { get_param: public_net_id }
port_id: { get_resource: server_port }
server_security_group:
Page 107
12-5-2015 &
13-5-2015
type: OS::Neutron::SecurityGroup
properties:
description: Add security group rules for server
name: security-group
rules:
- remote_ip_prefix: 0.0.0.0/0
protocol: tcp
port_range_min: 22
port_range_max: 22
- remote_ip_prefix: 0.0.0.0/0
protocol: icmp
The final section of the template describes the outputs we want to include in the persistent
stack overview.
outputs:
server_private_ip:
description: IP address of server on private network
value: { get_attr: [ server, first_address ] }
server_public_ip:
description: Floating IP address of server on public network
value: { get_attr: [ server_floating_ip, floating_ip_address ] }
Next time, well look in more detail at this Heat template, and extend it with additional Heat
features. In the meantime, if you start playing with Heat, heed this advice: use a YAML
language setting in your editor to manipulate HOT templates, set the editor to supplant tabs
with spaces, and just for the heck of it, make whitespace characters visible. The current
generation of OpenStack Heat validation is extremely picky, and its easy to scratch your
head for long minutes over a validation thats failing because a tab crept invisibly into the
middle.
Installing OpenStack CLI Clients
This tutorial should work for any user of Mirantis OpenStack Express, or for anyone whos
built a private cloud with Mirantis OpenStack. But its especially aimed at new users of
Mirantis OpenStack Express Developer Edition. Developer Edition users are running inside an
OpenStack Tenant (Project) on a shared cloud, rather than managing their own private
cluster. That means they cant access the CLI clients pre-installed on the OpenStack
Controller Node, as we described in an earlier tutorial (Mirantis OpenStack Express
Running OpenStack from the Command Line).
Thats not a bad thing, either! While access to the Controllers CLI can be convenient (in
some cases, critical), its not a good idea to use that CLI for regular work. Your Controller
node is critical infrastructure, so its inconvenient and potentially dangerous to build a
development environment there (not to mention that if you redeploy your cloud that
server goes away).
Putting the CLI elsewhere is easy to do, and gives you much more freedom. You can use a
comfy desktop, install your preferred developer tools, and provide secure storage for the
repos, image files and other data youll accumulate. You can also administer multiple clouds
from the same machine.
Intro to OpenStack CLI
OpenStacks CLI often referred to in the singular is actually provided by a set of Python
client modules, one for each OpenStack component. The clients have names like novaclient
Page 108
12-5-2015 &
13-5-2015
and glanceclient (the associated package names are of the form python-novaclient, pythonglanceclient, etc.). They work by accepting input arguments, calling the public (internet) or
private (internal network) entrypoints of OpenStack REST functions, and parsing results into
Python data structures. Most clients implement all the functionality of the corresponding
REST interface.
Each client has a corresponding shell script to call it named after the component, and
called as (component) (command) (optional arguments). So, when using the CLI, you can
type something like nova list (component command) into your terminal, and the nova
script will hand off to the novaclient module which calls parts of the REST interface (in this
case, Keystone to authenticate and Nova-Compute) to hand you back a nice table listing all
your active servers.
CLI inputs and outputs are much easier to read and manage than the web headers, JSON or
XML objects the REST interface likes to communicate with, directly. The client shell scripts
can be called by other shell scripts (e.g, bash), and the client modules can be included in
your own Python scripts, letting you create sophisticated tooling.
Installing the CLI Clients: Step by Step
Its easy to install the OpenStack command-line clients on popular flavors of Linux, as well
as on Mac or Windows. Details can be found in OpenStacks official documentation, here.
The basic formula is:
Make sure you have Python 2.6 or later (not Python 3!) installed.
Install Python setuptools, which is a distribution/package manager used by pip.
Install pip, the most commonly-used Python package manager.
Use pip to install the clients from PyPI, the Python Package Index.
Obtain and source your Project/Tenants OpenStack RC file, putting values into your shell
environment enabling authentication to your cloud.
Use your clients to achieve great things.
Installing Python
If youre using Mac OS X or any relatively recent desktop or server iteration of a popular
Linux, congratulations you already have an appropriate version of Python installed. To be
absolutely sure, open a terminal and enter python -V (any version 2 python with 6+ as a
sub-version number will do you). Windows users can install from the version 2.7.8
downloadable available at python.org.
Installing setuptools
Windows users are the outliers in installing setuptools. Luckily, they have a quick solution to
steps 1 and 2 above, provided by Christoph Gohlke, who created and maintains unofficial
binary installers for setuptools and pip
(seehttp://www.lfd.uci.edu/~gohlke/pythonlibs/#setuptools and http://www.lfd.uci.edu/~go
hlke/pythonlibs/#pip). Just download and run in sequence.
Mac OS X users can also sit out installing setuptools, because setuptools and easy_install (a
script used to install pip) are installed by default on their system.
Ubuntu and Debian users can open a terminal and type:
# sudo apt-get install python-setuptools
And Fedora, Red Hat, CentOS and other yum users can type:
Page 109
12-5-2015 &
13-5-2015
# sudo yum install python-setuptools

Installing pip
Mac users are an outlier here. They can just open a terminal and type:
# easy_install pip
Us Linux types will enter:
# sudo apt-get install python-pip
or
# sudo yum install python-pip
Note that the universe software source will need to be enabled on Ubuntu/Debian clients for this
command to work as expected.
Installing the CLI Clients
Now that pip is installed, this is simple. Heres the full list of clients:
ceilometer Telemetry API
cinder Block Storage API and extensions
glance Image Service API
heat Orchestration API
keystone Identity service API and extensions
neutron Networking API
nova Compute API and extensions
sahara Database Processing API
swift Object Storage API
trove Database Service API
Your job is to install them in sequence by typing commands of the form:
# sudo pip install python-(project)client
again and again and again. Heres a concrete example:
# sudo pip install python-ceilometerclient
Order doesnt matter. The clients will install and (in some cases) install other clients (e.g., Keystone)
to resolve their own dependencies.
Getting your OpenStack RC File
The CLI clients look for environment variables to point themselves towards your clouds REST API
entry points, and to derive other info (like your username) needed to authenticate transactions. You
could create the needed environment variables manually, but its much easier to download a
complete OpenStack RC script containing all the necessary info (except your password).
You can obtain your RC file through your Mirantis OpenStack Developer (or other edition) Horizon
console. Just go to Project -> Compute -> Access & Security, click the API Access tab, and click the
button labeled Download OpenStack RC File. Save your RC file in your home directory, or wherever
you consider toplevel for your CLI work, and run it by entering:
# source openrc.sh
which opens and runs the file in the context of the current environment. Enter your password
when requested this is the same password you use to log into Horizon, and can be found (in
Page 110
12-5-2015 &
13-5-2015
Developer Edition) in your Dashboards Credentials popup (Mirantis OpenStack Express Team Edition
users will find it on the main Dashboard page in the area describing your cluster.
Lets Test!
You should now be able to issue OpenStack CLI commands. A good first test is to try:
# nova image-list
which returns a list of boot images available to you. Note the ID of the Ubuntu 14.04 LTS dev
image. Now lets try:
# neutron net-list
which shows available networks. Note the ID of your private network. And finally, lets use the
nova boot command to start a VM, swapping in the IDs for the image and private network you
derived from the values returned by the two prior commands:
# nova boot [vm-name] --flavor m1.small --image (image ID) --security-groups default --nic netid=(private net ID)
In a couple of seconds, your new VM should spawn. Check to see if its active, using:
# nova list
which shows all your active VMs.
In upcoming tutorials, well start building on OpenStacks CLIs, REST interfaces, orchestration tools
and Application Catalog and start assembling more powerful automation.
Reference
https://www.mirantis.com
********************************************
Knowing is not enough
We must apply
Willing is not enough
We must do
Best Wishes
By
D.Kesavaraja M.E ,(PhD),MISTE,AMIE

Assistant Professor/CSE
Dr.Sivanthi Aditanar College of Engineering
Tiruchendur
Website : www.k7cloud.in Mail:k7cloud@gmail.com

Mobile: +91 9865213214
Page 111

Openstack Training On Cloud & Bigdata Analytics

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Openstack Training On Cloud & Bigdata Analytics

Hochgeladen von

Copyright:

Verfügbare Formate

OPENSTACK TRAINING ON CLOUD & BIGDATA ANALYTICS

TEQIP II Sponsored Faculty Development Programme

Presented By Mr.D.Kesavaraja; Organized By DEPARTMENT OF IT ,ANNA UNIVERSITY, BIT CAMPUS TIRUCHIRAPPALLI