openstack/openstack-manuals
Code Issues Proposed changes

restructure of associate training guide

Browse Source 
cleaning up the work that was starting at the icehouse summit. Removed some
of the work we started as it was going in the wrong direction. Added in
timeline which helped to limit the amount of content available for a two
day class. operator guide will take on the rest of the material that was
in the associate guide.

backport:none
implements bp/training-manuals

Change-Id: I6656afddee16c3deeb61c1ebc91522f45fd6d300
This commit is contained in:
Sean Roberts 2013-11-19 20:31:14 -08:00
parent 197e99f447
commit cbf64bff9c
59 changed files with 293 additions and 7464 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/training-guide/associate-compute-node-concept-neutron.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-concept-neutron">
<title>Conceptual Neutron</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-compute-node-concept-nova.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-concept-nova">
<title>Conceptual Nova</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-compute-node-install-neutron.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-install-neutron">
<title>Install Neutron</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-compute-node-install-nova.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-install-nova">
<title>Install Nova</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-compute-node-lab.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-lab">
<title>Lab</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-compute-node-quiz.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-quiz">
<title>Quiz</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

14
doc/training-guide/associate-compute-node.xml
View File

@ -1,14 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-computer-node">
<title>Compute Node</title>
<xi:include href="associate-compute-node-concept-nova.xml"/>
<xi:include href="associate-compute-node-install-nova.xml"/>
<xi:include href="associate-compute-node-concept-neutron.xml"/>
<xi:include href="associate-compute-node-install-neutron.xml"/>
<xi:include href="associate-compute-node-lab.xml"/>
<xi:include href="associate-compute-node-quiz.xml"/>
</chapter>

249
doc/training-guide/associate-controller-node-concept-cinder.xml
View File

@ -1,249 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-cinder">
<title>Conceptual Cinder</title>
<para>OpenStack Block Storage</para>
<para><emphasis role="bold">Block Storage and OpenStack
Compute</emphasis></para>
<para>OpenStack provides two classes of block storage, "ephemeral"
storage and persistent "volumes". Ephemeral storage exists only
for the life of an instance, it will persist across reboots of the
guest operating system but when the instance is deleted so is the
associated storage. All instances have some ephemeral storage.
Volumes are persistent virtualized block devices independent of
any particular instance. Volumes may be attached to a single
instance at a time, but may be detached or reattached to a
different instance while retaining all data, much like a USB
drive.</para>
<para><guilabel>Ephemeral Storage</guilabel></para>
<para>Ephemeral storage is associated with a single unique instance.
Its size is defined by the flavor of the instance.</para>
<para>Data on ephemeral storage ceases to exist when the instance it
is associated with is terminated. Rebooting the VM or restarting
the host server, however, will not destroy ephemeral data. In the
typical use case an instance's root filesystem is stored on
ephemeral storage. This is often an unpleasant surprise for people
unfamiliar with the cloud model of computing.</para>
<para>In addition to the ephemeral root volume all flavors except
the smallest, m1.tiny, provide an additional ephemeral block
device varying from 20G for the m1.small through 160G for the
m1.xlarge by default - these sizes are configurable. This is
presented as a raw block device with no partition table or
filesystem. Cloud aware operating system images may discover,
format, and mount this device. For example the cloud-init package
included in Ubuntu's stock cloud images will format this space as
an ext3 filesystem and mount it on /mnt. It is important to note
this a feature of the guest operating system. OpenStack only
provisions the raw storage.</para>
<para><guilabel>Volume Storage</guilabel></para>
<para>Volume storage is independent of any particular instance and
is persistent. Volumes are user created and within quota and
availability limits may be of any arbitrary size.</para>
<para>When first created volumes are raw block devices with no
partition table and no filesystem. They must be attached to an
instance to be partitioned and/or formatted. Once this is done
they may be used much like an external disk drive. Volumes may
attached to only one instance at a time, but may be detached and
reattached to either the same or different instances.</para>
<para>It is possible to configure a volume so that it is bootable
and provides a persistent virtual instance similar to traditional
non-cloud based virtualization systems. In this use case the
resulting instance may still have ephemeral storage depending on
the flavor selected, but the root filesystem (and possibly others)
will be on the persistent volume and thus state will be maintained
even if the instance it shutdown. Details of this configuration
are discussed in the<link
xlink:href="http://docs.openstack.org/user-guide/content/"
>OpenStack End User Guide</link>.</para>
<para>Volumes do not provide concurrent access from multiple
instances. For that you need either a traditional network
filesystem like NFS or CIFS or a cluster filesystem such as
GlusterFS. These may be built within an OpenStack cluster or
provisioned outside of it, but are not features provided by the
OpenStack software.</para>
<para>The OpenStack Block Storage service works via the interaction
of a series of daemon processes named cinder-* that reside
persistently on the host machine or machines. The binaries can all
be run from a single node, or spread across multiple nodes. They
can also be run on the same node as other OpenStack
services.</para>
<para><guilabel>The current services available in OpenStack Block
Storage are:</guilabel></para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">cinder-api</emphasis> - The
cinder-api service is a WSGI app that authenticates and routes
requests throughout the Block Storage system. It supports the
OpenStack API's only, although there is a translation that can
be done via Nova's EC2 interface which calls in to the
cinderclient.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">cinder-scheduler</emphasis> - The
cinder-scheduler is responsible for scheduling/routing
requests to the appropriate volume service. As of Grizzly;
depending upon your configuration this may be simple
round-robin scheduling to the running volume services, or it
can be more sophisticated through the use of the Filter
Scheduler. The Filter Scheduler is the default in Grizzly and
enables filter on things like Capacity, Availability Zone,
Volume Types and Capabilities as well as custom
filters.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">cinder-volume</emphasis> - The
cinder-volume service is responsible for managing Block
Storage devices, specifically the back-end devices
themselves.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">cinder-backup</emphasis> - The
cinder-backup service provides a means to back up a Cinder
Volume to OpenStack Object Store (SWIFT).</para>
</listitem>
</itemizedlist>
<para><guilabel>Introduction to OpenStack Block
Storage</guilabel></para>
<para>OpenStack Block Storage provides persistent High Performance
Block Storage resources that can be consumed by OpenStack Compute
instances. This includes secondary attached storage similar to
Amazon's Elastic Block Storage (EBS). In addition images can be
written to a Block Storage device and specified for OpenStack
Compute to use a bootable persistent instance.</para>
<para>There are some differences from Amazon's EBS that one should
be aware of. OpenStack Block Storage is not a shared storage
solution like NFS, but currently is designed so that the device is
attached and in use by a single instance at a time.</para>
<para><guilabel>Backend Storage Devices</guilabel></para>
<para>OpenStack Block Storage requires some form of back-end storage
that the service is built on. The default implementation is to use
LVM on a local Volume Group named "cinder-volumes". In addition to
the base driver implementation, OpenStack Block Storage also
provides the means to add support for other storage devices to be
utilized such as external Raid Arrays or other Storage
appliances.</para>
<para><guilabel>Users and Tenants (Projects)</guilabel></para>
<para>The OpenStack Block Storage system is designed to be used by
many different cloud computing consumers or customers, basically
tenants on a shared system, using role-based access assignments.
Roles control the actions that a user is allowed to perform. In
the default configuration, most actions do not require a
particular role, but this is configurable by the system
administrator editing the appropriate policy.json file that
maintains the rules. A user's access to particular volumes is
limited by tenant, but the username and password are assigned per
user. Key pairs granting access to a volume are enabled per user,
but quotas to control resource consumption across available
hardware resources are per tenant.</para>
<para><guilabel>For tenants, quota controls are available to limit
the:</guilabel></para>
<itemizedlist>
<listitem>
<para>Number of volumes which may be created</para>
</listitem>
<listitem>
<para>Number of snapshots which may be created</para>
</listitem>
<listitem>
<para>Total number of Giga Bytes allowed per tenant (shared
between snapshots and volumes)</para>
</listitem>
</itemizedlist>
<para><guilabel>Volumes Snapshots and Backups</guilabel></para>
<para>This introduction provides a high level overview of the two
basic resources offered by the OpenStack Block Storage service.
The first is Volumes and the second is Snapshots which are derived
from Volumes.</para>
<para><guilabel>Volumes</guilabel></para>
<para>Volumes are allocated block storage resources that can be
attached to instances as secondary storage or they can be used as
the root store to boot instances. Volumes are persistent R/W Block
Storage devices most commonly attached to the Compute node via
iSCSI.</para>
<para><guilabel>Snapshots</guilabel></para>
<para>A Snapshot in OpenStack Block Storage is a read-only point in
time copy of a Volume. The Snapshot can be created from a Volume
that is currently in use (via the use of '--force True') or in an
available state. The Snapshot can then be used to create a new
volume via create from snapshot.</para>
<para><guilabel>Backups</guilabel></para>
<para>A Backup is an archived copy of a Volume currently stored in
Object Storage (Swift).</para>
<para><guilabel>Managing Volumes</guilabel></para>
<para>Cinder is the OpenStack service that allows you to give extra
block level storage to your OpenStack Compute instances. You may
recognize this as a similar offering from Amazon EC2 known as
Elastic Block Storage (EBS). The default Cinder implementation is
an iSCSI solution that employs the use of Logical Volume Manager
(LVM) for Linux. Note that a volume may only be attached to one
instance at a time. This is not a ‘shared storage’ solution like a
SAN of NFS on which multiple servers can attach to. It's also
important to note that Cinder also includes a number of drivers to
allow you to use a number of other vendor's back-end storage
devices in addition to or instead of the base LVM
implementation.</para>
<para>Here is brief walk-through of a simple create/attach sequence,
keep in mind this requires proper configuration of both OpenStack
Compute via cinder.conf and OpenStack Block Storage via
cinder.conf.</para>
<orderedlist>
<listitem>
<para>The volume is created via cinder create; which creates
an LV into the volume group (VG) "cinder-volumes"</para>
</listitem>
<listitem>
<para>The volume is attached to an instance via nova
volume-attach; which creates a unique iSCSI IQN that will be
exposed to the compute node</para>
</listitem>
<listitem>
<para>The compute node which run the concerned instance has
now an active ISCSI session; and a new local storage
(usually a /dev/sdX disk)</para>
</listitem>
<listitem>
<para>libvirt uses that local storage as a storage for the
instance; the instance get a new disk (usually a /dev/vdX
disk)</para>
</listitem>
</orderedlist>
<para><guilabel>Block Storage Capabilities</guilabel></para>
<itemizedlist>
<listitem>
<para>OpenStack provides persistent block level storage
devices for use with OpenStack compute instances.</para>
</listitem>
<listitem>
<para>The block storage system manages the creation, attaching
and detaching of the block devices to servers. Block storage
volumes are fully integrated into OpenStack Compute and the
Dashboard allowing for cloud users to manage their own
storage needs.</para>
</listitem>
<listitem>
<para>In addition to using simple Linux server storage, it has
unified storage support for numerous storage platforms
including Ceph, NetApp, Nexenta, SolidFire, and
Zadara.</para>
</listitem>
<listitem>
<para>Block storage is appropriate for performance sensitive
scenarios such as database storage, expandable file systems,
or providing a server with access to raw block level
storage.</para>
</listitem>
<listitem>
<para>Snapshot management provides powerful functionality for
backing up data stored on block storage volumes. Snapshots
can be restored or used to create a new block storage
volume.</para>
</listitem>
</itemizedlist>
</section>

11
doc/training-guide/associate-controller-node-concept-glance.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-glance">
<title>Conceptual Glance</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

2613
doc/training-guide/associate-controller-node-concept-horizon.xml
View File

File diff suppressed because it is too large Load Diff

172
doc/training-guide/associate-controller-node-concept-keystone.xml
View File

