Coacourseslides 1530220008 3

Certified OpenStack Administrator
(COA)
Course Introduction
Certified OpenStack Administrator (COA)

About the Course
This course is designed to prepare you for the OpenStack Foundation’s Certified OpenStack Administrator exam.
In order to assist you in passing the exam, the course will have the following elements:
• Overview of OpenStack and related services
• Hands-on Labs to give you practical experience with tasks
• Troubleshooting
• Practice Exam

Course Pre-Requisites
When taking the exam, it is assumed that the student has six months of hands-on experience as an OpenStack
administrator. It is OK not to meet this requirement as our course covers all the required hands-on OpenStack
knowledge. However, the following courses are highly recommended:
• Linux Essentials
• OpenStack Essentials

Certification Objectives:
Getting to Know OpenStack – 3% • Understand the components that make up the cloud
• Use the OpenStack API/CLI

Getting to Know OpenStack – 3% • Manage Keystone catalogue services and endpoints

• Manage/Create domains, groups, projects, users, and
Identity Management – 12% roles
• Create roles for the environment
• Manage the identity service
• Verify operation of the Identity service

Getting to Know OpenStack – 3% • Verify operation of the Dashboard
Identity Management – 12%
Dashboard – 3%

Getting to Know OpenStack – 3% • Manage flavors

• Manage compute instance actions (e.g. launch,
Identity Management – 12% shutdown, terminate)
• Manage Nova user key pairs
Dashboard – 3% • Launch a new instance
• Shutdown an Instance
Compute – 15% • Terminate an Instance
• Configure an Instance with a Floating IP address
• Manage project security group rules
• Assign security group to an Instance
• Assign floating IP address to an Instance
• Detach floating IP address from an Instance
• Manage Nova host consoles (rdp, spice, tty)

Getting to Know OpenStack – 3% • Access an Instance using a key pair

• Manage instance snapshots
Identity Management – 12% • Manage Nova compute servers
• Manage quotas
Dashboard – 3% • Get Nova stats (hosts, services, tenants)
• Verify operation of the Compute service
Compute – 15%

Getting to Know OpenStack – 3% • Manage access to object storage

• Manage expiring objects
Identity Management – 12% • Manage storage policies
• Monitor space available for object store
Dashboard – 3% • Verify operation of Object Storage
• Manage permissions on a container in object storage
Compute – 15%
Object Storage – 10%

Getting to Know OpenStack – 3% • Manage volumes

• Create volume group for block storage
Identity Management – 12% • Create a new Block Storage Volume and mount it to a
Nova Instance
Dashboard – 3% • Manage quotas
• Manage volumes quotas
Compute – 15% • Manage volumes backups
• Backup and restore volumes
Object Storage – 10% • Manage volume snapshots (e.g, take, list, recover)
• Verify that block storage can perform snapshotting
Block Storage – 10% function
• Snapshot volume
• Manage volumes encryption
• Set up storage pools
• Monitor reserve capacity of block storage devices
• Analyze discrepancies in reported volume sizes

Getting to Know OpenStack – 3% • Manage network resources (e.g., routers, subnets)

• Create external networks
Identity Management – 12% • Create project networks
• Create project routers
Dashboard – 3% • Manage network services for a virtual environment
• Manage project security group rules
Compute – 15% • Manage quotas
• Verify operation of network service
Object Storage – 10% • Manage network interfaces on compute instances
• Troubleshoot network issues for a tenant network (enter
Block Storage – 10% namespace, run tcpdump, etc)
Networking – 16%

Getting to Know OpenStack – 3% • Launch a stack using a Heat/Orchestration template

(e.g., storage, network, and compute)
Identity Management – 12% • Use Heat/Orchestration CLI and Dashboard
• Verify Heat/Orchestration stack is working
Dashboard – 3% • Verify operation of Heat/Orchestration
• Create a Heat/Orchestration template that matches a
Compute – 15% specific scenario
• Update a stack
Object Storage – 10% • Obtain detailed information about a stack
Block Storage – 10%
Networking – 16%
Heat/Orchestration – 8%

