Openstack Manual

TWO DAY WORKSHOP ON CLOUD OPENSTACK KILO11

29-10-2015 & 30-10-2015

Presented By Mr.D.Kesavaraja; Organized By DEPARTMENT OF CSE ,ANNA UNIVERSITY Regional Office , Tirunelveli Page 1

Two Day Workshop on Cloud Openstack Kilo11

29.10.2015 to 30.10 .2105

ORGANIZED BY

DEPA RTMENT OF COMPUTER SCIENCE AND ENGINEERING

REGIONAL OFFICE ANNA UNIVERSITY TIRUNELVELI REGION,

TIRUNELVELI

Web: http://www.auttvl.ac.in


29-10-2015 & 30-10-2015


Two Day Workshop

on

Cloud Openstack Kilo 11

[Live Hands On Openstack Kilo version with Packstack , Rdo , Nova , Swift And Neutron ] 29 -October -2015 and 30-October -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 (29 -October -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

SESSION 2 [Open Stack Deployment PackStack and RDO , Key Stone] TIME: 1:30 AM TO 4:30 PM

Nova architecture overview Overlays vs Physical Networks Network Abstractions at Different Layers Neutron: The OpenStack Networking

Application-centric Abstractions for Neutron: Policy Extension Framework


29-10-2015 & 30-10-2015


Application-centric Network Policies Hands on - Installing Open Stack with Pack Stack

and RDO

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 ( 30-October -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

We must apply

Willing is not enough


29-10-2015 & 30-10-2015


More Details Visit : www.k7cloud.in : http://k7training.blogspot.in

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
http://www.k7cloud.in/http://k7training.blogspot.in/http://wp.me/p2WWnY-2Gfehttp://wp.me/p2WWnY-2Gi7http://wp.me/p2WWnY-2Gkxhttp://wp.me/p2WWnY-2Gkxhttp://wp.me/p2WWnY-2Gnzhttp://wp.me/p2WWnY-2Gpshttp://wp.me/p2WWnY-2GrOhttp://wp.me/p2WWnY-2Gsohttp://wp.me/p2WWnY-2Gv9http://wp.me/p2WWnY-2GvLhttp://wp.me/p2WWnY-2Gxfhttp://wp.me/p2WWnY-2Gzphttp://wp.me/p2WWnY-2GExhttp://wp.me/p2WWnY-2GIQ


29-10-2015 & 30-10-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 de velopment 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- DEVICE="" where is usually "eth0" or "em1". Take down all interfaces (but the one via you're connected to the machine) with: ifdown Start the network daemon: ifdown && 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/rdo-release-icehouse.rpm instead. Looking for an older version? See http://rdo.fedorapeople.org/ for the full listing.
https://openstack.redhat.com/Adding_a_compute_nodehttp://trystack.org/https://openstack.redhat.com/Install#Installationhttps://openstack.redhat.com/Repositorieshttp://www.redhat.com/mailman/listinfo/rdo-listhttp://rdo.fedorapeople.org/openstack-icehouse/rdo-release-icehouse.rpmhttp://rdo.fedorapeople.org/openstack-icehouse/rdo-release-icehouse.rpmhttp://rdo.fedorapeople.org/


29-10-2015 & 30-10-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 OpenStac k Express

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.
https://openstack.redhat.com/Workaroundshttps://openstack.redhat.com/Running_an_instancehttps://openstack.redhat.com/Floating_IP_rangehttps://openstack.redhat.com/Neutron_with_existing_external_networkhttps://openstack.redhat.com/Neutron_with_existing_external_networkhttps://openstack.redhat.com/Adding_a_compute_nodehttps://openstack.redhat.com/Adding_a_compute_node


29-10-2015 & 30-10-2015


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.

.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
http://docs.openstack.org/image-guide/content/ch_obtaining_images.htmlhttps://www.mirantis.com/wp-content/uploads/2014/09/1-MOX-Dashboard.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/2-MOX-images.png


29-10-2015 & 30-10-2015


.

OpenStack documentation offers a chapter on Getting Images, where links to compatible image files can be found. For our current purpose importing an image cloud- by right -clicking the URL and copying it. 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.
https://www.mirantis.com/wp-content/uploads/2014/09/3-Getting-images.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/4-MOX-images-Create-image.png


29-10-2015 & 30-10-2015


The import system can handle a range of common i mage 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 picking QCOW2.
https://www.mirantis.com/wp-content/uploads/2014/09/5-Name-your-image.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/6-Paste-Image-Location.png


29-10-2015 & 30-10-2015


A wide range of image formats is supported. 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.
https://www.mirantis.com/wp-content/uploads/2014/09/7-Pick-QCOW2.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/8-Create-Image.png


29-10-2015 & 30-10-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 Cirro s image that we can now use to configure and launch VM instances.
https://www.mirantis.com/wp-content/uploads/2014/09/9-Saving-Image.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/10-Success.png


29-10-2015 & 30-10-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.
https://www.mirantis.com/wp-content/uploads/2014/09/1.png


29-10-2015 & 30-10-2015


Mirantis OpenStack Express 2.0 Horizon stores your keypairs, so they can be associated with sing le 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.
https://www.mirantis.com/wp-content/uploads/2014/09/2.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/3.png


29-10-2015 & 30-10-2015


Then open the plaintext public key file and copy the contents.

gedit. Then choose Import Key to name the keypair and copy the public portion to Horizon.


29-10-2015 & 30-10-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.

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 inst ance.


29-10-2015 & 30-10-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

On the Access and Security tab, specify the SSH keypair you want to use to access this instance.


29-10-2015 & 30-10-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 d rop the basic networking model.
https://www.mirantis.com/wp-content/uploads/2014/09/7-prime.pnghttps://www.mirantis.com/wp-content/uploads/2014/09/8.png


29-10-2015 & 30-10-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

More menu. The new IP address appears in the list of IPs associated with the instance.


29-10-2015 & 30-10-2015


Associate a floating IP with your instance, visible fro m the public net.

port.


29-10-2015 & 30-10-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 pointing SSH to the


29-10-2015 & 30-10-2015


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 Pu

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


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-2015


You can also access Cirros and other appropriately-configured instances from the Horizon VNC console, with username/password authentication. In this case, the


29-10-2015 & 30-10-2015


You can also log into appropriately -configured inst ances using Mirantis

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.

Creating a Block Storage Volume

Step by Step

-> 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

You can specify the contents of a volume by uploading an .iso image. But since this

-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.


29-10-2015 & 30-10-2015


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 snapsho ts to store its state.

Creating a Block Storage Volume

Step by Step

-> Volumes -> Create Volume and pull up the dialog.


29-10-2015 & 30-10-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

You can specify the contents of a volume by uploading an .iso image. But since this is

-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.


29-10-2015 & 30-10-2015


You can keep track of atable. 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 Flavo rs

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.


29-10-2015 & 30-10-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 mi nimal 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

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 -engine.


29-10-2015 & 30-10-2015


To create a new flavor, state your requirements in the dialog. Here, w

- a multiprocessor machine

giving our flavor 50GB of ephemeral storage, which will vanish if an instance created with this flavor is te rminated. This hypothetical flavor might be useful for highly -parallelized data analysis.

-core vCPUs so it can run all our vectorized code. 16GB of RAM, . But

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 ke ep exotic VM

available to all.


29-10-2015 & 30-10-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 t he list. The system has assigned an ID to it.

CirrosVM image we created several lessons back. As you may recall, when we


29-10-2015 & 30-10-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

assign different requirements to images we create, based on OS, version and configuration.

-engine machine using an image with no minimum root disk requirement set. We n ame it, we pick our new flavor, and

launch. Set authentication and network parameters, and go.


29-10-2015 & 30-10-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.

And we can execute a cat /proc/cpuinfo command to see all of the many processors we have available.


29-10-2015 & 30-10-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 ca n 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.

xplored flavors, our next tutorial will cover higher -level administrative tools for creating Projects and adding Users. Setting up a Project

Step by Step

projects 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.

antis OpenStack Express Horizon as the admin, navigating to Projects in the Identity Panel subtab of the Admin menu, and clicking on Create Project.

that gives you the choice of initializing your product in an Enabled state, or not.

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.


29-10-2015 & 30-10-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 fully -enabled (thus availa ble 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

d fine-tuning: you can access more from the command-line interface. Users, too, can be given quotas with respect to projects 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.


29-10-2015 & 30-10-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 resolve s 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,

ne


29-10-2015 & 30-10-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 record -keeping.

enStack seems to throw an error here, though it also reports successful project creation. This simply means that we left the default quotas in


29-10-2015 & 30-10-2015


Our project is created. Note that OpenStack throws what app ears to be an error message, here, because we left certain project quotas set to permit

sensibly, however, with critical resources automatically parceled out among projects fairly. Nouser a name, insert their email, and specify a password. Associate them to the

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.

the upper left. As high-more-limited view of the system.


29-10-2015 & 30-10-2015


Switching to our new project as the admin user. In Overview, we now see

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 Net work tab, look at topology, and see that we have no network, except for the net04_ext external, public network, owned by the Admin.

an reach them from the internet.

identical to the default network at toplevel configured by Mirantis OpenStack


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-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.

conventional choice here is something like 192.168.0.0/24.

address the corresponding default is 192.168.0.1, which Horizon will use if we leave this field blank.


29-10-2015 & 30-10-2015


Creating a subnet and setting IP address ranges and the gateway address.


29-10-2015 & 30-10-2015


Our network and its associated subnet are created.

onnect 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.


29-10-2015 & 30-10-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.

network, bridging that to the external one.


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-2015


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

->Security


29-10-2015 & 30-10-2015


ffic on port 22.

Adding a new Ingress rule, permitting traffic on port 22 (SSH).


29-10-2015 & 30-10-2015


ty group rule -set.

Now we can make VMs nternet accessible by giving them floating IP addresses from

see if we can connect to it. Success!


29-10-2015 & 30-10-2015


usekeeping, appropriately -configured VMs launched within the project and given a floating IP address can be accessed remotely via SSH, with the appropriate keypair.

you 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.


29-10-2015 & 30-10-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


29-10-2015 & 30-10-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, befo re 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-environment as an instance, and use it. That makes Murano pretty -service

to people in immediately-usable forms. To install Murano on a Mirantis OpenStack Express cluster, you can select it from

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.


29-10-2015 & 30-10-2015


A tab at the bottom left o f 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.


29-10-2015 & 30-10-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. the Quick Deploy button. Give the Apache component a name, and select options.

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.


29-10-2015 & 30-10-2015


Beginning the Quick -Deploy process, we provide a name for the Apache component, and indicate that we want PHP installed, and that w hen started as an instance, this environment should be given a floating IP for internet access. On the next dialog, choose a VM flavor 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 Murano-compatible images and upload them to Glance.


29-10-2015 & 30-10-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.

environment created to hold it, called quick -env-1. The Topology tab shows us an in this case, very basic proposed host.


29-10-2015 & 30-10-2015


Our Apache webserver is now deployed as a component of a new, auto -created 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.

-env--hand


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-2015


Deployment is successful: our environment is now spun up as an instance, visible in the instance table.

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 installat ions. In a near-environments, and eventually explore how to add new applications to the Murano catalog. VPN-as-a-Service (VPNaaS) Step by Step


29-10-2015 & 30-10-2015


Step by Step

-separate OpenStack environments in MOX one representing the premise datacenter, the other a

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

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

these environments use Neutron VLAN-based networking), a pr oject can have its own private networks, subnets, and router gateways.

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

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


29-10-2015 & 30-10-2015


project as the Adminset up the VPN connection (e.g., router external gateway IP addresses and

Then, switching to each project as the admin user, I built a simple local network for

And e 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 addreDemoProject 1 can see machines in DemoProject 2, and vice-versa, while securing the traffic between the two projects from prying eyes.


29-10-2015 & 30-10-2015


ed to the

cloud-wide public network (and the Internet) with a router. OpenStack

range given to the local subnet: it does not overlap with the IP address


29-10-2015 & 30-10-2015


for VPNaaS to work. For VPNaaS to work in connecting these subnets, the subnets need to have non-overlapping IP

other cloud. Each range contains 256 IPv4 addresses. 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

group: like a general ICMP rule, enabling pings, and a port 22 TCP rule, enabling SSH.

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,

Set up VPNaaS on Cloud A

->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


29-10-2015 & 30-10-2015


of the VPN with info on address range.

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

from the defaults is to select the recommended 256 -bit AES encryption. Names assigned to policies are arbi trary and need only be locally unique,

Create the IPSec Policy: recommended to use aes-256 encryption.


29-10-2015 & 30-10-2015


the recommended AES -256 encryption. Create the VPN Service: VPN gateway

cal subnet. As noted, the main thing to remember is that VPN will not work if the subnets at both ends overlap.


29-10-2015 & 30-10-2015


Adding the VPN Service definition for DemoProject1/Cloud A selecting

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 t

see the info we need to know.

Starting to set up DemoProj

created. The first thing we need is the Peer gateway public IPV4 address or fully-qualified

und by going to

oject.


29-10-2015 & 30-10-2015


need two pieces of information from DemoProject2/Cloud B. The first is

izon, clicking on Routers, clicking on

This IP address goes into two slots in the IPSec Site Connection edit dialog for


29-10-2015 & 30-10-2015


Connection dialog. . Again, go to

subnet CIDR range, which is 192.168.111.0/24.


29-10-2015 & 30-10-2015


The second piece of info we need is the IPv4 subnet address range for find that in

name.

vide 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.

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

in two places the

subnet IP address range.


29-10-2015 & 30-10-2015


Now we set up the same components on DemoProject2/Cloud B. Setting up IKE Policy, IPSec Poli cy and VPN Service are simple. For the IPSec Site

DemoProject1/Cloud A that we needed for DemoProject2/Cloud B. Here,


29-10-2015 & 30-10-2015


address range.

Site Connection dialog, and supply the shared password. Then we click Add, and the VPN sets itself up. Once you click

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


29-10-2015 & 30-10-2015


ed! The IPSec Site Connection shows as Active at both ends.

Testing VPNaaS

the VM on DemoProject1 (Cloud A) and ping our new VPN friend on that internal IP address.


29-10-2015 & 30-10-2015


, one on each cloud, and given

the internal project.

its floating IP address


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-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 Command-Line 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).

gives you full root access to your private OpenStack environments something most cloud-as-a-

Step by Step

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,

your Fuel server.
http://docs.openstack.org/cli-reference/content/http://docs.openstack.org/cli-reference/content/https://www.mirantis.com/wp-content/uploads/2014/10/114.png


29-10-2015 & 30-10-2015


credentials on your Mirantis OpenStack Express Dash board. Next, use Fuel to find the fully -qualified internal domain name (FQDN) of the controller node of the cloud you want to access:

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

characteristics. -

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.

use to authenticate to the OpenStack API: ce, 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.


29-10-2015 & 30-10-2015


You can download an RC file to authenticate you to the Op enStack API by

Project (tenant) has its own.

openrc script is automatically saved for you in the root directory of your Controller

works in other spins of OpenStack you may encounter, and later, if you want to authenticate in the context of tenant projects.


29-10-2015 & 30-10-2015


The RC file sets authentication parameters into your environment when

toplevel, because an identical file is saved in the ro ot 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

Using the IP address, login (fuel) and password we retrieved from the Credentials popup, we start by SCPing the RC file to


29-10-2015 & 30-10-2015


Leapfrogging begins. Here, we SCP the admin -openrc.sh file to the Fuel Master node.

Next, we SSH to the Fuel Master Node, using the password to log in.


29-10-2015 & 30-10-2015


Now for our second leapfrog jump. First, we SCP the RC file to the CWD of the root account on the Controller server.

-openrc.sh file to the

password, because Fuel is pre -authenticated. Finally, SSH to the Controller server.


29-10-2015 & 30-10-2015


We SSH into the Controller node as root, completing the leapfrog access path.

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.

command keystone tenant -list will produce a list of tenants (projects) currently active in our cloud.


29-10-2015 & 30-10-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

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.

glance image-listby default in Mirantis OpenStack Express.
http://wp.me/p2WWnY-2GvLhttp://wp.me/p2WWnY-2Gv9http://wp.me/p2WWnY-2Gv9https://www.mirantis.com/wp-content/uploads/2014/10/103.png


29-10-2015 & 30-10-2015


The command glance image -list

calling the script install-apache.sh: #!/bin/bash /usr/bin/apt -get -qy update /usr/bin/apt -get -qy install apache2 echo "Hello world!" > /var/www/html/index2.html


29-10-2015 & 30-10-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

Now we can check out the VM flavors available to us by entering nova flavor-list.

We can also remind ourselves of the keypairs we have available by executing nova keypair-list


29-10-2015 & 30-10-2015


eck to see what

nova network-list.

Horizon to give it a floating IP to make it accessible from the internet.


29-10-2015 & 30-10-2015


nova network -list to find IDs for available networks, and attach our instance to the net04 internal network.

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.


29-10-2015 & 30-10-2015


The command gives back a table of VM details and status fields.

of the floating IPs we have a vailable (I only have two assigned to this demo cloud).

it can be accessed via the Internet.


29-10-2015 & 30-10-2015


It is!

Our fancy custom index2.html file has been created on our test server, and is served by Apache.

OpenStack command-line functions. Stay tuned! Intro to 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 Cepfilesystem 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 end points.

Swift proxy in MOX to permit use of Public containers and objects.

A Quick Tweak


29-10-2015 & 30-10-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,

so

deprecated mechanism). fault 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.

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

fine.


29-10-2015 & 30-10-2015


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 fo ur-part construct comprising the Storage URL, tenant ID, container name, and object name.


29-10-2015 & 30-10-2015


by appending the object name. http://23.246.243.215:8080/v1/AUTH_928c39946889488283 da99126148cc3f/DemoContainer/image.png

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

we get a page back with the message Authentication required.

But because Mirantis OpenStack Expre ss is default -configured with Public URLs off (because it uses Keystone authentication), this Public URL

configuration. 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

popdown of the Mirantis OpenStack


29-10-2015 & 30-10-2015


window, SSH into the Fuel Master node, then SSH to our Controller node using its -

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.

vi to edit /etc/swift/proxy -server.conf.

under [filter:authtoken] , and change its value from 0 to 1. Then save the file and exit.


29-10-2015 & 30-10-2015


Now we use vi>/i> to edit the file /etc/swift/proxy -server.conf , changing the value of variable delay_auth_decision from 0 to 1.

/etc/init.d/openstack -swift-proxy restart.


29-10-2015 & 30-10-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.

works!

Going Private

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.


29-10-2015 & 30-10-2015


Now that the container is private, it no longer displays a Public URL.

and the owner of this container we can still access

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.


29-10-2015 & 30-10-2015


The command swift stat DemoContainer shows us information about our now -private container, including the blank Read ACL (Access Control List)

We can also do: keystone tenant-list

container. As you can see, the Account is just AUTH_ with the tenant ID appended.


29-10-2015 & 30-10-2015


The Account identifier shown by swift stat DemoContainer is just AUTH_, prepended to the admin keystone tenant -list shows.

admin, a quick way to get this is to issue the Swift client command: swift stat -v

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.


29-10-2015 & 30-10-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/DemoContainer/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 terminal screen with scary graphics.


29-10-2015 & 30-10-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.


29-10-2015 & 30-10-2015


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

OpenStack REST functions via a terminal, using a tool like cURL that allows rapid iteration.

leapfrogging in using Fuel. On our Dashboard, click the Credentials link, grab the ssword.

-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

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

authenticate RESTfully, stracommand line.


29-10-2015 & 30-10-2015


The swift stat -v command returns your StorageURL and an Auth Token.

command, and recover both a token and t he 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


29-10-2015 & 30-10-2015


You can find the internal address of your Keystone in Horizon, under ab.

meaning that it lets us do anything

dangerous to use an unscoped token to access storage and other important

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.

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

ck 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 -this is an expanded form of the json for a default token: it conveys the username, password, and the project s called admin. At the end, we put the internal URL for Keystone and the port (5000), appending to this URL /v3/auth/tokens

ll find -

Returned Data

We can extract our token from the saved header file.


29-10-2015 & 30-10-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 object -store. Or we can extract the Public URLs for all components with grep and awk, or


29-10-2015 & 30-10-2015


URL for your Object St ore. Composing a cURL expression with token and Storage URL, appending the name of

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.

Thanks for watching! Intro to Heat Orchestration

Step by Step

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.

ots of flexibility for working with various kinds of source -code control systems for versioning and maintaining template and template -

template itself in a moment perspective of a user.


29-10-2015 & 30-10-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.

subnet you want to put the VM on, and the external network you want to c onnect the instance to, using a floating IP. Except for the instance name, defaults are supplied for all these values.


29-10-2015 & 30-10-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.

floating IPs, its SSH keypair and other details.


29-10-2015 & 30-10-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 manipul able 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.

Openstack Manual

Documents

Transcript of Openstack Manual