@ -1,172 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-keystone">
<title>Conceptual Keystone</title>
<para>More Content To be Added ...</para>
<para><guilabel>Identity Service Concepts</guilabel></para>
<para>The Identity service performs the following
functions:</para>
<itemizedlist>
<listitem>
<para>User management. Tracks users and their
permissions.</para>
</listitem>
<listitem>
<para>Service catalog. Provides a catalog of available
services with their API endpoints.</para>
</listitem>
</itemizedlist>
<para>To understand the Identity Service, you must understand the
following concepts:</para>
<para><guilabel>User</guilabel></para>
<para>Digital representation of a person, system, or service who
uses OpenStack cloud services. Identity authentication
services will validate that incoming request are being made by
the user who claims to be making the call. Users have a login
and may be assigned tokens to access resources. Users may be
directly assigned to a particular tenant and behave as if they
are contained in that tenant.</para>
<para><guilabel><anchor xml:id="h.i1npk4aiu35hs"/>Credentials</guilabel></para>
<para>Data that is known only by a user that proves who they
are. In the Identity Service, examples are:</para>
<itemizedlist>
<listitem>
<para>Username and password</para>
</listitem>
<listitem>
<para>Username and API key</para>
</listitem>
<listitem>
<para>An authentication token provided by the Identity
Service</para>
</listitem>
</itemizedlist>
<para><guilabel><anchor xml:id="h.aa29gdlbf7qas"/>Authentication</guilabel></para>
<para>The act of confirming the identity of a user. The Identity
Service confirms an incoming request by validating a set of
credentials supplied by the user. These credentials are
initially a username and password or a username and API key.
In response to these credentials, the Identity Service issues
the user an authentication token, which the user provides in
subsequent requests.</para>
<para><guilabel><anchor xml:id="h.grqljkbnx8fss"/>Token</guilabel></para>
<para>An arbitrary bit of text that is used to access resources.
Each token has a scope which describes which resources are
accessible with it. A token may be revoked at anytime and is
valid for a finite duration.</para>
<para>While the Identity Service supports token-based
authentication in this release, the intention is for it to
support additional protocols in the future. The intent is for
it to be an integration service foremost, and not aspire to be
a full-fledged identity store and management solution.</para>
<para><guilabel><anchor xml:id="h.qz798xvt751fs"/>Tenant</guilabel></para>
<para>A container used to group or isolate resources and/or
identity objects. Depending on the service operator, a tenant
may map to a customer, account, organization, or
project.</para>
<para><guilabel><anchor xml:id="h.ayp97sn984mys"/>Service</guilabel></para>
<para>An OpenStack service, such as Compute (Nova), Object
Storage (Swift), or Image Service (Glance). Provides one or
more endpoints through which users can access resources and
perform operations.</para>
<para><guilabel><anchor xml:id="h.74y77xwdnwlms"/>Endpoint</guilabel></para>
<para>An network-accessible address, usually described by URL,
from where you access a service. If using an extension for
templates, you can create an endpoint template, which
represents the templates of all the consumable services that
are available across the regions.</para>
<para><guilabel><anchor xml:id="h.r7samiog05ins"/>Role</guilabel></para>
<para>A personality that a user assumes that enables them to
perform a specific set of operations. A role includes a set of
rights and privileges. A user assuming that role inherits
those rights and privileges.</para>
<para>In the Identity Service, a token that is issued to a user
includes the list of roles that user can assume. Services that
are being called by that user determine how they interpret the
set of roles a user has and which operations or resources each
role grants access to.</para>
<figure>
<title>Keystone Authentication</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image19.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel><anchor xml:id="h.rdpcpnbvn06ws"/>User management</guilabel></para>
<para>The main components of Identity user management are:</para>
<itemizedlist>
<listitem>
<para>Users</para>
</listitem>
<listitem>
<para>Tenants</para>
</listitem>
<listitem>
<para>Roles</para>
</listitem>
</itemizedlist>
<para>A userrepresents a human user, and has associated
information such as username, password and email. This example
creates a user named "alice":</para>
<para>$ keystone user-create --name=alice --pass=mypassword123
--email=alice@example.com</para>
<para>A tenantcan be a project, group, or organization. Whenever
you make requests to OpenStack services, you must specify a
tenant. For example, if you query the Compute service for a list
of running instances, you will receive a list of all of the
running instances in the tenant you specified in your query.
This example creates a tenant named "acme":</para>
<para>$ keystone tenant-create --name=acmeA rolecaptures what
operations a user is permitted to perform in a given tenant.
This example creates a role named "compute-user":</para>
<para>$ keystone role-create --name=compute-userThe Identity
service associates a user with a tenant and a role. To continue
with our previous examples, we may wish to assign the "alice"
user the "compute-user" role in the "acme" tenant:</para>
<para>$ keystone user-list</para>
<para>$ keystone user-role-add --user=892585 --role=9a764e
--tenant-id=6b8fd2</para>
<para>A user can be assigned different roles in different tenants:
for example, Alice may also have the "admin" role in the
"Cyberdyne" tenant. A user can also be assigned multiple roles
in the same tenant.</para>
<para>The /etc/[SERVICE_CODENAME]/policy.json controls what users
are allowed to do for a given service. For example,
/etc/nova/policy.json specifies the access policy for the
Compute service, /etc/glance/policy.json specifies the access
policy for the Image service, and /etc/keystone/policy.json
specifies the access policy for the Identity service.</para>
<para>The default policy.json files in the Compute, Identity, and
Image service recognize only the admin role: all operations that
do not require the admin role will be accessible by any user
that has any role in a tenant.</para>
<para>If you wish to restrict users from performing operations in,
say, the Compute service, you need to create a role in the
Identity service and then modify /etc/nova/policy.json so that
this role is required for Compute operations.</para>
<para>For example, this line in /etc/nova/policy.json specifies
that there are no restrictions on which users can create
volumes: if the user has any role in a tenant, they will be able
to create volumes in that tenant.</para>
<para><guilabel><anchor xml:id="h.f5989v85c3fds"/></guilabel></para>
<para><guilabel><anchor xml:id="h.1rrjgvz0nkwhs"/>Service
management</guilabel></para>
<para>The Identity Service provides the following service
management functions:</para>
<itemizedlist>
<listitem>
<para>Services</para>
</listitem>
<listitem>
<para>Endpoints</para>
</listitem>
</itemizedlist>
<para>The Identity Service also maintains a user that corresponds
to each service (such as, a user named nova, for the Compute
service) and a special service tenant, which is called
service.</para>
<para>The commands for creating services and endpoints are
described in a later section.</para>
</section>

11
doc/training-guide/associate-controller-node-concept-mysql.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-mysql">
<title>Conceptual MySQL</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

331
doc/training-guide/associate-controller-node-concept-neutron.xml
View File