Getting to Know OpenStack – 3% • Analyze log files
• Backup the database(s) used by an OpenStack instance
Identity Management – 12% • Centralize and analyze logs
(e.g.,/var/log/COMPONENT_NAME, Database Server,
Dashboard – 3% Messaging Server, Web Server, syslog)
• Analyze database servers
Compute – 15%
• Analyze Host/Guest OS and Instance status
Object Storage – 10% • Analyze messaging servers
• Analyze metadata servers
Block Storage – 10% • Analyze network status (physical & virtual)
Networking – 16%
Troubleshooting – 13%

Getting to Know OpenStack – 3% • Analyze storage status (local, block & object)
• Manage OpenStack Services
Identity Management – 12% • Diagnose service incidents
• Digest OpenStack environment (Controller, Compute,
Dashboard – 3% Storage and Network nodes)
• Direct logging files through centralized logging system
Compute – 15%
• Backup and restore an OpenStack instance
Object Storage – 10% • Troubleshoot network performance
Networking – 16%

Getting to Know OpenStack – 3% • Deploy a new image to an OpenStack instance
• Manage image types and backends
Identity Management – 12%
• Manage images (e.g. add, update, remove)
Dashboard – 3% • Verify operation of the Image Service
Compute – 15%
Object Storage – 10%
Networking – 16%
Image Management – 10%

(COA)
OpenStack Overview

OpenStack Community
180
86,561 Countries
People
20+ Million
676 Lines of Code
Organizations

OpenStack Projects/Services
Projects Services
Horizon Nova Dashboard Compute
Keystone Swift Identity Object Storage
Glance Cinder Image Block Storage
Neutron Heat Networking Orchestration

How the Services Interact

Logical Architecture

Dashboard - Horizon
§ OpenStack Dashboard is a modular Django web

application that provides administrators and
users with a graphical interface to access,
provision, and automate the deployment of
cloud-based resources.
§ Allows for third party products and services, such

as billing, monitoring, and additional management
tools.
§ The dashboard is just one way to interact with

OpenStack resources.

Identity Service - Keystone
§ OpenStack Identity provides a single point of
integration for managing authentication,
authorization, and the service catalog.
§ Users and services can locate other services by
using the service catalog, which is managed by
the Identity service.
§ In order to benefit from Keystone, other
OpenStack services need to collaborate with it,
such as:
§ When an OpenStack service receives a
request from a user, it checks with the
Identity service whether the user is
authorized to make the request.
§ When an OpenStack user tries to reach a
service via an endpoint to perform a call to
its API.

Image Service - Glance
§ OpenStack Image Service enables users to discover,
register, and retrieve virtual machine images.
§ Glance accepts RESTful API requests for disk or

server images, and metadata definitions from end
users or OpenStack Compute components.
§ Glance also supports the storage of disk or server
images on various repository types, including
OpenStack Object Storage.
§ A number of periodic processes run on the

OpenStack Image service to support caching.
§ Replication services ensure consistency and

availability through the cluster.
§ Other periodic processes include auditors, updaters,

and reapers.

Networking Service - Neutron
§ OpenStack Networking manages all networking

facets for the Virtual Networking Infrastructure
(VNI) and the access layer aspects of the Physical
Networking Infrastructure (PNI) in your
OpenStack environment.
§ Neutron allows you to create and attach interface

devices managed by other OpenStack services to
networks.
§ Neutron enables projects to create advanced

virtual network topologies.
§ Plugins can be implemented to accommodate

different networking equipment and software,
providing flexibility to OpenStack architecture
and deployment.

Compute Service - Nova
§ OpenStack Compute is a major part of an
Infrastructure as a Service (IaaS) system. It
gives you control over instances and networks
and allows you to manage access to the cloud
through users and projects.
§ Nova interacts with other OpenStack services
in various ways; for example:
§ Identity for authentication
§ Dashboard for the user and
administrative interfaces
§ Image by limiting access by projects and
users
§ Nova limits quotas on a per project basis for
both floating and fixed IPs, number of
instances, number of volumes, amount of
RAM, and the number of CPUs.

Object Storage Service - Swift
• Used for storing Virtual machine images and data.
• Stores and retrieves arbitrary unstructured data

objects via a RESTful HTTP based API and is
available from anywhere.
• It is highly fault tolerant with its data replication

and scale-out architecture.
• Its implementation is not like a file server with

mountable directories.

Block Storage Service - Cinder
• Provides persistent block storage to running

instances.
• Its pluggable driver architecture facilitates the

creation and management of block storage
devices.
• Access associated with a VM.

Orchestration Service - Heat
§ OpenStack Orchestration service provides

template-based orchestration for describing a
cloud application by running OpenStack API calls
to generate running cloud applications.
§ The software integrates core OpenStack

components into a one-file template system.
§ The templates allow you to create most

OpenStack resource types, such as instances,
floating IPs, volumes, security groups, and users.
§ Heat also provides advanced functionality, such

as instance high availability, instance auto-scaling,
and nested stacks.

(COA)
OpenStack Dashboard Service - Horizon

Horizon

(COA)
Identity Service Terminology

Identity Terminology:
Service Refers to a service running in OpenStack, such as Compute

(Nova), Object Storage (Swift), or Image Service (Glance).
Provided by one or more endpoints in which users can

access resources and perform operations.

Service Network-accessible addresses where you can access a

given service via a URL and port.
Endpoint
Can be configured to service requests on three URLs: a
public facing URL, an administration URL, and an internal
URL.

Service A listing of the different endpoints that have been created

for the OpenStack services.
Endpoint
Catalog

Service A set of any resources assigned to an isolated group of

users.
Endpoint
Catalog
Project

Service Used by services and administrators to manage the

OpenStack cloud.
Endpoint
A digital representation of a person, system, or service who
Catalog uses OpenStack services.
Project Keystone validates the incoming requests made by the user

who claims to be making the call.
User
Have a login and may be assigned a token to access
resources.
Must be assigned to a project and be assigned a role.

Service Roles are the permissions given to users within a project.
Endpoint A first-class piece of metadata associated with the user for

the project, assigned directly to users or groups for projects
Catalog or inherited from domains
Project
User
Role

Service Identifying credentials associated with a user; an arbitrary

bit of text that is used to access resources.
Endpoint
A token may be revoked at any time and is valid for a finite
Catalog duration.
Project While OpenStack Identity supports token-based

authentication, the intention is to support additional
User protocols in the future.
Role
Token

Service A collection of users.
Endpoint
Catalog
Project
User
Role
Token
Group

Service Data that is known only by the user that proves who they
are; such as a username and password, a username and API
Endpoint key, or an authentication token.
Catalog
Project
User
Role
Token
Group
Credential

Service A collection of projects, groups, and users that define the
administrative boundaries for managing OpenStack Identity
Endpoint entities.
Catalog
Project
User
Role
Token
Group
Credential
Domain

Service Separates the OpenStack environments that have
dedicated API endpoints but utilize a common Keystone
Endpoint
service.
Catalog
Project
User
Role
Token
Group
Credential
Domain
Region

Identity Service - Keystone

Identity Workflow

(COA)
OpenStack Image Service - Glance

Image Management Service - Glance
• Glance is the component that discovers, registers, and retrieves virtual machine images
• Capabilities of the Image Service:
• Administrators can create base templates from which their users can start new compute instances
• Users can choose from available images or create their own from existing servers
• Snapshots can be stored in the Image Service so that virtual machines can be backed up quickly

Glance Architecture

Glance Workflow

(COA)
OpenStack Network Service - Neutron

Neutron Architecture