@ -1,331 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-neutron">
<title>Conceptual Neutron</title>
<itemizedlist>
<listitem>
<para>Networking in OpenStack</para>
<para><guilabel>Networking in OpenStack</guilabel></para>
<para>OpenStack Networking provides a rich tenant-facing API
for defining network connectivity and addressing in the
cloud. The OpenStack Networking project gives operators
the ability to leverage different networking technologies
to power their cloud networking. It is a virtual network
service that provides a powerful API to define the network
connectivity and addressing used by devices from other
services, such as OpenStack Compute. It has a rich API
which consists of the following components.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Network:</emphasis> An
isolated L2 segment, analogous to VLAN in the physical
networking world.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Subnet:</emphasis> A block
of v4 or v6 IP addresses and associated configuration
state.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Port:</emphasis> A
connection point for attaching a single device, such
as the NIC of a virtual server, to a virtual network.
Also describes the associated network configuration,
such as the MAC and IP addresses to be used on that
port.</para>
</listitem>
</itemizedlist>
<para>You can configure rich network topologies by creating
and configuring networks and subnets, and then instructing
other OpenStack services like OpenStack Compute to attach
virtual devices to ports on these networks. In
particular, OpenStack Networking supports each tenant
having multiple private networks, and allows tenants to
choose their own IP addressing scheme, even if those IP
addresses overlap with those used by other tenants. This
enables very advanced cloud networking use cases, such as
building multi-tiered web applications and allowing
applications to be migrated to the cloud without changing
IP addresses.</para>
<para><guilabel>Plugin Architecture: Flexibility to Choose
Different Network Technologies</guilabel></para>
<para>Enhancing traditional networking solutions to provide rich
cloud networking is challenging. Traditional networking is not
designed to scale to cloud proportions or to configure
automatically.</para>
<para>The original OpenStack Compute network implementation
assumed a very basic model of performing all isolation through
Linux VLANs and IP tables. OpenStack Networking introduces the
concept of a plugin, which is a pluggable back-end
implementation of the OpenStack Networking API. A plugin can
use a variety of technologies to implement the logical API
requests. Some OpenStack Networking plugins might use basic
Linux VLANs and IP tables, while others might use more
advanced technologies, such as L2-in-L3 tunneling or OpenFlow,
to provide similar benefits.</para>
<para>The current set of plugins include:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Open vSwitch:</emphasis>
Documentation included in this guide.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Cisco:</emphasis> Documented
externally at: <link
xlink:href="http://wiki.openstack.org/cisco-quantum"
>http://wiki.openstack.org/cisco-quantum</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Linux Bridge:</emphasis>
Documentation included in this guide and <link
xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
>http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin</link>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Nicira NVP:</emphasis>
Documentation include in this guide, <link
xlink:href="http://www.vmware.com/products/datacenter-virtualization/nicira.html"
>NVP Product Overview </link>, and <link
xlink:href="http://www.nicira.com/support">NVP
Product Support</link>.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Ryu:</emphasis>
<link
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
>https://github.com/osrg/ryu/wiki/OpenStack</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">NEC OpenFlow:</emphasis>
<link
xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin"
>http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Big Switch, Floodlight REST
Proxy:</emphasis>
<link
xlink:href="http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin"
>http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">PLUMgrid:</emphasis>
<link
xlink:href="https://wiki.openstack.org/wiki/Plumgrid-quantum"
>https://wiki.openstack.org/wiki/Plumgrid-quantum</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Hyper-V
Plugin</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">Brocade
Plugin</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">Midonet
Plugin</emphasis></para>
</listitem>
</itemizedlist>
<para>Plugins can have different properties in terms of hardware
requirements, features, performance, scale, operator tools,
etc. Supporting many plugins enables the cloud administrator
to weigh different options and decide which networking
technology is right for the deployment.</para>
<para>Components of OpenStack Networking</para>
<para>To deploy OpenStack Networking, it is useful to understand
the different components that make up the solution and how
those components interact with each other and with other
OpenStack services.</para>
<para>OpenStack Networking is a standalone service, just like
other OpenStack services such as OpenStack Compute, OpenStack
Image service, OpenStack Identity service, and the OpenStack
Dashboard. Like those services, a deployment of OpenStack
Networking often involves deploying several processes on a
variety of hosts.</para>
<para>The main process of the OpenStack Networking server is
quantum-server, which is a Python daemon that exposes the
OpenStack Networking API and passes user requests to the
configured OpenStack Networking plugin for additional
processing. Typically, the plugin requires access to a
database for persistent storage, similar to other OpenStack
services.</para>
<para>If your deployment uses a controller host to run centralized
OpenStack Compute components, you can deploy the OpenStack
Networking server on that same host. However, OpenStack
Networking is entirely standalone and can be deployed on its
own server as well. OpenStack Networking also includes
additional agents that might be required depending on your
deployment:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">plugin agent
(quantum-*-agent):</emphasis>Runs on each
hypervisor to perform local vswitch configuration.
Agent to be run depends on which plugin you are using,
as some plugins do not require an agent.</para>
</listitem>
<listitem>
<para><emphasis role="bold">dhcp agent
(quantum-dhcp-agent):</emphasis>Provides DHCP
services to tenant networks. This agent is the same
across all plugins.</para>
</listitem>
<listitem>
<para><emphasis role="bold">l3 agent
(quantum-l3-agent):</emphasis>Provides L3/NAT
forwarding to provide external network access for VMs
on tenant networks. This agent is the same across all
plugins.</para>
</listitem>
</itemizedlist>
<para>These agents interact with the main quantum-server process
in the following ways:</para>
<itemizedlist>
<listitem>
<para>Through RPC. For example, rabbitmq or qpid.</para>
</listitem>
<listitem>
<para>Through the standard OpenStack Networking
API.</para>
</listitem>
</itemizedlist>
<para>OpenStack Networking relies on the OpenStack Identity
Project (Keystone) for authentication and authorization of all
API request.</para>
<para>OpenStack Compute interacts with OpenStack Networking
through calls to its standard API. As part of creating a VM,
nova-compute communicates with the OpenStack Networking API to
plug each virtual NIC on the VM into a particular
network.</para>
<para>The OpenStack Dashboard (Horizon) has integration with the
OpenStack Networking API, allowing administrators and tenant
users, to create and manage network services through the
Horizon GUI.</para>
<para><emphasis role="bold">Place Services on Physical
Hosts</emphasis></para>
<para>Like other OpenStack services, OpenStack Networking provides
cloud administrators with significant flexibility in deciding
which individual services should run on which physical
devices. On one extreme, all service daemons can be run on a
single physical host for evaluation purposes. On the other,
each service could have its own physical hosts, and some cases
be replicated across multiple hosts for redundancy.</para>
<para>In this guide, we focus primarily on a standard architecture
that includes a “cloud controller” host, a “network gateway”
host, and a set of hypervisors for running VMs. The "cloud
controller" and "network gateway" can be combined in simple
deployments, though if you expect VMs to send significant
amounts of traffic to or from the Internet, a dedicated
network gateway host is suggested to avoid potential CPU
contention between packet forwarding performed by the
quantum-l3-agent and other OpenStack services.</para>
<para><emphasis role="bold">Network Connectivity for Physical
Hosts</emphasis></para>
<figure>
<title>Network Diagram</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image33.png"/>
</imageobject>
</mediaobject>
</figure>
<para>A standard OpenStack Networking setup has up to four
distinct physical data center networks:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Management
network:</emphasis>Used for internal communication
between OpenStack Components. The IP addresses on this
network should be reachable only within the data
center.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Data network:</emphasis>Used
for VM data communication within the cloud deployment.
The IP addressing requirements of this network depend
on the OpenStack Networking plugin in use.</para>
</listitem>
<listitem>
<para><emphasis role="bold">External
network:</emphasis>Used to provide VMs with Internet
access in some deployment scenarios. The IP addresses
on this network should be reachable by anyone on the
Internet.</para>
</listitem>
<listitem>
<para><emphasis role="bold">API network:</emphasis>Exposes
all OpenStack APIs, including the OpenStack Networking
API, to tenants. The IP addresses on this network
should be reachable by anyone on the Internet. This
may be the same network as the external network, as it
is possible to create a subnet for the external
network that uses IP allocation ranges to use only
less than the full range of IP addresses in an IP
block.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>OpenStack Networking Concepts</para>
<para><emphasis role="bold">Network Types</emphasis></para>
<para>The OpenStack Networking configuration provided by the
Rackspace Private Cloud cookbooks allows you to choose between
VLAN or GRE isolated networks, both provider- and
tenant-specific. From the provider side, an administrator can
also create a flat network.</para>
<para>The type of network that is used for private tenant networks
is determined by the network_type attribute, which can be
edited in the Chef override_attributes. This attribute sets
both the default provider network type and the only type of
network that tenants are able to create. Administrators can
always create flat and VLAN networks. GRE networks of any type
require the network_type to be set to gre.</para>
<para><emphasis role="bold">Namespaces</emphasis></para>
<para>For each network you create, the Network node (or Controller
node, if combined) will have a unique network namespace
(netns) created by the DHCP and Metadata agents. The netns
hosts an interface and IP addresses for dnsmasq and the
quantum-ns-metadata-proxy. You can view the namespaces with
the ip netns [list], and can interact with the namespaces with
the ip netns exec &lt;namespace&gt; &lt;command&gt;
command.</para>
<para><emphasis role="bold">Metadata</emphasis></para>
<para>Not all networks or VMs need metadata access. Rackspace
recommends that you use metadata if you are using a single
network. If you need metadata, you may also need a default
route. (If you don't need a default route, no-gateway will
do.)</para>
<para>To communicate with the metadata IP address inside the
namespace, instances need a route for the metadata network
that points to the dnsmasq IP address on the same namespaced
interface. OpenStack Networking only injects a route when you
do not specify a gateway-ip in the subnet.</para>
<para>If you need to use a default route and provide instances
with access to the metadata route, create the subnet without
specifying a gateway IP and with a static route from 0.0.0.0/0
to your gateway IP address. Adjust the DHCP allocation pool so
that it will not assign the gateway IP. With this
configuration, dnsmasq will pass both routes to instances.
This way, metadata will be routed correctly without any
changes on the external gateway.</para>
<para><emphasis role="bold">OVS Bridges</emphasis></para>
<para>An OVS bridge for provider traffic is created and configured
on the nodes where single-network-node and single-compute are
applied. Bridges are created, but physical interfaces are not
added. An OVS bridge is not created on a Controller-only
node.</para>
<para>When creating networks, you can specify the type and
properties, such as Flat vs. VLAN, Shared vs. Tenant, or
Provider vs. Overlay. These properties identify and determine
the behavior and resources of instances attached to the
network. The cookbooks will create bridges for the
configuration that you specify, although they do not add
physical interfaces to provider bridges. For example, if you
specify a network type of GRE, a br-tun tunnel bridge will be
created to handle overlay traffic.</para>
</listitem>
</itemizedlist>
</section>

11
doc/training-guide/associate-controller-node-concept-nova.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-nova">
<title>Conceptual Nova</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

442
doc/training-guide/associate-controller-node-concept-rabbitmq.xml
View File

@ -1,442 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-concept-rabbitmq">
<title>Conceptual RabbitMQ (Messging in OpenStack)</title>
<figure>
<title>Messaging in OpenStack</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image04.png"/>
</imageobject>
</mediaobject>
</figure>
<para>AMQP is the messaging technology chosen by the OpenStack
cloud. The AMQP broker, either RabbitMQ or Qpid, sits between any
two Nova components and allows them to communicate in a loosely
coupled fashion. More precisely, Nova components (the compute
fabric of OpenStack) use Remote Procedure Calls (RPC hereinafter)
to communicate to one another; however such a paradigm is built
atop the publish/subscribe paradigm so that the following benefits
can be achieved:</para>
<itemizedlist>
<listitem>
<para>Decoupling between client and servant (such as the client
does not need to know where the servant’s reference
is).</para>
</listitem>
<listitem>
<para>Full a-synchronism between client and servant (such as the
client does not need the servant to run at the same time of
the remote call).</para>
</listitem>
<listitem>
<para>Random balancing of remote calls (such as if more servants
are up and running, one-way calls are transparently dispatched
to the first available servant).</para>
</listitem>
</itemizedlist>
<para>Nova uses direct, fanout, and topic-based exchanges. The
architecture looks like the one depicted in the figure
below:</para>
<figure>
<title>AMQP</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image24.png"/>
</imageobject>
</mediaobject>
</figure>
<para>Nova implements RPC (both request+response, and one-way,
respectively nicknamed ‘rpc.call’ and ‘rpc.cast’) over AMQP by
providing an adapter class which take cares of marshaling and
unmarshaling of messages into function calls. Each Nova service
(for example Compute, Scheduler, etc.) create two queues at the
initialization time, one which accepts messages with routing keys
‘NODE-TYPE.NODE-ID’ (for example compute.hostname) and another,
which accepts messages with routing keys as generic ‘NODE-TYPE’
(for example compute). The former is used specifically when
Nova-API needs to redirect commands to a specific node like
‘euca-terminate instance’. In this case, only the compute node
whose host’s hypervisor is running the virtual machine can kill
the instance. The API acts as a consumer when RPC calls are
request/response, otherwise is acts as publisher only.</para>
<para><guilabel>Nova RPC Mappings</guilabel></para>
<para>The figure below shows the internals of a message broker
node (referred to as a RabbitMQ node in the diagrams) when a
single instance is deployed and shared in an OpenStack cloud.
Every Nova component connects to the message broker and,
depending on its personality (for example a compute node or a
network node), may use the queue either as an Invoker (such as
API or Scheduler) or a Worker (such as Compute or Network).
Invokers and Workers do not actually exist in the Nova object
model, but we are going to use them as an abstraction for sake
of clarity. An Invoker is a component that sends messages in the
queuing system via two operations: 1) rpc.call and ii) rpc.cast;
a Worker is a component that receives messages from the queuing
system and reply accordingly to rcp.call operations.</para>
<para>Figure 2 shows the following internal elements:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Topic Publisher:</emphasis>a Topic
Publisher comes to life when an rpc.call or an rpc.cast
operation is executed; this object is instantiated and used to
push a message to the queuing system. Every publisher connects
always to the same topic-based exchange; its life-cycle is
limited to the message delivery.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Consumer:</emphasis>a
Direct Consumer comes to life if (an only if) a rpc.call
operation is executed; this object is instantiated and used to
receive a response message from the queuing system; Every
consumer connects to a unique direct-based exchange via a
unique exclusive queue; its life-cycle is limited to the
message delivery; the exchange and queue identifiers are
determined by a UUID generator, and are marshaled in the
message sent by the Topic Publisher (only rpc.call
operations).</para>
</listitem>
<listitem>
<para><emphasis role="bold">Topic Consumer:</emphasis>a Topic
Consumer comes to life as soon as a Worker is instantiated and
exists throughout its life-cycle; this object is used to
receive messages from the queue and it invokes the appropriate
action as defined by the Worker role. A Topic Consumer
connects to the same topic-based exchange either via a shared
queue or via a unique exclusive queue. Every Worker has two
topic consumers, one that is addressed only during rpc.cast
operations (and it connects to a shared queue whose exchange
key is ‘topic’) and the other that is addressed only during
rpc.call operations (and it connects to a unique queue whose
exchange key is ‘topic.host’).</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Publisher:</emphasis>a
Direct Publisher comes to life only during rpc.call operations
and it is instantiated to return the message required by the
request/response operation. The object connects to a
direct-based exchange whose identity is dictated by the
incoming message.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Topic Exchange:</emphasis>The
Exchange is a routing table that exists in the context of a
virtual host (the multi-tenancy mechanism provided by Qpid or
RabbitMQ); its type (such as topic vs. direct) determines the
routing policy; a message broker node will have only one
topic-based exchange for every topic in Nova.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Exchange:</emphasis>this is
a routing table that is created during rpc.call operations;
there are many instances of this kind of exchange throughout
the life-cycle of a message broker node, one for each rpc.call
invoked.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Queue Element:</emphasis>A Queue
is a message bucket. Messages are kept in the queue until a
Consumer (either Topic or Direct Consumer) connects to the
queue and fetch it. Queues can be shared or can be exclusive.
Queues whose routing key is ‘topic’ are shared amongst Workers
of the same personality.</para>
</listitem>
</itemizedlist>
<figure>
<title>RabbitMQ</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image20.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>RPC Calls</guilabel></para>
<para>The diagram below shows the message flow during an rp.call
operation:</para>
<orderedlist>
<listitem>
<para>a Topic Publisher is instantiated to send the message
request to the queuing system; immediately before the
publishing operation, a Direct Consumer is instantiated to
wait for the response message.</para>
</listitem>
<listitem>
<para>once the message is dispatched by the exchange, it is
fetched by the Topic Consumer dictated by the routing key
(such as ‘topic.host’) and passed to the Worker in charge of
the task.</para>
</listitem>
<listitem>
<para>once the task is completed, a Direct Publisher is
allocated to send the response message to the queuing
system.</para>
</listitem>
<listitem>
<para>once the message is dispatched by the exchange, it is
fetched by the Direct Consumer dictated by the routing key
(such as ‘msg_id’) and passed to the Invoker.</para>
</listitem>
</orderedlist>
<figure>
<title>RabbitMQ</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image28.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>RPC Casts</guilabel></para>
<para>The diagram below the message flow during an rp.cast
operation:</para>
<orderedlist>
<listitem>
<para>A Topic Publisher is instantiated to send the message
request to the queuing system.</para>
</listitem>
<listitem>
<para>Once the message is dispatched by the exchange, it is
fetched by the Topic Consumer dictated by the routing key
(such as ‘topic’) and passed to the Worker in charge of the
task.</para>
</listitem>
</orderedlist>
<figure>
<title>RabbitMQ</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image20.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>AMQP Broker Load</guilabel></para>
<para>At any given time the load of a message broker node running
either Qpid or RabbitMQ is function of the following
parameters:</para>
<itemizedlist>
<listitem>
<para>Throughput of API calls: the number of API calls (more
precisely rpc.call ops) being served by the OpenStack cloud
dictates the number of direct-based exchanges, related
queues and direct consumers connected to them.</para>
</listitem>
<listitem>
<para>Number of Workers: there is one queue shared amongst
workers with the same personality; however there are as many
exclusive queues as the number of workers; the number of
workers dictates also the number of routing keys within the
topic-based exchange, which is shared amongst all
workers.</para>
</listitem>
</itemizedlist>
<para>The figure below shows the status of a RabbitMQ node after
Nova components’ bootstrap in a test environment. Exchanges and
queues being created by Nova components are:</para>
<itemizedlist>
<listitem>
<para>Exchanges</para>
</listitem>
</itemizedlist>
<orderedlist>
<listitem>
<para>nova (topic exchange)</para>
</listitem>
</orderedlist>
<itemizedlist>
<listitem>
<para>Queues</para>
</listitem>
</itemizedlist>
<orderedlist>
<listitem>
<para>compute.phantom (phantom is hostname)</para>
</listitem>
<listitem>
<para>compute</para>
</listitem>
<listitem>
<para>network.phantom (phantom is hostname)</para>
</listitem>
<listitem>
<para>network</para>
</listitem>
<listitem>
<para>scheduler.phantom (phantom is hostname)</para>
</listitem>
<listitem>
<para>scheduler</para>
</listitem>
</orderedlist>
<para><guilabel>RabbitMQ Gotchas</guilabel></para>
<para>Nova uses Kombu to connect to the RabbitMQ environment.
Kombu is a Python library that in turn uses AMQPLib, a library
that implements the standard AMQP 0.8 at the time of writing.
When using Kombu, Invokers and Workers need the following
parameters in order to instantiate a Connection object that
connects to the RabbitMQ server (please note that most of the
following material can be also found in the Kombu documentation;
it has been summarized and revised here for sake of
clarity):</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Hostname:</emphasis> The hostname
to the AMQP server.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Userid:</emphasis> A valid
username used to authenticate to the server.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Password:</emphasis> The password
used to authenticate to the server.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Virtual_host:</emphasis> The name
of the virtual host to work with. This virtual host must exist
on the server, and the user must have access to it. Default is
“/”.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Port:</emphasis> The port of the
AMQP server. Default is 5672 (amqp).</para>
</listitem>
</itemizedlist>
<para>The following parameters are default:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Insist:</emphasis> insist on
connecting to a server. In a configuration with multiple
load-sharing servers, the Insist option tells the server that
the client is insisting on a connection to the specified
server. Default is False.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Connect_timeout:</emphasis> the
timeout in seconds before the client gives up connecting to
the server. The default is no timeout.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SSL:</emphasis> use SSL to connect
to the server. The default is False.</para>
</listitem>
</itemizedlist>
<para>More precisely Consumers need the following
parameters:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Connection:</emphasis> the above
mentioned Connection object.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Queue:</emphasis>name of the
queue.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Exchange:</emphasis>name of the
exchange the queue binds to.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Routing_key:</emphasis>the
interpretation of the routing key depends on the value of the
exchange_type attribute.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Direct exchange:</emphasis>if the
routing key property of the message and the routing_key
attribute of the queue are identical, then the message is
forwarded to the queue.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Fanout
exchange:</emphasis>messages are forwarded to the queues bound
the exchange, even if the binding does not have a key.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Topic exchange:</emphasis>if the
routing key property of the message matches the routing key of
the key according to a primitive pattern matching scheme, then
the message is forwarded to the queue. The message routing key
then consists of words separated by dots (”.”, like domain
names), and two special characters are available; star (“”)
and hash (“#”). The star matches any word, and the hash
matches zero or more words. For example ”.stock.#” matches the
routing keys “usd.stock” and “eur.stock.db” but not
“stock.nasdaq”.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Durable:</emphasis>this flag
determines the durability of both exchanges and queues;
durable exchanges and queues remain active when a RabbitMQ
server restarts. Non-durable exchanges/queues (transient
exchanges/queues) are purged when a server restarts. It is
worth noting that AMQP specifies that durable queues cannot
bind to transient exchanges. Default is True.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Auto_delete:</emphasis>if set, the
exchange is deleted when all queues have finished using it.
Default is False.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Exclusive:</emphasis>exclusive
queues (such as non-shared) may only be consumed from by the
current connection. When exclusive is on, this also implies
auto_delete. Default is False.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Exchange_type:</emphasis>AMQP
defines several default exchange types (routing algorithms)
that covers most of the common messaging use cases.</para>
</listitem>
<listitem>
<para><emphasis role="bold"
>Auto_ack:</emphasis>acknowledgement is handled automatically
once messages are received. By default auto_ack is set to
False, and the receiver is required to manually handle
acknowledgment.</para>
</listitem>
<listitem>
<para><emphasis role="bold">No_ack:</emphasis>it disable
acknowledgement on the server-side. This is different from
auto_ack in that acknowledgement is turned off altogether.
This functionality increases performance but at the cost of
reliability. Messages can get lost if a client dies before it
can deliver them to the application.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Auto_declare:</emphasis>if this is
True and the exchange name is set, the exchange will be
automatically declared at instantiation. Auto declare is on by
default. Publishers specify most the parameters of Consumers
(such as they do not specify a queue name), but they can also
specify the following:</para>
</listitem>
<listitem>
<para><emphasis role="bold">Delivery_mode:</emphasis>the
default delivery mode used for messages. The value is an
integer. The following delivery modes are supported by
RabbitMQ:</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">1 or “transient”:</emphasis>the
message is transient. Which means it is stored in memory only,
and is lost if the server dies or restarts.</para>
</listitem>
<listitem>
<para><emphasis role="bold">2 or “persistent”:</emphasis>the
message is persistent. Which means the message is stored both
in-memory, and on disk, and therefore preserved if the server
dies or restarts.</para>
</listitem>
</itemizedlist>
<para>The default value is 2 (persistent). During a send
operation, Publishers can override the delivery mode of messages
so that, for example, transient messages can be sent over a
durable queue.</para>
</section>

11
doc/training-guide/associate-controller-node-install-cinder.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-cinder">
<title>Install Cinder</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-glance.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-glance">
<title>Install Glance</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-horizon.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-horizon">
<title>Install Horizon</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-keystone.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-keystone">
<title>Install Keystone</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-mysql.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-mysql">
<title>Conceptual MySQL</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-neutron.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-neutron">
<title>Install Neutron</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-nova.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-nova">
<title>Install Nova</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-install-rabbitmq.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-install-rabbitmq">
<title>Install RabbitMQ</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-lab.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-lab">
<title>Lab</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-controller-node-quiz.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-quiz">
<title>Quiz</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

26
doc/training-guide/associate-controller-node.xml
View File

@ -1,26 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-controller-node">
<title>Controller Node</title>
<xi:include href="associate-controller-node-concept-mysql.xml"></xi:include>
<xi:include href="associate-controller-node-install-mysql.xml"></xi:include>
<xi:include href="associate-controller-node-concept-rabbitmq.xml"></xi:include>
<xi:include href="associate-controller-node-install-rabbitmq.xml"></xi:include>
<xi:include href="associate-controller-node-concept-keystone.xml"></xi:include>
<xi:include href="associate-controller-node-install-keystone.xml"></xi:include>
<xi:include href="associate-controller-node-concept-glance.xml"></xi:include>
<xi:include href="associate-controller-node-install-glance.xml"></xi:include>
<xi:include href="associate-controller-node-concept-neutron.xml"></xi:include>
<xi:include href="associate-controller-node-install-neutron.xml"></xi:include>
<xi:include href="associate-controller-node-concept-nova.xml"></xi:include>
<xi:include href="associate-controller-node-install-nova.xml"></xi:include>
<xi:include href="associate-controller-node-concept-cinder.xml"></xi:include>
<xi:include href="associate-controller-node-install-cinder.xml"></xi:include>
<xi:include href="associate-controller-node-concept-horizon.xml"></xi:include>
<xi:include href="associate-controller-node-install-horizon.xml"></xi:include>
<xi:include href="associate-controller-node-lab.xml"></xi:include>
<xi:include href="associate-controller-node-quiz.xml"></xi:include>
</chapter>

1128
doc/training-guide/associate-getting-started.xml
View File

File diff suppressed because it is too large Load Diff

14
doc/training-guide/associate-horizon-cli-operations.xml
View File

@ -1,14 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="using-horizon-cli">
<title>Using Horizon and the CLI for Operations Tasks</title>
<xi:include href="module001-ch006-overview-horizon-cli.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(/*/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback></xi:include>
<para><link xlink:href="https://blueprints.launchpad.net/openstack-manuals/+filebug" xlink:show="new">Submit a bug on
the section above. Short description for the bug summary. Paragraph for the description and
then tag with training-manuals.</link></para>
</section>

657
doc/training-guide/associate-network-node-concept-neutron.xml
View File

@ -1,657 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-network-node-concept-neutron">
<title>Concept Neutron</title>
<section xml:id="mnetworking-in-openstack">
<title>Networking in OpenStack</title>
<para><guilabel>Networking in OpenStack</guilabel></para>
<para>OpenStack Networking provides a rich tenant-facing API
for defining network connectivity and addressing in the
cloud. The OpenStack Networking project gives operators
the ability to leverage different networking technologies
to power their cloud networking. It is a virtual network
service that provides a powerful API to define the network
connectivity and addressing used by devices from other
services, such as OpenStack Compute. It has a rich API
which consists of the following components.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Network:</emphasis> An
isolated L2 segment, analogous to VLAN in the physical
networking world.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Subnet:</emphasis> A block
of v4 or v6 IP addresses and associated configuration
state.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Port:</emphasis> A
connection point for attaching a single device, such
as the NIC of a virtual server, to a virtual network.
Also describes the associated network configuration,
such as the MAC and IP addresses to be used on that
port.</para>
</listitem>
</itemizedlist>
<para>You can configure rich network topologies by creating
and configuring networks and subnets, and then instructing
other OpenStack services like OpenStack Compute to attach
virtual devices to ports on these networks. In
particular, OpenStack Networking supports each tenant
having multiple private networks, and allows tenants to
choose their own IP addressing scheme, even if those IP
addresses overlap with those used by other tenants. This
enables very advanced cloud networking use cases, such as
building multi-tiered web applications and allowing
applications to be migrated to the cloud without changing
IP addresses.</para>
<para><guilabel>Plugin Architecture: Flexibility to Choose
Different Network Technologies</guilabel></para>
<para>Enhancing traditional networking solutions to provide rich
cloud networking is challenging. Traditional networking is not
designed to scale to cloud proportions or to configure
automatically.</para>
<para>The original OpenStack Compute network implementation
assumed a very basic model of performing all isolation through
Linux VLANs and IP tables. OpenStack Networking introduces the
concept of a plugin, which is a pluggable back-end
implementation of the OpenStack Networking API. A plugin can
use a variety of technologies to implement the logical API
requests. Some OpenStack Networking plugins might use basic
Linux VLANs and IP tables, while others might use more
advanced technologies, such as L2-in-L3 tunneling or OpenFlow,
to provide similar benefits.</para>
<para>The current set of plugins include:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Open vSwitch:</emphasis>
Documentation included in this guide.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Cisco:</emphasis> Documented
externally at: <link
xlink:href="http://wiki.openstack.org/cisco-quantum"
>http://wiki.openstack.org/cisco-quantum</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Linux Bridge:</emphasis>
Documentation included in this guide and <link
xlink:href="http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin"
>http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin</link>
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Nicira NVP:</emphasis>
Documentation include in this guide, <link
xlink:href="http://www.vmware.com/products/datacenter-virtualization/nicira.html"
>NVP Product Overview </link>, and <link
xlink:href="http://www.nicira.com/support">NVP
Product Support</link>.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Ryu:</emphasis>
<link
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
>https://github.com/osrg/ryu/wiki/OpenStack</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">NEC OpenFlow:</emphasis>
<link
xlink:href="http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin"
>http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Big Switch, Floodlight REST
Proxy:</emphasis>
<link
xlink:href="http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin"
>http://www.openflowhub.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">PLUMgrid:</emphasis>
<link
xlink:href="https://wiki.openstack.org/wiki/Plumgrid-quantum"
>https://wiki.openstack.org/wiki/Plumgrid-quantum</link></para>
</listitem>
<listitem>
<para><emphasis role="bold">Hyper-V
Plugin</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">Brocade
Plugin</emphasis></para>
</listitem>
<listitem>
<para><emphasis role="bold">Midonet
Plugin</emphasis></para>
</listitem>
</itemizedlist>
<para>Plugins can have different properties in terms of hardware
requirements, features, performance, scale, operator tools,
etc. Supporting many plugins enables the cloud administrator
to weigh different options and decide which networking
technology is right for the deployment.</para>
<para>Components of OpenStack Networking</para>
<para>To deploy OpenStack Networking, it is useful to understand
the different components that make up the solution and how
those components interact with each other and with other
OpenStack services.</para>
<para>OpenStack Networking is a standalone service, just like
other OpenStack services such as OpenStack Compute, OpenStack
Image service, OpenStack Identity service, and the OpenStack
Dashboard. Like those services, a deployment of OpenStack
Networking often involves deploying several processes on a
variety of hosts.</para>
<para>The main process of the OpenStack Networking server is
quantum-server, which is a Python daemon that exposes the
OpenStack Networking API and passes user requests to the
configured OpenStack Networking plugin for additional
processing. Typically, the plugin requires access to a
database for persistent storage, similar to other OpenStack
services.</para>
<para>If your deployment uses a controller host to run centralized
OpenStack Compute components, you can deploy the OpenStack
Networking server on that same host. However, OpenStack
Networking is entirely standalone and can be deployed on its
own server as well. OpenStack Networking also includes
additional agents that might be required depending on your
deployment:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">plugin agent
(quantum-*-agent):</emphasis>Runs on each
hypervisor to perform local vswitch configuration.
Agent to be run depends on which plugin you are using,
as some plugins do not require an agent.</para>
</listitem>
<listitem>
<para><emphasis role="bold">dhcp agent
(quantum-dhcp-agent):</emphasis>Provides DHCP
services to tenant networks. This agent is the same
across all plugins.</para>
</listitem>
<listitem>
<para><emphasis role="bold">l3 agent
(quantum-l3-agent):</emphasis>Provides L3/NAT
forwarding to provide external network access for VMs
on tenant networks. This agent is the same across all
plugins.</para>
</listitem>
</itemizedlist>
<para>These agents interact with the main quantum-server process
in the following ways:</para>
<itemizedlist>
<listitem>
<para>Through RPC. For example, rabbitmq or qpid.</para>
</listitem>
<listitem>
<para>Through the standard OpenStack Networking
API.</para>
</listitem>
</itemizedlist>
<para>OpenStack Networking relies on the OpenStack Identity
Project (Keystone) for authentication and authorization of all
API request.</para>
<para>OpenStack Compute interacts with OpenStack Networking
through calls to its standard API. As part of creating a VM,
nova-compute communicates with the OpenStack Networking API to
plug each virtual NIC on the VM into a particular
network.</para>
<para>The OpenStack Dashboard (Horizon) has integration with the
OpenStack Networking API, allowing administrators and tenant
users, to create and manage network services through the
Horizon GUI.</para>
<para><emphasis role="bold">Place Services on Physical
Hosts</emphasis></para>
<para>Like other OpenStack services, OpenStack Networking provides
cloud administrators with significant flexibility in deciding
which individual services should run on which physical
devices. On one extreme, all service daemons can be run on a
single physical host for evaluation purposes. On the other,
each service could have its own physical hosts, and some cases
be replicated across multiple hosts for redundancy.</para>
<para>In this guide, we focus primarily on a standard architecture
that includes a “cloud controller” host, a “network gateway”
host, and a set of hypervisors for running VMs. The "cloud
controller" and "network gateway" can be combined in simple
deployments, though if you expect VMs to send significant
amounts of traffic to or from the Internet, a dedicated
network gateway host is suggested to avoid potential CPU
contention between packet forwarding performed by the
quantum-l3-agent and other OpenStack services.</para>
<para><emphasis role="bold">Network Connectivity for Physical
Hosts</emphasis></para>
<figure>
<title>Network Diagram</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image33.png"/>
</imageobject>
</mediaobject>
</figure>
<para>A standard OpenStack Networking setup has up to four
distinct physical data center networks:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Management
network:</emphasis>Used for internal communication
between OpenStack Components. The IP addresses on this
network should be reachable only within the data
center.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Data network:</emphasis>Used
for VM data communication within the cloud deployment.
The IP addressing requirements of this network depend
on the OpenStack Networking plugin in use.</para>
</listitem>
<listitem>
<para><emphasis role="bold">External
network:</emphasis>Used to provide VMs with Internet
access in some deployment scenarios. The IP addresses
on this network should be reachable by anyone on the
Internet.</para>
</listitem>
<listitem>
<para><emphasis role="bold">API network:</emphasis>Exposes
all OpenStack APIs, including the OpenStack Networking
API, to tenants. The IP addresses on this network
should be reachable by anyone on the Internet. This
may be the same network as the external network, as it
is possible to create a subnet for the external
network that uses IP allocation ranges to use only
less than the full range of IP addresses in an IP
block.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="openstack-networking-concepts">
<title>OpenStack Networking Concepts</title>
<para><emphasis role="bold">Network Types</emphasis></para>
<para>The OpenStack Networking configuration provided by the
Rackspace Private Cloud cookbooks allows you to choose between
VLAN or GRE isolated networks, both provider- and
tenant-specific. From the provider side, an administrator can
also create a flat network.</para>
<para>The type of network that is used for private tenant networks
is determined by the network_type attribute, which can be
edited in the Chef override_attributes. This attribute sets
both the default provider network type and the only type of
network that tenants are able to create. Administrators can
always create flat and VLAN networks. GRE networks of any type
require the network_type to be set to gre.</para>
<para><emphasis role="bold">Namespaces</emphasis></para>
<para>For each network you create, the Network node (or Controller
node, if combined) will have a unique network namespace
(netns) created by the DHCP and Metadata agents. The netns
hosts an interface and IP addresses for dnsmasq and the
quantum-ns-metadata-proxy. You can view the namespaces with
the ip netns [list], and can interact with the namespaces with
the ip netns exec &lt;namespace&gt; &lt;command&gt;
command.</para>
<para><emphasis role="bold">Metadata</emphasis></para>
<para>Not all networks or VMs need metadata access. Rackspace
recommends that you use metadata if you are using a single
network. If you need metadata, you may also need a default
route. (If you don't need a default route, no-gateway will
do.)</para>
<para>To communicate with the metadata IP address inside the
namespace, instances need a route for the metadata network
that points to the dnsmasq IP address on the same namespaced
interface. OpenStack Networking only injects a route when you
do not specify a gateway-ip in the subnet.</para>
<para>If you need to use a default route and provide instances
with access to the metadata route, create the subnet without
specifying a gateway IP and with a static route from 0.0.0.0/0
to your gateway IP address. Adjust the DHCP allocation pool so
that it will not assign the gateway IP. With this
configuration, dnsmasq will pass both routes to instances.
This way, metadata will be routed correctly without any
changes on the external gateway.</para>
<para><emphasis role="bold">OVS Bridges</emphasis></para>
<para>An OVS bridge for provider traffic is created and configured
on the nodes where single-network-node and single-compute are
applied. Bridges are created, but physical interfaces are not
added. An OVS bridge is not created on a Controller-only
node.</para>
<para>When creating networks, you can specify the type and
properties, such as Flat vs. VLAN, Shared vs. Tenant, or
Provider vs. Overlay. These properties identify and determine
the behavior and resources of instances attached to the
network. The cookbooks will create bridges for the
configuration that you specify, although they do not add
physical interfaces to provider bridges. For example, if you
specify a network type of GRE, a br-tun tunnel bridge will be
created to handle overlay traffic.</para>
</section>
<section xml:id="neutron-use-cases">
<title>Neutron Use Cases</title>
<para>As of now you must be wondering, how to use these awesome
features that OpenStack Networking has given to us.</para>
<para><guilabel><anchor xml:id="h.lrsgdytf1mh5"/>Use Case: Single Flat
Network</guilabel></para>
<para>In the simplest use case, a single OpenStack Networking
network exists. This is a "shared" network, meaning it is
visible to all tenants via the OpenStack Networking API.
Tenant VMs have a single NIC, and receive a fixed IP
address from the subnet(s) associated with that network.
This essentially maps to the FlatManager and
FlatDHCPManager models provided by OpenStack Compute.
Floating IPs are not supported.</para>
<para>It is common that such an OpenStack Networking network
is a "provider network", meaning it was created by the
OpenStack administrator to map directly to an existing
physical network in the data center. This allows the
provider to use a physical router on that data center
network as the gateway for VMs to reach the outside world.
For each subnet on an external network, the gateway
configuration on the physical router must be manually
configured outside of OpenStack.</para>
<figure>
<title>Single Flat Network</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image34.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>Use Case: Multiple Flat
Network</guilabel></para>
<para>This use case is very similar to the above Single Flat
Network use case, except that tenants see multiple shared
networks via the OpenStack Networking API and can choose
which network (or networks) to plug into.</para>
<figure>
<title>Multiple Flat Network</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image35.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>Use Case: Mixed Flat and Private
Network</guilabel></para>
<para>This use case is an extension of the above flat network
use cases, in which tenants also optionally have access to
private per-tenant networks. In addition to seeing one or
more shared networks via the OpenStack Networking API,
tenants can create additional networks that are only
visible to users of that tenant. When creating VMs, those
VMs can have NICs on any of the shared networks and/or any
of the private networks belonging to the tenant. This
enables the creation of "multi-tier" topologies using VMs
with multiple NICs. It also supports a model where a VM
acting as a gateway can provide services such as routing,
NAT, or load balancing.</para>
<figure>
<title>Mixed Flat and Private Network</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image36.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>Use Case: Provider Router with Private
Networks</guilabel></para>
<para>This use provides each tenant with one or more private
networks, which connect to the outside world via an
OpenStack Networking router. The case where each tenant
gets exactly one network in this form maps to the same
logical topology as the VlanManager in OpenStack Compute
(of course, OpenStack Networking doesn't require VLANs).
Using the OpenStack Networking API, the tenant would only
see a network for each private network assigned to that
tenant. The router object in the API is created and owned
by the cloud admin.</para>
<para>This model supports giving VMs public addresses using
"floating IPs", in which the router maps public addresses
from the external network to fixed IPs on private
networks. Hosts without floating IPs can still create
outbound connections to the external network, as the
provider router performs SNAT to the router's external IP.
The IP address of the physical router is used as the
gateway_ip of the external network subnet, so the provider
has a default router for Internet traffic.</para>
<para>The router provides L3 connectivity between private
networks, meaning that different tenants can reach each
others instances unless additional filtering (e.g.,
security groups) is used. Because there is only a single
router, tenant networks cannot use overlapping IPs. Thus,
it is likely that the admin would create the private
networks on behalf of tenants.</para>
<figure>
<title>Provider Router with Private Networks</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image37.png"/>
</imageobject>
</mediaobject>
</figure>
<para><guilabel>Use Case: Per-tenant Routers with Private
Networks</guilabel></para>
<para>A more advanced router scenario in which each tenant
gets at least one router, and potentially has access to
the OpenStack Networking API to create additional routers.
The tenant can create their own networks, potentially
uplinking those networks to a router. This model enables
tenant-defined multi-tier applications, with each tier
being a separate network behind the router. Since there
are multiple routers, tenant subnets can be overlapping
without conflicting, since access to external networks all
happens via SNAT or Floating IPs. Each router uplink and
floating IP is allocated from the external network
subnet.</para>
<figure>
<title>Per-tenant Routers with Private Networks</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/image38.png"/>
</imageobject>
</mediaobject>
</figure>
</section>
<section xml:id="security-in-neutron">
<title>Security in Neutron</title>
<para><guilabel>Security Groups</guilabel></para>
<para>Security groups and security group rules allows
administrators and tenants the ability to specify the type
of traffic and direction (ingress/egress) that is allowed
to pass through a port. A security group is a container
for security group rules.</para>
<para>When a port is created in OpenStack Networking it is
associated with a security group. If a security group is
not specified the port will be associated with a 'default'
security group. By default this group will drop all
ingress traffic and allow all egress. Rules can be added
to this group in order to change the behaviour.</para>
<para>If one desires to use the OpenStack Compute security
group APIs and/or have OpenStack Compute orchestrate the
creation of new ports for instances on specific security
groups, additional configuration is needed. To enable
this, one must configure the following file
/etc/nova/nova.conf and set the config option
security_group_api=neutron on every node running
nova-compute and nova-api. After this change is made
restart nova-api and nova-compute in order to pick up this
change. After this change is made one will be able to use
both the OpenStack Compute and OpenStack Network security
group API at the same time.</para>
<para><guilabel>Authentication and Authorization</guilabel></para>
<para>OpenStack Networking uses the OpenStack Identity service
(project name keystone) as the default authentication
service. When OpenStack Identity is enabled Users
submitting requests to the OpenStack Networking service
must provide an authentication token in X-Auth-Token
request header. The aforementioned token should have been
obtained by authenticating with the OpenStack Identity
endpoint. For more information concerning authentication
with OpenStack Identity, please refer to the OpenStack
Identity documentation. When OpenStack Identity is
enabled, it is not mandatory to specify tenant_id for
resources in create requests, as the tenant identifier
will be derived from the Authentication token. Please note
that the default authorization settings only allow
administrative users to create resources on behalf of a
different tenant. OpenStack Networking uses information
received from OpenStack Identity to authorize user
requests. OpenStack Networking handles two kind of
authorization policies:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Operation-based:</emphasis>
policies specify access criteria for specific
operations, possibly with fine-grained control over
specific attributes;</para>
</listitem>
<listitem>
<para><emphasis role="bold"
>Resource-based:</emphasis>whether access to specific
resource might be granted or not according to the
permissions configured for the resource (currently
available only for the network resource). The actual
authorization policies enforced in OpenStack
Networking might vary from deployment to
deployment.</para>
</listitem>
</itemizedlist>
<para>The policy engine reads entries from the policy.json
file. The actual location of this file might vary from
distribution to distribution. Entries can be updated while
the system is running, and no service restart is required.
That is to say, every time the policy file is updated, the
policies will be automatically reloaded. Currently the
only way of updating such policies is to edit the policy
file. Please note that in this section we will use both
the terms "policy" and "rule" to refer to objects which
are specified in the same way in the policy file; in other
words, there are no syntax differences between a rule and
a policy. We will define a policy something which is
matched directly from the OpenStack Networking policy
engine, whereas we will define a rule as the elements of
such policies which are then evaluated. For instance in
create_subnet: [["admin_or_network_owner"]], create_subnet
is regarded as a policy, whereas admin_or_network_owner is
regarded as a rule.</para>
<para>Policies are triggered by the OpenStack Networking
policy engine whenever one of them matches an OpenStack
Networking API operation or a specific attribute being
used in a given operation. For instance the create_subnet
policy is triggered every time a POST /v2.0/subnets
request is sent to the OpenStack Networking server; on the
other hand create_network:shared is triggered every time
the shared attribute is explicitly specified (and set to a
value different from its default) in a POST /v2.0/networks
request. It is also worth mentioning that policies can be
also related to specific API extensions; for instance
extension:provider_network:set will be triggered if the
attributes defined by the Provider Network extensions are
specified in an API request.</para>
<para>An authorization policy can be composed by one or more
rules. If more rules are specified, evaluation policy will
be successful if any of the rules evaluates successfully;
if an API operation matches multiple policies, then all
the policies must evaluate successfully. Also,
authorization rules are recursive. Once a rule is matched,
the rule(s) can be resolved to another rule, until a
terminal rule is reached.</para>
<para>The OpenStack Networking policy engine currently defines
the following kinds of terminal rules:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Role-based
rules:</emphasis> evaluate successfully if the
user submitting the request has the specified role.
For instance "role:admin"is successful if the user
submitting the request is an administrator.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Field-based
rules:</emphasis> evaluate successfully if a field
of the resource specified in the current request
matches a specific value. For instance
"field:networks:shared=True" is successful if the
attribute shared of the network resource is set to
true.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Generic
rules:</emphasis>compare an attribute in the resource
with an attribute extracted from the user's security
credentials and evaluates successfully if the
comparison is successful. For instance
"tenant_id:%(tenant_id)s" is successful if the tenant
identifier in the resource is equal to the tenant
identifier of the user submitting the request.</para>
</listitem>
</itemizedlist>
</section>
<section xml:id="floating-ips">
<title>Floating IP Addresses And Security Rules</title>
<para>OpenStack Networking has the concept of Fixed IPs and
Floating IPs. Fixed IPs are assigned to an instance on
creation and stay the same until the instance is explicitly
terminated. Floating ips are ip addresses that can be
dynamically associated with an instance. This address can be
disassociated and associated with another instance at any
time.</para>
<para>Various tasks carried out by Floating IP's as of
now.</para>
<itemizedlist>
<listitem>
<para>create IP ranges under a certain group, only
available for admin role.</para>
</listitem>
<listitem>
<para>allocate an floating IP to a certain tenant,
only available for admin role.</para>
</listitem>
<listitem>
<para>deallocate an floating IP from a certain
tenant</para>
</listitem>
<listitem>
<para>associate an floating IP to a given
instance</para>
</listitem>
<listitem>
<para>disassociate an floating IP from a certain
instance</para>
</listitem>
</itemizedlist>
<para>Just as shown by above figure, we will have
nova-network-api to support nova client floating
commands. nova-network-api will invoke quantum cli lib
to interactive with quantum server via API. The data
about floating IPs will be store in to quantum DB.
Quantum Agent, which is running on compute host will
enforce the floating IP.</para>
<para><guilabel>Multiple Floating
IP Pools</guilabel></para>
<para>The L3 API in OpenStack Networking supports multiple
floating IP pools. In OpenStack Networking, a floating
IP pool is represented as an external network and a
floating IP is allocated from a subnet associated with
the external network. Since each L3 agent can be
associated with at most one external network, we need
to invoke multiple L3 agent to define multiple
floating IP pools. 'gateway_external_network_id'in L3
agent configuration file indicates the external
network that the L3 agent handles. You can run
multiple L3 agent instances on one host.</para>
<para>In addition, when you run multiple L3 agents, make
sure that handle_internal_only_routersis set to
Trueonly for one L3 agent in an OpenStack Networking
deployment and set to Falsefor all other L3 agents.
Since the default value of this parameter is True, you
need to configure it carefully.</para>
<para>Before starting L3 agents, you need to create
routers and external networks, then update the
configuration files with UUID of external networks and
start L3 agents.</para>
<para>For the first agent, invoke it with the following
l3_agent.ini where handle_internal_only_routers is
True.</para>
</section>
</section>

50
doc/training-guide/associate-network-node-install-neutron.xml
View File

@ -1,50 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-network-node-install-neutron">
<title>Install Neutron</title>
<orderedlist>
<listitem>
<para><emphasis role="bold">Network Diagram :</emphasis></para>
</listitem>
</orderedlist>
<figure>
<title>Network Diagram</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/lab000-virtual-box/image03.png"/>
</imageobject>
</mediaobject>
</figure>
<para><emphasis role="bold">Vboxnet0</emphasis>, <emphasis
role="bold">Vboxnet1</emphasis>, <emphasis role="bold"
>Vboxnet2</emphasis> - are virtual networks setup up by virtual
box with your host machine. This is the way your host can
communicate with the virtual machines. These networks are in turn
used by virtual box VM’s for OpenStack networks, so that
OpenStack’s services can communicate with each other.</para>
<para><guilabel>Network Node</guilabel></para>
<para>Start your Controller Node the one you setup in previous
section.</para>
<para><emphasis role="bold">Preparing Ubuntu
13.04/12.04</emphasis></para>
<itemizedlist>
<listitem>
<para>After you install Ubuntu Server, go in sudo mode</para>
<para>
<programlisting>$sudo su</programlisting>
</para>
</listitem>
<listitem>
<para>Add Grizzly repositories:</para>
<para><programlisting>#apt-get install ubuntu-cloud-keyring python-software-properties software-properties-common python-keyring
# echo deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/grizzly main >> /etc/apt/sources.list.d/grizzly.list</programlisting></para>
</listitem>
<listitem>
<para>Update your system:</para>
<para><programlisting>#apt-get update
#apt-get upgrade
#apt-get dist-upgrade</programlisting></para>
</listitem>
</itemizedlist>
</section>

11
doc/training-guide/associate-network-node-lab.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-network-node-lab">
<title>Lab</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-network-node-quiz.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-network-node-quiz">
<title>Quiz</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

12
doc/training-guide/associate-network-node.xml
View File

@ -1,12 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-network-node">
<title>Network Node</title>
<xi:include href="associate-network-node-concept-neutron.xml"/>
<xi:include href="associate-network-node-install-neutron.xml"/>
<xi:include href="associate-network-node-lab.xml"/>
<xi:include href="associate-network-node-quiz.xml"/>
</chapter>

11
doc/training-guide/associate-review-concept.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-review-concept">
<title>Review of Conceptual Material</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</chapter>

1205
doc/training-guide/associate-storage-node-concept-swift.xml
View File

File diff suppressed because it is too large Load Diff

88
doc/training-guide/associate-storage-node-install-swift.xml
View File

@ -1,88 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-storage-node-install-swift">
<title>Install Swift</title>
<para>
<emphasis role="bold">Starting Installation of Swift</emphasis>
</para>
<xi:include href="../install-guide/object-storage/section_object-storage-install.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'general-installation-steps-swift']/*[not(self::db:title)])">
<xi:fallback>
<para><mediaobject>
<imageobject>
<imagedata fileref="figures/openstack-training-remote-content-not-available.png"
format="PNG"/>
</imageobject>
</mediaobject>Remote content not available</para>
<para>image source</para>
<para><link
xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing"
>https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para>
</xi:fallback>
</xi:include>
<xi:include
href="../install-guide/object-storage/section_object-storage-install-config-proxy-node.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'installing-and-configuring-the-proxy-node']/*[not(self::db:title)])">
<xi:fallback>
<para><mediaobject>
<imageobject>
<imagedata fileref="figures/openstack-training-remote-content-not-available.png"
format="PNG"/>
</imageobject>
</mediaobject>Remote content not available</para>
<para>image source</para>
<para><link
xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing"
>https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para>
</xi:fallback>
</xi:include>
<xi:include
href="../install-guide/object-storage/section_object-storage-install-config-storage-nodes.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'installing-and-configuring-storage-nodes']/*[not(self::db:title)])">
<xi:fallback>
<para><mediaobject>
<imageobject>
<imagedata fileref="figures/openstack-training-remote-content-not-available.png"
format="PNG"/>
</imageobject>
</mediaobject>Remote content not available</para>
<para>image source</para>
<para><link
xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing"
>https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para>
</xi:fallback>
</xi:include>
<para><emphasis role="bold">Starting Services</emphasis></para>
<xi:include href="../install-guide/object-storage/section_start-storage-node-services.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'start-storage-node-services']/*[not(self::db:title)])">
<xi:fallback>
<para><mediaobject>
<imageobject>
<imagedata fileref="figures/openstack-training-remote-content-not-available.png"
format="PNG"/>
</imageobject>
</mediaobject>Remote content not available</para>
<para>image source</para>
<para><link
xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing"
>https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para>
</xi:fallback>
</xi:include>
<para><emphasis role="bold">Finishing Up</emphasis></para>
<xi:include href="../install-guide/object-storage/section_object-storage-verifying-install.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'verify-swift-installation']/*[not(self::db:title)])">
<xi:fallback>
<para><mediaobject>
<imageobject>
<imagedata fileref="figures/openstack-training-remote-content-not-available.png"
format="PNG"/>
</imageobject>
</mediaobject>Remote content not available</para>
<para>image source</para>
<para><link
xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing"
>https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para>
</xi:fallback>
</xi:include>
</section>

11
doc/training-guide/associate-storage-node-lab.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-storage-node-lab">
<title>Lab</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

11
doc/training-guide/associate-storage-node-quiz.xml
View File

@ -1,11 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<section xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-storage-node-quiz">
<title>Quiz</title>
<para>foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar
</para>
</section>

12
doc/training-guide/associate-storage-node.xml
View File

@ -1,12 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-storage-node">
<title>Storage Node</title>
<xi:include href="associate-storage-node-concept-swift.xml"/>
<xi:include href="associate-storage-node-install-swift.xml"/>
<xi:include href="associate-storage-node-lab.xml"/>
<xi:include href="associate-storage-node-quiz.xml"/>
</chapter>

19
doc/training-guide/bk001-associate-training-guide.xml
View File

@ -3,11 +3,16 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="bk001-associate-training-guide">
<title>Associate Training Guide</title>
<xi:include href="associate-getting-started.xml"></xi:include>
<xi:include href="associate-controller-node.xml"></xi:include>
<xi:include href="associate-compute-node.xml"></xi:include>
<xi:include href="associate-network-node.xml"></xi:include>
<xi:include href="associate-storage-node.xml"></xi:include>
<xi:include href="associate-review-concept.xml"></xi:include>
<xi:include href="associate-assessment.xml"></xi:include>
<xi:include href="bk001-ch001-associate-getting-started.xml"></xi:include>
<xi:include href="bk001-ch002-associate-getting-started-quiz.xml"></xi:include>
<xi:include href="bk001-ch003-associate-controller-node.xml"></xi:include>
<xi:include href="bk001-ch004-associate-controller-node-quiz.xml"></xi:include>
<xi:include href="bk001-ch005-associate-compute-node.xml"></xi:include>
<xi:include href="bk001-ch006-associate-compute-node-quiz.xml"></xi:include>
<xi:include href="bk001-ch007-associate-network-node.xml"></xi:include>
<xi:include href="bk001-ch008-associate-network-node-quiz.xml"></xi:include>
<xi:include href="bk001-ch009-associate-storage-node.xml"></xi:include>
<xi:include href="bk001-bk010-associate-storage-node-quiz.xml"></xi:include>
<xi:include href="bk001-ch011-associate-assessment.xml"></xi:include>
<xi:include href="bk001-ch012-associate-review-concept.xml"></xi:include>
</book>

10
doc/training-guide/bk001-bk010-associate-storage-node-quiz.xml Normal file
View File

@ -0,0 +1,10 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-storage-node-quiz">
<title>Storage Node Quiz</title>
<section xml:id="day-two-objstore-quiz-schedule">
<title>Day 2, 14:25 to 14:45</title>
<para></para>
</section>
</chapter>

58
doc/training-guide/bk001-ch001-associate-getting-started.xml Normal file
View File

@ -0,0 +1,58 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-getting-started">
<?dbhtml stop-chunking?>
<title>Getting Started</title>
<section xml:id="day-one-morning-schedule">
<title>Day 1, 09:00 to 11:00</title>
<para></para>
</section>
<section xml:id="getting-started-overview">
<title>Overview</title>
<para>Training will take 1 month self paced, (2) 2 week periods with a user group meeting,
or 16 hours instructor led.</para>
<para>Prerequisites</para>
<orderedlist>
<listitem><para>Working knowledge of Linux CLI, basic Linux SysAdmin skills (directory structure, vi, ssh,
installing software)</para></listitem>
<listitem><para>Basic networking knowledge (Ethernet, VLAN, IP addressing)</para></listitem>
<listitem><para>Laptop with VirtualBox installed (highly recommended)</para></listitem>
</orderedlist>
</section>
<section xml:id="intro-text">
<title>Introduction Text</title>
<xi:include href="./module001-ch001-intro-text.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch001-intro-text']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="brief-overview">
<title>Brief Overview</title>
<xi:include href="./module001-ch002-brief-overview.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch002-brief-overview']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="core-projects">
<title>Core Projects</title>
<xi:include href="./module001-ch003-core-projects.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch003-core-projects']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="openstack-architecture">
<title>OpenStack Architecture</title>
<xi:include href="./module001-ch004-openstack-architecture.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch004-openstack-architecture']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="vm-provisioning-walk-through">
<title>Virtual Machine Provisioning Walk-Through</title>
<xi:include href="./module001-ch005-vm-provisioning-walk-through.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch005-vm-provisioning-walk-through']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
</chapter>

60
doc/training-guide/bk001-ch001-associate-what-does-this-book-intend-to-teach.xml
View File

@ -1,60 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="bk001-ch001-associate-what-does-this-book-intend-to-teach">
<title>OpenStack Associate, What Does This Book Intend to Teach</title>
<para>
<orderedlist>
<listitem>
<para>training would take 1 month self paced, (2) 2 week periods with a user group meeting,
or 16 hours instructor led. Some time set aside for distro specific training.</para>
</listitem>
<listitem>
<para>basic knowledge of core OpenStack components (Compute, Block, Network,
Dashboard)</para>
</listitem>
<listitem>
<para>create an instance</para>
</listitem>
<listitem>
<para>understand conf and log files</para>
</listitem>
<listitem>
<para>understand basics of APIs and framework architecture</para>
</listitem>
<listitem>
<para>understand shared components</para>
</listitem>
<listitem>
<para>work off a single node OpenStack implementation</para>
</listitem>
<listitem>
<para>get on IRC, mailing lists</para>
</listitem>
<listitem>
<para>able to deploy applications to OpenStack clouds</para>
</listitem>
<listitem>
<para>able to leverage basic functions including pools IPs and multiple disks</para>
</listitem>
<listitem>
<para>able to deploy multi-tier applications to OpenStack clouds</para>
</listitem>
<listitem>
<para>advanced knowledge of OpenStack components including new and incubated
projects</para>
</listitem>
<listitem>
<para>able to create complicated network topologies</para>
</listitem>
<listitem>
<para>able to leverage advanced application topologies</para>
</listitem>
<listitem>
<para>able to operate and manage projects and elements via Horizon, and some
CLI</para>
</listitem>
</orderedlist>
</para>
<para><link xlink:href="https://blueprints.launchpad.net/openstack-manuals/+filebug" xlink:show="new">Submit a bug. Enter the summary as "Training, " with a few words. Be descriptive as possible in the description field. Open the tag pull-down and enter training-manuals.</link></para>
</chapter>

11
doc/training-guide/bk001-ch002-associate-getting-started-quiz.xml Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-getting-started-quiz">
<?dbhtml stop-chunking?>
<title>Getting Started Quiz</title>
<section xml:id="day-one-getting-started-quiz-schedule">
<title>Day 1, 10:40 to 11:00</title>
<para></para>
</section>
</chapter>

17
doc/training-guide/bk001-ch002-associate-getting-started.xml
View File

@ -1,17 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="bk002-ch001-associate-getting-started">
<title>OpenStack Associate, Getting Started</title>
<para>
<orderedlist>
<listitem>
<para>Knowledge and skills</para>
</listitem>
<listitem>
<para>Materials and equipment</para>
</listitem>
</orderedlist>
</para>
<para><link xlink:href="https://blueprints.launchpad.net/openstack-manuals/+filebug" xlink:show="new">Submit a bug. Enter the summary as "Training, " with a few words. Be descriptive as possible in the description field. Open the tag pull-down and enter training-manuals.</link></para>
</chapter>

38
doc/training-guide/bk001-ch003-associate-controller-node.xml Normal file
View File

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-controller-node">
<?dbhtml stop-chunking?>
<title>Controller Node</title>
<section xml:id="day-one-late-morning-schedule">
<title>Day 1, 11:15 to 12:30, 13:30 to 14:45</title>
<para></para>
</section>
<section xml:id="overview-horizon-cli">
<title>Overview Horizon and OpenStack CLI</title>
<xi:include href="./module001-ch006-overview-horizon-cli.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch006-overview-horizon-cli']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="keystone-arch">
<title>Keystone Architecture</title>
<xi:include href="./module001-ch007-keystone-arch.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch007-keystone-arch']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="queues-messaging">
<title>OpenStack Messaging and Queues</title>
<xi:include href="./module001-ch008-queues-messaging.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch008-queues-messaging']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="controller-node-administration-tasks">
<title>Administration Tasks</title>
<para></para>
</section>
</chapter>

34
doc/training-guide/bk001-ch003-associate-general.xml
View File

@ -1,34 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="bk001-ch003-associate-general">
<title>OpenStack Associate, General Material To Learn</title>
<xi:include href="card007-core-overview.xml"></xi:include>
<!-- <xi:include href="card008.xml"></xi:include>
<xi:include href="card006.xml"></xi:include>
<xi:include href="card009.xml"></xi:include>
<xi:include href="card011.xml"></xi:include>
<xi:include href="card025.xml"></xi:include>
<xi:include href="card026-network-node-architecture.xml"></xi:include>
<xi:include href="card037-rabbitmq.xml"></xi:include>
<xi:include href="card038.xml"></xi:include>
<xi:include href="card039-nova.xml"></xi:include>
<xi:include href="card040-cinder.xml"></xi:include>
<xi:include href="card041-neutron.xml"></xi:include>
<xi:include href="card043-ovs-in-network-node.xml"></xi:include>
<xi:include href="card044-install-and-configure-neutron-network-node.xml"></xi:include>
<xi:include href="card045-configure-virtual-networking.xml"></xi:include>
<xi:include href="card046-L3_Configuration_in_the_Network_Node.xml"></xi:include>
<xi:include href="card047-install-nova-compute.xml"></xi:include>
<xi:include href="card070-create-floating-ips.xml"></xi:include>
<xi:include href="card071-create-cinder-horizon.xml"></xi:include>
<xi:include href="card072-cinder-attach-volume.xml"></xi:include>
<xi:include href="card073-control-state-instance.xml"></xi:include>
<xi:include href="card074-horizon-snapshots.xml"></xi:include>
<xi:include href="card126-horizon.xml"></xi:include>
<xi:include href="card127-glance.xml"></xi:include>
<xi:include href="card128-swift.xml"></xi:include>
<xi:include href="associate-horizon-cli-operations.xml"></xi:include> -->
</chapter>

50
doc/training-guide/bk001-ch004-associate-assessment.xml
View File

@ -1,50 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-assessment">
<title>Assessment</title>
<para><table rules="all" width="1011">
<caption>Assessment Question 1</caption>
<col width="95%"/>
<col width="05%"/>
<thead>
<tr>
<th>Task</th>
<th>Completed?</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<para>Configure a ....</para>
</td>
<td>
<para/>
</td>
</tr>
</tbody>
</table>
<table rules="all" width="1011">
<caption>Assessment Question 2</caption>
<col width="95%"/>
<col width="05%"/>
<thead>
<tr>
<th>Task</th>
<th>Completed?</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<para>Configure a ....</para>
</td>
<td>
<para/>
</td>
</tr>
</tbody>
</table>
</para>
<para><link xlink:href="https://blueprints.launchpad.net/openstack-manuals/+filebug" xlink:show="new">Submit a bug. Enter the summary as "Training, " with a few words. Be descriptive as possible in the description field. Open the tag pull-down and enter training-manuals.</link></para>
</chapter>

11
doc/training-guide/bk001-ch004-associate-controller-node-quiz.xml Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-controller-node-quiz">
<?dbhtml stop-chunking?>
<title>Controller Node Quiz</title>
<section xml:id="day-one-controller-quiz-schedule">
<title>Day 1, 14:25 to 14:45</title>
<para></para>
</section>
</chapter>

38
doc/training-guide/bk001-ch005-associate-compute-node.xml Normal file
View File

@ -0,0 +1,38 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-computer-node">
<?dbhtml stop-chunking?>
<title>Compute Node</title>
<section xml:id="day-one-afternoon-schedule">
<title>Day 1, 15:00 to 17:00</title>
<para></para>
</section>
<section xml:id="vm-placement">
<title>VM Placement</title>
<xi:include href="./module001-ch009-vm-placement.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch009-vm-placement']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="vm-provisioning-indepth">
<title>VM Provisioning Indepth</title>
<xi:include href="./module001-ch010-vm-provisioning-indepth.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch010-vm-provisioning-indepth']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="block-storage">
<title>OpenStack Block Storage</title>
<xi:include href="./module001-ch011-block-storage.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module001-ch011-block-storage']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="compute-node-administration-tasks">
<title>Administration Tasks</title>
<para></para>
</section>
</chapter>

11
doc/training-guide/bk001-ch006-associate-compute-node-quiz.xml Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-compute-node-quiz">
<?dbhtml stop-chunking?>
<title>Compute Node Quiz</title>
<section xml:id="day-one-compute-quiz-schedule">
<title>Day 1, 16:40 to 17:00</title>
<para></para>
</section>
</chapter>

31
doc/training-guide/bk001-ch007-associate-network-node.xml Normal file
View File

@ -0,0 +1,31 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-network-node">
<?dbhtml stop-chunking?>
<title>Network Node</title>
<section xml:id="day-two-morning-schedule">
<title>Day 2, 09:00 to 11:00</title>
<para></para>
</section>
<section xml:id="networking-in-openstack">
<title>Networking in OpenStack</title>
<xi:include href="./module002-ch001-networking-in-openstack.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module002-ch001-networking-in-openstack']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="openstack-networking-concepts">
<title>OpenStack Networking Concepts</title>
<xi:include href="./module002-ch002-openstack-networking-concepts.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module002-ch002-openstack-networking-concepts']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="network-node-administration-tasks">
<title>Administration Tasks</title>
<para></para>
</section>
</chapter>

11
doc/training-guide/bk001-ch008-associate-network-node-quiz.xml Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-network-node-quiz">
<?dbhtml stop-chunking?>
<title>Network Node Quiz</title>
<section xml:id="day-two-network-quiz-schedule">
<title>Day 2, 10:40 to 11:00</title>
<para></para>
</section>
</chapter>

31
doc/training-guide/bk001-ch009-associate-storage-node.xml Normal file
View File

@ -0,0 +1,31 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="associate-storage-node">
<?dbhtml stop-chunking?>
<title>Storage Node</title>
<section xml:id="day-two-late-morning-schedule">
<title>Day 2, 11:30 to 12:30, 13:30 to 14:45</title>
<para></para>
</section>
<section xml:id="intro-objstore">
<title>Introduction to Object Storage</title>
<xi:include href="./module003-ch001-intro-objstore.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module003-ch001-intro-objectstore']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="objstore-features-benefits">
<title>Features and Benefits</title>
<xi:include href="./module003-ch002-features-benifits.xml"
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'module003-ch002-features-benefits']/*[not(self::db:title)])">
<xi:fallback><para><mediaobject><imageobject><imagedata fileref="figures/openstack-training-remote-content-not-available.png" format="PNG"/></imageobject></mediaobject>Remote content not available</para><para>image source</para><para><link xlink:href="https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing">https://docs.google.com/drawings/d/1J2LZSxmc06xKyxMgPjv5fC0blV7qK6956-AeTmFOZD4/edit?usp=sharing</link></para></xi:fallback>
</xi:include>
</section>
<section xml:id="objstore-node-administration-tasks">
<title>Administration Tasks</title>
<para></para>
</section>
</chapter>

9
doc/training-guide/associate-assessment.xml → doc/training-guide/bk001-ch011-associate-assessment.xml
View File

@ -2,7 +2,14 @@
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-assessment">
<?dbhtml stop-chunking?>
<title>Assessment</title>
<section xml:id="day-two-assessment-schedule">
<title>Day 2, 15:00 to 16:00</title>
<para></para>
</section>
<section xml:id="assessment">
<title>Questions</title>
<para><table rules="all" width="1011">
<caption>Assessment Question 1</caption>
<col width="95%"/>
@ -46,5 +53,5 @@
</tbody>
</table>
</para>
<para><link xlink:href="https://blueprints.launchpad.net/openstack-manuals/+filebug" xlink:show="new">Submit a bug. Enter the summary as "Training, " with a few words. Be descriptive as possible in the description field. Open the tag pull-down and enter training-manuals.</link></para>
</section>
</chapter>

11
doc/training-guide/bk001-ch012-associate-review-concept.xml Normal file
View File

@ -0,0 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="associate-review-concept">
<?dbhtml stop-chunking?>
<title>Review of Concepts</title>
<section xml:id="day-two-review-schedule">
<title>Day 2, 16:00 to 17:00</title>
<para></para>
</section>
</chapter>

25
doc/training-guide/module001-ch007-keystone-arch.xml
View File

@ -4,7 +4,7 @@
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="module001-ch007-keystone-arch">
<title>Ketstone Architecture</title>
<title>Keystone Architecture</title>
<para>More Content To be Added ...</para>
<para><guilabel>Identity Service Concepts</guilabel></para>
@ -32,7 +32,7 @@
directly assigned to a particular tenant and behave as if they
are contained in that tenant.</para>
<para><guilabel><anchor xml:id="h.i1npk4aiu35h"/>Credentials</guilabel></para>
<para><guilabel>Credentials</guilabel></para>
<para>Data that is known only by a user that proves who they
are. In the Identity Service, examples are:</para>
<itemizedlist>
@ -48,7 +48,7 @@
</listitem>
</itemizedlist>
<para><guilabel><anchor xml:id="h.aa29gdlbf7qa"/>Authentication</guilabel></para>
<para><guilabel>Authentication</guilabel></para>
<para>The act of confirming the identity of a user. The Identity
Service confirms an incoming request by validating a set of
credentials supplied by the user. These credentials are
@ -57,7 +57,7 @@
the user an authentication token, which the user provides in
subsequent requests.</para>
<para><guilabel><anchor xml:id="h.grqljkbnx8fs"/>Token</guilabel></para>
<para><guilabel>Token</guilabel></para>
<para>An arbitrary bit of text that is used to access resources.
Each token has a scope which describes which resources are
accessible with it. A token may be revoked at anytime and is
@ -68,26 +68,26 @@
it to be an integration service foremost, and not aspire to be
a full-fledged identity store and management solution.</para>
<para><guilabel><anchor xml:id="h.qz798xvt751f"/>Tenant</guilabel></para>
<para><guilabel>Tenant</guilabel></para>
<para>A container used to group or isolate resources and/or
identity objects. Depending on the service operator, a tenant
may map to a customer, account, organization, or
project.</para>
<para><guilabel><anchor xml:id="h.ayp97sn984my"/>Service</guilabel></para>
<para><guilabel>Service</guilabel></para>
<para>An OpenStack service, such as Compute (Nova), Object
Storage (Swift), or Image Service (Glance). Provides one or
more endpoints through which users can access resources and
perform operations.</para>
<para><guilabel><anchor xml:id="h.74y77xwdnwlm"/>Endpoint</guilabel></para>
<para><guilabel>Endpoint</guilabel></para>
<para>An network-accessible address, usually described by URL,
from where you access a service. If using an extension for
templates, you can create an endpoint template, which
represents the templates of all the consumable services that
are available across the regions.</para>
<para><guilabel><anchor xml:id="h.r7samiog05in"/>Role</guilabel></para>
<para><guilabel>Role</guilabel></para>
<para>A personality that a user assumes that enables them to
perform a specific set of operations. A role includes a set of
rights and privileges. A user assuming that role inherits
@ -106,7 +106,7 @@
</mediaobject>
</figure>
<para><guilabel><anchor xml:id="h.rdpcpnbvn06w"/>User management</guilabel></para>
<para><guilabel>User management</guilabel></para>
<para>The main components of Identity user management are:</para>
<itemizedlist>
<listitem>
@ -162,11 +162,7 @@
that there are no restrictions on which users can create
volumes: if the user has any role in a tenant, they will be able
to create volumes in that tenant.</para>
<para><guilabel><anchor xml:id="h.f5989v85c3fd"/></guilabel></para>
<para><guilabel><anchor xml:id="h.1rrjgvz0nkwh"/>Service
management</guilabel></para>
<para><guilabel>Service Management</guilabel></para>
<para>The Identity Service provides the following service
management functions:</para>
<itemizedlist>
@ -183,5 +179,4 @@
service.</para>
<para>The commands for creating services and endpoints are
described in a later section.</para>
</chapter>

3
doc/training-guide/module002-ch003-neutron-use-cases.xml
View File

@ -7,8 +7,7 @@
<title>Neutron Use Cases</title>
<para>As of now you must be wondering, how to use these awesome
features that OpenStack Networking has given to us.</para>
<para><guilabel><anchor xml:id="h.lrsgdytf1mh51"/>Use Case: Single Flat
Network</guilabel></para>
<para><guilabel>Use Case: Single Flat Network</guilabel></para>
<para>In the simplest use case, a single OpenStack Networking
network exists. This is a "shared" network, meaning it is
visible to all tenants via the OpenStack Networking API.

2
doc/training-guide/module003-ch002-features-benifits.xml
View File

@ -201,4 +201,4 @@
</tbody>
</informaltable>
</para>
</chapter>
</chapter>