Networking Terminology:
Provider Networks Provider networks offer layer 2 connectivity to instances

with optional support for DHCP and metadata services.
These networks connect, or map, to existing layer 2

networks in the data center, typically using VLAN (802.1q)
tagging to identify and separate them.

Provider Networks Routed provider networks offer layer 3 connectivity to

instances. Two hosts that are connected to the same
Routed Provider Networks switch but on different VLANs so they do not see each
other’s traffic.
Routed provider networks offer performance at scale that

is difficult to achieve with a plain provider network at the
expense of guaranteed layer 2 connectivity.

Provider Networks Flat:

• All instances reside on the same network, which can also
Routed Provider Networks be shared with the hosts. No VLAN tagging or other
network segregation takes place.
Self-service Networks

Provider Networks VLAN:

• Networking allows users to create multiple providers or
Routed Provider Networks project networks using VLAN IDs (802.1Q tagged) that
correspond to VLANs present in the physical network.

Provider Networks VXLAN and GRE:

• VXLAN and GRE are encapsulation protocols that create
Routed Provider Networks overlay networks to activate and control communication
between compute instances.

Provider Networks A block of IP addresses and associated configuration

states.
Routed Provider Networks
Subnets

Provider Networks End users normally can create subnets with any valid IP
addresses without other restrictions.
Routed Provider Networks
Subnets
Subnet Pools

Provider Networks Routers provide virtual layer 3 services such as routing and
NAT between self-service and provider networks or among
Routed Provider Networks self-service networks belonging to a project.
Subnets
Subnet Pools
Routers

Provider Networks Security groups provide a container for virtual firewall rules
that control ingress (inbound to instances) and egress
Routed Provider Networks (outbound from instances) network traffic at the port level.
Self-service Networks Security groups use a default deny policy and only contain
rules that allow specific traffic.
Subnets
Each port can reference one or more security groups in an
Subnet Pools additive fashion.
Routers
Security Groups

Provider Networks Hosts connected to a network use the Dynamic Host

Configuration Protocol (DHCP) to dynamically obtain IP
Routed Provider Networks addresses.
Self-service Networks A DHCP server hands out the IP addresses to network

hosts, which are the DHCP clients.
Subnets
Subnet Pools
Routers
Security Groups
DHCP

(COA)
OpenStack Compute Service - Nova

How Does Nova Work?

Nova Services
Nova API The Compute API, run by the nova-api daemon, is the
component of OpenStack Compute that receives and
responds to user requests, whether they are direct API calls
or via the CLI tools or dashboard
The API enables users to specify an administrative

password when they create or rebuild a server instance. If
the user does not specify a password, a random password
is generated and returned in the API response
Nova API is stateless and can be used for HA deployments

Nova Services
Nova API Compute uses the nova-scheduler service to determine

how to dispatch compute requests
Nova Scheduler
The nova-scheduler service determines which host will
launch a VM
In the context of filters used with the nova-scheduler, the

term host means a physical node that has a nova-compute
service running on it
The daemon generally resides on the controller node

Nova Services
Nova API The nova-conductor service enables OpenStack to

function without compute nodes accessing the database
Nova Scheduler
Conceptually, it implements a new layer on top of nova-
Nova Conductor compute
Just like other Nova services, such as nova-api or nova-

scheduler, it can scale horizontally

Nova Services
Nova API This daemon primarily creates and terminates VMs via
Hypervisor API
Nova Scheduler
It allows multiple hypervisor types per cloud
Nova Conductor
Libvirt/KVM and QEMU are the most commonly used in
Nova Compute deployments

Nova Services
Nova API The Nova database stores the current state of all objects in
the compute cluster
Nova Scheduler
The database is usually MySQL, but SQLite and PostgreSQL
Nova Conductor can also be used
Nova Compute The nova-conductor service is the only service that writes
to the database. The other Compute services access the
Nova Database database through the nova-conductor service

Nova Services
Nova API Message Queue is a unified way for collaboration between

sub-components
Nova Scheduler
RabbitMQ is the most commonly used queueing system
Nova Conductor
Can use multiple queues within a single RabbitMQ instance:
Nova Compute • Used by the OpenStack services to build machine state
• Each compute node has a queue
Nova Database
RabbitMQ nodes failover on the application and the
Message Queue infrastructure layers when used in HA

Nova Services
Nova API The purpose of the cells functionality in Nova is specifically

to allow larger deployments to shard their many compute
Nova Scheduler nodes into cells, each of which has a database and message
queue.
Nova Conductor
Nova Compute
Nova Database
Message Queue
Cells v2

Nova Services
Nova API The purpose of the cells functionality in Nova is specifically

to allow larger deployments to shard their many compute
Nova Scheduler nodes into cells, each of which has a database and message
queue.
Nova Conductor
Nova Compute
Nova Database
Message Queue
Cells v2

Virtual Machine Placement
• The nova-scheduler interacts with other components
through the queue and central database
• All of the compute nodes periodically publish their status,

resources available, and hardware capabilities to nova-
scheduler through the queue
• nova-scheduler then collects the status data and uses it
to make decisions when requests come in
• By default, the compute scheduler is configured as a

filter scheduler
• In a default configuration, the scheduler considers hosts

that meet the following criteria:
• In the requested Availability Zone (AbilityZoneFilter)
• Have sufficient RAM available (RamFilter)
• Capable of servicing the request (ComputeFilter)

Placement API
• Is a separate REST API stack and data model used to track resource provider inventories and usages,
along with different classes of resources
• Example resource providers are:
• A compute node
• A shared storage pool
• An IP allocation pool
• The types of resources consumed are tracked as classes
• Example resource classes are:
• DISK_GB
• MEMORY_MB
• VCPU

(COA)
OpenStack Object Storage - Swift

What is Object Storage?
• Object Storage (Swift) is a robust, highly-scalable, and fault-tolerant storage platform for unstructured data
such as objects
• It is commonly used to archive and back up data, with use cases in virtual machine image, photo, video, and
music storage
• Provides a high degree of availability, throughput, and performance with its scale-out architecture

CAP Theorem
• Distributed systems cannot

simultaneously guarantee:
• Consistency
• Availability
• Partition tolerance
CONSISTENCY PARTITION AVAILABILITY
(Same View) TOLERANCE (Data Access)
(Node
• Swift chooses Availability and
Access)
Partition Tolerance over
Consistency
Enforced Eventual
Consistency Consistency

Features and Benefits
• Leverages commodity hardware • Runs on industry-standard hardware, such as DELL, HP,

and Supermicro
• No vendor lock-in

• Leverages commodity hardware • Self-healing, reliable, data redundancy that protects from
failures
• HDD/node failure agnostic
• Detects drive failures, preventing data corruption
• Failed nodes and disks can be swapped out with no

downtime

• Leverages commodity hardware • Utilizes a large, flat namespace
• HDD/node failure agnostic • Highly scalable read/write access
• Unlimited Storage • Serves content directly from storage system

• Leverages commodity hardware • Cluster can be scaled out both horizontally and vertically
• HDD/node failure agnostic • New nodes and drives can be added with no downtime
• Unlimited Storage • Raid not required, so data scales without a resize
• Highly Scalable Architecture

• Leverages commodity hardware • Users can set an expiration time or a TTL on an object to
control access
• HDD/node failure agnostic
• Unlimited Storage
• Object Expiration

• Leverages commodity hardware • Objects are accessed directly via a browser
• HDD/node failure agnostic • Object data can be located anywhere in the cluster
• Unlimited Storage
• Object Expiration
• All objects stored in Object Storage have a URL

Swift Overview
swift-proxy
SWIFT NODE SWIFT NODE
Account Container Object Account Container Object
Account Container Object Account Container Object

DB DB Store DB DB Store

Rings
• A ring represents a mapping between

the names of entities stored on a
disk and their physical locations
PARTITION PARTITION PARTITION
• The ring maintains the mapping,
using zones, devices, partitions, and
replicas:
The Ring
• Each partition in the ring is
replicated, by default, three times
across the cluster, and partition
locations are stored in the mapping
maintained by the ring
• The ring is also responsible for STORAGE
determining which devices are NODE
used for handoffs in failure
scenarios

Zones
• Object Storage allows configuring zones in

order to isolate failure boundaries:
• Each data replica resides in a separate
zone, if possible
• At the smallest level, a zone can be a single
drive or a grouping of a few drives
• If there were five object storage servers,
then each server would represent its own
ZONE 1 ZONE 2 ZONE 3 ZONE 4 ZONE 5
zone
• The goal of zones is to allow the cluster to
tolerate significant outages of storage
servers without losing all replicas of the data
• Everything in Object Storage is stored, by

default, three times

Accounts and Containers ACCOUNT DATABASE
• Each account and container is an

individual SQLite database that is
distributed across the cluster
• An account database contains the list of

CONTAINER DATABASE
containers in that account
• A container database contains the list of

objects in that container
OBJECT
OBJ OBJ OBJ

OBJ OBJ

Partitions
• A partition is a collection of stored
data, including account databases,
and objects:
• Partitions are core to the
replications system ACCOUNT DATABASE CONTAINER DATABASE
• System replicators and object

uploads/downloads operate on Partition is
partitions: assigned to ZONE ZONE
three disks in ZONE
different 1 2 3
• As the system scales up, its OBJECT zones
behavior continues to be
predictable because of the
number of partitions is a fixed OBJ OBJ OBJ
number OBJ OBJ
• Implementing a partition is
conceptually simple; a partition is
just a directory sitting on a disk with
a corresponding hash table of
what it contains

Replicators
• In order to ensure that there are

three copies of the data
everywhere, replicators
continuously examine each
partition Storage Storage Storage Storage Storage
Node Node Node Node Node
• The replicator knows if the

Storage Storage Storage Storage Storage
replication needs to take place Node Node Node Node Node
by examining hashes
Storage Storage Storage Storage Storage
• This is where partitions come in Node Node Node Node Node
handy
• The cluster eventually has a ZONE 1 ZONE 2 ZONE 3 ZONE 4 ZONE 5

consistent behavior where the
newest data has priority

(COA)
Swift ACLs

Controlling Read Access
• HTTP referer header can read container • -r “.r:*”

contents

• HTTP referer header can read container • -r “.r:*,.rlistings”

contents
• HTTP referer header can read and list

container contents

• HTTP referer header can read container • -r “.r:openstack.example.com,.r:swift.example.com”

contents

container contents
• A list of specific HTTP referer headers

permitted to read container contents

• HTTP referer header can read container • -r “.r:*,.r:-openstack.example.com,.r:-swift.example.com”

contents

container contents

• A list of specific HTTP referer headers denied

read access

• HTTP referer header can read container • -r “project1:*”

contents

container contents


read access
• All users residing in project1 can read

container contents

• HTTP referer header can read container • -r “project1:user1”
contents
container contents
read access
• All users residing in project1 can read
container contents
• user1 from project1 can read container
contents

• HTTP referer header can read container contents • -r “project1:user1,project1:user2,project3:*”
• HTTP referer header can read and list container

contents
• A list of specific HTTP referer headers permitted

to read container contents
• A list of specific HTTP referer headers denied read
access
• All users residing in project1 can read container

contents
• user1 from project1 can read container contents
• A list of specific users and projects permitted to

read container contents

Controlling Write Access
• All users residing in project1 can write to the • -w “project1:*”

container

• All users residing in project1 can write to the • -w “project1:user1”

container
• user1 from project1 can write to the container

• All users residing in project1 can write to the • -w “project1:user1,project1:user2,project3:*"

container
• user1 from project1 can write to the container
• A list of specific users and projects permitted

to write to the container

Expiring Objects
• Set an object to expire at an absolute time (in • -H "X-Delete-At:UNIX_TIME”

Unix time). You can get the current Unix time
by running date --date=<date> +%s

Expiring Objects
• Set an object to expire at an absolute time (in • -H "X-Delete-After:SECONDS"

• Set an object to expire after a relative amount

of time (in seconds)

Expiring Objects
• Set an object to expire at an absolute time (in • -H "X-Remove-Delete-At:"

• Set an object to expire after a relative amount

of time (in seconds)
• If you no longer want to expire the object, you

can remove the X-Delete-At header

(COA)
OpenStack Block Storage Service - Cinder

Cinder Architecture

Cinder Features
• Provides users with access to block-storage devices:
• Users interact with block storage by attaching volumes to their running VM instances
• Sometimes referred to as volume storage
• The running VM’s attached to these volumes are persistent
• They can be detached from one instance and re-attached to another, and the data remains intact

(COA)
OpenStack Orchestration Service - Heat

Heat Architecture

How Heat Works
A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable by
humans and can be checked into version control and used with, for example, Git.
Infrastructure resources that can be described include:
• Servers
• Floating IPs
• Volumes
• Security groups
• Users

Parts of a Heat Template
heat_template_version Formatting and supported features can vary based upon

the version
heat_template_version: 2013-05-23

heat_template_version The description provides the purpose of the template
description description: Test Stack

heat_template_version The parameter_groups section specifies how the input

parameters are grouped. Note a parameter can only be part
description of one group
parameter_groups Parameter groups are only to inform user interfaces and

other tooling and have no direct impact on the actual
orchestration
parameter_groups:

heat_template_version The parameters section is where you customize the

deployment
description
parameters:
parameter_groups ServerName:
type: string
parameters description: A name for the server
Image:
type: string
description: Image ID used to boot the server

heat_template_version Other type of information in parameters
description constraints:
- length: {min: 2}
parameter_groups
constraints:
parameters - allowed_values:
- m1.tiny
Additional parameters - m1.small
default: m1.tiny

heat_template_version The resources are declarations of the single resources of

the template
description
resources:
parameter_groups server1:
type: OS::Nova::Server
parameters properties:
name: { get_param: ServerName }
Additional parameters image: { get_param: Image }
flavor: { get_param: Flavor }
resources networks:
- network: { get_param: Net }

heat_template_version The outputs are how you receive information about the
stack from your Heat Orchestration Template
description
outputs:
parameter_groups private_ip:
description: Allocated IP
parameters value: {get_attr : [server_vm, first_address]}
Additional parameters
resources
outputs

(COA)
Get Certified

About the Exam:
• Cost $300

About the Exam:
• Cost You will have 1 year from the time you pay for the
exam to take it.
• Time from Registration

About the Exam:
• Cost You will need a desktop or laptop with either the

Chrome or Chromium browser
• Time from Registration Reliable Internet
Webcam and microphone
• System Requirements

About the Exam:
• Cost 2.5 hours
• Duration

About the Exam:
• Cost Acceptable forms of photo ID include current,

non-expired: passport, government-issued driver's
• Time from Registration license/permit, national ID card, state or province-
issued ID card, or other form of government issued
identification.
• Duration
• ID Requirements

About the Exam:
• Cost Performance-based exam performing tasks and

solving problems utilizing the CLI or dashboard
• Duration
• ID Requirements
• Format

About the Exam:
• Cost You will receive your score within 3 business days
• Time from Registration 76 or higher is passing

• Duration
• ID Requirements
• Format
• Scoring

About the Exam:
• Cost Certification is valid for 36 months before expiring
• Duration
• ID Requirements
• Format
• Scoring
• Certification Period

About the Exam:
• Cost The exam is currently only available in English.
• Duration
• ID Requirements
• Format
• Scoring
• Certification Period
• Language

Tips for the Exam:
• Watch your time!
• Attempt to answer all the questions to increase your chances
• Complete the questions you know first and go back to others
• Report any issues to the Proctor
• Cut and paste where possible - project names, UUIDs, etc.
• You will not need to install OpenStack services or edit configurations
• You can install favorite editors, etc. if you need them
• Not everything can be accomplished in the dashboard, make a note of those things and be prepared to use
the CLI

Tips for the Exam:
• The OpenStack docs are available through the interface, but try not to need them.
• Use --help if you’re unsure about a command on the CLI, pipe to less, and grep to avoid page scroll.
• If the OpenStack CLI doesn’t have the functionality you need, fall back to the project client like we did using
swift. Utilize their help as well.

References
• OpenStack COA site:
• https://www.openstack.org/coa/
• Superuser Article on the Newton COA Release:
• http://superuser.openstack.org/articles/certified-openstack-administrator-exam-newton/
• OpenStack Summit Boston Panel on ’Why You should Take the COA’:
• https://www.openstack.org/videos/boston-2017/the-coa-and-why-you-should-take-it
• OpenStack Summit Sydney Presentation on ‘The All New COA’:
• https://www.openstack.org/videos/sydney-2017/the-all-new-coa
• OpenStack Summit Vancouver Presentation on ‘COA: The Importance for Your Career’:
• https://www.openstack.org/videos/vancouver-2018/coa-the-importance-for-your-career-
and-tips-to-achieve-it-in-english-and-en-espanol

(COA)
Where to Next?

Where to Next?
OpenStack Certification Courses Mirantis OCM100 Certification Course
RedHat OpenStack Platform Prep Courses:

• RHCSA
• RHCE

Where to Next?
OpenStack Certification Courses Deploy and Manage OpenStack Pike on Ubuntu
Other OpenStack Courses Deploy and Manage OpenStack Newton on Ubuntu

Where to Next?
OpenStack Certification Courses Google Cloud Platform
Amazon Web Services
Other OpenStack Courses Red Hat Linux Certifications
DevOPS:
Other Areas l Git
l Ansible
l Docker
Containers:
l Kubernetes
l Docker
l LXC/LXD
Python

Coacourseslides 1530220008 3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Coacourseslides 1530220008 3

Uploaded by

Copyright:

Available Formats

Certified OpenStack Administrator

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Manage Keystone catalogue services and endpoints

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Verify operation of the Dashboard

Identity Management – 12%

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Manage flavors

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Access an Instance using a key pair

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Manage access to object storage

Object Storage – 10%

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Manage volumes

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Manage network resources (e.g., routers, subnets)

Certified OpenStack Administrator (COA)

Getting to Know OpenStack – 3% • Launch a stack using a Heat/Orchestration template

Block Storage – 10%

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Block Storage – 10%

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Horizon Nova Dashboard Compute

Keystone Swift Identity Object Storage

Glance Cinder Image Block Storage

Neutron Heat Networking Orchestration

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

§ OpenStack Dashboard is a modular Django web

§ Allows for third party products and services, such

§ The dashboard is just one way to interact with

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

§ Glance accepts RESTful API requests for disk or

§ A number of periodic processes run on the

§ Replication services ensure consistency and

§ Other periodic processes include auditors, updaters,

Certified OpenStack Administrator (COA)

§ OpenStack Networking manages all networking

§ Neutron allows you to create and attach interface

§ Neutron enables projects to create advanced

§ Plugins can be implemented to accommodate

Certified OpenStack Administrator (COA)

Certified OpenStack Administrator (COA)

• Used for storing Virtual machine images and data.

• Stores and retrieves arbitrary unstructured data

• It is highly fault tolerant with its data replication

• Its implementation is not like a file server with

Certified OpenStack Administrator (COA)

• Provides persistent block storage to running

• Its pluggable driver architecture facilitates the

• Access associated with a VM.

Certified OpenStack Administrator (COA)