Merge "Delete the XML content to prepare for Juno"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
e383d9916a
@ -1,10 +0,0 @@
|
||||
Important note about glossary
|
||||
=============================
|
||||
|
||||
This directory is synced from openstack-manuals. If you need to make
|
||||
changes, make the changes in openstack-manuals/doc/glossary. After any
|
||||
change merged to openstack-manuals/doc/glossary, automatically a patch
|
||||
for this directory will be proposed.
|
||||
|
||||
**Note:** Core-reviewers please do not let any patches go through into
|
||||
this directory. Redirect the patches to openstack-manuals.
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,10 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<book 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="bk_architect-training-guide">
|
||||
<title>Architect Training Guide</title>
|
||||
<chapter xml:id="architect-training-guide-coming-soon">
|
||||
<title>Architect Training Guide Coming Soon</title>
|
||||
<para>TBD</para>
|
||||
</chapter>
|
||||
</book>
|
||||
@ -1,18 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<book 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="bk_associate-training-guide">
|
||||
<title>Associate Training Guide</title>
|
||||
<xi:include href="ch_associate-getting-started.xml"></xi:include>
|
||||
<xi:include href="ch_associate-getting-started-quiz.xml"></xi:include>
|
||||
<xi:include href="ch_associate-controller-node.xml"></xi:include>
|
||||
<xi:include href="ch_associate-controller-node-quiz.xml"></xi:include>
|
||||
<xi:include href="ch_associate-compute-node.xml"></xi:include>
|
||||
<xi:include href="ch_associate-compute-node-quiz.xml"></xi:include>
|
||||
<xi:include href="ch_associate-network-node.xml"></xi:include>
|
||||
<xi:include href="ch_associate-network-node-quiz.xml"></xi:include>
|
||||
<xi:include href="ch_associate-object-storage-node.xml"></xi:include>
|
||||
<xi:include href="ch_associate-object-storage-node-quiz.xml"></xi:include>
|
||||
<xi:include href="ch_associate-assessment.xml"></xi:include>
|
||||
<xi:include href="ch_associate-review-concept.xml"></xi:include>
|
||||
</book>
|
||||
@ -1,57 +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">
|
||||
<?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%"/>
|
||||
<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>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,265 +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-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>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Compute Node Quiz Questions</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Which component determines which host a VM should launch on?</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>nova-network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>queue</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-console</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-api</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>All compute nodes (also known as hosts in terms of OpenStack) periodically publish
|
||||
their status, resources available and hardware capabilities: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>through the queue</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>with SQL calls to the database</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>with direct interprocess communication</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>By default, the compute node's scheduler is configured as:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>the RAM scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the base scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the chance scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the filter scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>the weight scheduler</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>If the compute node is using the filter scheduler, it works by:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>filtering hosts by using predefined properties</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>weighting hosts by applying predefined weights</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>sorting hosts by using weights to determine host preference list first, then applying filters</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>filtering hosts first, then using weights to determine host preference</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>filtering hosts first, then choosing a random host from the filtered list</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Scheduler always returns a host on which Nova can start the requested VM.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack provides which classes of block storage? (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>RAM storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>object storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>persistent storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>file storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>SSD storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ephemeral storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>disk storage</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Persistent volumes can be used by more than one instance at the same time:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Specify in which order these steps must be completed to provision VMs:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>nova-scheduler picks up the request from the queue.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute generates data for the hypervisor driver and executes the request on the hypervisor (via libvirt or API).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-scheduler interacts with nova DB to find an appropriate host via filtering and weighting, returns the updated instance entry with the appropriate host ID and sends the rpc.cast request to nova-compute for launching an instance on the appropriate host.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-conductor interacts with nova DB and returns the instance information. nova-compute picks up the instance information from the queue.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-api receives the request and sends a request to the Identity Service for validation of the auth-token and access permission. The Identity Service validates the token.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute picks up the request for launching an instance on the appropriate host from the queue.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>neutron-server validates the auth-token with Identity Service. nova-compute retrieves the network info.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute performs the REST-call by passing the auth-token to Network API to allocate and configure the network so that the instance gets the IP address.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The dashboard or CLI converts the new instance request to a REST API request and sends it to nova-api.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute performs the REST call by passing the auth-token to glance-api. Then, nova-compute uses the Image ID to retrieve the Image URI from the Image Service, and loads the image from the image storage.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute sends the rpc.call request to nova-conductor to fetch the instance information such as host ID and flavor (RAM, CPU, disk).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>cinder-api validates the auth-token with Identity Service. nova-compute retrieves the block storage info.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The dashboard or CLI gets the user credentials and authenticates with the Identity Service via REST API. The Identity Service authenticates the user and sends back an auth-token.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>glance-api validates the auth-token with Identity Service. nova-compute gets the image metadata.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute performs the REST call by passing the auth-token to Volume API to attach volumes to the instance.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-api checks for conflicts with nova DB and creates the initial database entry for a new instance.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-api sends the rpc.call request to nova-scheduler expecting to get an updated instance entry with the host ID specified.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-conductor picks up the request from the queue.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Compute Node Quiz Answers</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>e (nova-scheduler)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>a (through the queue) - This increases scalability.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>d (the filter scheduler)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>d filtering hosts first, then using weights to determine host preference</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>b (False) - Scheduler can also return an error (no suitable host for the requested VM).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>c (persistent storage), f (ephemeral storage) - The question is about OpenStack's block storage classes.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>b (False)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>a (6), b (18), c (7), d (11), e (3), f (8), g (15), h (14), i (2), j (12), k (9), l (17), m (1), n (13), o (16), p (4), q (5), r (10)</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,70 +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">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Compute Node</title>
|
||||
<section xml:id="associate-day-one-afternoon-schedule">
|
||||
<title>Day 1, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="associate-vm-placement">
|
||||
<title>VM Placement</title>
|
||||
<xi:include href="../common/section_vm-placement.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_vm-placement']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-vm-provisioning-indepth">
|
||||
<title>VM provisioning in-depth</title>
|
||||
<xi:include href="../common/section_vm-provisioning-indepth.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_vm-provisioning-indepth']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-block-storage">
|
||||
<title>OpenStack Block Storage</title>
|
||||
<xi:include href="../common/section_block-storage.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_block-storage']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-compute-node-administration-tasks">
|
||||
<title>Administration Tasks</title>
|
||||
<section xml:id="associate-block-storage-commands">
|
||||
<title>Block Storage CLI Commands</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/cli-reference/generated/ch_cli_cinder_commands.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'cinderclient_commands']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-block-storage-manage-volumes">
|
||||
<title>Block Storage Manage Volumes</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_cinder_manage_volumes.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'cli_manage_volumes']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-nova-cli-commands">
|
||||
<title>Compute CLI Commands</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/cli-reference/generated/ch_cli_nova_commands.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'novaclient_commands']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-nova-image-creation">
|
||||
<title>Compute Image creation</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_nova_images.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'nova_manage_images']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-nova-boot-instance">
|
||||
<title>Compute Boot Instance</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_nova_boot_from_volume.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'boot_from_volume']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-nova-terminate-instance">
|
||||
<title>Compute Terminate Instance</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/user-guide/section_cli_nova_terminate.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'terminating']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,384 +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-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Controller Node Quiz</title>
|
||||
<section xml:id="associate-day-one-controller-quiz-schedule">
|
||||
<title>Day 1, 14:25 to 14:45</title>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Controller Node Quiz Questions</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>When managing images for OpenStack you can complete all those tasks with the OpenStack
|
||||
dashboard.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>When setting up access and security, SSH credentials (keypairs) must be injected
|
||||
into images after they are launched with a script.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>You can track monthly costs with metrics like: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>VCPU</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>QoS</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Uptime</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Disks</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>RAM</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>The following OpenStack command-line clients are available: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>python-keystoneclient</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>python-hypervisorclient</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>python-imageclient</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>python-cinderclient</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>python-novaclient</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>To install a client package</title>
|
||||
<para>
|
||||
Run this command:
|
||||
<screen><prompt>#</prompt> <userinput>pip install [--update] python-project client</userinput></screen>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>To list images</title>
|
||||
<para>
|
||||
Run this command:
|
||||
<screen><prompt>$</prompt> <userinput>glance image-list</userinput></screen>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>When troubleshooting image creation you will need to look at which of the following
|
||||
log files for errors? (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Examine the /var/log/nova-api.log</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Examine the /var/log/nova-compute.log</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Examine the /var/log/nova-error.log</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Examine the /var/log/nova-status.log</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Examine the /var/log/nova-image.log</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>To generate a keypair use the following command syntax:
|
||||
$ nova keypair-add --pub_key ~/.ssh/id_rsa.pub KEY_NAME</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>When you want to launch an instance you can only do that from an image.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>An instance has a Private IP address which has the following properties: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Used for communication between instances</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VMware vShpere 4.1, update 1 or greater</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Stays the same, even after reboots</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Stays allocated, even if you terminate the instance</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To see the status of the Private IP addresses you use the following command:
|
||||
$ nova floating-ip-pool-list</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>To start and stop and instance you can use the following options: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Pause/Un-pause</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Suspend/Resume</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Reboot</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Evacuate</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Shutdown/Restart</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>To create a network in OpenStack use the following command: $ neutron net-create net1</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Identity Service provides the following functions: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Group policy objects</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Message queuing</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>User management</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Publishing</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Service catalog</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>The AMQP supports the following messaging bus options: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>ZeroMQ</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>RabbitMQ</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Tibco Rendezvous</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>IBM WebSphere Message Broker</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Qpid</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack uses the term tenant but in earlier versions it used the term customer.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Controller Node Quiz Answers</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>B (False) - you can manage images through only the glance and nova clients or the Image
|
||||
Service and Compute APIs.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B (False) - Keypairs are SSH credentials that are injected into images when they are launched.
|
||||
For this to work, the image must contain the cloud-init package</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, C, D, E - You can track costs per month by showing metrics like number of VCPUs, disks,
|
||||
RAM, and uptime of all your instances</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, D, E - The following command-line clients are available for the respective services' APIs:
|
||||
cinder(python-cinderclient)
|
||||
Client for the Block Storage service API. Use to create and manage volumes.
|
||||
glance(python-glanceclient)
|
||||
Client for the Image Service API. Use to create and manage images.
|
||||
keystone(python-keystoneclient)
|
||||
Client for the Identity Service API. Use to create and manage users, tenants, roles, endpoints, and credentials.
|
||||
nova(python-novaclient)
|
||||
Client for the Compute API and its extensions. Use to create and manage images, instances, and flavors.
|
||||
neutron(python-neutronclient)
|
||||
Client for the Networking API. Use to configure networks for guest servers. This client was previously known as quantum.
|
||||
swift(python-swiftclient)
|
||||
Client for the Object Storage API. Use to gather statistics, list items, update metadata, upload, download and delete files stored by the object storage service. Provides access to a swift installation for ad hoc processing.
|
||||
heat(python-heatclient)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A (True)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A (True)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B (False) - $ nova keypair-add KEY_NAME > MY_KEY.pem</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B (False) - you can launch and instance from an image or a volume</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B, C</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B, C, D</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A (True)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>C, E</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B, E</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B (False) - Because the term project was used instead of tenant in earlier versions of
|
||||
OpenStack Compute, some command-line tools use --project_id instead of --tenant-id or
|
||||
--os-tenant-id to refer to a tenant ID.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,76 +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">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Controller Node</title>
|
||||
<section xml:id="associate-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="associate-overview-horizon-cli">
|
||||
<title>Overview Horizon and OpenStack CLI</title>
|
||||
<xi:include href="../common/section_overview-horizon-cli.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_overview-horizon-cli']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-keystone-arch">
|
||||
<title>Keystone Architecture</title>
|
||||
<xi:include href="../common/section_keystone-arch.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_keystone-arch']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-queues-messaging">
|
||||
<title>OpenStack Messaging and Queues</title>
|
||||
<xi:include href="../common/section_queues-messaging.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_queues-messaging']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-controller-node-administration-tasks">
|
||||
<title>Administration Tasks</title>
|
||||
<section xml:id="associate-identity-cli-commands">
|
||||
<title>Identity CI Commands</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_keystone_example_usage.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'example-usage']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-identity-user-management">
|
||||
<title>Identity User Management</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_keystone-concepts-user-management.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'keystone-user-management']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-glance-cli-commands">
|
||||
<title>Image CLI Commands</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/cli-reference/generated/ch_cli_glance_commands.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'glanceclient_commands']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-glance-image-list">
|
||||
<title>Image List Images</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_glance_manage_images.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'glance-image-list']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-glance-image-add">
|
||||
<title>Image Adding Images</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_glance_manage_images.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'glance_add_image']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-glance-manage-images">
|
||||
<title>Image Manage Images</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_nova_manage_images.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'nova_manage_images']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-oslo-configuration">
|
||||
<title>Message Queue Configuration</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/config-reference/compute/section_rpc.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'configuring-rpc']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,249 +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-getting-started-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started Quiz</title>
|
||||
<section xml:id="associate-day-one-getting-started-quiz-schedule">
|
||||
<title>Day 1, 10:40 to 11:00</title>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Getting Started Quiz Questions</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>What are some of the compelling features of a cloud? (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>On-demand self-service</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Resource pooling</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Metered or measured service</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Elasticity</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Network access</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>What three service models does cloud computing provide? (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Software-as-a-Service (SaaS)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Applications-as-a-Service (AaaS)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Hardware-as-a-Service (HaaS)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Infrastructure-as-a-Service (IaaS)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Platform-as-a-Service (PaaS)</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>What does the OpenStack project aim to deliver? (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Simple to implement cloud solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Massively scalable cloud solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Feature rich cloud solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Multi-vendor interoperability cloud solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A new hypervisor cloud solution</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack code is freely available via the FreeBSD license.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack Swift is Object Storage.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack Networking is now called Quantum.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>The Image Service (Glance) in OpenStack provides: (Choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Base Templates which users can start new compute instances</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configuration of centralized policies across users and systems</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Available images for users to choose from or create their own from existing servers</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A central directory of users</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Ability to take store snapshots in the Image Service for backup</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>OpenStack APIs are compatible with Amazon EC2 and Amazon S3.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Horizon is the OpenStack name for Compute.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Which Hypervisors can be supported in OpenStack? (Choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>KVM</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VMware vShpere 4.1, update 1 or greater</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>bhyve (BSD)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Xen</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>LXC</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Getting Started Quiz Answers</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>A, B, C, D, E</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, D, E</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B, C</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, C, E</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A, B, D, E</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,58 +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-getting-started">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started</title>
|
||||
<section xml:id="associate-day-one-morning-schedule">
|
||||
<title>Day 1, 09:00 to 11:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="associate-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="associate-intro-text">
|
||||
<title>Introduction Text</title>
|
||||
<xi:include href="../common/section_intro-text.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="associate-brief-overview">
|
||||
<title>Brief Overview</title>
|
||||
<xi:include href="../common/section_brief-overview.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="associate-official-programs">
|
||||
<title>Official Programs</title>
|
||||
<xi:include href="../common/section_official-programs.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_official-programs']/*[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="associate-openstack-architecture">
|
||||
<title>OpenStack Architecture</title>
|
||||
<xi:include href="../common/section_openstack-architecture.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="associate-vm-provisioning-walk-through">
|
||||
<title>Virtual Machine Provisioning Walk-Through</title>
|
||||
<xi:include href="../common/section_vm-provisioning-walk-through.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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>
|
||||
@ -1,145 +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-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>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Network Node Quiz Questions</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>The concept of a plug-in, which is a pluggable back-end implementation of the OpenStack Networking API, is used in OpenStack Networking and nova-network.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>A plug-in implements the logical API requests with L2-in-L3 tunneling or OpenFlow.</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>True</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>False</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>As part of creating a VM, which process communicates with the OpenStack Networking API to plug each virtual NIC on the VM into a particular network:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>nova-scheduler</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-compute</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-quantum</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-neutron</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>A standard OpenStack Networking setup (like it was presented in this guide) has many distinct physical data center networks: (choose all that apply)</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>isolated network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>cloud network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>management network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>data network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>external-network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>API network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>datacenter network</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>In this guide, we focused primarily on a standard architecture that includes a “cloud controller” host (Control node), a “network gateway” host (Network node), and a set of hypervisors for running VMs (Compute nodes). For each of the following services identify a host on which it usually runs:</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Neutron plugin agent</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron L3 agent</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron DHCP agent</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron server</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron metadata agent</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Associate Training Guide, Network Node Quiz Answers</title>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>B (False) - only OpenStack Networking (Neutron) has a pluggable back-end.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>B (False) - a plug-in can use a variety of technologies to implement the logical API requests. Some OpenStack Networking plug-ins 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>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>C</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>C, D, E, F</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A - network node, compute nodes, B - network node, C - network node, D - control node, E - network node</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="associate-network-node">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Network Node</title>
|
||||
<section xml:id="associate-day-two-morning-schedule">
|
||||
<title>Day 2, 09:00 to 11:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="associate-networking-in-openstack">
|
||||
<title>Networking in OpenStack</title>
|
||||
<xi:include href="../common/section_networking-in-openstack.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_networking-in-openstack']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-openstack-networking-concepts">
|
||||
<title>OpenStack Networking Concepts</title>
|
||||
<xi:include href="../common/section_openstack-networking-concepts.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_openstack-networking-concepts']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-network-node-administration-tasks">
|
||||
<title>Administration Tasks</title>
|
||||
<section xml:id="associate-network-manage">
|
||||
<title>Manage Networks</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_cli_neutron_manage_networks.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'neutron_client_sample_commands']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,10 +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-object-storage-node-quiz">
|
||||
<title>Object Storage Node Quiz</title>
|
||||
<section xml:id="day-two-object-store-quiz-schedule">
|
||||
<title>Day 2, 14:25 to 14:45</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,38 +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">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Object Storage Node</title>
|
||||
<section xml:id="associate-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="associate-intro-object-store">
|
||||
<title>Introduction to Object Storage</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-intro.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_objectstorage-intro']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-object-store-features-benefits">
|
||||
<title>Features and Benefits</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-features.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_objectstorage_features']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-object-store-node-administration-tasks">
|
||||
<title>Administration Tasks</title>
|
||||
<section xml:id="associate-object-store-cli-commands">
|
||||
<title>Object Storage CLI Commands</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/cli-reference/generated/ch_cli_swift_commands.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'swiftclient_commands']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="associate-object-store-manage">
|
||||
<title>Manage Object Storage</title>
|
||||
<para>Will be included from the swift developer reference</para>
|
||||
</section>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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">
|
||||
<?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>
|
||||
@ -1,13 +0,0 @@
|
||||
Introduction
|
||||
============
|
||||
|
||||
* This folder contains the XML files related to Basic Install Guide.
|
||||
* Refer to the following etherpad for more details on the design and planning
|
||||
for the basic install guide section.
|
||||
https://etherpad.openstack.org/p/training-guides-install-guide
|
||||
* Please refer the following link to get more information about this project
|
||||
https://launchpad.net/openstack-training-guides
|
||||
* Please follow the following wiki to get more information about development
|
||||
process of Training Guides. This should provide enough information to start
|
||||
contributing to training guides
|
||||
https://wiki.openstack.org/wiki/Training-guides
|
||||
@ -1,4 +0,0 @@
|
||||
export OS_TENANT_NAME=admin
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=admin_pass
|
||||
export OS_AUTH_URL="http://192.168.100.51:5000/v2.0/"
|
||||
@ -1,56 +0,0 @@
|
||||
#!/bin/bash
|
||||
#
|
||||
# License: Apache Software License (ASL) 2.0
|
||||
# Inspired by
|
||||
# https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
|
||||
###############################################################################
|
||||
# #
|
||||
# This script adds users and grants them roles #
|
||||
# #
|
||||
###############################################################################
|
||||
|
||||
HOST_IP=10.10.10.51
|
||||
ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin_pass}
|
||||
SERVICE_PASSWORD=${SERVICE_PASSWORD:-service_pass}
|
||||
export SERVICE_TOKEN="ADMIN"
|
||||
export SERVICE_ENDPOINT="http://${HOST_IP}:35357/v2.0"
|
||||
SERVICE_TENANT_NAME=${SERVICE_TENANT_NAME:-service}
|
||||
|
||||
get_id () {
|
||||
echo $($@ | awk '/ id / { print $4 }')
|
||||
}
|
||||
|
||||
# Tenants
|
||||
ADMIN_TENANT=$(get_id keystone tenant-create --name=admin)
|
||||
SERVICE_TENANT=$(get_id keystone tenant-create --name=$SERVICE_TENANT_NAME)
|
||||
|
||||
|
||||
# Users
|
||||
ADMIN_USER=$(get_id keystone user-create --name=admin --pass="$ADMIN_PASSWORD" --email=admin@domain.com)
|
||||
|
||||
|
||||
# Roles
|
||||
ADMIN_ROLE=$(get_id keystone role-create --name=admin)
|
||||
KEYSTONEADMIN_ROLE=$(get_id keystone role-create --name=KeystoneAdmin)
|
||||
KEYSTONESERVICE_ROLE=$(get_id keystone role-create --name=KeystoneServiceAdmin)
|
||||
|
||||
# Add Roles to Users in Tenants
|
||||
keystone user-role-add --user-id $ADMIN_USER --role-id $ADMIN_ROLE --tenant-id $ADMIN_TENANT
|
||||
keystone user-role-add --user-id $ADMIN_USER --role-id $KEYSTONEADMIN_ROLE --tenant-id $ADMIN_TENANT
|
||||
keystone user-role-add --user-id $ADMIN_USER --role-id $KEYSTONESERVICE_ROLE --tenant-id $ADMIN_TENANT
|
||||
|
||||
# The Member role is used by Horizon and Swift
|
||||
MEMBER_ROLE=$(get_id keystone role-create --name=Member)
|
||||
|
||||
# Configure service users/roles
|
||||
NOVA_USER=$(get_id keystone user-create --name=nova --pass="$SERVICE_PASSWORD" --tenant-id $SERVICE_TENANT --email=nova@domain.com)
|
||||
keystone user-role-add --tenant-id $SERVICE_TENANT --user-id $NOVA_USER --role-id $ADMIN_ROLE
|
||||
|
||||
GLANCE_USER=$(get_id keystone user-create --name=glance --pass="$SERVICE_PASSWORD" --tenant-id $SERVICE_TENANT --email=glance@domain.com)
|
||||
keystone user-role-add --tenant-id $SERVICE_TENANT --user-id $GLANCE_USER --role-id $ADMIN_ROLE
|
||||
|
||||
neutron_USER=$(get_id keystone user-create --name=neutron --pass="$SERVICE_PASSWORD" --tenant-id $SERVICE_TENANT --email=neutron@domain.com)
|
||||
keystone user-role-add --tenant-id $SERVICE_TENANT --user-id $neutron_USER --role-id $ADMIN_ROLE
|
||||
|
||||
CINDER_USER=$(get_id keystone user-create --name=cinder --pass="$SERVICE_PASSWORD" --tenant-id $SERVICE_TENANT --email=cinder@domain.com)
|
||||
keystone user-role-add --tenant-id $SERVICE_TENANT --user-id $CINDER_USER --role-id $ADMIN_ROLE
|
||||
@ -1,133 +0,0 @@
|
||||
#!/bin/bash
|
||||
#
|
||||
# License: Apache Software License (ASL) 2.0
|
||||
# Inspired by
|
||||
# https://github.com/openstack/keystone/blob/master/tools/sample_data.sh
|
||||
###############################################################################
|
||||
# #
|
||||
# This script creates keystone services and endpoints #
|
||||
# #
|
||||
###############################################################################
|
||||
|
||||
# Host address
|
||||
HOST_IP=10.10.10.51
|
||||
EXT_HOST_IP=192.168.100.51
|
||||
|
||||
# MySQL definitions
|
||||
MYSQL_USER=keystoneUser
|
||||
MYSQL_DATABASE=keystone
|
||||
MYSQL_HOST=$HOST_IP
|
||||
MYSQL_PASSWORD=keystonePass
|
||||
|
||||
# Keystone definitions
|
||||
KEYSTONE_REGION=RegionOne
|
||||
export SERVICE_TOKEN=ADMIN
|
||||
export SERVICE_ENDPOINT="http://${HOST_IP}:35357/v2.0"
|
||||
|
||||
while getopts "u:D:p:m:K:R:E:T:vh" opt; do
|
||||
case $opt in
|
||||
u)
|
||||
MYSQL_USER=$OPTARG
|
||||
;;
|
||||
D)
|
||||
MYSQL_DATABASE=$OPTARG
|
||||
;;
|
||||
p)
|
||||
MYSQL_PASSWORD=$OPTARG
|
||||
;;
|
||||
m)
|
||||
MYSQL_HOST=$OPTARG
|
||||
;;
|
||||
K)
|
||||
MASTER=$OPTARG
|
||||
;;
|
||||
R)
|
||||
KEYSTONE_REGION=$OPTARG
|
||||
;;
|
||||
E)
|
||||
export SERVICE_ENDPOINT=$OPTARG
|
||||
;;
|
||||
T)
|
||||
export SERVICE_TOKEN=$OPTARG
|
||||
;;
|
||||
v)
|
||||
set -x
|
||||
;;
|
||||
h)
|
||||
cat <<EOF
|
||||
Usage: $0 [-m mysql_hostname] [-u mysql_username] [-D mysql_database] [-p mysql_password]
|
||||
[-K keystone_master ] [ -R keystone_region ] [ -E keystone_endpoint_url ]
|
||||
[ -T keystone_token ]
|
||||
Add -v for verbose mode, -h to display this message.
|
||||
EOF
|
||||
exit 0
|
||||
;;
|
||||
\?)
|
||||
echo "Unknown option -$OPTARG" >&2
|
||||
exit 1
|
||||
;;
|
||||
:)
|
||||
echo "Option -$OPTARG requires an argument" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
if [ -z "$KEYSTONE_REGION" ]; then
|
||||
echo "Keystone region not set. Please set with -R option or set KEYSTONE_REGION variable." >&2
|
||||
missing_args="true"
|
||||
fi
|
||||
|
||||
if [ -z "$SERVICE_TOKEN" ]; then
|
||||
echo "Keystone service token not set. Please set with -T option or set SERVICE_TOKEN variable." >&2
|
||||
missing_args="true"
|
||||
fi
|
||||
|
||||
if [ -z "$SERVICE_ENDPOINT" ]; then
|
||||
echo "Keystone service endpoint not set. Please set with -E option or set SERVICE_ENDPOINT variable." >&2
|
||||
missing_args="true"
|
||||
fi
|
||||
|
||||
if [ -z "$MYSQL_PASSWORD" ]; then
|
||||
echo "MySQL password not set. Please set with -p option or set MYSQL_PASSWORD variable." >&2
|
||||
missing_args="true"
|
||||
fi
|
||||
|
||||
if [ -n "$missing_args" ]; then
|
||||
exit 1
|
||||
fi
|
||||
|
||||
keystone service-create --name nova --type compute --description 'OpenStack Compute Service'
|
||||
keystone service-create --name cinder --type volume --description 'OpenStack Volume Service'
|
||||
keystone service-create --name glance --type image --description 'OpenStack Image Service'
|
||||
keystone service-create --name keystone --type identity --description 'OpenStack Identity'
|
||||
keystone service-create --name ec2 --type ec2 --description 'OpenStack EC2 service'
|
||||
keystone service-create --name neutron --type network --description 'OpenStack Networking service'
|
||||
|
||||
create_endpoint () {
|
||||
case $1 in
|
||||
compute)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':8774/v2/$(tenant_id)s' --adminurl 'http://'"$HOST_IP"':8774/v2/$(tenant_id)s' --internalurl 'http://'"$HOST_IP"':8774/v2/$(tenant_id)s'
|
||||
;;
|
||||
volume)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':8776/v1/$(tenant_id)s' --adminurl 'http://'"$HOST_IP"':8776/v1/$(tenant_id)s' --internalurl 'http://'"$HOST_IP"':8776/v1/$(tenant_id)s'
|
||||
;;
|
||||
image)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':9292/' --adminurl 'http://'"$HOST_IP"':9292/' --internalurl 'http://'"$HOST_IP"':9292/'
|
||||
;;
|
||||
identity)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':5000/v2.0' --adminurl 'http://'"$HOST_IP"':35357/v2.0' --internalurl 'http://'"$HOST_IP"':5000/v2.0'
|
||||
;;
|
||||
ec2)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':8773/services/Cloud' --adminurl 'http://'"$HOST_IP"':8773/services/Admin' --internalurl 'http://'"$HOST_IP"':8773/services/Cloud'
|
||||
;;
|
||||
network)
|
||||
keystone endpoint-create --region $KEYSTONE_REGION --service-id $2 --publicurl 'http://'"$EXT_HOST_IP"':9696/' --adminurl 'http://'"$HOST_IP"':9696/' --internalurl 'http://'"$HOST_IP"':9696/'
|
||||
;;
|
||||
esac
|
||||
}
|
||||
|
||||
for i in compute volume image object-store identity ec2 network; do
|
||||
id=$(mysql -h "$MYSQL_HOST" -u "$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE" -ss -e "SELECT id FROM service WHERE type='"$i"';") || exit 1
|
||||
create_endpoint $i $id
|
||||
done
|
||||
@ -1,288 +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="lab_compute-node">
|
||||
<title>Compute Node</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Network Diagram:</emphasis></para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<figure>
|
||||
<title>Network Diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image03.png"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Publicly editable image source at <link
|
||||
xlink:href="https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing"
|
||||
>https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing</link></para>
|
||||
<para><emphasis role="bold">Vboxnet0</emphasis>, <emphasis
|
||||
role="bold">Vboxnet1</emphasis>, <emphasis role="bold"
|
||||
>Vboxnet2</emphasis> - are virtual networks set up up by VirtualBox
|
||||
with your host machine. This is the way the host can
|
||||
communicate with the virtual machines. These networks are in turn
|
||||
used by VirtualBox VMs for OpenStack networks, so that
|
||||
OpenStack’s services can communicate with each other.</para>
|
||||
<para><guilabel>Compute node</guilabel></para>
|
||||
<para>Start the controller node, which was set up in a previous section.</para>
|
||||
<note>
|
||||
<para>After the reboot of the node, the VM may lose internet and network
|
||||
connectivity. Restart the networking service and use the
|
||||
<command>ping</command> command to verify the network
|
||||
connectivity for the given VM.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>Take regular snapshots of the VirtualBox virtual machines after
|
||||
each section. In case the VM is broken, you may revert back to the
|
||||
snapshot to save time and effort.</para>
|
||||
</note>
|
||||
<para><guilabel>Controller node</guilabel></para>
|
||||
<para>
|
||||
Start the controller node, which was set up in a previous section.
|
||||
</para>
|
||||
<para><emphasis role="bold">Preparing Ubuntu 14.04</emphasis></para>
|
||||
<para><emphasis role="bold">Networking:</emphasis></para>
|
||||
<para>Configure your network by editing the
|
||||
<filename>/etc/network/interfaces</filename> file</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Open <filename>/etc/network/interfaces</filename> and edit the
|
||||
file as mentioned:</para>
|
||||
<programlisting>
|
||||
# This file is for the OpenStack compute node for the OpenStack training project.
|
||||
# Note: Selection of the IP addresses is important.
|
||||
# Any changes to the IP addresses may break OpenStack related services.
|
||||
|
||||
# The loopback network interface
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
# The primary network interface - VirtualBox NAT connection
|
||||
# (VirtualBox Network Adapter 1)
|
||||
auto eth0
|
||||
iface eth0 inet dhcp
|
||||
|
||||
# VirtualBox vboxnet0 - OpenStack management network
|
||||
# (VirtualBox Network Adapter 2)
|
||||
auto eth1
|
||||
iface eth1 inet static
|
||||
address 10.10.10.53
|
||||
netmask 255.255.255.0
|
||||
|
||||
# VirtualBox vboxnet2 - OpenStack VM data/communication network
|
||||
# (VirtualBox Network Adapter 3)
|
||||
auto eth2
|
||||
iface eth2 inet static
|
||||
address 10.20.20.53
|
||||
netmask 255.255.255.0
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>After saving the interfaces file, restart the networking
|
||||
service:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service networking restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>ifconfig</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The expected network interface should match with the required IP
|
||||
addresses as configured above.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">SSH from host</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To SSH into the compute node from the host machine, type the
|
||||
command below:</para>
|
||||
<screen><prompt>$</prompt> <userinput>ssh compute@10.10.10.53</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>sudo su</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis role="bold">Preparing Ubuntu 14.04</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>After installing Ubuntu Server, switch to the root user</para>
|
||||
<para>
|
||||
<screen><prompt>$</prompt> <userinput>sudo su</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add the Icehouse repositories:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt><userinput>apt-get install ubuntu-cloud-keyring python-software-properties software-properties-common python-keyring</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>add-apt-repository cloud-archive:icehouse</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update your system:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt><userinput>apt-get update</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>apt-get upgrade</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>apt-get dist-upgrade</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart the machine for the changes to apply:</para>
|
||||
<screen><prompt>#</prompt> <userinput>reboot</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Install vlan and bridge-utils packages:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install vlan bridge-utils</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Install NTP:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install ntp</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configure NTP Server to controller node:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 0.ubuntu.pool.ntp.org/#server 0.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 1.ubuntu.pool.ntp.org/#server 1.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 2.ubuntu.pool.ntp.org/#server 2.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 3.ubuntu.pool.ntp.org/#server 3.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server ntp.ubuntu.com/server 10.10.10.51/g'/etc/ntp.conf</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Enable IP forwarding by adding the following to <filename>/etc/sysctl.conf</filename>:</para>
|
||||
<para>
|
||||
<programlisting>net.ipv4.ip_forward=1
|
||||
net.ipv4.conf.all.rp_filter=0
|
||||
net.ipv4.conf.default.rp_filter=0</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Run the following commands:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.ip_forward=1</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.conf.all.rp_filter=0</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.conf.default.rp_filter=0</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl -p</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role='bold'>Nova and KVM</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install the Compute packages:</para>
|
||||
<screen><prompt>#</prompt><userinput>apt-get install nova-compute-kvm python-guestfs</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>dpkg-statoverride --update --add root root 0644 /boot/vmlinuz-$(uname -r)</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configure <filename>/etc/nova/nova.conf</filename></para>
|
||||
<para><programlisting>[DEFAULT]
|
||||
auth_strategy = keystone
|
||||
rpc_backend = rabbit
|
||||
rabbit_host = 10.10.10.51
|
||||
my_ip = 10.10.10.53
|
||||
vnc_enabled = True
|
||||
vncserver_listen = 0.0.0.0
|
||||
vncserver_proxyclient_address = 10.10.10.53
|
||||
novncproxy_base_url = http://10.10.10.51:6080/vnc_auto.html
|
||||
glance_host = 10.10.10.51
|
||||
network_api_class = nova.network.neutronv2.api.API
|
||||
neutron_url = http://10.10.10.51:9696
|
||||
neutron_auth_strategy = keystone
|
||||
neutron_admin_tenant_name = service
|
||||
neutron_admin_username = neutron
|
||||
neutron_admin_password = service_pass
|
||||
neutron_admin_auth_url = http://10.10.10.51:35357/v2.0
|
||||
linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
|
||||
firewall_driver = nova.virt.firewall.NoopFirewallDriver
|
||||
security_group_api = neutron
|
||||
|
||||
[database]
|
||||
# The SQLAlchemy connection string used to connect to the database
|
||||
connection = mysql://novaUSER:novaPass@10.10.10.51/nova
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://10.10.10.51:5000
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = nova
|
||||
admin_password = service_pass</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/nova/nova-compute.conf</filename></para>
|
||||
<para><programlisting>[libvirt]
|
||||
virt_type = qemu</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart the Nova Compute Service:</para>
|
||||
<screen><prompt>#</prompt><userinput>service nova-compute restart</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis role="bold">Neutron and OVS</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install Open vSwitch:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y neutron-common neutron-plugin-ml2 neutron-plugin-openvswitch-agent</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/neutron/plugins/ml2/ml2_conf.ini</filename></para>
|
||||
<para><programlisting>[ml2]
|
||||
type_drivers = gre
|
||||
tenant_network_types = gre
|
||||
mechanism_drivers = openvswitch
|
||||
|
||||
[ml2_type_gre]
|
||||
tunnel_id_ranges = 1:1000
|
||||
|
||||
[ovs]
|
||||
local_ip = 10.20.20.53
|
||||
tunnel_type = gre
|
||||
enable_tunneling = True
|
||||
|
||||
[securitygroup]
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
|
||||
enable_security_group = True</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/neutron/neutron.conf</filename></para>
|
||||
<para><programlisting>[DEFAULT]
|
||||
auth_strategy = keystone
|
||||
rpc_backend = neutron.openstack.common.rpc.impl_kombu
|
||||
rabbit_host = 10.10.10.51
|
||||
rabbit_password = RABBIT_PASS
|
||||
core_plugin = ml2
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
[keystone_authtoken]
|
||||
...
|
||||
auth_uri = http://10.10.10.51:5000
|
||||
auth_host = 10.10.10.51
|
||||
auth_protocol = http
|
||||
auth_port = 35357
|
||||
admin_tenant_name = service
|
||||
admin_user = neutron
|
||||
admin_password = service_pass</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart all the services:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>service openvswitch-switch restart</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add the integration bridge:</para>
|
||||
<screen><prompt>#</prompt><userinput>ovs-vsctl add-br br-int</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Nova</emphasis></para>
|
||||
<para>List nova services (Check for the Smiley Faces to know if the services are running):</para>
|
||||
<screen><prompt>#</prompt> <userinput>nova-manage service list</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</chapter>
|
||||
@ -1,598 +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="lab_control-node.xml">
|
||||
<title>Controller node</title>
|
||||
<para><emphasis role="bold">Network Diagram:</emphasis></para>
|
||||
<figure>
|
||||
<title>Network Diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image03.png"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Publicly editable image source at <link
|
||||
xlink:href="https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing"
|
||||
>https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing</link></para>
|
||||
<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 VirtualBox VMs for OpenStack networks, so
|
||||
that OpenStack’s services can communicate with each other.</para>
|
||||
<note>
|
||||
<para>On reboot the node VM may lose internet and network connectivity.
|
||||
Restart the networking service and use the <command>ping</command>
|
||||
command to verify the network connectivity for the given VM.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>To avoid issues on the VirtualBox virtual machine
|
||||
(controller node), <emphasis role="bold">save the virtual
|
||||
machine</emphasis> state instead of completing a reboot or
|
||||
shut down.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>Take regular snapshots of the VirtualBox virtual machines after
|
||||
each section. In case the VM is broken, you may revert back to the
|
||||
snapshot to save time and effort.</para>
|
||||
</note>
|
||||
<para><guilabel>Controller node</guilabel></para>
|
||||
<para>
|
||||
Start the controller node which was set up in a previous section.
|
||||
</para>
|
||||
<para><emphasis role="bold">Preparing Ubuntu 14.04</emphasis></para>
|
||||
<para><emphasis role="bold">Networking :</emphasis></para>
|
||||
<para>Configure your network by editing the
|
||||
<filename>/etc/network/interfaces</filename> file</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Open <filename>/etc/network/interfaces</filename> and edit the
|
||||
file as mentioned:</para>
|
||||
<programlisting>
|
||||
# This file is for the OpenStack controller node for OpenStack training project.
|
||||
# Note: Selection of the IP addresses is important.
|
||||
# Any changes to the IP addresses may break OpenStack related services.
|
||||
|
||||
# The loopback network interface
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
# The primary network interface - VirtualBox NAT connection
|
||||
# (VirtualBox Network Adapter 1)
|
||||
auto eth0
|
||||
iface eth0 inet dhcp
|
||||
|
||||
# VirtualBox vboxnet0 - OpenStack management network
|
||||
# (VirtualBox Network Adapter 2)
|
||||
auto eth1
|
||||
iface eth1 inet static
|
||||
address 10.10.10.51
|
||||
netmask 255.255.255.0
|
||||
|
||||
# VirtualBox vboxnet2 - OpenStack API network
|
||||
# (VirtualBox Network Adapter 3)
|
||||
auto eth2
|
||||
iface eth2 inet static
|
||||
address 192.168.100.51
|
||||
netmask 255.255.255.0
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>After saving the interfaces file, restart the networking
|
||||
service:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service networking restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>ifconfig</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Verify if the network interfaces have the given IP addresses as
|
||||
configured above.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">SSH from host</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To SSH into the controller node from the host machine, type
|
||||
the following command.</para>
|
||||
<screen><prompt>$</prompt> <userinput>ssh control@10.10.10.51</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>sudo su</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Now you can have access to your host clipboard.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Update package lists and repository information</emphasis></para>
|
||||
<screen>
|
||||
<prompt>#</prompt><userinput>apt-get update</userinput>
|
||||
</screen>
|
||||
<para><emphasis role="bold">Update Ubuntu Cloud Archive for Icehouse</emphasis>
|
||||
</para>
|
||||
<para>The <link
|
||||
xlink:href="https://wiki.ubuntu.com/ServerTeam/CloudArchive"
|
||||
>Ubuntu Cloud Archive</link> is a special repository that
|
||||
allows you to install newer releases of OpenStack on the
|
||||
stable supported version of Ubuntu.</para>
|
||||
<para>Install the Ubuntu Cloud Archive for Icehouse
|
||||
<screen>
|
||||
<prompt>#</prompt><userinput>apt-get install ubuntu-cloud-keyring software-properties-common \
|
||||
python-software-properties</userinput>
|
||||
<prompt>#</prompt><userinput>add-apt-repository cloud-archive:icehouse</userinput>
|
||||
</screen>
|
||||
</para>
|
||||
<para>Update the package database and upgrade your system:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>apt-get update</userinput>
|
||||
<prompt>#</prompt> <userinput>apt-get dist-upgrade</userinput>
|
||||
</screen>
|
||||
<para>Reboot the system for all changes to take effect:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>reboot</userinput>
|
||||
</screen>
|
||||
<para>Install vlan and bridge-utils packages:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install vlan bridge-utils</userinput></screen>
|
||||
</para>
|
||||
<para>Install NTP:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y ntp</userinput></screen>
|
||||
</para>
|
||||
<para>Configure NTP Server to controller node:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 0.ubuntu.pool.ntp.org/#server 0.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 1.ubuntu.pool.ntp.org/#server 1.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 2.ubuntu.pool.ntp.org/#server 2.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 3.ubuntu.pool.ntp.org/#server 3.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server ntp.ubuntu.com/server 10.10.10.51/g'/etc/ntp.conf</userinput></screen>
|
||||
</para>
|
||||
<para><emphasis role="bold">MySQL</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install MySQL:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt>
|
||||
<userinput>apt-get install -y mysql-server python-mysqldb</userinput>
|
||||
</screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configure mysql to accept all incoming requests:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf</userinput>
|
||||
</screen>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>service mysql restart</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">RabbitMQ</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install RabbitMQ:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt>
|
||||
<userinput>apt-get install -y rabbitmq-server</userinput>
|
||||
</screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create these databases:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mysql -u root -p</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>CREATE DATABASE keystone;</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>GRANT ALL ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'KEYSTONE_DBPASS';</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>CREATE DATABASE glance;</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>GRANT ALL ON glance.* TO 'glance'@'%' IDENTIFIED BY 'GLANCE_DBPASS';</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>CREATE DATABASE neutron;</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>GRANT ALL ON neutron.* TO 'neutron'@'%' IDENTIFIED BY 'NEUTRON_DBPASS';</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>CREATE DATABASE nova;</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>GRANT ALL ON nova.* TO 'nova'@'%' IDENTIFIED BY 'NOVA_DBPASS';</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>CREATE DATABASE cinder;</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>GRANT ALL ON cinder.* TO 'cinder'@'%' IDENTIFIED BY 'CINDER_DBPASS';</userinput></screen>
|
||||
<screen><prompt>mysql></prompt> <userinput>quit;</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Installing Keystone</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install the Keystone packages:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y keystone</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Adapt the connection attribute in the
|
||||
<filename>/etc/keystone/keystone.conf</filename> to the new
|
||||
database:</para>
|
||||
<programlisting>connection = mysql://keystone:KEYSTONE_DBPASS@10.10.10.51/keystone</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart the identity service then synchronize the
|
||||
database:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service keystone restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>keystone-manage db_sync</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Fill up the keystone database using the following
|
||||
scripts:</para>
|
||||
<para>
|
||||
<link
|
||||
xlink:href="http://git.openstack.org/cgit/openstack/training-guides/plain/doc/training-guides/basic-install-guide/keystone-scripts/keystone_basic.sh">
|
||||
<filename>keystone_basic.sh</filename>
|
||||
</link></para>
|
||||
<para>
|
||||
<link
|
||||
xlink:href="http://git.openstack.org/cgit/openstack/training-guides/plain/doc/training-guides/basic-install-guide/keystone-scripts/keystone_endpoints_basic.sh">
|
||||
<filename>keystone_endpoints_basic.sh</filename>
|
||||
</link></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Run scripts:</para>
|
||||
<screen><prompt>$</prompt> <userinput>chmod +x keystone_basic.sh</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>chmod +x keystone_endpoints_basic.sh</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>./keystone_basic.sh</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>./keystone_endpoints_basic.sh</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create a simple credentials file</para>
|
||||
<programlisting>nano Credentials.sh</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Paste the following:</para>
|
||||
<screen><prompt>$</prompt> <userinput>export OS_TENANT_NAME=admin</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>export OS_USERNAME=admin</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>export OS_PASSWORD=admin_pass</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>export OS_AUTH_URL="http://192.168.100.51:5000/v2.0/"</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Load the above credentials:</para>
|
||||
<screen><prompt>$</prompt> <userinput>source Credentials.sh</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To test Keystone, we use a simple CLI command:</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-list</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Glance</emphasis></para>
|
||||
<para>The OpenStack Glance project provides services for
|
||||
discovering, registering, and retrieving virtual machine images.
|
||||
Glance has a RESTful API that allows querying of VM image metadata
|
||||
as well as retrieval of the actual image.</para>
|
||||
<para>VM images made available through Glance can be stored in a
|
||||
variety of locations from simple file systems to object-storage
|
||||
systems like the OpenStack Swift project.</para>
|
||||
<para>Glance, as with all OpenStack projects, is written with the
|
||||
following design guidelines in mind:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Component based architecture: Quickly adds new
|
||||
behaviors</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Highly available: Scales to very serious workloads</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Fault tolerant: Isolated processes avoid cascading
|
||||
failures</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Recoverable: Failures should be easy to diagnose, debug,
|
||||
and rectify</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Open standards: Be a reference implementation for a
|
||||
community-driven api</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Install Glance:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y glance</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update
|
||||
<filename>/etc/glance/glance-api-paste.ini</filename>:</para>
|
||||
<programlisting>[filter:authtoken]
|
||||
paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
|
||||
delay_auth_decision = true
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
admin_password = service_pass</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update the
|
||||
<filename>/etc/glance/glance-registry-paste.ini</filename>:</para>
|
||||
<programlisting>[filter:authtoken]
|
||||
paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
admin_password = service_pass</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update the
|
||||
<filename>/etc/glance/glance-api.conf</filename>:</para>
|
||||
<programlisting>
|
||||
[DEFAULT]
|
||||
rpc_backend = rabbit
|
||||
rabbit_host = 10.10.10.51
|
||||
|
||||
[database]
|
||||
sql_connection = mysql://glance:GLANCE_DBPASS@10.10.10.51/glance
|
||||
[keystone_authtoken]
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
admin_password = service_pass
|
||||
|
||||
[paste_deploy]
|
||||
flavor = keystone</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update the
|
||||
<filename>/etc/glance/glance-registry.conf</filename>:</para>
|
||||
<programlisting>[database]
|
||||
sql_connection = mysql://glance:GLANCE_DBPASS@10.10.10.51/glance
|
||||
[keystone_authtoken]
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = glance
|
||||
admin_password = service_pass
|
||||
|
||||
[paste_deploy]
|
||||
flavor = keystone</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart the glance-api and glance-registry
|
||||
services:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service glance-api restart; service glance-registry restart</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Synchronize the Glance database:</para>
|
||||
<screen><prompt>#</prompt> <userinput>glance-manage db_sync</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To test Glance, upload the “cirros cloud image” directly
|
||||
from the internet:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance image-create --name OS4Y_Cirros --is-public true --container-format bare --disk-format qcow2 --location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Check if the image is successfully uploaded:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance image-list</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Nova</emphasis></para>
|
||||
<para>Nova is the project name for OpenStack Compute, a cloud
|
||||
computing fabric controller, the main part of an IaaS system.
|
||||
Individuals and organizations can use Nova to host and manage
|
||||
their own cloud computing systems. Nova originated as a project
|
||||
out of NASA Ames Research Laboratory.</para>
|
||||
<para>Nova is written with the following design guidelines in
|
||||
mind:</para>
|
||||
<para>Install nova components:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>apt-get install -y nova-api nova-cert nova-conductor nova-consoleauth nova-novncproxy nova-scheduler python-novaclient</userinput>
|
||||
</screen>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/nova/nova.conf</filename></para>
|
||||
<programlisting>[database]
|
||||
connection = mysql://nova:NOVA_DBPASS@10.10.10.51/nova
|
||||
|
||||
[DEFAULT]
|
||||
rpc_backend = rabbit
|
||||
rabbit_host = 10.10.10.51
|
||||
my_ip = 10.10.10.51
|
||||
vncserver_listen = 10.10.10.51
|
||||
vncserver_proxyclient_address = 10.10.10.51
|
||||
auth_strategy = keystone
|
||||
|
||||
network_api_class = nova.network.neutronv2.api.API
|
||||
neutron_url = http://10.10.10.51:9696
|
||||
neutron_auth_strategy = keystone
|
||||
neutron_admin_tenant_name = service
|
||||
neutron_admin_username = neutron
|
||||
neutron_admin_password = service_pass
|
||||
neutron_admin_auth_url = http://10.10.10.51:35357/v2.0
|
||||
linuxnet_interface_driver = nova.network.linux_net.LinuxOVSInterfaceDriver
|
||||
firewall_driver = nova.virt.firewall.NoopFirewallDriver
|
||||
security_group_api = neutron
|
||||
service_neutron_metadata_proxy = true
|
||||
neutron_metadata_proxy_shared_secret = OpenStackTraining
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://10.10.10.51:5000
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = nova
|
||||
admin_password = service_pass
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Synchronize your database:</para>
|
||||
<screen><prompt>#</prompt> <userinput>nova-manage db sync</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart nova-* services (all nova services):</para>
|
||||
<screen><prompt>#</prompt><userinput>service nova-api restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service nova-cert restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service nova-consoleauth restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service nova-scheduler restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service nova-conductor restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service nova-novncproxy restart</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Check for the smiling faces on
|
||||
<systemitem class="service">nova-*</systemitem> services to confirm your
|
||||
installation:</para>
|
||||
<screen><prompt>#</prompt> <userinput>nova-manage service list</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Neutron</emphasis></para>
|
||||
<para>Neutron is an OpenStack project to provide “network
|
||||
connectivity as a service" between interface devices (e.g., vNICs)
|
||||
managed by other OpenStack services (e.g., nova).</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install the Neutron Server and the Open vSwitch package
|
||||
collection:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y neutron-server neutron-plugin-ml2</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit the
|
||||
<filename>/etc/neutron/plugins/ml2/ml2_conf.ini</filename>:</para>
|
||||
<programlisting>[ml2]
|
||||
type_drivers = gre
|
||||
tenant_network_types = gre
|
||||
mechanism_drivers = openvswitch
|
||||
|
||||
[ml2_type_gre]
|
||||
tunnel_id_ranges = 1:1000
|
||||
|
||||
[securitygroup]
|
||||
firewall_driver =
|
||||
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
|
||||
enable_security_group = True</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit the
|
||||
<filename>/etc/neutron/api-paste.ini</filename>:</para>
|
||||
<programlisting>[filter:authtoken]
|
||||
firewall_driver =
|
||||
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriverpaste.
|
||||
filter_factory = keystoneclient.middleware.auth_token:filter_factory
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = neutron
|
||||
admin_password = service_pass</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit the
|
||||
<filename>/etc/neutron/neutron.conf</filename>:</para>
|
||||
<programlisting>[DEFAULT]
|
||||
auth_strategy = keystone
|
||||
rpc_backend = neutron.openstack.common.rpc.impl_kombu
|
||||
rabbit_host = controller
|
||||
notify_nova_on_port_status_changes = True
|
||||
notify_nova_on_port_data_changes = True
|
||||
nova_url = http://controller:8774/v2
|
||||
nova_admin_username = nova
|
||||
nova_admin_tenant_id = SERVICE_TENANT_ID
|
||||
nova_admin_password = NOVA_PASS
|
||||
nova_admin_auth_url = http://controller:35357/v2.0
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = neutron
|
||||
admin_password = service_pass
|
||||
signing_dir = /var/lib/neutron/keystone-signing
|
||||
|
||||
[database]
|
||||
connection = mysql://neutron:NEUTRON_DBPASS@10.10.10.51/neutron</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart Nova Services</para>
|
||||
<screen><prompt>#</prompt> <userinput>service nova-api restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>service nova-scheduler restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>service nova-conductor restart</userinput></screen>
|
||||
<para>Restart Neutron services:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service neutron-server restart</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis role="bold">Cinder</emphasis></para>
|
||||
<para>Cinder is an OpenStack project that provides “block storage as a
|
||||
service”.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install Cinder components:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y cinder-api cinder-scheduler cinder-volume lvm2</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/cinder/cinder.conf</filename>:</para>
|
||||
<programlisting>[database]
|
||||
sql_connection = mysql://cinder:CINDER_DBPASS@10.10.10.51/cinder
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://10.10.10.51:5000
|
||||
auth_host = 10.10.10.51
|
||||
auth_port = 35357
|
||||
auth_protocol = http
|
||||
admin_tenant_name = service
|
||||
admin_user = cinder
|
||||
admin_password = service_pass
|
||||
|
||||
[DEFAULT]
|
||||
rpc_backend = cinder.openstack.common.rpc.impl_kombu
|
||||
rabbit_host = 10.10.10.51
|
||||
rabbit_port = 5672
|
||||
rabbit_userid = guest
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Then, synchronize Cinder database:</para>
|
||||
<screen><prompt>#</prompt> <userinput>cinder-manage db sync</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart Cinder Services</para>
|
||||
<screen><prompt>#</prompt> <userinput>service cinder-scheduler restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>service cinder-api restart</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Finally, create a volume group and name it
|
||||
<literal>cinder-volumes</literal>:</para>
|
||||
<screen><prompt>#</prompt> <userinput>dd if=/dev/zero of=cinder-volumes bs=1 count=0 seek=2G</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>losetup /dev/loop2 cinder-volumes</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>fdisk /dev/loop2</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>n</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>p</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>1</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>t</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>8e</userinput></screen>
|
||||
<screen><prompt>Command (m for help):</prompt> <userinput>w</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Proceed to create the physical volume then the volume
|
||||
group:</para>
|
||||
<screen><prompt>#</prompt> <userinput>pvcreate /dev/loop2</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>vgcreate cinder-volumes /dev/loop2</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<note>
|
||||
<para>Be aware that this volume group gets lost after a system
|
||||
reboot. If you do not want to perform this step again, make
|
||||
sure that you save the machine state and do not shut it
|
||||
down.</para>
|
||||
</note>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Horizon</emphasis></para>
|
||||
<para>Horizon is the canonical implementation of OpenStack’s
|
||||
dashboard, which provides a web-based user interface to OpenStack
|
||||
services including Nova, Swift, Keystone, etc.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To install Horizon, complete these steps:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y openstack-dashboard memcached</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If you do not like the OpenStack Ubuntu Theme, you can
|
||||
remove it with the below command:</para>
|
||||
<screen><prompt>#</prompt> <userinput>dpkg --purge openstack-dashboard-ubuntu-theme</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Reload Apache and memcached:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service apache2 restart; service memcached restart</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</chapter>
|
||||
@ -1,61 +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="lab_important-terms">
|
||||
<title>Important terms</title>
|
||||
<formalpara>
|
||||
<title>Host Operating System (Host)</title>
|
||||
<para>The operating system that is installed on your laptop or
|
||||
desktop that hosts virtual machines. This is commonly referred to as
|
||||
the host OS or <glossterm>host</glossterm>.
|
||||
In short, the machine where your VirtualBox is
|
||||
installed.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Guest Operating System (Guest)</title>
|
||||
<para>The operating system that is installed on your VirtualBox
|
||||
Virtual Machine. This virtual instance is independent of the
|
||||
host OS. It is commonly referred to as the <glossterm>guest OS</glossterm>
|
||||
or guest.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Node</title>
|
||||
<para>In this context, node refers specifically to servers. Each
|
||||
OpenStack server is a node.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Control Node</title>
|
||||
<para>Hosts the database, Keystone (Middleware), and the servers
|
||||
for the scope of the current OpenStack deployment. It acts as the
|
||||
brains behind OpenStack and drives services such as
|
||||
authentication, database, and so on.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Compute Node</title>
|
||||
<para>Has the required Hypervisor (Qemu/KVM) and is your Virtual
|
||||
Machine host.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Network Node</title>
|
||||
<para>Provides Network-as-a-Service and virtual networks for
|
||||
OpenStack.</para>
|
||||
</formalpara>
|
||||
<formalpara>
|
||||
<title>Using OpenSSH</title>
|
||||
<para>After the network interfaces file has been setup, you can switch
|
||||
to an SSH session by using an OpenSSH client to log in remotely
|
||||
to the required server node (Control, Network, Compute). Open a
|
||||
terminal on your host machine and run the following command:
|
||||
<screen><prompt>$</prompt> <userinput>ssh-keygen -t rsa</userinput>
|
||||
<computeroutput>Generating public/private rsa key pair.
|
||||
Enter the location in which to save the key (/u/kim/.ssh/id_rsa): [RETURN]
|
||||
Enter passphrase (empty for no passphrase): <can be left empty>
|
||||
Enter same passphrase again: <can be left empty>
|
||||
Your identification has been saved in /home/user/.ssh/id_rsa.
|
||||
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
|
||||
The key fingerprint is:
|
||||
b7:18:ad:3b:0b:50:5c:e1:da:2d:6f:5b:65:82:94:c5 xyz@example</computeroutput></screen>
|
||||
</para>
|
||||
</formalpara>
|
||||
</chapter>
|
||||
@ -1,307 +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="lab_network-node">
|
||||
<title>Network Node</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Network Diagram:</emphasis></para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<figure>
|
||||
<title>Network Diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image03.png"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Publicly editable image source at <link
|
||||
xlink:href="https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing"
|
||||
>https://docs.google.com/drawings/d/1GX3FXmkz3c_tUDpZXUVMpyIxicWuHs5fNsHvYNjwNNk/edit?usp=sharing</link></para>
|
||||
<para><emphasis role="bold">Vboxnet0</emphasis>, <emphasis role="bold">Vboxnet1</emphasis>,
|
||||
<emphasis role="bold">Vboxnet2</emphasis> - are virtual networks setup up by VirtualBox with
|
||||
your host machine. This is the way the host can communicate with the virtual machine instances. These
|
||||
networks are in turn used by VirtualBox VM’s for OpenStack networks, so that OpenStack’s
|
||||
services can communicate with each other.</para>
|
||||
<para><guilabel>Network node</guilabel></para>
|
||||
<para>Start the controller node which was set up in a previous section.</para>
|
||||
<note>
|
||||
<para>On reboot the VirtualBox VM may lose internet and network
|
||||
connectivity. Restart the networking service and use the
|
||||
<command>ping</command> command to verify the network
|
||||
connectivity for the given VM.</para>
|
||||
</note>
|
||||
<note>
|
||||
<para>Take regular snapshots of the VirtualBox virtual machines after
|
||||
each section. In case the VM is broken, you may revert back to the
|
||||
snapshot to save time and effort.</para>
|
||||
</note>
|
||||
<para><guilabel>Controller node</guilabel></para>
|
||||
<para>
|
||||
Start the controller node which was set up in a previous section.
|
||||
</para>
|
||||
<para><emphasis role="bold">Preparing Ubuntu 14.04</emphasis></para>
|
||||
<para><emphasis role="bold">Networking :</emphasis></para>
|
||||
<para>Configure your network by editing the
|
||||
<filename>/etc/network/interfaces</filename> file</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Open <filename>/etc/network/interfaces</filename> and edit the
|
||||
file as mentioned:</para>
|
||||
<programlisting>
|
||||
# This file is for the OpenStack network node for OpenStack training project.
|
||||
# Note: Selection of the IP addresses is important.
|
||||
# Any changes to the IP addresses may break OpenStack related services.
|
||||
|
||||
# The loopback network interface
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
# The primary network interface - VirtualBox NAT connection
|
||||
# (VirtualBox Network Adapter 1)
|
||||
auto eth0
|
||||
iface eth0 inet dhcp
|
||||
|
||||
# VirtualBox vboxnet0 - OpenStack management network
|
||||
# (VirtualBox Network Adapter 2)
|
||||
auto eth1
|
||||
iface eth1 inet static
|
||||
address 10.10.10.52
|
||||
netmask 255.255.255.0
|
||||
|
||||
# VirtualBox vboxnet2 - OpenStack VM data/communication network
|
||||
# (VirtualBox Network Adapter 3)
|
||||
auto eth2
|
||||
iface eth2 inet static
|
||||
address 10.20.20.52
|
||||
netmask 255.255.255.0
|
||||
|
||||
# VirtualBox vboxnet3 - For exposing external network
|
||||
# (VirtualBox Network Adapter 4)
|
||||
auto eth3
|
||||
iface eth3 inet static
|
||||
address 192.168.100.52
|
||||
netmask 255.255.255.0
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>After saving the interfaces file, restart the networking
|
||||
service:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service networking restart</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>ifconfig</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The expected network interface should match with the required IP
|
||||
addresses as configured above.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">SSH from host</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Create an SSH keypair for the controller node.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>To SSH into the network node from the host machine, type the
|
||||
command mentioned below.</para>
|
||||
<screen><prompt>$</prompt> <userinput>ssh network@10.10.10.51</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>sudo su</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Preparing Ubuntu 14.04</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>After installing Ubuntu Server, ssh into the VM and change to the root user</para>
|
||||
<para>
|
||||
<screen><prompt>$</prompt> <userinput>sudo su</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add Icehouse repositories:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt><userinput>apt-get install ubuntu-cloud-keyring python-software-properties software-properties-common python-keyring</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>add-apt-repository cloud-archive:icehouse</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Update your system:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt><userinput>apt-get update</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>apt-get upgrade</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>apt-get dist-upgrade</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart the machine for the changes to apply</para>
|
||||
<screen><prompt>#</prompt> <userinput>reboot</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Install vlan and bridge-utils packages:</para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install vlan bridge-utils</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Install NTP:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install ntp</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configure NTP server to controller node:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 0.ubuntu.pool.ntp.org/#server0.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 1.ubuntu.pool.ntp.org/#server1.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 2.ubuntu.pool.ntp.org/#server2.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server 3.ubuntu.pool.ntp.org/#server3.ubuntu.pool.ntp.org/g' /etc/ntp.conf</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sed -i 's/server ntp.ubuntu.com/server 10.10.10.51/g'/etc/ntp.conf</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Enable IP forwarding by adding the following to <filename>/etc/sysctl.conf</filename>:</para>
|
||||
<para>
|
||||
<programlisting>net.ipv4.ip_forward=1
|
||||
net.ipv4.conf.all.rp_filter=0
|
||||
net.ipv4.conf.default.rp_filter=0</programlisting>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Run the following commands:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.ip_forward=1</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.conf.all.rp_filter=0</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl net.ipv4.conf.default.rp_filter=0</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>sysctl -p</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Open vSwitch</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install Open vSwitch packages:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install -y openvswitch-switch openvswitch-datapath-dkms</userinput></screen>
|
||||
<note os="ubuntu">
|
||||
<para>The Ubuntu version 14.04 or Linux kernel version 3.11 or
|
||||
newer do not require the
|
||||
<emphasis>openvswitch-datapath-dkms</emphasis>
|
||||
package.</para>
|
||||
</note>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create the bridges:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>ovs-vsctl add-br br-int</userinput></screen>
|
||||
<screen><prompt>#</prompt> <userinput>ovs-vsctl add-br br-ex</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Neutron</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Neutron:</para>
|
||||
<para>
|
||||
<screen><prompt>#</prompt> <userinput>apt-get install neutron-plugin-ml2 neutron-plugin-openvswitch-agent openvswitch-datapath-dkms \
|
||||
neutron-l3-agent neutron-dhcp-agent</userinput></screen>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/neutron/neutron.conf</filename></para>
|
||||
<para><programlisting>[DEFAULT]
|
||||
auth_strategy = keystone
|
||||
rpc_backend = neutron.openstack.common.rpc.impl_kombu
|
||||
rabbit_host = 10.10.10.51
|
||||
core_plugin = ml2
|
||||
service_plugins = router
|
||||
allow_overlapping_ips = True
|
||||
|
||||
[keystone_authtoken]
|
||||
auth_uri = http://10.10.10.51:5000
|
||||
auth_host = 10.10.10.51
|
||||
auth_protocol = http
|
||||
auth_port = 35357
|
||||
admin_tenant_name = service
|
||||
admin_user = neutron
|
||||
admin_password = service_pass</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/neutron/l3_agent.ini</filename></para>
|
||||
<para><programlisting>[DEFAULT]
|
||||
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
|
||||
use_namespaces = True</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/neutron/metadata_agent.ini</filename></para>
|
||||
<para><programlisting>[DEFAULT]
|
||||
auth_url = http://10.10.10.51:5000/v2.0
|
||||
auth_region = regionOne
|
||||
admin_tenant_name = service
|
||||
admin_user = neutron
|
||||
admin_password = service_pass
|
||||
nova_metadata_ip = 10.10.10.51
|
||||
metadata_proxy_shared_secret = OpenStackTraining</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Configure ML2 Plugin by editing the file <filename>/etc/neutron/plugins/ml2/ml2_conf.ini</filename></para>
|
||||
<para><programlisting>[ml2]
|
||||
type_drivers = gre
|
||||
tenant_network_types = gre
|
||||
mechanism_drivers = openvswitch
|
||||
|
||||
[ml2_type_gre]
|
||||
tunnel_id_ranges = 1:1000
|
||||
|
||||
[ovs]
|
||||
local_ip = 10.20.20.52
|
||||
tunnel_type = gre
|
||||
enable_tunneling = True
|
||||
|
||||
[securitygroup]
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
|
||||
enable_security_group = True</programlisting></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart OVS service</para>
|
||||
<screen><prompt>#</prompt><userinput>service openvswitch-switch restart</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add the integration bridge</para>
|
||||
<screen><prompt>#</prompt><userinput>ovs-vsctl add-br br-int</userinput></screen>
|
||||
<para>Add the external bridge</para>
|
||||
<screen><prompt>#</prompt><userinput>ovs-vsctl add-br br-ex</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit <filename>/etc/network/interfaces</filename> to make
|
||||
the following changes:</para>
|
||||
<programlisting>
|
||||
# VirtualBox vboxnet2 - OpenStack VM internet access
|
||||
# (VirtualBox Network Adapter 3)
|
||||
auto eth3
|
||||
iface eth3 inet manual
|
||||
up ifconfig $IFACE 0.0.0.0 up
|
||||
up ip link set $IFACE promisc on
|
||||
down ip link set $IFACE promisc off
|
||||
down ifconfig $IFACE down
|
||||
|
||||
# For giving access to network node via. the external network
|
||||
auto br-ex
|
||||
iface br-ex inet static
|
||||
address 192.168.100.52
|
||||
netmask 255.255.255.0
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Add port to external bridge</para>
|
||||
<screen><prompt>#</prompt><userinput>ovs-vsctl add-port br-ex eth3</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Restart neutron services</para>
|
||||
<screen><prompt>#</prompt><userinput>service neutron-plugin-openvswitch-agent restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service neutron-l3-agent restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service neutron-dhcp-agent restart</userinput></screen>
|
||||
<screen><prompt>#</prompt><userinput>service neutron-metadata-agent restart</userinput></screen>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</chapter>
|
||||
@ -1,9 +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="lab_openstack-production.xml">
|
||||
<title>OpenStack In Production</title>
|
||||
<para>More Content To be Added.</para>
|
||||
</chapter>
|
||||
@ -1,662 +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="lab_virtualbox-basics">
|
||||
<title>VirtualBox basics</title>
|
||||
<para><guilabel>Getting Started</guilabel></para>
|
||||
<para>The following methods are conventional for deploying
|
||||
OpenStack on VirtualBox for the sake of a test/sandbox or just to
|
||||
try out OpenStack on commodity hardware.</para>
|
||||
<para>1. DevStack</para>
|
||||
<para>2. Vagrant</para>
|
||||
<para>DevStack and Vagrant bring in some level of automated
|
||||
deployment as running the scripts will get your VirtualBox
|
||||
instance configured as the required OpenStack deployment. We
|
||||
will be manually deploying OpenStack on VirtualBox to
|
||||
get a better view of how OpenStack works.</para>
|
||||
<para><guilabel>Prerequisites:</guilabel></para>
|
||||
<para>Networking and Linux are required to get setup.</para>
|
||||
<para>The Virtual Machines and Virtual Networks will be given
|
||||
equal privileges as a physical machine on a physical
|
||||
network.</para>
|
||||
<para>For more information, refer to the following
|
||||
links:</para>
|
||||
<para>
|
||||
<emphasis role="bold">OpenStack:</emphasis> <link
|
||||
xlink:href="http://docs.openstack.org">OpenStack Official
|
||||
Documentation</link></para>
|
||||
<para><emphasis role="bold">Networking:</emphasis> Computer
|
||||
Networks (5th Edition) by Andrew S. Tanenbaum</para>
|
||||
<para><emphasis role="bold">VirtualBox:</emphasis> <link
|
||||
xlink:href="http://www.virtualbox.org/manual/UserManual.html">Virtual
|
||||
Box Manual</link></para>
|
||||
<para><emphasis role="bold">Requirements:</emphasis></para>
|
||||
<para>Operating Systems - It is recommended to use Ubuntu Server 14.04 LTS
|
||||
</para>
|
||||
<note><para>Older Ubuntu versions may not support Icehouse. Ubuntu Server
|
||||
12.04 will support Icehouse but is out of scope for this book.
|
||||
</para></note>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Recommended Requirements:</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">VT Enabled PC:</td>
|
||||
<td rowspan="1" colspan="1">Intel ix or AMD QuadCore</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">4 GB RAM:</td>
|
||||
<td rowspan="1" colspan="1">DDR2/DDR3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Minimum Requirements:</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Non-VT PC's:</td>
|
||||
<td rowspan="1" colspan="1">Intel Core 2 Duo or AMD Dual
|
||||
Core</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">2GB Ram:</td>
|
||||
<td rowspan="1" colspan="1">DDR2/DDR3</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para>To check if the processor is VT enabled, install cpu-checker as
|
||||
follows:</para>
|
||||
<screen>
|
||||
<prompt>#</prompt> <userinput>apt-get install cpu-checker</userinput>
|
||||
<prompt>#</prompt> <userinput>kvm-ok</userinput>
|
||||
</screen>
|
||||
<para>If your device does not support VT it will show:</para>
|
||||
<screen>
|
||||
<computeroutput>INFO: Your CPU does not support KVM extensions
|
||||
KVM acceleration can NOT be used</computeroutput>
|
||||
</screen>
|
||||
<para>You will still be able to use VirtualBox but the instances
|
||||
will be very slow.</para>
|
||||
<para>There are many ways to configure your OpenStack Setup. In this example, we
|
||||
will deploy OpenStack multi-node using OVS as the network
|
||||
plug-in and QEMU/KVM as the hypervisor.</para>
|
||||
<para><emphasis role="bold">Host only connections:</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Host only connections provide an internal network
|
||||
between your host and the Virtual Machine instances on your host machine. This network is not traceable
|
||||
by other networks.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Bridged connections are not recommended.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The following are the host only connections that you
|
||||
will be setting up later on:</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>vboxnet0 - OpenStack management network - host static IP
|
||||
10.10.10.1</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>vboxnet1 - VM conf.network - host static IP
|
||||
10.20.20.1</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>vboxnet2 - VM external network access (host
|
||||
machine) 192.168.100.1</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<figure>
|
||||
<title>Network diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata contentwidth="5in" fileref="../figures/lab_virtual-box/image03.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Vboxnet0, Vboxnet1, Vboxnet2 - are virtual networks setup
|
||||
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.
|
||||
For details, see the <link
|
||||
xlink:href="http://www.virtualbox.org/manual/ch06.html#network_hostonly">VirtualBox
|
||||
documentation</link>
|
||||
</para>
|
||||
<section xml:id="lab_virtualbox-basics_setup_virtualbox">
|
||||
<title>Setup your VM environment</title>
|
||||
<para>Before you can start configuring your environment you need to
|
||||
download some of the following stuff:</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para><link xlink:href="https://www.virtualbox.org/wiki/Downloads">
|
||||
Oracle VirtualBox</link></para>
|
||||
<note><para>You cannot set up an AMD64 VM on a x86 machine.</para></note>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link xlink:href="http://www.ubuntu.com/download/server">
|
||||
Ubuntu 12.04 Server or Ubuntu 13.04 Server</link></para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<note><para>You need an x86 image for VM's if kvm-ok fails, even
|
||||
though you are on an AMD64 machine.</para></note>
|
||||
<note><para>Even though I'm using Ubuntu as host, the same is
|
||||
applicable to Windows, Mac and other Linux hosts.</para></note>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>If you have an i5 or i7 2nd gen processor you can have VT
|
||||
technology inside VM's provided by VMware. This means that
|
||||
your OpenStack nodes (which are in turn VM's) will give a
|
||||
positive result on KVM-OK. (I call it - nesting of type-2
|
||||
hypervisors). The rest of the configurations remain the same except
|
||||
for the UI and a few other trivial differences.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_virtual_networks">
|
||||
<title>Configure virtual networks</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>This section of the guide will help you setup your
|
||||
networks for your Virtual Machine.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Launch VirtualBox</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Click on <emphasis role="bold"
|
||||
>File>Preferences</emphasis> present on the menu bar of
|
||||
VirtualBox.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Select the <emphasis role="bold">Network
|
||||
tab</emphasis>.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>On the right side you will see an option to add
|
||||
Host-Only networks.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<figure>
|
||||
<title>Create host only networks</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image13.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Create three host-only network connections. As shown
|
||||
above.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Edit the host-only connections to have the following
|
||||
settings.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Vboxnet0</emphasis></para>
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Option</th>
|
||||
<th>Value</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>IPv4 Address:</td>
|
||||
<td>10.10.10.1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>IPv4 Network Mask:</td>
|
||||
<td>255.255.255.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>IPv6 Address:</td>
|
||||
<td>Can be left blank</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>IPv6 Network Mask Length:</td>
|
||||
<td>Can be left blank</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<figure>
|
||||
<title>Vboxnet0</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image19.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Vboxnet1</emphasis></para>
|
||||
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th rowspan="1" colspan="1">Option</th>
|
||||
<th rowspan="1" colspan="1">Value</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv4 Address:</td>
|
||||
<td rowspan="1" colspan="1">10.20.20.1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv4 Network Mask:</td>
|
||||
<td rowspan="1" colspan="1">255.255.255.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv6 Address:</td>
|
||||
<td rowspan="1" colspan="1">Can be Left Blank</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv6 Network Mask Length :</td>
|
||||
<td rowspan="1" colspan="1">Can be Left Blank</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<figure>
|
||||
<title>Vboxnet1</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image16.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Vboxnet2</emphasis></para>
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th rowspan="1" colspan="1">Option</th>
|
||||
<th rowspan="1" colspan="1">Value</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv4 Address:</td>
|
||||
<td rowspan="1" colspan="1">192.168.100.1</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv4 Network Mask:</td>
|
||||
<td rowspan="1" colspan="1">255.255.255.0</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv6 Address:</td>
|
||||
<td rowspan="1" colspan="1">Can be Left Blank</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">IPv6 Network Mask Length :</td>
|
||||
<td rowspan="1" colspan="1">Can be Left Blank</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<figure>
|
||||
<title>Image: Vboxnet2</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image08.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_install_ssh_ftp">
|
||||
<title>Install SSH and FTP</title>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>You may benefit by installing SSH and FTP so that you
|
||||
can use your remote shell to login into the machine and
|
||||
use your terminal which is more convenient than using the
|
||||
Virtual Machines tty through the VirtualBox's UI. You get a
|
||||
few added features such as copy - paste commands into the
|
||||
remote terminal, which is not possible directly on the VM.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>FTP is for transferring files to and from your local machine
|
||||
and the virtual machine. You can
|
||||
also use SFTP or install FTPD on both the HOST and the VM's.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Installation of SSH and FTP with the configuration steps are
|
||||
out of the scope of this guide.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<note><para>Set up the
|
||||
networks from inside the VM before trying to SSH and FTP into the
|
||||
machines.</para>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_install_vm_instances">
|
||||
<title>Install your VM instances</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>During the installation of the operating systems you will be
|
||||
asked for custom software to install. You may skip this step
|
||||
by pressing the <keycap>Enter</keycap> key without selecting
|
||||
any of the given options.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<warning><para>Please do not install any of the other packages
|
||||
except for the packages that are mentioned below, unless you are
|
||||
familiar with the process.</para>
|
||||
</warning>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_control_node">
|
||||
<title>Control node</title>
|
||||
|
||||
<para>Create a new virtual machine and select Ubuntu Server.</para>
|
||||
<figure>
|
||||
<title>Create new virtual machine</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image11.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Select the appropriate amount of RAM. For the control node,
|
||||
the minimum is 512 MB of RAM. For other settings, use the
|
||||
defaults. The hard disk size can be 8 GB.</para>
|
||||
<para>Configure the networks</para>
|
||||
<para>(Ignore the IP Address for now, you will set it up from
|
||||
inside the VM)</para>
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Network Adapter</th>
|
||||
<th>Host-Only Adapter Name</th>
|
||||
<th>IP Address</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth0</td>
|
||||
<td>Vboxnet0</td>
|
||||
<td>10.10.10.51</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth1</td>
|
||||
<td>Vboxnet2</td>
|
||||
<td>192.168.100.51</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth2</td>
|
||||
<td>NAT</td>
|
||||
<td>DHCP</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para><emphasis role="bold">Adapter 1 (Vboxnet0)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter1 - Vboxnet0</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image07.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 2 (Vboxnet2)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter2 - Vboxnet2</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image18.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 3 (NAT)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter3 - NAT</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image14.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Now install Ubuntu Server 12.04 or 13.04 on this
|
||||
machine.</para>
|
||||
<note><para>Install the SSH server
|
||||
when asked for custom software to install. The rest of the packages
|
||||
are not required and may come in the way of the OpenStack packages -
|
||||
like DNS servers etc. (unless you are an advanced user).</para>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_network_node">
|
||||
<title>Network node</title>
|
||||
|
||||
<para>Create a new virtual machine, with the minimum RAM as
|
||||
512 MB. The remainder can be left as default. The minimum HDD
|
||||
space is 8 GB.</para>
|
||||
|
||||
<figure>
|
||||
<title>Create New Virtual Machine</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image12.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Configure the networks</para>
|
||||
<para>(Ignore the IP Address for now, you will set it up from
|
||||
inside the VM)</para>
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Network Adapter</th>
|
||||
<th>Host-Only Adapter Name</th>
|
||||
<th>IP Address</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth0</td>
|
||||
<td>Vboxnet0</td>
|
||||
<td>10.10.10.52</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth1</td>
|
||||
<td>Vboxnet1</td>
|
||||
<td>10.20.20.52</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth2</td>
|
||||
<td>Vboxnet2</td>
|
||||
<td>192.168.100.52</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth3</td>
|
||||
<td>NAT</td>
|
||||
<td>DHCP</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para><emphasis role="bold">Adapter 1 (Vboxnet0)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter 1 - Vboxnet0</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image05.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 2 (Vboxnet1)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter2 - Vboxnet1</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image17.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 3 (Vboxnet2)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter3 - Vboxnet2</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image02.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 4 (NAT)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter4 - NAT</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image00.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Now install Ubuntu Server 12.04 or 13.04 on this
|
||||
machine.</para>
|
||||
<note><para>Install the SSH server when you are prompted for the
|
||||
custom software to install. The rest of the packages are not
|
||||
required and may come in the way of OpenStack packages - like DNS
|
||||
servers.</para>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_compute_node">
|
||||
<title>Compute node</title>
|
||||
|
||||
<para>Create a virtual machine with at least 1,000 MB RAM and
|
||||
8 GB HDD. For other settings, use the defaults.</para>
|
||||
<figure>
|
||||
<title>Create new virtual machine</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image04.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Configure the networks</para>
|
||||
<para>(Ignore the IP Address for now, you will set it up from
|
||||
inside the VM)</para>
|
||||
|
||||
<informaltable class="c25">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Network Adapter</th>
|
||||
<th>Host-Only Adapter Name</th>
|
||||
<th>IP Address</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth0</td>
|
||||
<td>Vboxnet0</td>
|
||||
<td>10.10.10.53</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth1</td>
|
||||
<td>Vboxnet1</td>
|
||||
<td>10.20.20.53</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>eth2</td>
|
||||
<td>NAT</td>
|
||||
<td>DHCP</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para><emphasis role="bold">Adapter 1 (Vboxnet0)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter1 - Vboxnet0</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image15.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 2 (Vboxnet1)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter2 - Vboxnet1</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image10.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><emphasis role="bold">Adapter 3 (NAT)</emphasis></para>
|
||||
<figure>
|
||||
<title>Adapter3 - NAT</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/lab_virtual-box/image01.png"
|
||||
contentwidth="6in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Now install Ubuntu Server 12.04 or 13.04 on this
|
||||
machine.</para>
|
||||
<note><para>Install the SSH server
|
||||
when asked for custom software to install. The rest of the packages
|
||||
are not required and may come in the way of OpenStack packages -
|
||||
like DNS servers etc.</para>
|
||||
</note>
|
||||
</section>
|
||||
<section xml:id="lab_virtualbox-basics_setup_warnings">
|
||||
<title>Warnings and advice</title>
|
||||
<para>Shutting down your Virtual Machine may lead to
|
||||
malfunctioning OpenStack Services. Do not directly
|
||||
shutdown your VM, in case your VM's don't have Internet connectivity.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>From your VM instance, use the <command>ping</command>
|
||||
command to verify internet access.</para>
|
||||
<screen><prompt>$</prompt> <userinput>ping www.google.com</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If its not connected, restart the networking
|
||||
service:</para>
|
||||
<screen><prompt>#</prompt> <userinput>service networking restart</userinput>
|
||||
<prompt>#</prompt> <userinput>ping www.google.com</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>If this doesn't work, check your network
|
||||
settings from VirtualBox. Something may be missing or it may be
|
||||
misconfigured.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>This should reconnect the network a majority of the
|
||||
time. If you still cannot connect, there may be another issue,
|
||||
or internet access is unavailable.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Note: There are known bugs with the ping under NAT.
|
||||
Although the latest versions of VirtualBox have better
|
||||
performance, sometimes ping may not work even if the
|
||||
Network is connected to the Internet.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Congratulations! You are now setup with the infrastructure for
|
||||
deploying OpenStack. Just make sure that the Ubuntu Server
|
||||
is installed on the above setup VirtualBox instances. In the
|
||||
next section we will go through deploying OpenStack using the
|
||||
above created VirtualBox instances.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,145 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<book 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="bk000-preface">
|
||||
<title>Start Here</title>
|
||||
<preface xml:id="preface">
|
||||
<title>Preface</title>
|
||||
<?dbhtml stop-chunking?>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_dochistory.xml">
|
||||
</xi:include>
|
||||
</preface>
|
||||
<appendix xml:id="preface_under-construction">
|
||||
<title>OpenStack Training Guides Are Under Construction</title>
|
||||
<para>We need your help! This is a community driven project to provide the user group community
|
||||
access to OpenStack training materials. We cannot make this work without your help.</para>
|
||||
<para>There are a few ways to get involved. The easiest way is to use the training guides. Look at
|
||||
the end of each section and you will see the Submit a Bug link. When you find something that can
|
||||
be improved or fixed, submit a bug by clicking on the link.</para>
|
||||
<para>If you want to get involved with the effort around OpenStack community training, read on,
|
||||
here are the options:</para>
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<formalpara><title>Attending a user group using the training materials</title>
|
||||
<para>The OpenStack community training started at the SFBay OpenStack User Group. More
|
||||
information on this user group and others using the training guides on the <link
|
||||
xlink:href="https://wiki.openstack.org/wiki/OpenStackUserGroups">OpenStack User Groups
|
||||
page</link>.</para>
|
||||
</formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara><title>Teach / Lead a user group using the training materials</title>
|
||||
<para>Awesome! Your experience will not only give you more experience with OpenStack, but
|
||||
you will help some people find new jobs. We have put all the information about <link
|
||||
xlink:href="https://wiki.openstack.org/wiki/OpenStackUserGroups/HowTo#Running_a_Hackathon"
|
||||
>How To Run An OpenStack Hackathon</link> here.</para></formalpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<formalpara>
|
||||
<title>Help create the training pages</title>
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>We are currently working on creating the Associate Training Guide. It is the
|
||||
first of four training guides. We are using the Install Guide, Administration
|
||||
Guides, Developer Documentation, and Aptira supplied content as the sources for
|
||||
most of the Associate Training Guide. The basic idea is that we use XML include
|
||||
statements to actually use the source content to create new pages. We aim to use
|
||||
as much of the material as possible from existing documentation. By doing this
|
||||
we reuse and improve the existing docs. The topics in the Associate Training
|
||||
Guide are in a bunch of KanBan story board cards. Each card in the story board
|
||||
represents something that an Associate trainee needs to learn. But first things
|
||||
first, you need to get some basic tools and accounts installed and configured
|
||||
before you can really start.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Getting Accounts and Tools:</emphasis> We can't do
|
||||
this without operators and developers using and creating the content. Anyone can
|
||||
contribute content. You will need the tools to get started. Go to the
|
||||
<link xlink:href="http://docs.openstack.org/training-guides/content/operator-getting-started-lab.html#getting-tools-and-accounts">
|
||||
Getting Tools and Accounts</link> page.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Pick a Bug:</emphasis> Once you have your tools ready
|
||||
to go, you can assign some work to yourself. Go to the <link xlink:href="https://bugs.launchpad.net/openstack-training-guides">Bugs</link> and assign a bug from the list to yourself.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Create the Content:</emphasis> Each bug
|
||||
from the list will be a separate chunk of content that you will
|
||||
add to the openstack-manuals repository openstack-training sub-project.
|
||||
<link xlink:href="http://docs.openstack.org/training-guides/content/operator-getting-started-lab.html#operator-add-training-content">
|
||||
More details on creating training content here.</link></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<note>
|
||||
<para>Here are more details on committing changes to OpenStack
|
||||
<link xlink:href="http://docs.openstack.org/training-guides/content/operator-getting-started-lab.html#submit-doc-bug">fixing a documentation bug</link>
|
||||
, <link xlink:href="http://docs.openstack.org/infra/manual/developers.html#development-workflow">OpenStack Gerrit
|
||||
Workflow</link>, <link xlink:href="https://wiki.openstack.org/wiki/Documentation/HowTo">OpenStack
|
||||
Documentation HowTo</link> and , <link xlink:href="http://git-scm.com/doc">Git Documentation</link></para>
|
||||
</note>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>More details on the OpenStack Training project.</para>
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para><link xlink:href="https://wiki.openstack.org/wiki/Training-manuals">OpenStack Training
|
||||
Wiki</link> (describes the project in detail)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="https://blueprints.launchpad.net/openstack-manuals/+spec/training-manuals"
|
||||
>OpenStack Training blueprint</link>(this is the key project page)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link xlink:href="http://www.meetup.com/openstack/">Bi-Weekly SFBay Hackathon meetup
|
||||
page</link>(we discuss project details with all team members)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link xlink:href="https://etherpad.openstack.org/sfbay-openstack">Bi-Weekly SFBay
|
||||
Hackathon Etherpad</link>(meetup notes)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link xlink:href="https://wiki.openstack.org/wiki/Meetings/training-manuals">Core
|
||||
Training Weekly Meeting Agenda</link>(we review project action items here)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="https://launchpad.net/openstack-training-guides"
|
||||
>Training Bugs</link></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>
|
||||
</appendix>
|
||||
<appendix xml:id="building-training-cluster">
|
||||
<title>Building the Training Cluster</title>
|
||||
<?dbhtml stop-chunking?>
|
||||
<section xml:id="important-terms">
|
||||
<title>Important Terms</title>
|
||||
<xi:include href="./basic-install-guide/lab_important-terms.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'lab_important-terms']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="virtualbox-scripted">
|
||||
<title>Building the Training Cluster, Scripted</title>
|
||||
<xi:include href="./training-cluster-by-script.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'training-cluster-by-script']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<section xml:id="virtualbox-manual">
|
||||
<title>Building the Training Cluster, Manually</title>
|
||||
<xi:include href="./basic-install-guide/lab_virtualbox-basics.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'lab_virtualbox-basics']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
</appendix>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/app_support.xml"/>
|
||||
</book>
|
||||
@ -1,14 +0,0 @@
|
||||
Introduction
|
||||
============
|
||||
|
||||
* This folder contains the XML files commonly used by all the other Training
|
||||
Guides.
|
||||
* If you feel that the XML files in this section can be re-used for other books
|
||||
under OpenStack-Manuals, you may move them to common folder located in
|
||||
OpenStack-Manuals.
|
||||
* Please refer the following link to get more information about this project
|
||||
https://launchpad.net/openstack-training-guides
|
||||
* Please follow the following wiki to get more information about development
|
||||
process of Training Guides. This should provide enough information to start
|
||||
contributing to training guides
|
||||
https://wiki.openstack.org/wiki/Training-guides
|
||||
@ -1,611 +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="operator-editing-code">
|
||||
<title>Editing Code</title>
|
||||
<section xml:id="getting-tools-and-accounts">
|
||||
<title>Get Tools and Accounts</title>
|
||||
<procedure>
|
||||
<note>
|
||||
<para>First create a GitHub account at <link
|
||||
xlink:href="http://github.com"
|
||||
>github.com.</link></para>
|
||||
</note>
|
||||
<note>
|
||||
<para>Check out <link
|
||||
xlink:href="https://wiki.openstack.org/wiki/Documentation/HowTo"
|
||||
>https://wiki.openstack.org/wiki/Documentation/HowTo</link>
|
||||
for more extensive setup instructions.</para>
|
||||
</note>
|
||||
<step>
|
||||
<para>Download and install Git from <link
|
||||
xlink:href="http://git-scm.com/downloads"
|
||||
>http://git-scm.com/downloads</link>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Create your local repository directory:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mkdir /Users/<replaceable>username</replaceable>/code/</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<title>Install SourceTree</title>
|
||||
<substeps>
|
||||
<step>
|
||||
<para><link
|
||||
xlink:href="http://www.sourcetreeapp.com/download/"
|
||||
>http://www.sourcetreeapp.com/download/</link>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Ignore the Atlassian Bitbucket and Stack
|
||||
setup.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add your GitHub username and
|
||||
password.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Set your local repository
|
||||
location.</para>
|
||||
</step>
|
||||
</substeps>
|
||||
</step>
|
||||
<step>
|
||||
<title>Install an XML editor</title>
|
||||
<substeps>
|
||||
<step>
|
||||
<para>You can download a 30 day trial of
|
||||
Oxygen. The floating licenses donated by
|
||||
OxygenXML have all been handed out.<link
|
||||
xlink:href="http://www.oxygenxml.com/download_oxygenxml_editor.html"
|
||||
>http://www.oxygenxml.com/download_oxygenxml_editor.html</link></para>
|
||||
</step>
|
||||
<step>
|
||||
<para>AND/OR PyCharm <link
|
||||
xlink:href="http://download.jetbrains.com/python/pycharm-community-3.0.1.dmg"
|
||||
>http://download.jetbrains.com/python/pycharm-community-3.0.1.dmg</link></para>
|
||||
</step>
|
||||
<step>
|
||||
<para>AND/OR You can use emacs or vi
|
||||
editors.</para>
|
||||
<para>Here are some great resources on DocBook
|
||||
and Emacs' NXML mode:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="http://paul.frields.org/2011/02/09/xml-editing-with-emacs/"
|
||||
>http://paul.frields.org/2011/02/09/xml-editing-with-emacs/</link></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="https://fedoraproject.org/wiki/How_to_use_Emacs_for_XML_editing"
|
||||
>https://fedoraproject.org/wiki/How_to_use_Emacs_for_XML_editing</link></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="http://infohost.nmt.edu/tcc/help/pubs/nxml/"
|
||||
>http://infohost.nmt.edu/tcc/help/pubs/nxml/</link></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>If you prefer vi, there are ways to make
|
||||
DocBook editing easier:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><link
|
||||
xlink:href="https://fedoraproject.org/wiki/Editing_DocBook_with_Vi"
|
||||
>https://fedoraproject.org/wiki/Editing_DocBook_with_Vi</link></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</step>
|
||||
</substeps>
|
||||
</step>
|
||||
<step>
|
||||
<title>Install Maven</title>
|
||||
<substeps>
|
||||
<step>
|
||||
<para>Create the
|
||||
<filename>apache-maven</filename>
|
||||
directory:</para>
|
||||
<screen><prompt>#</prompt> <userinput>mkdir /usr/local/apache-maven</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Copy the latest stable binary from <link
|
||||
xlink:href="http://maven.apache.org/download.cgi"
|
||||
>http://maven.apache.org/download.cgi</link>
|
||||
into
|
||||
<filename>/usr/local/apache-maven</filename>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Extract the distribution archive to the directory you wish to install Maven:</para>
|
||||
<screen><prompt>#</prompt> <userinput>cd /usr/local/apache-maven/</userinput>
|
||||
<prompt>#</prompt> <userinput>tar -xvzf apache-maven-x.x.x-bin.tar.gz</userinput></screen>
|
||||
<para>The <filename>apache-maven-<replaceable>x.x.x</replaceable></filename> subdirectory is created from the archive file, where <replaceable>x.x.x</replaceable> is your Maven version.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add the M2_HOME environment variable:</para>
|
||||
<screen><prompt>$</prompt> <userinput>export M2_HOME=/usr/local/apache-maven/apache-maven-x.x.x</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add the M2 environment variable:</para>
|
||||
<screen><prompt>$</prompt> <userinput>export M2=$M2_HOME/bin</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Optionally, add the MAVEN_OPTS environment variable to specify JVM properties. Use this environment variable to specify extra options to Maven:</para>
|
||||
<screen><prompt>$</prompt> <userinput>export MAVEN_OPTS='-Xms256m -XX:MaxPermSize=1024m -Xmx1024m'</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add the M2 environment variable to your path:</para>
|
||||
<screen><prompt>$</prompt> <userinput>export PATH=$M2:$PATH</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Make sure that JAVA_HOME is set to the location of your JDK and that $JAVA_HOME/bin is in your PATH environment variable.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Run the mvn command to make sure that Maven is correctly installed:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mvn --version</userinput></screen>
|
||||
</step>
|
||||
</substeps>
|
||||
</step>
|
||||
<!-- the next five paragraphs were lifted from https://wiki.openstack.org/wiki/Documentation/HowTo#First-time_Contributors, we should figure out how to embed instead -->
|
||||
<step>
|
||||
<para>Create a Launchpad account: Visit <link
|
||||
xlink:href="https://login.launchpad.net/+new_account"
|
||||
>
|
||||
https://login.launchpad.net/+new_account</link>.
|
||||
After you create this account, the follow-up page
|
||||
is slightly confusing. It does not tell you that
|
||||
you are done. (It gives you the opportunity to
|
||||
change your -password, but you do not have
|
||||
to.)</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add at least one SSH key to your account
|
||||
profile. To do this, follow the instructions on
|
||||
<link
|
||||
xlink:href="https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair"
|
||||
>
|
||||
https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair"</link>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Join The OpenStack Foundation: Visit <link
|
||||
xlink:href="https://www.openstack.org/join"
|
||||
>https://www.openstack.org/join</link>. Among
|
||||
other privileges, this membership enables you to
|
||||
vote in elections and run for elected positions in
|
||||
The OpenStack Project. When you sign up for
|
||||
membership, make sure to give the same e-mail
|
||||
address you will use for code contributions
|
||||
because the primary e-mail address in your
|
||||
foundation profile must match the preferred e-mail
|
||||
that you set later in your Gerrit contact
|
||||
information.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Validate your Gerrit identity: Add your public
|
||||
key to your gerrit identity by going to <link
|
||||
xlink:href="https://review.openstack.org"
|
||||
>https://review.openstack.org</link>, click
|
||||
the <guibutton>Sign In</guibutton> link, if you
|
||||
are not already logged in. At the top-right corner
|
||||
of the page select settings, then add your public
|
||||
ssh key under <guibutton> SSH Public
|
||||
Keys</guibutton>.</para>
|
||||
<para>The CLA: Every developer and contributor needs
|
||||
to sign the Individual Contributor License
|
||||
agreement. Visit <link
|
||||
xlink:href="https://review.openstack.org/"
|
||||
>https://review.openstack.org/</link> and
|
||||
click the <guibutton>Sign In</guibutton> link at
|
||||
the top-right corner of the page. Log in with your
|
||||
Launchpad ID. You can preview the text of the
|
||||
Individual CLA.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add your SSH keys to your GitHub account profile
|
||||
(the same one that was used in Launchpad). When
|
||||
you copy and paste the SSH key, include the
|
||||
ssh-rsa algorithm and computer identifier. If this
|
||||
is your first time setting up git and Github, be
|
||||
sure to run these steps in a Terminal
|
||||
window:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git config --global user.name "Firstname Lastname"</userinput>
|
||||
<prompt>$</prompt> <userinput>git config --global user.email "your_email@youremail.com"</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Install git-review. If pip is not already
|
||||
installed, run <code>easy_install pip</code> as
|
||||
<systemitem class="username">root</systemitem> to
|
||||
install it on a Mac or Ubuntu.</para>
|
||||
<screen><prompt>#</prompt> <userinput>pip install git-review</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Change to the directory:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cd /Users/<replaceable>username</replaceable>/code</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Clone the openstack-manuals repository:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git clone http://github.com/openstack/openstack-manuals.git</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Change directory to the pulled repository:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cd openstack-manuals</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Test the ssh key setup:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git review -s</userinput></screen>
|
||||
<para>Then, enter your Launchpad account information.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</section>
|
||||
<section xml:id="fix-doc-bug">
|
||||
<title>Fix a Documentation Bug</title>
|
||||
<procedure>
|
||||
<step>
|
||||
<note><para>For this example, we are going to assume
|
||||
bug 1188522 and change 33713</para></note>
|
||||
</step>
|
||||
<step>
|
||||
<para>Bring up <link
|
||||
xlink:href="https://bugs.launchpad.net/openstack-manuals"
|
||||
>https://bugs.launchpad.net/openstack-manuals</link></para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Select an unassigned bug that you want to fix.
|
||||
Start with something easy, like a syntax error.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Using oXygen, open the <filename>
|
||||
/Users/<replaceable>username</replaceable>/code/openstack-manuals/doc/admin-guide-cloud/bk-admin-guide-cloud.xml
|
||||
</filename> master page for this example. It links
|
||||
together the rest of the material. Find the page
|
||||
with the bug. Open the page that is referenced in
|
||||
the bug description by selecting the content in
|
||||
the author view. Verify you have the correct page
|
||||
by visually inspecting the html page and the xml
|
||||
page.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>In the shell,</para>
|
||||
<screen><prompt>$</prompt> <userinput>cd /Users/<replaceable>username</replaceable>/code/openstack-manuals/doc/admin-guide-cloud/</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Verify that you are on master:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git checkout master</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Create your working branch off master:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git checkout -b bug/1188522</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Verify that you have the branch open through
|
||||
SourceTree</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Correct the bug through oXygen. Toggle back and
|
||||
forth through the different views at the bottom of
|
||||
the editor.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>After you fix the bug, run maven to verify that the documentation builds successfully.
|
||||
To build a specific guide,
|
||||
look for a <filename>pom.xml</filename> file within a subdirectory, switch to that directory,
|
||||
then run the <command>mvn</command> command in that directory:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mvn clean generate-sources</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Verify that the HTML page reflects your changes
|
||||
properly. You can open the file from the command
|
||||
line by using the <command>open</command> command</para>
|
||||
<screen><prompt>$</prompt> <userinput>open target/docbkx/webhelp/local/openstack-training/index.html</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add the changes:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git add .</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Commit the changes:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git commit -a -m "Removed reference to volume scheduler in the computer scheduler config and admin pages, bug 1188522"</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Build committed changes locally by using <command>tox</command>. As part of the review process,
|
||||
Jenkins runs gating scripts to check that the patch is fine. Locally,
|
||||
you can use the <command>tox</command> tool to run the same checks and ensure that a patch works.
|
||||
Install the tox package and run it from the top level directory which has the <filename>tox.ini</filename> file.</para>
|
||||
<screen><prompt>#</prompt> <userinput>pip install tox</userinput>
|
||||
<prompt>$</prompt> <userinput>tox</userinput></screen>
|
||||
<para>Jenkins runs the following four checks. You can run them individually:</para>
|
||||
<substeps>
|
||||
<step>
|
||||
<para>Niceness tests (for example, to see extra whitespaces). Verify that the niceness check succeeds.</para>
|
||||
<screen><prompt>$</prompt> <userinput>tox -e checkniceness</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Syntax checks. Verify that the syntax check succeeds.</para>
|
||||
<screen><prompt>$</prompt> <userinput>tox -e checksyntax</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Check that no deleted files are referenced. Verify that the check succeeds.</para>
|
||||
<screen><prompt>$</prompt> <userinput>tox -e checkdeletions</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Build the manuals. It also generates a directory <filename>publish-docs/</filename> that contains the built files for inspection.
|
||||
You can also use <filename>doc/local-files.html</filename> for looking at the manuals.
|
||||
Verify that the build succeeds.</para>
|
||||
<screen><prompt>$</prompt> <userinput>tox -e checkbuild</userinput></screen>
|
||||
</step>
|
||||
</substeps>
|
||||
</step>
|
||||
<step>
|
||||
<para>Submit the bug fix to Gerrit:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git review</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Track the Gerrit review process at<link
|
||||
xlink:href="https://review.openstack.org/#/c/33713"
|
||||
>https://review.openstack.org/#/c/33713</link>.
|
||||
Follow and respond inline to the Code Review
|
||||
requests and comments.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Your change will be tested, track the Jenkins
|
||||
testing process at <link
|
||||
xlink:href="https://jenkins.openstack.org">
|
||||
https://jenkins.openstack.org</link></para>
|
||||
</step>
|
||||
<step>
|
||||
<para>If your change is rejected, complete the
|
||||
following steps:</para>
|
||||
<substeps>
|
||||
<step>
|
||||
<para>Respond to the inline comments if
|
||||
any.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Update the status to work in
|
||||
progress.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Checkout the patch from the Gerrit
|
||||
change review:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git review -d 33713</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Follow the recommended tweaks to the
|
||||
files.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Rerun:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mvn clean generate-sources</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add your additional changes to the
|
||||
change log:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git commit -a --amend</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Final commit:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git review</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Update the Jenkins status to change
|
||||
completed.</para>
|
||||
</step>
|
||||
</substeps>
|
||||
</step>
|
||||
<step>
|
||||
<para>Follow the jenkins build progress at <link
|
||||
xlink:href="https://jenkins.openstack.org/view/Openstack-manuals/"
|
||||
>
|
||||
https://jenkins.openstack.org/view/Openstack-manuals/
|
||||
</link>. Note if the build process fails, the
|
||||
online documentation will not reflect your bug
|
||||
fix.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</section>
|
||||
<section xml:id="submit-doc-bug">
|
||||
<title>Submit a Documentation Bug Fix</title>
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Bring up <link
|
||||
xlink:href="https://bugs.launchpad.net/openstack-manuals/+filebug"
|
||||
>https://bugs.launchpad.net/openstack-manuals/+filebug</link>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Give your bug a descriptive name.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Verify if asked that it is not a duplicate.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add some more detail into the description field.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Once submitted, select the assigned to pane and select
|
||||
"assign to me" or "sarob".</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Follow the instructions for fixing a bug in the Fix a
|
||||
Documentation Bug section.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</section>
|
||||
<section xml:id="create-branch">
|
||||
<title>Create a Branch</title>
|
||||
<note>
|
||||
<para>This section uses the submission of this training material as the example.</para>
|
||||
</note>
|
||||
<procedure>
|
||||
<step>
|
||||
<para>Create a bp/training-manuals branch:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git checkout -b bp/training-manuals</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>From the openstack-manuals repository, use
|
||||
the template <filename
|
||||
>user-story-includes-template.xml</filename> as
|
||||
the starting point for your user story. File
|
||||
<filename>bk001-ch003-associate-general.xml</filename>
|
||||
has at least one other included user story that
|
||||
you can use for additional help.
|
||||
</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Include the user story xml file into the <filename
|
||||
>bk001-ch003-associate-general.xml</filename> file. Follow the syntax of the
|
||||
existing <code>xi:include</code> statements.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>When your editing is completed. Double check Oxygen doesn't have any errors you
|
||||
are not expecting.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Run maven locally to verify the build will run without errors.
|
||||
Look for a <filename>pom.xml</filename> file within a subdirectory, switch to that directory,
|
||||
then run the <command>mvn</command> command in that directory:</para>
|
||||
<screen><prompt>$</prompt> <userinput>mvn clean generate-sources</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Add your changes into git:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git add .</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Commit the changes with good syntax. After
|
||||
entering the commit command, VI syntax applies,
|
||||
use "i" to insert and Esc to break out. ":wq" to
|
||||
write and quit.</para>
|
||||
<screen><prompt>$</prompt> <userinput>git commit -a</userinput>
|
||||
<computeroutput>my very short summary
|
||||
|
||||
more details go here. A few sentences would be nice.
|
||||
|
||||
blueprint training-manuals</computeroutput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Build committed changes locally using <command>tox</command>. As part of the review process,
|
||||
Jenkins runs gating scripts to check that the patch is fine. Locally,
|
||||
you can use the <command>tox</command> tool to run the same checks and ensure that a patch works.
|
||||
Install the tox package and run it from the top level directory which has the <filename>tox.ini</filename> file.</para>
|
||||
<screen><prompt>#</prompt> <userinput>pip install tox</userinput>
|
||||
<prompt>$</prompt> <userinput>tox</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>Submit your patch for review:</para>
|
||||
<screen><prompt>$</prompt> <userinput>git review</userinput></screen>
|
||||
</step>
|
||||
<step>
|
||||
<para>One last step. Go to the review page listed after you submitted your review
|
||||
and add the training core team as reviewers; Sean Roberts and Colin McNamara.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>More details on branching can be found here under <link
|
||||
xlink:href="http://docs.openstack.org/infra/manual/developers.html#development-workflow">Gerrit
|
||||
Workflow</link> and the <link xlink:href="http://git-scm.com/doc">Git
|
||||
docs</link>.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</section>
|
||||
<section xml:id="add-training-content">
|
||||
<title>Add Content to the Training Manuals</title>
|
||||
<procedure>
|
||||
<step>
|
||||
<para><emphasis role="bold">Getting Accounts and
|
||||
Tools:</emphasis> We cannot do this without
|
||||
operators and developers using and creating the
|
||||
content. Anyone can contribute content. You will
|
||||
need the tools to get started. Go to the <link
|
||||
xlink:href="http://docs.openstack.org/trunk/openstack-training/content/getting-tools-and-accounts.html"
|
||||
>Getting Tools and Accounts</link>
|
||||
page.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para><emphasis role="bold">Pick a bug:</emphasis>
|
||||
Once you have your tools ready to go, you can
|
||||
assign a bug to yourself. Go to the <link
|
||||
xlink:href="https://bugs.launchpad.net/openstack-training-guides"
|
||||
>Training Bugs</link> and assign a bug from the list to yourself.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Open the file <emphasis role="bold"
|
||||
>st-training-guides.xml</emphasis> with your
|
||||
XML editor. All the content starts with the set
|
||||
file <filename>st-training-guides.xml</filename>.
|
||||
The XML structure follows the hierarchy Set ->
|
||||
Book -> Chapter -> Section. The
|
||||
<filename>st-training-guides.xml</filename>
|
||||
file holds the set level. Notice the set file uses
|
||||
<code>xi:include</code> statements to include
|
||||
the books. We want to open the associate book.
|
||||
Open the associate book and you will see the
|
||||
chapter include statements. These are the chapters
|
||||
that make up the Associate Training Guide
|
||||
book.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Create a branch by using the bug number as
|
||||
<emphasis role="bold"
|
||||
>associate-card-<replaceable>XXX</replaceable></emphasis>
|
||||
where <replaceable>XXX</replaceable> is the bug
|
||||
number. Review <link
|
||||
xlink:href="http://docs.openstack.org/trunk/openstack-training/content/operator-create-branch.html"
|
||||
>Creating a Branch</link> again for
|
||||
instructions on how to complete the branch
|
||||
merge.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Copy the
|
||||
<filename>user-story-includes-template.xml</filename>
|
||||
to
|
||||
<filename>associate-card-XXX.xml</filename>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Open the
|
||||
<filename>bk001-ch003-asssociate-general.xml</filename>
|
||||
file and add <emphasis role="bold"><xi:include
|
||||
href="associate-card-XXX.xml"></emphasis>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Side by side, open<emphasis role="bold">
|
||||
associate-card-XXX.xml</emphasis> with your
|
||||
XML editor and open the <citetitle>Ubuntu 12.04
|
||||
Install Guide</citetitle> with your HTML
|
||||
browser.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Find the HTML content to include. Find the XML
|
||||
file that matches the HTML. Include the whole page
|
||||
using a simple href like <emphasis role="bold"
|
||||
><xi:include
|
||||
href="associate-card-XXX.xml"></emphasis> or
|
||||
include a section using xpath like <emphasis
|
||||
role="bold"><xi:include
|
||||
href="../basic-install/src/basic-install_controller-common.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook)
|
||||
xpath(//*[@xml:id =
|
||||
'controller-os'])"></emphasis> . Review the
|
||||
<filename>user-story-includes-template.xml</filename>
|
||||
file for the whole syntax.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Copy in other content sources including the
|
||||
Aptira content, a description of what the section
|
||||
aims to teach, diagrams, and quizzes. If you
|
||||
include content from another source like Aptira
|
||||
content, add a paragraph that references the file
|
||||
and/or HTTP address from where the content
|
||||
came.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Verify the code is good by running <command>mvn
|
||||
clean generate-sources</command> and by
|
||||
reviewing the local HTML in <uri
|
||||
>file:///Users/<replaceable>username</replaceable>/code/training-guides/doc/training-guides/target/docbkx/webhelp/training-guides/content/</uri>.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>Merge the branch.</para>
|
||||
</step>
|
||||
<step>
|
||||
<para>The bug will be completed automatically if the commit message references the bug number.</para>
|
||||
</step>
|
||||
</procedure>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,249 +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="section_block-storage">
|
||||
<title>OpenStack Block Storage</title>
|
||||
<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 is 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>
|
||||
</chapter>
|
||||
@ -1,92 +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="section_brief-overview">
|
||||
<title>Brief Overview</title>
|
||||
<para>OpenStack is a cloud operating system that controls large
|
||||
pools of compute, storage, and networking resources throughout a
|
||||
datacenter. It is all managed through a dashboard called Horizon, that gives
|
||||
administrators control while empowering their users to provision
|
||||
resources through a web interface.</para>
|
||||
<para>OpenStack is a global collaboration of developers and cloud
|
||||
computing technologists, producing the ubiquitous open source cloud
|
||||
computing platform for public and private clouds. The project aims
|
||||
to deliver solutions for all types of clouds by being</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>simple to implement</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>massively scalable</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>feature rich</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>To check out more information on OpenStack visit <link
|
||||
xlink:href="http://www.openstack.org/"
|
||||
>http://www.openstack.org/</link></para>
|
||||
<para><guilabel> OpenStack Foundation:</guilabel></para>
|
||||
<para>The OpenStack Foundation, established in September of 2012, is an
|
||||
independent body, providing shared resources to help achieve the
|
||||
OpenStack Mission by protecting, empowering, and promoting
|
||||
OpenStack software and the community around it. This includes users,
|
||||
developers and the entire ecosystem. For more information visit
|
||||
<link xlink:href="http://www.openstack.org/foundation"
|
||||
>http://www.openstack.org/foundation</link>.</para>
|
||||
<para><guilabel> Who's behind OpenStack? </guilabel></para>
|
||||
<para>Founded by Rackspace Hosting and NASA, OpenStack has grown
|
||||
to be a global software community of developers collaborating on
|
||||
a standard and massively scalable open source cloud operating
|
||||
system. The OpenStack Foundation promotes the development,
|
||||
distribution and adoption of the OpenStack cloud operating
|
||||
system. As the independent home for OpenStack, the Foundation
|
||||
has already attracted more than 7,000 individual members from
|
||||
100 countries and 850 different organizations. It has also secured more than
|
||||
$10 million in funding and is ready to fulfill the OpenStack
|
||||
mission of becoming the ubiquitous cloud computing platform.
|
||||
Checkout <link xlink:href="http://www.openstack.org/foundation"
|
||||
>http://www.openstack.org/foundation</link>for more information.</para>
|
||||
<figure>
|
||||
<title>Nebula (NASA)</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image23.jpg"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>The goal of the OpenStack Foundation is to serve developers,
|
||||
users, and the entire ecosystem by providing a set of shared
|
||||
resources to grow the footprint of public and private OpenStack
|
||||
clouds, enable technology vendors targeting the platform and
|
||||
assist developers in producing the best cloud software in the
|
||||
industry.</para>
|
||||
<para><guilabel>Who uses OpenStack?</guilabel></para>
|
||||
<para>Corporations, service providers, VARS, SMBs, researchers,
|
||||
and global data centers looking to deploy large-scale cloud
|
||||
deployments for private or public clouds, leveraging the support
|
||||
and resulting technology of a global open source community. This is just
|
||||
four years into OpenStack, it's new and has immense possibilities.</para>
|
||||
<para><guilabel>It's Open Source:</guilabel></para>
|
||||
<para>All of the code for OpenStack is freely available under the
|
||||
Apache 2.0 license. Anyone can run it, build on it, or submit
|
||||
changes back to the project. This open development model is one
|
||||
of the best ways to foster badly-needed cloud standards, remove
|
||||
the fear of proprietary lock-in for cloud customers, and create
|
||||
a large ecosystem that spans cloud providers.</para>
|
||||
<para><guilabel>Who it's for:</guilabel></para>
|
||||
<para>Enterprises, service providers, government and academic
|
||||
institutions with physical hardware that would like to build a
|
||||
public or private cloud.</para>
|
||||
<para><guilabel>How it's being used today:</guilabel></para>
|
||||
<para>Organizations like CERN, Cisco WebEx, DreamHost, eBay, The
|
||||
Gap, HP, MercadoLibre, NASA, PayPal, Rackspace and University of
|
||||
Melbourne have deployed OpenStack clouds to achieve control,
|
||||
business agility and cost savings without the licensing fees and
|
||||
terms of proprietary software. For complete user stories visit
|
||||
<link xlink:href="http://www.openstack.org/user-stories"
|
||||
>http://www.openstack.org/user-stories</link>, this should give you a good idea
|
||||
about the importance of OpenStack.</para>
|
||||
</chapter>
|
||||
@ -1,80 +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="section_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 IPs as of
|
||||
now.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>create IP ranges under a certain group, only
|
||||
available for admin role.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>allocate a floating IP to a certain tenant,
|
||||
only available for admin role.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>deallocate a floating IP from a certain
|
||||
tenant</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>associate a floating IP to a given
|
||||
instance</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>disassociate a floating IP from a certain
|
||||
instance</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Just as shown by the above figure, we will have
|
||||
nova-network-api to support nova client floating
|
||||
commands. Nova-network-api will invoke neutron cli lib
|
||||
to interact with the neutron server via API. The data
|
||||
for the floating IPs will be stored in the neutron DB.
|
||||
Neutron Agent, which is running on the 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_routers is set to
|
||||
True only for one L3 agent in an OpenStack Networking
|
||||
deployment and set to False for 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>
|
||||
<programlisting>
|
||||
handle_internal_only_routers = True
|
||||
external_network_bridge = br-ex
|
||||
</programlisting>
|
||||
<programlisting>
|
||||
$sudo service neutron-l3-agent restart
|
||||
</programlisting>
|
||||
<para>For the second (or later) agent, invoke it with the following l3_agent.ini where handle_internal_only_routers is False.</para>
|
||||
</chapter>
|
||||
@ -1,108 +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="section_intro-text">
|
||||
<title>Introduction to OpenStack</title>
|
||||
<para>OpenStack is a cloud operating system that controls large
|
||||
pools of compute, storage, and networking resources throughout a
|
||||
data center, all managed through a dashboard that gives
|
||||
administrators control while empowering users to provision
|
||||
resources through a web interface.</para>
|
||||
<para>Cloud computing provides users with access to a shared
|
||||
collection of computing resources: networks for transfer, servers
|
||||
for storage, and applications or services for completing
|
||||
tasks.</para>
|
||||
<para>The compelling features of a cloud are:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>On-demand self-service: Users can automatically provision
|
||||
needed computing capabilities, such as server time and network
|
||||
storage, without requiring human interaction with each service
|
||||
provider.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Network access: Any computing capabilities are available
|
||||
over the network. Many different devices are allowed access
|
||||
through standardized mechanisms.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Resource pooling: Multiple users can access clouds that
|
||||
serve other consumers according to demand.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Elasticity: Provisioning is rapid and scales out or is
|
||||
based on need.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Metered or measured service: Cloud systems can optimize
|
||||
and control resource use at the level that is appropriate for
|
||||
the service. Services include storage, processing, bandwidth,
|
||||
and active user accounts. Monitoring and reporting of resource
|
||||
usage provides transparency for both the provider and consumer
|
||||
of the utilized service.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Cloud computing offers different service models depending on
|
||||
the capabilities a consumer may require.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>SaaS: Software-as-a-Service. Provides the consumer the
|
||||
ability to use the software in a cloud environment, such as
|
||||
web-based email for example.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>PaaS: Platform-as-a-Service. Provides the consumer the
|
||||
ability to deploy applications through a programming language
|
||||
or tools supported by the cloud platform provider. An example
|
||||
of Platform-as-a-service is an Eclipse/Java programming
|
||||
platform provided with no downloads required.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>IaaS: Infrastructure-as-a-Service. Provides infrastructure
|
||||
such as computer instances, network connections, and storage
|
||||
so that people can run any software or operating
|
||||
system.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Terms such as public cloud or private cloud refer to the
|
||||
deployment model for the cloud. A private cloud operates for a
|
||||
single organization, but can be managed on-premise or off-premise.
|
||||
A public cloud has an infrastructure that is available to the
|
||||
general public or a large industry group and is likely owned by a
|
||||
cloud services company.</para>
|
||||
<para>Clouds can also be described as hybrid. A hybrid cloud can be
|
||||
a deployment model, as a composition of both public and private
|
||||
clouds, or a hybrid model for cloud computing may involve both
|
||||
virtual and physical servers.</para>
|
||||
<para>Cloud computing can help with large-scale computing needs or
|
||||
can lead consolidation efforts by virtualizing servers to make
|
||||
more use of existing hardware and potentially release old hardware
|
||||
from service. Cloud computing is also used for collaboration
|
||||
because of its high availability through networked computers.
|
||||
Productivity suites for word processing, number crunching, and
|
||||
email communications, and more are also available through cloud
|
||||
computing. Cloud computing also avails additional storage to the
|
||||
cloud user, avoiding the need for additional hard drives on each
|
||||
user's desktop and enabling access to huge data storage capacity
|
||||
online in the cloud.</para>
|
||||
<para>When you explore OpenStack and see what it means technically,
|
||||
you can see its reach and impact on the entire world.</para>
|
||||
<para>OpenStack is an open source software for building private and
|
||||
public clouds which delivers a massively scalable cloud operating
|
||||
system.</para>
|
||||
<informaltable class="c20">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">OpenStack is backed up by a global
|
||||
community of technologists, developers, researchers,
|
||||
corporations and cloud computing experts.</td>
|
||||
<td rowspan="1" colspan="1"><inlinemediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image11.png"/>
|
||||
</imageobject>
|
||||
</inlinemediaobject></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
</chapter>
|
||||
@ -1,230 +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="section_keystone-arch">
|
||||
<title>Keystone Architecture</title>
|
||||
<!--<para>More Content To be Added ...</para>
|
||||
<section xml:id="section_keystone-arch-concepts">
|
||||
<title>Identity Service Concepts</title> -->
|
||||
<para>The Identity service performs these
|
||||
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 these concepts:</para>
|
||||
<variablelist wordsize="10">
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">User</emphasis></term>
|
||||
<listitem>
|
||||
<para>Digital representation of a person, system, or service
|
||||
who uses OpenStack cloud services. Identity authentication
|
||||
services will validate that incoming requests 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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Credentials</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Authentication</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">Token</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Tenant</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">Service</emphasis></term>
|
||||
<listitem>
|
||||
<para>An OpenStack service, such as Compute (Nova), Object
|
||||
Storage (Swift), or the Image Service (Glance) provides one
|
||||
or more endpoints through which users can access resources
|
||||
and perform operations.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Endpoint</emphasis></term>
|
||||
<listitem>
|
||||
<para>A 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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Role</emphasis></term>
|
||||
<listitem>
|
||||
<para>A personality that a user assumes which 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 a 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" contentwidth="4in" scale="50" width="4in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<emphasis role="bold">User management</emphasis></term>
|
||||
<listitem>
|
||||
<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 user represents a human user, and has associated
|
||||
information such as username, password and email. This
|
||||
example creates a user named "alice":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com</userinput></screen>
|
||||
<para>A tenant can 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 get a list of
|
||||
all running instances for the specified tenant. This
|
||||
example creates a tenant named "acme":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone tenant-create --name=acme</userinput></screen>
|
||||
<para>A role captures what operations a user is permitted to
|
||||
perform in a given tenant. This example creates a role
|
||||
named "compute-user":</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone role-create --name=compute-user</userinput></screen>
|
||||
<para>The Identity service associates a user with a tenant
|
||||
and a role. To continue with our previous examples, we may
|
||||
assign the "alice" user the "compute-user" role in
|
||||
the "acme" tenant:</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-list</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-role-add --user=892585 --role=9a764e --tenant-id=6b8fd2</userinput></screen>
|
||||
<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
|
||||
<filename>/etc/[SERVICE_CODENAME]/policy.json</filename>
|
||||
file controls what users are allowed to do for a given
|
||||
service. For example,
|
||||
<filename>/etc/nova/policy.json</filename> specifies the
|
||||
access policy for the Compute service,
|
||||
<filename>/etc/glance/policy.json</filename> specifies
|
||||
the access policy for the Image Service, and
|
||||
<filename>/etc/keystone/policy.json</filename> 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 the Compute service, you need to
|
||||
create a role in the Identity service and then modify
|
||||
<filename>/etc/nova/policy.json</filename> so that this
|
||||
role is required for Compute operations.</para>
|
||||
<para>For example, this line "volume:create": [] in
|
||||
<filename>/etc/cinder/policy.json</filename> 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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><emphasis role="bold">Service
|
||||
Management</emphasis></term>
|
||||
<listitem>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<!-- </section>-->
|
||||
</chapter>
|
||||
@ -1,224 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!DOCTYPE chapter [
|
||||
<!ENTITY % openstack SYSTEM "https://raw.githubusercontent.com/openstack/openstack-manuals/master/doc/common/entities/openstack.ent">
|
||||
%openstack;
|
||||
]>
|
||||
<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="section_more-concepts">
|
||||
<title>A Bit More On Swift</title>
|
||||
<para><guilabel>Containers and Objects</guilabel></para>
|
||||
<para>A container is a storage compartment for your data and
|
||||
provides a way for you to organize your data. You can
|
||||
think of a container as a folder in Windows or a
|
||||
directory in UNIX. The primary difference between a
|
||||
container and these other file system concepts is that
|
||||
containers cannot be nested. You can, however, create an
|
||||
unlimited number of containers within your account. Data
|
||||
must be stored in a container so you must have at least
|
||||
one container defined in your account prior to uploading
|
||||
data.</para>
|
||||
<para>The only restrictions on container names is that they
|
||||
cannot contain a forward slash (/) or an ascii null (%00)
|
||||
and must be less than 257 bytes in length. Please note
|
||||
that the length restriction applies to the name after it
|
||||
has been URL encoded. For example, a container name of
|
||||
Course Docs would be URL encoded as Course%20Docs and
|
||||
therefore be 13 bytes in length rather than the expected
|
||||
11.</para>
|
||||
<para>An object is the basic storage entity and any optional
|
||||
metadata that represents the files you store in the
|
||||
OpenStack Object Storage system. When you upload data to
|
||||
OpenStack Object Storage, the data is stored as-is (no
|
||||
compression or encryption) and consists of a location
|
||||
(container), the object's name, and any metadata
|
||||
consisting of key/value pairs. For instance, you may chose
|
||||
to store a backup of your digital photos and organize them
|
||||
into albums. In this case, each object could be tagged
|
||||
with metadata such as Album : Caribbean Cruise or Album :
|
||||
Aspen Ski Trip.</para>
|
||||
<para>The only restriction on object names is that they must
|
||||
be less than 1024 bytes in length after URL encoding. For
|
||||
example, an object name of C++final(v2).txt should be URL
|
||||
encoded as C%2B%2Bfinal%28v2%29.txt and therefore be 24
|
||||
bytes in length rather than the expected 16.</para>
|
||||
<para>The maximum allowable size for a storage object upon
|
||||
upload is 5 GB and the minimum is zero bytes.
|
||||
You can use the built-in large object support and the
|
||||
swift utility to retrieve objects larger than 5 GB.</para>
|
||||
<para>For metadata, you should not exceed 90 individual
|
||||
key/value pairs for any one object and the total byte
|
||||
length of all key/value pairs should not exceed 4 KB
|
||||
(4096 bytes).</para>
|
||||
<para><guilabel>Language-Specific API
|
||||
Bindings</guilabel></para>
|
||||
<para>A set of supported API bindings in several popular
|
||||
languages are available from the Rackspace Cloud Files
|
||||
product, which uses OpenStack Object Storage code for its
|
||||
implementation. These bindings provide a layer of
|
||||
abstraction on top of the base REST API, allowing
|
||||
programmers to work with a container and object model
|
||||
instead of working directly with HTTP requests and
|
||||
responses. These bindings are free (as in beer and as in
|
||||
speech) to download, use, and modify. They are all
|
||||
licensed under the MIT License as described in the COPYING
|
||||
file packaged with each binding. If you do make any
|
||||
improvements to an API, you are encouraged (but not
|
||||
required) to submit those changes back to us.</para>
|
||||
<para>The API bindings for Rackspace Cloud Files are hosted
|
||||
at<link xlink:href="http://github.com/rackspace"
|
||||
></link><link
|
||||
xlink:href="http://github.com/rackspace"
|
||||
>http://github.com/rackspace</link>. Feel free to
|
||||
coordinate your changes through github or, if you prefer,
|
||||
send your changes to cloudfiles@rackspacecloud.com. Just
|
||||
make sure to indicate which language and version you
|
||||
modified and send a unified diff.</para>
|
||||
<para>Each binding includes its own documentation (either
|
||||
HTML, PDF, or CHM). They also include code snippets and
|
||||
examples to help you get started. The currently supported
|
||||
API binding for OpenStack Object Storage are:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>PHP (requires 5.x and the modules: cURL,
|
||||
FileInfo, mbstring)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Python (requires 2.4 or newer)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Java (requires JRE v1.5 or newer)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>C#/.NET (requires .NET Framework v3.5)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Ruby (requires 1.8 or newer and mime-tools
|
||||
module)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>There are no other supported language-specific bindings
|
||||
at this time. You are welcome to create your own language
|
||||
API bindings and we can help answer any questions during
|
||||
development, host your code if you like, and give you full
|
||||
credit for your work.</para>
|
||||
<para><guilabel>Proxy Server</guilabel></para>
|
||||
<para>The Proxy Server is responsible for tying together
|
||||
the rest of the OpenStack Object Storage architecture.
|
||||
For each request, it will look up the location of the
|
||||
account, container, or object in the ring (see below)
|
||||
and route the request accordingly. The public API is
|
||||
also exposed through the Proxy Server.</para>
|
||||
<para>A large number of failures are also handled in the
|
||||
Proxy Server. For example, if a server is unavailable
|
||||
for an object PUT, it will ask the ring for a hand-off
|
||||
server and route there instead.</para>
|
||||
<para>When objects are streamed to or from an object
|
||||
server, they are streamed directly through the proxy
|
||||
server to or from the user – the proxy server does not
|
||||
spool them.</para>
|
||||
<para>You can use a proxy server with account management
|
||||
enabled by configuring it in the proxy server
|
||||
configuration file.</para>
|
||||
<para><guilabel>Object Server</guilabel></para>
|
||||
<para>The Object Server is a very simple blob storage
|
||||
server that can store, retrieve and delete objects
|
||||
stored on local devices. Objects are stored as binary
|
||||
files on the filesystem with metadata stored in the
|
||||
file’s extended attributes (xattrs). This requires
|
||||
that the underlying filesystem choice for object
|
||||
servers support xattrs on files. Some filesystems,
|
||||
like ext3, have xattrs turned off by default.</para>
|
||||
<para>Each object is stored using a path derived from the
|
||||
object name’s hash and the operation’s timestamp. Last
|
||||
write always wins, and ensures that the latest object
|
||||
version will be served. A deletion is also treated as
|
||||
a version of the file (a 0 byte file ending with
|
||||
“.ts”, which stands for tombstone). This ensures that
|
||||
deleted files are replicated correctly and older
|
||||
versions don’t magically reappear due to failure
|
||||
scenarios.</para>
|
||||
<para><guilabel>Container Server</guilabel></para>
|
||||
<para>The Container Server’s primary job is to handle
|
||||
listings of objects. It does not know where those
|
||||
objects are, just what objects are in a specific
|
||||
container. The listings are stored as SQLite database
|
||||
files, and replicated across the cluster similar to
|
||||
how objects are. Statistics are also tracked that
|
||||
include the total number of objects, and total storage
|
||||
usage for that container.</para>
|
||||
<para><guilabel>Account Server</guilabel></para>
|
||||
<para>The Account Server is very similar to the Container
|
||||
Server, excepting that it is responsible for listings
|
||||
of containers rather than objects.</para>
|
||||
<para><guilabel>Replication</guilabel></para>
|
||||
<para>Replication is designed to keep the system in a
|
||||
consistent state in the face of temporary error
|
||||
conditions like network outages or drive
|
||||
failures.</para>
|
||||
<para>The replication processes compare local data with
|
||||
each remote copy to ensure they all contain the latest
|
||||
version. Object replication uses a hash list to
|
||||
quickly compare subsections of each partition, and
|
||||
container and account replication use a combination of
|
||||
hashes and shared high water marks.</para>
|
||||
<para>Replication updates are push based. For object
|
||||
replication, updating is just a matter of rsyncing
|
||||
files to the peer. Account and container replication
|
||||
push missing records over HTTP or rsync whole database
|
||||
files.</para>
|
||||
<para>The replicator also ensures that data is removed
|
||||
from the system. When an item (object, container, or
|
||||
account) is deleted, a tombstone is set as the latest
|
||||
version of the item. The replicator will see the
|
||||
tombstone and ensure that the item is removed from the
|
||||
entire system.</para>
|
||||
<para>To separate the cluster-internal replication traffic
|
||||
from client traffic, separate replication servers can
|
||||
be used. These replication servers are based on the
|
||||
standard storage servers, but they listen on the
|
||||
replication IP and only respond to REPLICATE requests.
|
||||
Storage servers can serve REPLICATE requests, so an
|
||||
operator can transition to using a separate
|
||||
replication network with no cluster downtime.</para>
|
||||
<para>Replication IP and port information is stored in the
|
||||
ring on a per-node basis. These parameters will be
|
||||
used if they are present, but they are not required.
|
||||
If this information does not exist or is empty for a
|
||||
particular node, the node's standard IP and port will
|
||||
be used for replication.</para>
|
||||
<para><guilabel>Updaters</guilabel></para>
|
||||
<para>There are times when container or account data can
|
||||
not be immediately updated. This usually occurs during
|
||||
failure scenarios or periods of high load. If an
|
||||
update fails, the update is queued locally on the file
|
||||
system, and the updater will process the failed
|
||||
updates. This is where an eventual consistency window
|
||||
will most likely come in to play. For example, suppose
|
||||
a container server is under load and a new object is
|
||||
put in to the system. The object will be immediately
|
||||
available for reads as soon as the proxy server
|
||||
responds to the client with success. However, the
|
||||
container server did not update the object listing,
|
||||
and so the update would be queued for a later update.
|
||||
Container listings, therefore, may not immediately
|
||||
contain the object.</para>
|
||||
<para>In practice, the consistency window is only as large
|
||||
as the frequency at which the updater runs and may not
|
||||
even be noticed as the proxy server will route listing
|
||||
requests to the first container server which responds.
|
||||
The server under load may not be the one that serves
|
||||
subsequent listing requests – one of the other two
|
||||
replicas may handle the listing.</para>
|
||||
<para><guilabel>Auditors</guilabel></para>
|
||||
<para>Auditors crawl the local server checking the
|
||||
integrity of the objects, containers, and accounts. If
|
||||
corruption is found (in the case of bit rot, for
|
||||
example), the file is quarantined, and replication
|
||||
will replace the bad file from another replica. If
|
||||
other errors are found they are logged. For example,
|
||||
an object’s listing cannot be found on any container
|
||||
server it should be.</para>
|
||||
</chapter>
|
||||
@ -1,270 +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="section_networking-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 plug-in, which is a pluggable back-end
|
||||
implementation of the OpenStack Networking API. A plug-in can
|
||||
use a variety of technologies to implement the logical API
|
||||
requests. Some OpenStack Networking plug-ins 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 plug-ins include:</para>
|
||||
<itemizedlist>
|
||||
<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">Brocade
|
||||
Plugin</emphasis></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">Hyper-V
|
||||
Plugin</emphasis></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">Midonet
|
||||
Plugin</emphasis></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">Open vSwitch:</emphasis>
|
||||
Documentation included in this guide.</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">Ryu:</emphasis>
|
||||
<link
|
||||
xlink:href="https://github.com/osrg/ryu/wiki/OpenStack"
|
||||
>https://github.com/osrg/ryu/wiki/OpenStack</link></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- TODO: Update support link, when available -->
|
||||
<para><emphasis role="bold">VMware NSX:</emphasis>
|
||||
Documentation include in this guide, <link
|
||||
xlink:href="http://www.vmware.com/products/nsx"
|
||||
>NSX Product Overview </link>, and <link
|
||||
xlink:href="http://www.nicira.com/support">NSX
|
||||
Product Support</link>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Plugins can have different properties in terms of hardware
|
||||
requirements, features, performance, scale, operator tools,
|
||||
etc. Supporting many plug-ins 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 plug-in for additional
|
||||
processing. Typically, the plug-in 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 plug-in you are using,
|
||||
as some plug-ins 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 plug-ins.</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
|
||||
plug-ins.</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 in 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. 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" contentwidth="7in"/>
|
||||
</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 plug-in 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>
|
||||
</chapter>
|
||||
@ -1,130 +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="section_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>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 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
|
||||
other's instances unless additional filtering, such as
|
||||
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>
|
||||
</chapter>
|
||||
@ -1,638 +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="section_official-programs">
|
||||
<title>OpenStack Projects, History, and Releases Overview</title>
|
||||
<para><guilabel>Project history and releases overview.</guilabel></para>
|
||||
<para>OpenStack is a cloud computing project that provides an
|
||||
Infrastructure-as-a-Service (IaaS). It is free open source
|
||||
software released under the terms of the Apache License. The
|
||||
project is managed by the OpenStack Foundation, a non-profit
|
||||
corporate entity established in September 2012 to promote
|
||||
OpenStack software and its community.</para>
|
||||
<para>More than 200 companies joined the project, among which are
|
||||
AMD, Brocade Communications Systems, Canonical, Cisco, Dell, EMC,
|
||||
Ericsson, Groupe Bull, HP, IBM, Inktank, Intel, NEC, Rackspace
|
||||
Hosting, Red Hat, SUSE Linux, VMware, and Yahoo!</para>
|
||||
<para>The technology consists of a series of interrelated projects
|
||||
that control pools of processing, storage, and networking
|
||||
resources throughout a data center, all managed through a
|
||||
dashboard that gives administrators control while empowering its
|
||||
users to provision resources through a web interface.</para>
|
||||
<para>The OpenStack community collaborates around a six-month,
|
||||
time-based release cycle with frequent development milestones.
|
||||
During the planning phase of each release, the community gathers
|
||||
for the OpenStack Design Summit to facilitate developer working
|
||||
sessions and assemble plans.</para>
|
||||
<para>In July 2010 Rackspace Hosting and NASA jointly launched an
|
||||
open-source cloud-software initiative known as OpenStack. The
|
||||
OpenStack project intended to help organizations which offer
|
||||
cloud-computing services running on standard hardware. The first
|
||||
official release, code-named Austin, appeared four months later,
|
||||
with plans to release regular updates of the software every few
|
||||
months. The early code came from the NASA Nebula platform and from
|
||||
the Rackspace Cloud Files platform. In July 2011, Ubuntu Linux
|
||||
developers adopted OpenStack.</para>
|
||||
<para><emphasis role="bold">OpenStack Releases</emphasis></para>
|
||||
<informaltable class="c20">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Release Name</td>
|
||||
<td rowspan="1" colspan="1">Release Date</td>
|
||||
<td rowspan="1" colspan="1">Included Components</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Austin</td>
|
||||
<td rowspan="1" colspan="1">21 October 2010</td>
|
||||
<td rowspan="1" colspan="1">Nova, Swift</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Bexar</td>
|
||||
<td rowspan="1" colspan="1">3 February 2011</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Cactus</td>
|
||||
<td rowspan="1" colspan="1">15 April 2011</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Diablo</td>
|
||||
<td rowspan="1" colspan="1">22 September 2011</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Essex</td>
|
||||
<td rowspan="1" colspan="1">5 April 2012</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Folsom</td>
|
||||
<td rowspan="1" colspan="1">27 September 2012</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Quantum, Cinder</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Grizzly</td>
|
||||
<td rowspan="1" colspan="1">4 April 2013</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Quantum, Cinder</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Havana</td>
|
||||
<td rowspan="1" colspan="1">17 October 2013</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Neutron, Cinder,
|
||||
Ceilometer, Heat</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Icehouse</td>
|
||||
<td rowspan="1" colspan="1">17 April 2014</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Neutron, Cinder,
|
||||
Ceilometer, Heat, Trove</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Juno</td>
|
||||
<td rowspan="1" colspan="1">October 2014</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Neutron, Cinder,
|
||||
Ceilometer, Heat, Trove, Sahara</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="1" colspan="1">Kilo</td>
|
||||
<td rowspan="1" colspan="1">April 2015</td>
|
||||
<td rowspan="1" colspan="1">Nova, Glance, Swift,
|
||||
Horizon, Keystone, Neutron, Cinder,
|
||||
Ceilometer, Heat, Trove, Sahara, Ironic</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</informaltable>
|
||||
<para>Some OpenStack users include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>PayPal / eBay</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>NASA</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>CERN</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Yahoo!</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Rackspace Cloud</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>HP Public Cloud</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>MercadoLibre.com</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>AT&T</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>KT (formerly Korea Telecom)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Deutsche Telekom</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Wikimedia Labs</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Hostalia of Telef nica Group</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>SUSE Cloud solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Red Hat OpenShift PaaS solution</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Zadara Storage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Mint Services</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>GridCentric</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>OpenStack is a true and innovative open standard. For more
|
||||
user stories, see <link xlink:href="http://www.openstack.org/user-stories"
|
||||
>http://www.openstack.org/user-stories</link>.</para>
|
||||
<para><guilabel>Release Cycle</guilabel></para>
|
||||
<figure>
|
||||
<title>Community Heartbeat</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image05.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>OpenStack is based on a coordinated 6-month release cycle
|
||||
with frequent development milestones. You can find a link to the
|
||||
current development release schedule <link xlink:href=
|
||||
"https://wiki.openstack.org/wiki/Releases">here</link>.
|
||||
The Release Cycle is made of four major stages:</para>
|
||||
<figure>
|
||||
<title>Various Projects under OpenStack</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image16.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>The creation of OpenStack took an estimated 249 years of
|
||||
effort (COCOMO model).</para>
|
||||
<para>In a nutshell, OpenStack has:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>64,396 commits made by 1,128 contributors, with its
|
||||
first commit made in May, 2010.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>908,491 lines of code. OpenStack is written mostly in
|
||||
Python with an average number of source code comments.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A code base with a long source history.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Increasing Y-O-Y commits.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A very large development team comprised of people from
|
||||
around the world.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<figure>
|
||||
<title>Programming Languages used to design OpenStack</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image06.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>For an overview of OpenStack refer to
|
||||
http://www.openstack.org. Common
|
||||
questions and answers are also covered here.</para>
|
||||
<para><guilabel>Official Programs Overview</guilabel></para>
|
||||
<para>Let's take a dive into some of the technical aspects of
|
||||
OpenStack. Its scalability and flexibility are just some of the
|
||||
awesome features that make it a rock-solid cloud computing
|
||||
platform. The OpenStack official programs serve the community and
|
||||
its demands.</para>
|
||||
<para>Being a cloud computing platform, OpenStack consists of many
|
||||
official programs and incubated projects which makes it really good
|
||||
as an IaaS cloud computing platform/Operating System. The
|
||||
following points are the main components
|
||||
necessary to call it an OpenStack
|
||||
Cloud.</para>
|
||||
<para><guimenu>Components of OpenStack</guimenu></para>
|
||||
<para>OpenStack has a modular architecture with various code names
|
||||
for its components. OpenStack has several shared services that
|
||||
span the three pillars of compute, storage and networking,
|
||||
making it easier to implement and operate your cloud. These
|
||||
services - including identity, image management and a web
|
||||
interface - integrate the OpenStack components with each other
|
||||
as well as external systems to provide a unified experience for
|
||||
users as they interact with different cloud resources.</para>
|
||||
<para><guisubmenu>Compute (Nova)</guisubmenu></para>
|
||||
<para>The OpenStack cloud operating system enables enterprises
|
||||
and service providers to offer on-demand computing resources,
|
||||
by provisioning and managing large networks of virtual
|
||||
machines. Compute resources are accessible via APIs for
|
||||
developers building cloud applications and via web interfaces
|
||||
for administrators and users. The compute architecture is
|
||||
designed to scale horizontally on standard hardware.</para>
|
||||
<figure>
|
||||
<title>OpenStack Compute: Provision and manage large networks of
|
||||
virtual machines</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image03.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>OpenStack Compute (Nova) is a cloud computing fabric
|
||||
controller (the main part of an IaaS system). It is written in
|
||||
Python and uses many external libraries such as Eventlet (for
|
||||
concurrent programming), Kombu (for AMQP communication), and
|
||||
SQLAlchemy (for database access). Nova's architecture is
|
||||
designed to scale horizontally on standard hardware with no
|
||||
proprietary hardware or software requirements and provide the
|
||||
ability to integrate with legacy systems and third party
|
||||
technologies. It is designed to manage and automate pools of
|
||||
computer resources and can work with widely available
|
||||
virtualization technologies, as well as bare metal and
|
||||
high-performance computing (HPC) configurations. KVM and
|
||||
XenServer are available choices for hypervisor technology,
|
||||
together with Hyper-V and Linux container technology such as
|
||||
LXC. In addition to different hypervisors, OpenStack runs on
|
||||
ARM.</para>
|
||||
<para><emphasis role="bold">Popular Use Cases:</emphasis></para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Service providers offering an IaaS compute platform
|
||||
or services higher up the stack</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>IT departments acting as cloud service providers for
|
||||
business units and project teams</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Processing big data with tools like Hadoop</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Scaling compute up and down to meet demand for web
|
||||
resources and applications</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>High-performance computing (HPC) environments
|
||||
processing diverse and intensive workloads</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guisubmenu>Object Storage(Swift)</guisubmenu></para>
|
||||
<para>In addition to traditional enterprise-class storage
|
||||
technology, many organizations now have a variety of storage
|
||||
needs with varying performance and price requirements.
|
||||
OpenStack has support for both Object Storage and Block
|
||||
Storage, with many deployment options for each depending on
|
||||
the use case.</para>
|
||||
<figure>
|
||||
<title>OpenStack Storage: Object and Block storage for use with
|
||||
servers and applications</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image17.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>OpenStack Object Storage (Swift) is a scalable redundant
|
||||
storage system. Objects and files are written to multiple disk
|
||||
drives spread throughout servers in the data center, with the
|
||||
OpenStack software responsible for ensuring data replication
|
||||
and integrity across the cluster. Storage clusters scale
|
||||
horizontally simply by adding new servers. Should a server or
|
||||
hard drive fail, OpenStack replicates its content from other
|
||||
active nodes to new locations in the cluster. Because
|
||||
OpenStack uses software logic to ensure data replication and
|
||||
distribution across different devices, inexpensive commodity
|
||||
hard drives and servers can be used.</para>
|
||||
<para>Object Storage is ideal for cost effective, scale-out
|
||||
storage. It provides a fully distributed, API-accessible
|
||||
storage platform that can be integrated directly into
|
||||
applications or used for backup, archiving and data retention.
|
||||
Block Storage allows block devices to be exposed and connected
|
||||
to compute instances for expanded storage, better performance
|
||||
and integration with enterprise storage platforms, such as
|
||||
NetApp, Nexenta and SolidFire.</para>
|
||||
<para>A few details on OpenStack’s Object Storage</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>OpenStack provides redundant, scalable object storage using
|
||||
clusters of standardized servers capable of storing
|
||||
petabytes of data</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Object Storage is not a traditional file system, but rather a
|
||||
distributed storage system for static data such as
|
||||
virtual machine images, photo storage, email storage,
|
||||
backups and archives. Having no central "brain" or
|
||||
master point of control provides greater scalability,
|
||||
redundancy and durability.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Objects and files are written to multiple disk drives spread
|
||||
throughout servers in the data center, with the
|
||||
OpenStack software responsible for ensuring data
|
||||
replication and integrity across the cluster.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Storage clusters scale horizontally simply by adding new servers.
|
||||
Should a server or hard drive fail, OpenStack
|
||||
replicates its content from other active nodes to new
|
||||
locations in the cluster. Because OpenStack uses
|
||||
software logic to ensure data replication and
|
||||
distribution across different devices, inexpensive
|
||||
commodity hard drives and servers can be used in lieu
|
||||
of more expensive equipment.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guisubmenu>Block Storage(Cinder)</guisubmenu></para>
|
||||
<para>OpenStack Block Storage (Cinder) provides persistent block
|
||||
level storage devices for use with OpenStack compute
|
||||
instances. 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. In addition to local Linux server storage, it
|
||||
can use storage platforms including Ceph, CloudByte, Coraid,
|
||||
EMC (VMAX and VNX), GlusterFS, IBM Storage (Storwize family,
|
||||
SAN Volume Controller, and XIV Storage System), Linux LIO,
|
||||
NetApp, Nexenta, Scality, SolidFire and HP (Store Virtual and
|
||||
StoreServ 3Par families). 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. 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>
|
||||
<para><emphasis role="bold">A few points on OpenStack Block
|
||||
Storage:</emphasis></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>
|
||||
<para><guisubmenu>Networking(Neutron)</guisubmenu></para>
|
||||
<para>Today's data center networks contain more devices than
|
||||
ever before. From servers, network equipment, storage systems and
|
||||
security appliances, many of which are further divided into
|
||||
virtual machines and virtual networks. The number of IP addresses,
|
||||
routing configurations and security rules can quickly grow into
|
||||
the millions. Traditional network management techniques fall short
|
||||
of providing a truly scalable, automated approach to managing
|
||||
these next-generation networks. At the same time, users expect
|
||||
more control and flexibility with quicker provisioning.</para>
|
||||
<para>OpenStack Networking is a pluggable, scalable and
|
||||
API-driven system for managing networks and IP addresses. Like
|
||||
other aspects of the cloud operating system, it can be used by
|
||||
administrators and users to increase the value of existing data
|
||||
center assets. OpenStack Networking ensures the network will not
|
||||
be the bottleneck or limiting factor in a cloud deployment and
|
||||
gives users real self-service, even over their network
|
||||
configurations.</para>
|
||||
<figure>
|
||||
<title>OpenStack Networking: Pluggable, scalable, API-driven
|
||||
network and IP management</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image26.png"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>OpenStack Networking (Neutron, formerly Quantum) is a
|
||||
system for managing networks and IP addresses. Like other
|
||||
aspects of the cloud operating system, it can be used by
|
||||
administrators and users to increase the value of existing
|
||||
data center assets. OpenStack Networking ensures the network
|
||||
will not be the bottleneck or limiting factor in a cloud
|
||||
deployment and gives users real self-service, even over their
|
||||
network configurations.</para>
|
||||
<para>OpenStack Neutron provides networking models for different
|
||||
applications or user groups. Standard models include flat
|
||||
networks or VLANs for separation of servers and traffic.
|
||||
OpenStack Networking manages IP addresses, allowing for
|
||||
dedicated static IPs or DHCP. Floating IPs allow traffic to be
|
||||
dynamically re routed to any of your compute resources, which
|
||||
allows you to redirect traffic during maintenance or in the
|
||||
case of failure. Users can create their own networks, control
|
||||
traffic and connect servers and devices to one or more
|
||||
networks. Administrators can take advantage of
|
||||
software-defined networking (SDN) technology like OpenFlow to
|
||||
allow for high levels of multi-tenancy and massive scale.
|
||||
OpenStack Networking has an extension framework allowing
|
||||
additional network services, such as intrusion detection
|
||||
systems (IDS), load balancing, firewalls and virtual private
|
||||
networks (VPN) to be deployed and managed.</para>
|
||||
<para>Networking Capabilities</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>OpenStack provides flexible networking models to
|
||||
suit the needs of different applications or user groups.
|
||||
Standard models include flat networks or VLANs for
|
||||
separation of servers and traffic.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack Networking manages IP addresses, allowing
|
||||
for dedicated static IPs or DHCP. Floating IPs allow
|
||||
traffic to be dynamically re-routed to any of your
|
||||
compute resources, which allows you to redirect traffic
|
||||
during maintenance or in the case of failure.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Users can create their own networks, control traffic
|
||||
and connect servers and devices to one or more
|
||||
networks.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The pluggable backend architecture lets users take
|
||||
advantage of commodity gear or advanced networking
|
||||
services from supported vendors.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Administrators can take advantage of
|
||||
software-defined networking (SDN) technology like
|
||||
OpenFlow to allow for high levels of multi-tenancy and
|
||||
massive scale.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OpenStack Networking has an extension framework
|
||||
allowing additional network services, such as intrusion
|
||||
detection systems (IDS), load balancing, firewalls and
|
||||
virtual private networks (VPN) to be deployed and
|
||||
managed.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guisubmenu>Dashboard(Horizon)</guisubmenu></para>
|
||||
<para>OpenStack Dashboard (Horizon) provides administrators and
|
||||
users a graphical interface to access, provision and automate
|
||||
cloud-based resources. The design allows for third party products
|
||||
and services, such as billing, monitoring and additional
|
||||
management tools. Service providers and other commercial vendors
|
||||
can customize the dashboard with their own brand.</para>
|
||||
<para>The dashboard is just one way to interact with OpenStack
|
||||
resources. Developers can automate access or build tools to
|
||||
manage their resources using the native OpenStack API or the
|
||||
EC2 compatibility API.</para>
|
||||
<para><guisubmenu>Identity Service(Keystone)</guisubmenu></para>
|
||||
<para>OpenStack Identity (Keystone) provides a central directory
|
||||
of users mapped to the OpenStack services they can access. It acts
|
||||
as a common authentication system across the cloud operating
|
||||
system and can integrate with existing backend directory services
|
||||
like LDAP. It supports multiple forms of authentication including
|
||||
standard username and password credentials, token-based systems,
|
||||
and Amazon Web Services log in credentials such as those used
|
||||
for EC2.</para>
|
||||
<para>Additionally, the catalog provides a query-able list of all
|
||||
of the services deployed in an OpenStack cloud in a single
|
||||
registry. Users and third-party tools can programmatically
|
||||
determine which resources they can access.</para>
|
||||
<para>The OpenStack Identity Service enables administrators
|
||||
to:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Configure centralized policies across users and
|
||||
systems</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create users and tenants and define permissions for
|
||||
compute, storage, and networking resources by using role-based
|
||||
access control (RBAC) features</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Integrate with an existing directory, like LDAP, to
|
||||
provide a single source of authentication across the
|
||||
enterprise</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>The OpenStack Identity Service enables users to:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>List the services to which they have access</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Make API requests</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Log into the web dashboard to create resources owned
|
||||
by their account</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guisubmenu>Image Service(Glance)</guisubmenu></para>
|
||||
<para>OpenStack Image Service (Glance) provides discovery,
|
||||
registration and delivery services for disk and server images.
|
||||
Stored images can be used as a template. They can also be used
|
||||
to store and catalog an unlimited number of backups. The Image
|
||||
Service can store disk and server images in a variety of
|
||||
back-ends, including OpenStack Object Storage. The Image
|
||||
Service API provides a standard REST interface for querying
|
||||
information about disk images and lets clients stream the
|
||||
images to new servers.</para>
|
||||
<para>Capabilities of the Image Service include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Administrators can create base templates from which
|
||||
their users can start new compute instances</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Users can choose from available images, or create
|
||||
their own from existing servers</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Snapshots can also be stored in the Image Service so
|
||||
that virtual machines can be backed up quickly</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>A multi-format image registry, the image service allows
|
||||
uploads of private and public images in a variety of formats,
|
||||
including:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Raw</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Machine (kernel/ramdisk outside of image, also known
|
||||
as AMI)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VHD (Hyper-V)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VDI (VirtualBox)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>qcow2 (Qemu/KVM)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VMDK (VMware)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>OVF (VMware, others)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>To checkout the complete list of official programs
|
||||
under OpenStack check out here :
|
||||
https://wiki.openstack.org/wiki/Program</para>
|
||||
<para>To checkout the complete list of official programs and
|
||||
incubated projects under OpenStack check out OpenStack’s Launchpad
|
||||
Project Page here : https://launchpad.net/openstack/</para>
|
||||
<para><guisubmenu>Amazon Web Services compatibility</guisubmenu></para>
|
||||
<para>OpenStack APIs are compatible with Amazon EC2 and Amazon
|
||||
S3 and thus client applications written for Amazon Web
|
||||
Services can be used with OpenStack with minimal porting
|
||||
effort.</para>
|
||||
<para><guilabel>Governance</guilabel></para>
|
||||
<para>OpenStack is governed by a non-profit foundation and its
|
||||
board of directors, a technical committee and a user
|
||||
committee.</para>
|
||||
<para>The foundation's stated mission is by providing shared
|
||||
resources to help achieve the OpenStack Mission by Protecting,
|
||||
Empowering, and Promoting OpenStack software and the community
|
||||
around it, including users, developers and the entire
|
||||
ecosystem. Though, it has little to do with the development of
|
||||
the software, which is managed by the technical committee - an
|
||||
elected group that represents the contributors to the project,
|
||||
and has oversight on all technical matters.</para>
|
||||
</chapter>
|
||||
@ -1,375 +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="section_openstack-architecture">
|
||||
<title>OpenStack Architecture</title>
|
||||
<para><guilabel>Conceptual Architecture</guilabel></para>
|
||||
<para>The OpenStack project as a whole is designed to deliver a
|
||||
massively scalable cloud operating system. To achieve this, each
|
||||
of the constituent services are designed to work together to
|
||||
provide a complete Infrastructure-as-a-Service (IaaS). This
|
||||
integration is facilitated through public application
|
||||
programming interfaces (APIs) that each service offers (and in
|
||||
turn can consume). While these APIs allow each of the services
|
||||
to use another service, it also allows an implementer to switch
|
||||
out any service as long as they maintain the API. These are
|
||||
(mostly) the same APIs that are available to end users of the
|
||||
cloud.</para>
|
||||
<para>Conceptually, you can picture the relationships between the
|
||||
services as so:</para>
|
||||
<figure>
|
||||
<title>Conceptual Diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image13.jpg"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Dashboard ("Horizon") provides a web front end to the
|
||||
other OpenStack services</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Compute ("Nova") stores and retrieves virtual disks
|
||||
("images") and associated metadata in Image
|
||||
("Glance")</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Network ("Neutron") provides virtual networking for
|
||||
Compute.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Block Storage ("Cinder") provides storage volumes for
|
||||
Compute.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Image ("Glance") can store the actual virtual disk files
|
||||
in the Object Store("Swift")</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>All the services authenticate with Identity
|
||||
("Keystone")</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>The conceptual diagram is a stylized and simplified view of the
|
||||
architecture. It assumes that the implementer uses all services in the most
|
||||
common configuration. It also shows only the operator side of the cloud; it
|
||||
does not show how consumers might use the cloud. For example, many
|
||||
users directly and heavily access object storage.</para>
|
||||
<para><guilabel>Logical Architecture</guilabel></para>
|
||||
<para>The following diagram is consistent with the conceptual architecture
|
||||
as previously described:</para>
|
||||
<figure>
|
||||
<title>Logical diagram</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/openstack-arch-havana-logical-v1.jpg"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>End users can interact through a common web interface
|
||||
(Horizon) or directly to each service through their
|
||||
API</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>All services authenticate through a common source
|
||||
(facilitated through keystone)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Individual services interact with each other through
|
||||
their public APIs (except where privileged administrator
|
||||
commands are necessary)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>In the sections below, we'll delve into the architecture for
|
||||
each of the services.</para>
|
||||
<para><guilabel>Dashboard</guilabel></para>
|
||||
<para>Horizon is a modular Django web application that provides
|
||||
an end user and administrator interface to OpenStack
|
||||
services.</para>
|
||||
<figure>
|
||||
<title>Horizon Dashboard</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image10.jpg"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>As with most web applications, the architecture is fairly
|
||||
simple:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Horizon is usually deployed via mod_wsgi in Apache.
|
||||
The code itself is separated into a reusable python module
|
||||
with most of the logic (interactions with various
|
||||
OpenStack APIs) and presentation (to make it easily
|
||||
customizable for different sites).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A database (configurable as to which one) which relies
|
||||
mostly on the other services for data. It also stores very
|
||||
little data of its own.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>From a network architecture point of view, this service
|
||||
will need to be customer accessible as well as be able to talk
|
||||
to each service's public APIs. If you wish to use the
|
||||
administrator functionality (i.e. for other services), it will
|
||||
also need connectivity to their Admin API endpoints (which
|
||||
should be non-customer accessible).</para>
|
||||
<para><guilabel>Compute</guilabel></para>
|
||||
<para>Nova is the most complicated and distributed component of
|
||||
OpenStack. A large number of processes cooperate to turn end
|
||||
user API requests into running virtual machines. Below is a
|
||||
list of these processes and their functions:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>nova-api accepts and responds to end user compute API
|
||||
calls. It supports OpenStack Compute API, Amazon's EC2 API
|
||||
and a special Admin API (for privileged users to perform
|
||||
administrative actions). It also initiates most of the
|
||||
orchestration activities (such as running an instance) as
|
||||
well as enforces some policy (mostly quota checks).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The nova-compute process is primarily a worker daemon
|
||||
that creates and terminates virtual machine instances via
|
||||
hypervisor's APIs (XenAPI for XenServer/XCP, libvirt for
|
||||
KVM or QEMU, VMwareAPI for VMware, etc.). The process by
|
||||
which it does so is fairly complex but the basics are
|
||||
simple: accept actions from the queue and then perform a
|
||||
series of system commands (like launching a KVM instance)
|
||||
to carry them out while updating state in the
|
||||
database.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>nova-volume manages the creation, attaching and
|
||||
detaching of z volumes to compute instances, which has a similar
|
||||
functionality to Amazon’s Elastic Block Storage. It can
|
||||
use volumes from a variety of providers such as iSCSI or
|
||||
Rados Block Device in Ceph. The OpenStack Block Storage project,
|
||||
Cinder, has replaced the nova-volume functionality.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The nova-network worker daemon is very similar to
|
||||
nova-compute and nova-volume. It accepts networking tasks
|
||||
from the queue and then performs tasks to manipulate the
|
||||
network (such as setting up bridging interfaces or
|
||||
changing iptables rules). This functionality is being
|
||||
migrated to Neutron, a separate OpenStack project. In the
|
||||
Icehouse release, the functionality is duplicated between nova-network and Neutron.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The nova-schedule process is conceptually the simplest
|
||||
piece of code in OpenStack Nova: it takes a virtual machine
|
||||
instance request from the queue and determines where it
|
||||
should run (specifically, which compute server host it
|
||||
should run on).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The queue provides a central hub for passing messages
|
||||
between daemons. This is usually implemented with RabbitMQ
|
||||
today, but could be any AMQP message queue (such as Apache
|
||||
Qpid and ZeroMQ).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The SQL database stores most of the build-time and
|
||||
runtime state for a cloud infrastructure. This includes
|
||||
the instance types that are available for use, instances
|
||||
in use, networks available and projects. Theoretically,
|
||||
OpenStack Nova can support any database supported by
|
||||
SQL-Alchemy but the only databases currently being widely
|
||||
used are SQLite3 (only appropriate for test and
|
||||
development work), MySQL and PostgreSQL.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Nova also provides console services to allow end users
|
||||
to access their virtual instance's console through a
|
||||
proxy. This involves several daemons (nova-console,
|
||||
nova-novncproxy and nova-consoleauth).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Nova interacts with many other OpenStack services:
|
||||
Keystone for authentication, Glance for images and Horizon for
|
||||
web interface. The Glance interactions are central. The API
|
||||
process can upload and query Glance while nova-compute will
|
||||
download images for use in launching images.</para>
|
||||
<para><guilabel>Object Store</guilabel></para>
|
||||
<para>The swift architecture is very distributed to prevent any
|
||||
single point of failure as well as to scale horizontally. It
|
||||
includes the following components:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Proxy server (swift-proxy-server) accepts incoming
|
||||
requests via the OpenStack Object API or just raw HTTP. It
|
||||
accepts files to upload, modifications to metadata or
|
||||
container creation. In addition, it will also serve files
|
||||
or container listing to web browsers. The proxy server may
|
||||
utilize an optional cache (usually deployed with memcache)
|
||||
to improve performance.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Account servers manage accounts defined with the
|
||||
object storage service.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Container servers manage a mapping of containers (i.e
|
||||
folders) within the object store service.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Object servers manage actual objects (i.e. files) on
|
||||
the storage nodes.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>There are also a number of periodic processes which run
|
||||
to perform housekeeping tasks on the large data store. The
|
||||
most important of these is the replication services, which
|
||||
ensures consistency and availability through the cluster.
|
||||
Other periodic processes include auditors, updaters and
|
||||
reapers.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Authentication is handled through configurable WSGI
|
||||
middleware (which will usually be Keystone).</para>
|
||||
<para><guilabel>Image Store</guilabel></para>
|
||||
<para>The Glance architecture has stayed relatively stable since
|
||||
the Cactus release. The biggest architectural change has been
|
||||
the addition of authentication, which was added in the Diablo
|
||||
release. Just as a quick reminder, Glance has four main parts
|
||||
to it:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>glance-api accepts Image API calls for image
|
||||
discovery, image retrieval and image storage.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>glance-registry stores, processes and retrieves
|
||||
metadata about images (size, type, etc.).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A database to store the image metadata. Like Nova, you
|
||||
can choose your database depending on your preference (but
|
||||
most people use MySQL or SQLite).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>A storage repository for the actual image files. In
|
||||
the diagram above, Swift is shown as the image repository,
|
||||
but this is configurable. In addition to Swift, Glance
|
||||
supports normal filesystems, RADOS block devices, Amazon
|
||||
S3 and HTTP. Be aware that some of these choices are
|
||||
limited to read-only usage.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>There are also a number of periodic processes which run on
|
||||
Glance to support caching. The most important of these is the
|
||||
replication services, which ensures consistency and
|
||||
availability through the cluster. Other periodic processes
|
||||
include auditors, updaters and reapers.</para>
|
||||
<para>As you can see from the diagram in the Conceptual
|
||||
Architecture section, Glance serves a central role to the
|
||||
overall IaaS picture. It accepts API requests for images (or
|
||||
image metadata) from end users or Nova components and can
|
||||
store its disk files in the object storage service,
|
||||
Swift.</para>
|
||||
<para><guilabel>Identity</guilabel></para>
|
||||
<para>Keystone provides a single point of integration for
|
||||
OpenStack policy, catalog, token and authentication.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Keystone handles API requests as well as providing
|
||||
configurable catalog, policy, token and identity
|
||||
services.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Each Keystone function has a pluggable backend which
|
||||
allows different ways to use the particular service. Most
|
||||
support standard backends like LDAP or SQL, as well as Key
|
||||
Value Stores (KVS).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Most people will use this as a point of customization for
|
||||
their current authentication services.</para>
|
||||
<para><guilabel>Network</guilabel></para>
|
||||
<para>Neutron provides "network connectivity as a service"
|
||||
between interface devices managed by other OpenStack services
|
||||
(most likely Nova). The service works by allowing users to
|
||||
create their own networks and then attach interfaces to them.
|
||||
Like many of the OpenStack services, Neutron is highly
|
||||
configurable due to its plug-in architecture. These plug-ins
|
||||
accommodate different networking equipment and software. As
|
||||
such, the architecture and deployment can vary dramatically.
|
||||
In the above architecture, a simple Linux networking plug-in
|
||||
is shown.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>neutron-server accepts API requests and then routes
|
||||
them to the appropriate Neutron plug-in for action.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Neutron plug-ins and agents perform the actual actions
|
||||
such as plugging and unplugging ports, creating networks
|
||||
or subnets and IP addressing. These plug-ins and agents
|
||||
differ depending on the vendor and technologies used in
|
||||
the particular cloud. Neutron ships with plug-ins and
|
||||
agents for: Cisco virtual and physical switches, NEC
|
||||
OpenFlow products, Open vSwitch, Linux bridging, the Ryu
|
||||
Network Operating System, and VMware NSX.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The common agents are L3 (layer 3), DHCP (dynamic host
|
||||
IP addressing) and the specific plug-in agent.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Most Neutron installations will also make use of a
|
||||
messaging queue to route information between the
|
||||
neutron-server and various agents as well as a database to
|
||||
store networking state for particular plug-ins.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Neutron will interact mainly with Nova, where it will
|
||||
provide networks and connectivity for its instances.</para>
|
||||
<para><guilabel>Block Storage</guilabel></para>
|
||||
<para>Cinder separates out the persistent block storage
|
||||
functionality that was previously part of OpenStack Compute
|
||||
(in the form of nova-volume) into its own service. The
|
||||
OpenStack Block Storage API allows for manipulation of
|
||||
volumes, volume types (similar to compute flavors) and volume
|
||||
snapshots.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>cinder-api accepts API requests and routes them to
|
||||
cinder-volume for action.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>cinder-volume acts upon the requests by reading or
|
||||
writing to the Cinder database to maintain state,
|
||||
interacting with other processes (like cinder-scheduler)
|
||||
through a message queue and directly upon block storage
|
||||
providing hardware or software. It can interact with a
|
||||
variety of storage providers through a driver
|
||||
architecture. Currently, there are drivers for IBM,
|
||||
SolidFire, NetApp, Nexenta, Zadara, linux iSCSI and other
|
||||
storage providers.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Much like nova-scheduler, the cinder-scheduler daemon
|
||||
picks the optimal block storage provider node to create
|
||||
the volume on.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Cinder deployments will also make use of a messaging
|
||||
queue to route information between the cinder processes as
|
||||
well as a database to store volume state.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Like Neutron, Cinder will mainly interact with Nova,
|
||||
providing volumes for its instances.</para>
|
||||
</chapter>
|
||||
@ -1,64 +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="section_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 <namespace> <command>
|
||||
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>
|
||||
</chapter>
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,437 +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="section_queues-messaging">
|
||||
<title>OpenStack Messaging and Queues</title>
|
||||
<figure>
|
||||
<title>Messaging in OpenStack</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image04.png" contentwidth="7in"/>
|
||||
</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 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" contentwidth="7in"/>
|
||||
</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
|
||||
un-marshaling of messages into function calls. Each Nova service,
|
||||
such as Compute, Scheduler, and so on, creates 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 it 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 component
|
||||
within Nova connects to the message broker and, depending on its
|
||||
personality, such as 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 in this example they are used
|
||||
as an abstraction for the sake of clarity. An Invoker is a
|
||||
component that sends messages in the queuing system using <command>rpc.call
|
||||
</command> and <command>rpc.cast</command>. A worker is a component
|
||||
that receives messages from the queuing system and replies
|
||||
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" contentwidth="7in"/>
|
||||
</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" contentwidth="7in"/>
|
||||
</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" contentwidth="7in"/>
|
||||
</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 a 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 the hostname)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>compute</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>network.phantom (phantom is the hostname)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>network</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>scheduler.phantom (phantom is the 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 the 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 disables
|
||||
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
|
||||
(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>
|
||||
</chapter>
|
||||
@ -1,140 +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="section_security-in-neutron">
|
||||
<title>Security in Neutron</title>
|
||||
<para><guilabel>Security Groups</guilabel></para>
|
||||
<para>Security groups and security group rules allow
|
||||
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 traffic. Rules can be added
|
||||
to this group in order to change this 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, the user 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 a 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 as 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
|
||||
also relate 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, the evaluation policy will
|
||||
be successful, if any of the rules evaluate 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>
|
||||
</chapter>
|
||||
@ -1,206 +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="section_vm-placement">
|
||||
<title>VM Placement</title>
|
||||
<para>Compute uses the nova-scheduler service to determine how to
|
||||
dispatch compute and volume requests. For example, the
|
||||
nova-scheduler service determines which host a VM should launch
|
||||
on. The term host, in the context of filters, means a physical node
|
||||
that has the <systemitem class="service">nova-compute</systemitem>
|
||||
service running on it. You can configure the scheduler through a
|
||||
variety of options.</para>
|
||||
<figure>
|
||||
<title>Nova</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image29.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Just as shown by the above figure, nova-scheduler interacts with
|
||||
other components through the queue and central database repo. For
|
||||
scheduling, the queue is the essential communications hub.</para>
|
||||
<para>All compute nodes (also known as hosts in terms of OpenStack)
|
||||
periodically publish their status, resources available and
|
||||
hardware capabilities to nova-scheduler through the queue.
|
||||
Nova-scheduler then collects this data and uses it to make
|
||||
decisions when a request comes in.</para>
|
||||
<para>By default, the compute scheduler is configured as a filter
|
||||
scheduler, as described in the next section. In the default
|
||||
configuration, this scheduler considers hosts that meet all of the
|
||||
following criteria:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Are in the requested availability zone
|
||||
(AvailabilityZoneFilter).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Have sufficient RAM available (RamFilter).</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Are capable of servicing the request
|
||||
(ComputeFilter).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><guilabel>Filter Scheduler</guilabel></para>
|
||||
<para>The Filter Scheduler supports filtering and weighting to
|
||||
make informed decisions on where a new instance should be created.
|
||||
This Scheduler only supports working with Compute Nodes.</para>
|
||||
|
||||
<para><guilabel>Filtering</guilabel></para>
|
||||
<figure>
|
||||
<title>Filtering</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image27.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>During its work, Filter Scheduler first makes a dictionary
|
||||
of unfiltered hosts, then filters them using filter properties
|
||||
and finally chooses hosts for the requested number of
|
||||
instances (each time it chooses the most weighed host and
|
||||
appends it to the list of selected hosts).</para>
|
||||
<para>If it turns up that it can’t find candidates for the next
|
||||
instance, it means that there are no more appropriate hosts
|
||||
where the instance could be scheduled.</para>
|
||||
<para>If we speak about filtering and weighting, their work is
|
||||
quite flexible in the Filter Scheduler. There are a lot of
|
||||
filtering strategies for the Scheduler to support. Also you
|
||||
can even implement your own algorithm of filtering.</para>
|
||||
<para>There are some standard filter classes to use
|
||||
(nova.scheduler.filters):</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>AllHostsFilter - This filter does no
|
||||
operation. It passes all the available hosts.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ImagePropertiesFilter - filters hosts based on
|
||||
properties defined on the instance’s image. It passes
|
||||
hosts that can support the specified image properties
|
||||
contained in the instance.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>AvailabilityZoneFilter - filters hosts by availability
|
||||
zone. It passes hosts matching the availability zone
|
||||
specified in the instance properties.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>ComputeCapabilitiesFilter - checks that the
|
||||
capabilities provided by the host Compute service satisfy
|
||||
any extra specifications associated with the instance
|
||||
type. It passes hosts that can create the specified
|
||||
instance type.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The extra specifications can have a scope at the
|
||||
beginning of the key string of a key/value pair. The scope
|
||||
format is scope:key and can be nested, i.e. key_string :=
|
||||
scope:key_string. Example like capabilities:cpu_info:
|
||||
features is valid scope format. A key string without any :
|
||||
is non-scope format. Each filter defines its valid scope,
|
||||
and not all filters accept non-scope format.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>The extra specifications can have an operator at the
|
||||
beginning of the value string of a key/value pair. If
|
||||
there is no operator specified, then a default operator of
|
||||
s== is used. Valid operators are:</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>* = (equal to or greater than as a number; same as vcpus
|
||||
case)* == (equal to as a number)* != (not equal to as a
|
||||
number)* >= (greater than or equal to as a number)* <=
|
||||
(less than or equal to as a number)* s== (equal to as a
|
||||
string)* s!= (not equal to as a string)* s>= (greater than
|
||||
or equal to as a string)* s> (greater than as a string)*
|
||||
s<= (less than or equal to as a string)* s< (less than
|
||||
as a string)* <in> (substring)* <or> (find one of
|
||||
these)Examples are: ">= 5", "s== 2.1.0", "<in> gcc",
|
||||
and "<or> fpu <or> gpu"</para>
|
||||
<programlisting>class RamFilter(filters.BaseHostFilter):
|
||||
"""Ram Filter with over subscription flag"""
|
||||
|
||||
def host_passes(self, host_state, filter_properties):
|
||||
"""Only return hosts with sufficient available RAM."""
|
||||
|
||||
instance_type = filter_properties.get('instance_type')
|
||||
requested_ram = instance_type['memory_mb']
|
||||
free_ram_mb = host_state.free_ram_mb
|
||||
total_usable_ram_mb = host_state.total_usable_ram_mb
|
||||
used_ram_mb = total_usable_ram_mb - free_ram_mb
|
||||
return total_usable_ram_mb * FLAGS.ram_allocation_ratio - used_ram_mb >= requested_ram</programlisting>
|
||||
<para>Here ram_allocation_ratio means the virtual RAM to
|
||||
physical RAM allocation ratio (it is 1.5 by default). Really,
|
||||
nice and simple.</para>
|
||||
<para>The next standard filter to describe is AvailabilityZoneFilter
|
||||
and it isn’t difficult. This filter just looks at the
|
||||
availability zone of compute node and availability zone from
|
||||
the properties of the request. Each Compute service has its
|
||||
own availability zone, so that deployment engineers have an option
|
||||
to run scheduler with availability zones support and can
|
||||
configure availability zones on each compute host. This
|
||||
classes method host_passes returns True if the availability zone
|
||||
mentioned in the request is the same on the current compute
|
||||
host.</para>
|
||||
<para>The ImagePropertiesFilter filters hosts based on the
|
||||
architecture, hypervisor type, and virtual machine mode
|
||||
specified in the instance. E.g., an instance might require a
|
||||
host that supports the arm architecture on a qemu compute
|
||||
host. The ImagePropertiesFilter will only pass hosts that can
|
||||
satisfy this request. These instance properties are populated
|
||||
from properties defined on the instance’s image. E.g. an image
|
||||
can be decorated with these properties using glance
|
||||
image-update img-uuid --property architecture=arm --property
|
||||
hypervisor_type=qemu Only hosts that satisfy these
|
||||
requirements will pass the ImagePropertiesFilter.</para>
|
||||
<para>ComputeCapabilitiesFilter checks if the host satisfies any
|
||||
extra_specs specified on the instance type. The extra_specs
|
||||
can contain key/value pairs. The key for the filter is either
|
||||
non-scope format (i.e. no : contained), or scope format in
|
||||
capabilities scope (i.e. capabilities:xxx:yyy). One example of
|
||||
capabilities scope is capabilities:cpu_info:features, which
|
||||
will match host’s cpu features capabilities. The
|
||||
ComputeCapabilitiesFilter will only pass hosts whose
|
||||
capabilities satisfy the requested specifications. All hosts
|
||||
are passed if no extra_specs are specified.</para>
|
||||
<para>ComputeFilter is quite simple and passes any host whose
|
||||
Compute service is enabled and operational.</para>
|
||||
<para>Now we are going to the IsolatedHostsFilter. There can be some
|
||||
special hosts reserved for specific images. These hosts are
|
||||
called isolated. The images to run on the isolated hosts
|
||||
are also called isolated. This Scheduler checks if the
|
||||
image_isolated flag named in instance specifications is the
|
||||
same that the host has.</para>
|
||||
|
||||
<para><guilabel>Weights</guilabel></para>
|
||||
<para>Filter Scheduler uses so-called weights during its
|
||||
work.</para>
|
||||
<para>The Filter Scheduler weighs hosts based on the config
|
||||
option scheduler_weight_classes, this defaults to
|
||||
nova.scheduler.weights.all_weighers, which selects the only
|
||||
weigher available – the RamWeigher. Hosts are then weighed and
|
||||
sorted with the largest weight winning.</para>
|
||||
<para>Filter Scheduler finds local list of acceptable hosts by
|
||||
repeated filtering and weighing. Each time it chooses a host, it
|
||||
virtually consumes resources on it, so subsequent selections can
|
||||
adjust accordingly. It is useful if the customer asks for the
|
||||
same large amount of instances, because weight is computed for
|
||||
each instance requested.</para>
|
||||
<figure>
|
||||
<title>Weights</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="https://raw.githubusercontent.com/openstack/openstack-manuals/master/doc/common/../figures/nova-weighting-hosts.png"
|
||||
contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>In the end Filter Scheduler sorts selected hosts by their
|
||||
weight and provisions instances on them.</para>
|
||||
</chapter>
|
||||
@ -1,217 +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="section_vm-provisioning-indepth">
|
||||
<title>VM provisioning in-depth</title>
|
||||
<!--
|
||||
<para>More content to be added...</para>
|
||||
-->
|
||||
<para>
|
||||
The request flow for provisioning an instance goes like
|
||||
this:
|
||||
</para>
|
||||
<!-- The steps here correspond to numbers in figure
|
||||
../figures/image02.png at the end of this file. Do not renumber
|
||||
the steps -->
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<!-- 1 -->
|
||||
<para>The dashboard or CLI gets the user credentials and authenticates
|
||||
with the Identity Service via REST API.
|
||||
</para>
|
||||
<para>
|
||||
The Identity Service authenticates the user with the user
|
||||
credentials, and then generates and sends back an auth-token
|
||||
which will be used for sending the request to other components
|
||||
through REST-call.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 2 -->
|
||||
<para>
|
||||
The dashboard or CLI converts the new instance request
|
||||
specified in <guilabel>launch instance</guilabel> or
|
||||
<command>nova-boot</command> form to a REST API request and
|
||||
sends it to <systemitem class="service">nova-api</systemitem>.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 3 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-api</systemitem> receives the
|
||||
request and sends a request to the Identity Service for
|
||||
validation of the auth-token and access permission.
|
||||
</para>
|
||||
<para>
|
||||
The Identity Service validates the token and sends updated
|
||||
authentication headers with roles and permissions.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 4 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-api</systemitem> checks for
|
||||
conflicts with <systemitem
|
||||
class="service">nova-database</systemitem>.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-api</systemitem> creates
|
||||
initial database entry for a new instance.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 5 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-api</systemitem> sends the
|
||||
rpc.call request to <systemitem
|
||||
class="service">nova-scheduler</systemitem> expecting to get
|
||||
updated instance entry with host ID specified.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 6 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-scheduler</systemitem> picks
|
||||
up the request from the queue.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 7 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-scheduler</systemitem>
|
||||
interacts with <systemitem
|
||||
class="service">nova-database</systemitem> to find an
|
||||
appropriate host via filtering and weighing.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-scheduler</systemitem>
|
||||
returns the updated instance entry with the appropriate host
|
||||
ID after filtering and weighing.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-scheduler</systemitem> sends
|
||||
the rpc.cast request to <systemitem
|
||||
class="service">nova-compute</systemitem> for launching an
|
||||
instance on the appropriate host.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 8 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem> picks up
|
||||
the request from the queue.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<!-- 9 -->
|
||||
<systemitem class="service">nova-compute</systemitem> sends the
|
||||
rpc.call request to <systemitem
|
||||
class="service">nova-conductor</systemitem> to fetch the
|
||||
instance information such as host ID and flavor (RAM, CPU,
|
||||
Disk).
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 10 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-conductor</systemitem> picks
|
||||
up the request from the queue.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 11 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-conductor</systemitem>
|
||||
interacts with <systemitem
|
||||
class="service">nova-database</systemitem>.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-conductor</systemitem>
|
||||
returns the instance information.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem> picks up the
|
||||
instance information from the queue.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 12 -->
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem> performs
|
||||
the REST call by passing the auth-token to <systemitem
|
||||
class="service">glance-api</systemitem>. Then, <systemitem
|
||||
class="service">nova-compute</systemitem> uses the Image ID to
|
||||
retrieve the Image URI from the Image Service, and loads the
|
||||
image from the image storage.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<!-- 13 -->
|
||||
<systemitem class="service">glance-api</systemitem> validates
|
||||
the auth-token with keystone.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem> gets the
|
||||
image metadata.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<!-- 14 -->
|
||||
<systemitem class="service">nova-compute</systemitem> performs
|
||||
the REST-call by passing the auth-token to Network API to
|
||||
allocate and configure the network so that the instance gets
|
||||
the IP address.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<!-- 15 -->
|
||||
<para>
|
||||
<systemitem class="service">neutron-server</systemitem>
|
||||
validates the auth-token with keystone.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem>
|
||||
retrieves the network info.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<!-- 16 -->
|
||||
<systemitem class="service">nova-compute</systemitem> performs
|
||||
the REST call by passing the auth-token to Volume API to attach
|
||||
volumes to the instance.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<!-- 17 -->
|
||||
<systemitem class="service">cinder-api</systemitem> validates
|
||||
the auth-token with keystone.
|
||||
</para>
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem> retrieves the
|
||||
block storage info.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<systemitem class="service">nova-compute</systemitem>
|
||||
generates data for the hypervisor driver and executes the
|
||||
request on the hypervisor (via libvirt or API).
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
<figure>
|
||||
<title>Nova VM provisioning</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image02.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
</chapter>
|
||||
@ -1,241 +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="section_vm-provisioning-walk-through">
|
||||
<title>VM Provisioning Walk Through</title>
|
||||
<para>More Content To be Added ...</para>
|
||||
<para>OpenStack Compute gives you a tool to orchestrate a cloud,
|
||||
including running instances, managing networks, and controlling
|
||||
access to the cloud through users and projects. The underlying
|
||||
open source project's name is Nova, and it provides the software
|
||||
that can control an Infrastructure-as-a-Service (IaaS) cloud
|
||||
computing platform. It is similar in scope to Amazon EC2 and
|
||||
Rackspace Cloud Servers. OpenStack Compute does not include any
|
||||
virtualization software; rather it defines drivers that interact
|
||||
with underlying virtualization mechanisms that run on your host
|
||||
operating system, and exposes functionality over a web-based
|
||||
API.</para>
|
||||
<para><guilabel>Hypervisors</guilabel></para>
|
||||
<para>OpenStack Compute requires a hypervisor and Compute controls
|
||||
the hypervisors through an API server. The process for selecting
|
||||
a hypervisor usually means prioritizing and making decisions
|
||||
based on budget and resource constraints as well as the
|
||||
inevitable list of supported features and required technical
|
||||
specifications. The majority of development is done with the KVM
|
||||
and Xen-based hypervisors. Refer to
|
||||
<link xlink:href="http://wiki.openstack.org/HypervisorSupportMatrix"></link>
|
||||
for a detailed list of features and support across the hypervisors.</para>
|
||||
<para>With OpenStack Compute, you can orchestrate clouds using
|
||||
multiple hypervisors in different zones. The types of
|
||||
virtualization standards that may be used with Compute
|
||||
include:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>KVM- Kernel-based Virtual Machine (visit <link
|
||||
xlink:href="http://www.linux-kvm.org/"
|
||||
>http://www.linux-kvm.org/</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>LXC- Linux Containers (through libvirt) (visit <link
|
||||
xlink:href="http://linuxcontainers.org/"
|
||||
>http://linuxcontainers.org/</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>QEMU- Quick EMUlator (visit <link
|
||||
xlink:href="http://www.qemu.org/"
|
||||
>http://www.qemu.org/</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>UML- User Mode Linux (visit <link
|
||||
xlink:href="http://en.wikipedia.org/wiki/User-mode_Linux"
|
||||
>http://en.wikipedia.org/wiki/User-mode_Linux</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>VMware vSphere4.1 update 1 and newer (visit <link
|
||||
xlink:href="http://vmware.com/products/vsphere"
|
||||
>http://vmware.com/products/vsphere</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Xen- Xen, Citrix XenServer and Xen Cloud Platform (XCP)
|
||||
(visit <link xlink:href="http://wiki.xen.org/"
|
||||
>http://wiki.xen.org/</link>)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Bare Metal- Provisions physical hardware via pluggable
|
||||
sub-drivers. (visit
|
||||
<link xlink:href="https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework"
|
||||
>Bare Metal wiki page</link>)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guilabel>Users and Tenants (Projects)</guilabel></para>
|
||||
<para>The OpenStack Compute 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 <filename>policy.json</filename>
|
||||
file that
|
||||
maintains the rules. For example, a rule can be defined so that
|
||||
a user cannot allocate a public IP without the admin role. A
|
||||
user's access to particular images is limited by tenant, but the
|
||||
username and password are assigned per user. Key pairs granting
|
||||
access to an instance are enabled per user, but quotas to
|
||||
control resource consumption across available hardware resources
|
||||
are per tenant.</para>
|
||||
<para>While the original EC2 API supports users, OpenStack Compute
|
||||
adds the concept of tenants. Tenants are isolated resource
|
||||
containers forming the principal organizational structure within
|
||||
the Compute service. They consist of a separate VLAN, volumes,
|
||||
instances, images, keys, and users. A user can specify which
|
||||
tenant he or she wishes to be known as by appending :project_id
|
||||
to his or her access key. If no tenant is specified in the API
|
||||
request, Compute attempts to use a tenant with the same ID as
|
||||
the user</para>
|
||||
<para>For tenants, quota controls are available to limit
|
||||
the:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Number of volumes which may be created</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Total size of all volumes within a project as measured
|
||||
in GB</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Number of instances which may be launched</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Number of processor cores which may be allocated</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Floating IP addresses (assigned to any instance when it
|
||||
launches so the instance has the same publicly accessible IP
|
||||
addresses)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Fixed IP addresses (assigned to the same instance each
|
||||
time it boots, publicly or privately accessible, typically
|
||||
private for management purposes)</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><guilabel>Images and Instances</guilabel></para>
|
||||
<para>This introduction provides a high level overview of what
|
||||
images and instances are and description of the life-cycle of a
|
||||
typical virtual system within the cloud. There are many ways to
|
||||
configure the details of an OpenStack cloud and many ways to
|
||||
implement a virtual system within that cloud. These
|
||||
configuration details as well as the specific command-line
|
||||
utilities and API calls to perform the actions described are
|
||||
presented in the Image Management and Volume
|
||||
Management chapters.</para>
|
||||
<para>Images are disk images which are templates for virtual
|
||||
machine file systems. The OpenStack Image Service is responsible
|
||||
for the storage and management of images within
|
||||
OpenStack.</para>
|
||||
<para>Instances are the individual virtual machines running on
|
||||
physical compute nodes. The OpenStack Compute service manages
|
||||
instances. Any number of instances may be started from the same
|
||||
image. Each instance is run from a copy of the base image so
|
||||
runtime changes made by an instance do not change the image it
|
||||
is based on. Snapshots of running instances may be taken which
|
||||
create a new image based on the current disk state of a
|
||||
particular instance.</para>
|
||||
<para>When starting an instance, a set of virtual resources known
|
||||
as a flavor must be selected. Flavors define how many virtual
|
||||
CPUs an instance has and the amount of RAM and size of its
|
||||
ephemeral disks. OpenStack provides a number of predefined
|
||||
flavors which cloud administrators may edit or add to. Users
|
||||
must select from the set of available flavors defined on their
|
||||
cloud.</para>
|
||||
<para>Additional resources such as persistent volume storage and a
|
||||
public IP address may be added to and removed from running
|
||||
instances. The examples below show the cinder-volume service
|
||||
which provide persistent block storage as opposed to the
|
||||
ephemeral storage provided by the instance flavor.</para>
|
||||
<para>Here is an example of the life cycle of a typical virtual
|
||||
system within an OpenStack cloud to illustrate these
|
||||
concepts.</para>
|
||||
<para><guilabel>Initial State</guilabel></para>
|
||||
<para><guilabel>Images and Instances</guilabel></para>
|
||||
<para>The following diagram shows the system state prior to
|
||||
launching an instance. The image store fronted by the Image
|
||||
Service has some number of predefined images. In the
|
||||
cloud, there is an available compute node with available vCPU,
|
||||
memory and local disk resources. Plus there are a number of
|
||||
predefined volumes in the
|
||||
<systemitem class="service">cinder-volume</systemitem> service.
|
||||
</para>
|
||||
<para>Figure 2.1. Base image state with no running
|
||||
instances</para>
|
||||
<figure>
|
||||
<title>Initial State</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image21.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para><guilabel>Launching an instance</guilabel></para>
|
||||
<para>To launch an instance, the user selects an image, a flavor,
|
||||
and other optional attributes. In this case the selected
|
||||
flavor provides a root volume (as all flavors do). Let us assume that the
|
||||
root volume is labelled as 'vda' and additional ephemeral storage labelled
|
||||
as 'vdb'. The user has also opted to map a volume from the
|
||||
<systemitem class="service">cinder-volume</systemitem>
|
||||
store to the third virtual disk, vdc, on this instance.</para>
|
||||
<para>Figure 2.2. Instance creation from image and run time
|
||||
state</para>
|
||||
<figure>
|
||||
<title>Launch VM Instance</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image09.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>The OpenStack system copies the base image from the image
|
||||
store to local disk which is used as the first disk of the
|
||||
instance (vda). Having small images will result in faster start
|
||||
up of your instances as less data needs to be copied across the
|
||||
network. The system also creates a new empty disk image to
|
||||
present as the second disk (vdb). Be aware that the second disk
|
||||
is an empty disk with an ephemeral life as it is destroyed when
|
||||
you delete the instance. The compute node attaches to the
|
||||
requested <systemitem class="service">cinder-volume</systemitem>
|
||||
using iSCSI and maps this to the third disk (vdc) as requested.
|
||||
The vCPU and memory resources are provisioned and the instance is booted
|
||||
from the first drive. The instance runs and changes data on the disks
|
||||
highlighted in yellow in the diagram.</para>
|
||||
<para>There are many possible variations in the details of the
|
||||
scenario, particularly in terms of what the backing storage is
|
||||
and the network protocols used to attach and move storage. One
|
||||
variant worth mentioning here is that the ephemeral storage used
|
||||
for volumes vda and vdb in this example may be backed by network
|
||||
storage rather than local disk. The details are left for later
|
||||
chapters.</para>
|
||||
<para><guilabel>End State</guilabel></para>
|
||||
<para>Once the instance has served its purpose and is deleted,
|
||||
all state is reclaimed, except the persistent volume. The
|
||||
ephemeral storage is purged. Memory and vCPU resources are
|
||||
released. The image remains unchanged
|
||||
throughout.</para>
|
||||
<para>Figure 2.3. End state of image and volume after instance
|
||||
exits</para>
|
||||
<figure>
|
||||
<title>End State</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="../figures/image22.png" contentwidth="7in"/>
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
<para>Once you launch a VM in OpenStack, there's something more
|
||||
going on in the background. To understand what's happening
|
||||
behind the dashboard, lets take a deeper dive into OpenStack's
|
||||
VM provisioning. For launching a VM, you can either use
|
||||
the command-line interface or the OpenStack dashboard.
|
||||
</para>
|
||||
</chapter>
|
||||
@ -1,29 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<book 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="bk_developer-training-guide">
|
||||
<title>Developer Training Guide</title>
|
||||
<xi:include href="./ch_developer-getting-started.xml"/>
|
||||
<xi:include href="./ch_developer-getting-started-lab.xml"/>
|
||||
<xi:include href="./ch_developer-getting-started-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-apis-in-depth.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-two-lab.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-two-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-three-lab.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-three-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-four-lab.xml"/>
|
||||
<xi:include href="./ch_developer-apis-day-four-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-partipate.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-five-lab.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-five-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-six-lab.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-six-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-seven-lab.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-seven-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-eight-lab.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-eight-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-nine-lab.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-day-nine-quiz.xml"/>
|
||||
<xi:include href="./ch_developer-assessment.xml"/>
|
||||
<xi:include href="./ch_developer-how-to-participate-bootcamp.xml"/>
|
||||
</book>
|
||||
@ -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="developer-apis-day-four-lav">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Four</title>
|
||||
<section xml:id="developer-apis-day-four-lab-schedule">
|
||||
<title>Day 4, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-day-four-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth Day Four Quiz</title>
|
||||
<section xml:id="developer-apis-day-four-quiz-schedule">
|
||||
<title>Day 4, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-lab-three">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth Lab Day Three</title>
|
||||
<section xml:id="developer-apis-lab-three-schedule">
|
||||
<title>Day 3, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-day-three-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth Day Three Quiz</title>
|
||||
<section xml:id="developer-apis-day-three-quiz-schedule">
|
||||
<title>Day 3, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-lab-two">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth Lab Day Two</title>
|
||||
<section xml:id="developer-apis-lab-two-schedule">
|
||||
<title>Day 2, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<formalpara>
|
||||
<title>Pre-Requisites</title>
|
||||
<!-- Need to add more content here -->
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="http://git-scm.com/">Git Basics</link>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="http://docs.openstack.org/infra/manual/developers.html#development-workflow">Gerrit Basics</link>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<link xlink:href="http://jenkins-ci.org/">Jenkins</link>
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</formalpara>
|
||||
<!-- Need to add more content here -->
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-day-two-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth Day Two Quiz</title>
|
||||
<section xml:id="developer-apis-day-two-quiz-schedule">
|
||||
<title>Day 2, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-apis-in-depth">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer APIs in Depth</title>
|
||||
<section xml:id="developer-apis-morning-schedule">
|
||||
<title>Day 2 to 4, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
@ -1,57 +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="developer-assessment">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Assessment</title>
|
||||
<section xml:id="developer-day-ten-assessment-schedule">
|
||||
<title>Day 10, 9:00 to 11:00, 11:15 to 12:30, hands on lab 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="developer-assessment-questions">
|
||||
<title>Questions</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>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,46 +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="developer-getting-started-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started Lab</title>
|
||||
<section xml:id="developer-getting-started-lab-schedule">
|
||||
<title>Day 1, 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="developer-getting-tools-and-accounts">
|
||||
<title>Getting the Tools and Accounts for Committing Code</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'getting-tools-and-accounts']/*[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="developer-fix-doc-bug">
|
||||
<title>Fix a Documentation Bug</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'fix-doc-bug']/*[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="developer-submit-doc-bug">
|
||||
<title>Submit a Documentation Bug</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'submit-doc-bug']/*[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="developer-create-branch">
|
||||
<title>Create a Branch</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'create-branch']/*[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="developer-add-training-content">
|
||||
<title>Optional: Add to the Training Guide Documentation</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'add-training-content']/*[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>
|
||||
@ -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="developer-getting-started-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started Quiz</title>
|
||||
<section xml:id="developer-day-one-getting-started-quiz-schedule">
|
||||
<title>Day 1, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,56 +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="developer-getting-started">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started</title>
|
||||
<section xml:id="developer-day-one-morning-schedule">
|
||||
<title>Day 1, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="developer-getting-started-overview">
|
||||
<title>Overview</title>
|
||||
<para>Training would take 2.5 months self paced, (5) 2 week periods with a user group meeting, or
|
||||
40 hours instructor led with 40 hours of self paced lab time.</para>
|
||||
<para>Prerequisites</para>
|
||||
<orderedlist>
|
||||
<listitem><para>Associate guide training</para></listitem>
|
||||
<listitem><para>Associate guide virtualbox scripted install completed and running</para></listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section xml:id="developer-intro-text">
|
||||
<title>Review Operator Introduction</title>
|
||||
<xi:include href="../common/section_intro-text.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="developer-brief-overview">
|
||||
<title>Review Operator Brief Overview</title>
|
||||
<xi:include href="../common/section_brief-overview.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="developer-official-programs">
|
||||
<title>Review Operator Official Programs</title>
|
||||
<xi:include href="../common/section_official-programs.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_official-programs']/*[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="developer-openstack-architecture">
|
||||
<title>Review Operator OpenStack Architecture</title>
|
||||
<xi:include href="../common/section_openstack-architecture.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="developer-vm-provisioning-walk-through">
|
||||
<title>Review Operator Virtual Machine Provisioning Walk-Through</title>
|
||||
<xi:include href="../common/section_vm-provisioning-walk-through.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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>
|
||||
@ -1,79 +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="developer-how-to-participate-bootcamp">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Bootcamp</title>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-schedule">
|
||||
<title>One Day with Focus on Contribution</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-overview">
|
||||
<title>Overview</title>
|
||||
<para>Training will take 6 hours with labs and quizzes.</para>
|
||||
<para>Prerequisites</para>
|
||||
<orderedlist>
|
||||
<listitem><para>Some knowledge of Python and/or Perl</para></listitem>
|
||||
<listitem><para>Editor on a self-supplied laptop with either Eclipse with pydev, vim, emacs, or pycharm</para></listitem>
|
||||
<listitem><para>Run through the Operator Training Guide Getting Started Lab in full. This will walk each trainee through installing the accounts and tools required for the bootcamp.</para></listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-morning-classroom">
|
||||
<title>Morning Classroom 10:00 to 11:15</title>
|
||||
<para>Understanding the local tools in-depth</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Pycharm editor</para></listitem>
|
||||
<listitem><para>Git</para></listitem>
|
||||
<listitem><para>Sourcetree</para></listitem>
|
||||
<listitem><para>Maven</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>Understanding the remote tools in-depth</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>git-review</para></listitem>
|
||||
<listitem><para>github</para></listitem>
|
||||
<listitem><para>gerrit</para></listitem>
|
||||
<listitem><para>jenkins</para></listitem>
|
||||
<listitem><para>gearman</para></listitem>
|
||||
<listitem><para>jeepy</para></listitem>
|
||||
<listitem><para>zuul</para></listitem>
|
||||
<listitem><para>launchpad</para></listitem>
|
||||
</itemizedlist>
|
||||
<para>CI Pipeline Workflow Overview</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Understanding the submission process in-depth</para></listitem>
|
||||
<listitem><para>Review submission syntax</para></listitem>
|
||||
<listitem><para>Gerrit etiquette</para></listitem>
|
||||
<listitem><para>Resubmission</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-morning-lab">
|
||||
<title>Morning Lab 11:30 to 12:30</title>
|
||||
<para>TBD</para>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-morning-quiz">
|
||||
<title>Morning Quiz 12:30 to 12:50</title>
|
||||
<para>Online moodle test for theory, bit of syntax and terms, retake until 100%</para>
|
||||
<para>Content TBD</para>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-afternoon-classroom">
|
||||
<title>Afternoon Classroom 13:30 to 14:45</title>
|
||||
<para>Understanding the CI Pipeline in-depth</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>Gerrit Workflow</para></listitem>
|
||||
<listitem><para>Common jenkins tests</para></listitem>
|
||||
<listitem><para>Reviewing and understanding zuul</para></listitem>
|
||||
<listitem><para>Understanding jenkins output</para></listitem>
|
||||
<listitem><para>Understanding jenkins system manual (devstack)</para></listitem>
|
||||
<listitem><para>automated (tempest) integration tests</para></listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-afternoon-lab-schedule">
|
||||
<title>Afternoon Lab 15:00 to 17:00</title>
|
||||
<para>TBD</para>
|
||||
</section>
|
||||
<section xml:id="developer-how-to-participate-bootcamp-afternoon-quiz-schedule">
|
||||
<title>Afternoon Quiz 17:00 to 17:20</title>
|
||||
<para>Online moodle test for theory, bit of syntax and terms, retake until 100%</para>
|
||||
<para>Content TBD</para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-lab-eight">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Eight</title>
|
||||
<section xml:id="developer-how-to-participate-lab-eight-schedule">
|
||||
<title>Day 8, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-day-eight-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Day Eight Quiz</title>
|
||||
<section xml:id="developer-how-to-participate-day-eight-quiz-schedule">
|
||||
<title>Day 8, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-lab-five">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Five</title>
|
||||
<section xml:id="developer-how-to-participate-lab-five-schedule">
|
||||
<title>Day 5, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-day-five-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Day Five Quiz</title>
|
||||
<section xml:id="developer-how-to-participate-day-five-quiz-schedule">
|
||||
<title>Day 5, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-lab-nine">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Nine</title>
|
||||
<section xml:id="developer-how-to-participate-lab-nine-schedule">
|
||||
<title>Day 9, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-day-nine-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Day Nine Quiz</title>
|
||||
<section xml:id="developer-how-to-participate-day-nine-quiz-schedule">
|
||||
<title>Day 9, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-lab-seven">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Seven</title>
|
||||
<section xml:id="developer-how-to-participate-lab-seven-schedule">
|
||||
<title>Day 7, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-day-seven-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Day Seven Quiz</title>
|
||||
<section xml:id="developer-how-to-participate-day-seven-quiz-schedule">
|
||||
<title>Day 7, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-lab-six">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Lab Day Six</title>
|
||||
<section xml:id="developer-how-to-participate-lab-six-schedule">
|
||||
<title>Day 6, 13:30 to 14:45, 15:00 to 16:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate-day-six-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate Day Six Quiz</title>
|
||||
<section xml:id="developer-how-to-participate-day-six-quiz-schedule">
|
||||
<title>Day 6, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="developer-how-to-participate">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Developer How To Participate</title>
|
||||
<section xml:id="developer-how-to-participate-schedule">
|
||||
<title>Day 5 to 9, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,21 +0,0 @@
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<book 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="bk_operator-training-guide">
|
||||
<title>Operator Training Guide</title>
|
||||
<xi:include href="./ch_operator-getting-started.xml"/>
|
||||
<xi:include href="./ch_operator-getting-started-lab.xml"/>
|
||||
<xi:include href="./ch_operator-getting-started-quiz.xml"/>
|
||||
<xi:include href="./ch_operator-controller-node.xml"/>
|
||||
<xi:include href="./ch_operator-controller-node-lab.xml"/>
|
||||
<xi:include href="./ch_operator-controller-node-quiz.xml"/>
|
||||
<xi:include href="./ch_operator-network-node.xml"/>
|
||||
<xi:include href="./ch_operator-network-node-lab.xml"/>
|
||||
<xi:include href="./ch_operator-network-node-quiz.xml"/>
|
||||
<xi:include href="./ch_operator-compute-node.xml"/>
|
||||
<xi:include href="./ch_operator-compute-node-lab.xml"/>
|
||||
<xi:include href="./ch_operator-compute-node-quiz.xml"/>
|
||||
<!-- <xi:include href="./ch_operator-object-storage-node.xml"/> -->
|
||||
<xi:include href="./ch_operator-object-storage-node-lab.xml"/>
|
||||
<xi:include href="./ch_operator-object-storage-node-quiz.xml"/>
|
||||
</book>
|
||||
@ -1,18 +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="operator-compute-node-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Compute Node Lab</title>
|
||||
<section xml:id="operator-compute-node-lab-schedule">
|
||||
<title>Days 5 to 6, 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-basic-install-guide-compute-lab">
|
||||
<title>Compute Node Lab</title>
|
||||
<xi:include href="../basic-install-guide/lab_compute-node.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'lab_compute-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>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="operator-compute-node-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Compute Node Quiz</title>
|
||||
<section xml:id="operator-compute-quiz-schedule">
|
||||
<title>Days 5 to 6, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,38 +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="operator-computer-node">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Compute Node</title>
|
||||
<section xml:id="operator-day-one-afternoon-schedule">
|
||||
<title>Days 5 to 6, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-vm-placement">
|
||||
<title>Review Associate VM Placement</title>
|
||||
<xi:include href="../common/section_vm-placement.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-vm-provisioning-indepth">
|
||||
<title>Review Associate VM Provisioning Indepth</title>
|
||||
<xi:include href="../common/section_vm-provisioning-indepth.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-block-storage">
|
||||
<title>Review Associate OpenStack Block Storage</title>
|
||||
<xi:include href="../common/section_block-storage.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-compute-node-administration-tasks">
|
||||
<title>Review Associate Administration Tasks</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,18 +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="operator-controller-node-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Controller Node Lab</title>
|
||||
<section xml:id="operator-controller-node-lab-schedule">
|
||||
<title>Days 2 to 4, 13:30 to 14:45, 15:00 to 16:30, 16:45 to 18:15</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-basic-install-guide-controller-lab">
|
||||
<title>Control Node Lab</title>
|
||||
<xi:include href="../basic-install-guide/lab_control-node.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'lab_control-node.xml']/*[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>
|
||||
@ -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="operator-controller-node-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Controller Node Quiz</title>
|
||||
<section xml:id="operator-controller-quiz-schedule">
|
||||
<title>Days 2 to 4, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,38 +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="operator-controller-node">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Controller Node</title>
|
||||
<section xml:id="operator-day-one-late-morning-schedule">
|
||||
<title>Day 2 to 4, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-overview-horizon-cli">
|
||||
<title>Review Associate Overview Horizon and OpenStack CLI</title>
|
||||
<xi:include href="../common/section_overview-horizon-cli.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-keystone-arch">
|
||||
<title>Review Associate Keystone Architecture</title>
|
||||
<xi:include href="../common/section_keystone-arch.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-queues-messaging">
|
||||
<title>Review Associate OpenStack Messaging and Queues</title>
|
||||
<xi:include href="../common/section_queues-messaging.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-controller-node-administration-tasks">
|
||||
<title>Review Associate Administration Tasks</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,46 +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="operator-getting-started-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started Lab</title>
|
||||
<section xml:id="operator-getting-started-lab-schedule">
|
||||
<title>Day 1, 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-getting-tools-and-accounts">
|
||||
<title>Getting the Tools and Accounts for Committing Code</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'getting-tools-and-accounts']/*[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="operator-fix-doc-bug">
|
||||
<title>Fix a Documentation Bug</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'fix-doc-bug']/*[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="operator-submit-doc-bug">
|
||||
<title>Submit a Documentation Bug</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'submit-doc-bug']/*[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="operator-create-branch">
|
||||
<title>Create a Branch</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'create-branch']/*[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="operator-add-training-content">
|
||||
<title>Optional: Add to the Training Guide Documentation</title>
|
||||
<xi:include href="../common/editing-code.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'add-training-content']/*[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>
|
||||
@ -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="operator-getting-started-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started Quiz</title>
|
||||
<section xml:id="operator-day-one-getting-started-quiz-schedule">
|
||||
<title>Day 1, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,56 +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="operator-getting-started">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Getting Started</title>
|
||||
<section xml:id="operator-day-one-morning-schedule">
|
||||
<title>Day 1, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-getting-started-overview">
|
||||
<title>Overview</title>
|
||||
<para>Training would take 2.5 months self paced, (5) 2 week periods with a user group meeting, or
|
||||
40 hours instructor led with 40 hours of self paced lab time.</para>
|
||||
<para>Prerequisites</para>
|
||||
<orderedlist>
|
||||
<listitem><para>Associate guide training</para></listitem>
|
||||
<listitem><para>Associate guide virtualbox scripted install completed and running</para></listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section xml:id="operator-intro-text">
|
||||
<title>Review Associate Introduction</title>
|
||||
<xi:include href="../common/section_intro-text.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-brief-overview">
|
||||
<title>Review Associate Brief Overview</title>
|
||||
<xi:include href="../common/section_brief-overview.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-official-programs">
|
||||
<title>Review Associate Official Programs</title>
|
||||
<xi:include href="../common/section_official-programs.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_official-programs']/*[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="operator-openstack-architecture">
|
||||
<title>Review Associate OpenStack Architecture</title>
|
||||
<xi:include href="../common/section_openstack-architecture.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-vm-provisioning-walk-through">
|
||||
<title>Review Associate Virtual Machine Provisioning Walk-Through</title>
|
||||
<xi:include href="../common/section_vm-provisioning-walk-through.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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>
|
||||
@ -1,18 +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="operator-network-node-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Network Node Lab</title>
|
||||
<section xml:id="operator-network-node-lab-schedule">
|
||||
<title>Days 7 to 8, 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-basic-install-guide-network-lab">
|
||||
<title>Network Node Lab</title>
|
||||
<xi:include href="../basic-install-guide/lab_network-node.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'lab_network-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>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="operator-network-node-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Network Node Quiz</title>
|
||||
<section xml:id="operator-network-quiz-schedule">
|
||||
<title>Days 7 to 8, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,52 +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="operator-network-node">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Network Node</title>
|
||||
<section xml:id="operator-network-node-morning-schedule">
|
||||
<title>Days 7 to 8, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-networking-in-openstack">
|
||||
<title>Review Associate Networking in OpenStack</title>
|
||||
<xi:include href="../common/section_networking-in-openstack.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-openstack-networking-concepts">
|
||||
<title>Review Associate OpenStack Networking Concepts</title>
|
||||
<xi:include href="../common/section_openstack-networking-concepts.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_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="operator-network-node-administration-tasks">
|
||||
<title>Review Associate Administration Tasks</title>
|
||||
<para>TBD</para>
|
||||
</section>
|
||||
<section xml:id="operator-openstack-networking-use-cases">
|
||||
<title>Operator OpenStack Neutron Use Cases</title>
|
||||
<xi:include href="../common/section_neutron-use-cases.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_neutron-use-cases']/*[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="operator-openstack-networking-security">
|
||||
<title>Operator OpenStack Neutron Security</title>
|
||||
<xi:include href="../common/section_security-in-neutron.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_security-in-neutron']/*[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="operator-openstack-networking-floating-ips">
|
||||
<title>Operator OpenStack Neutron Floating IPs</title>
|
||||
<xi:include href="../common/section_floating-ips.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_floating-ips']/*[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>
|
||||
@ -1,39 +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="operator-object-storage-node-lab">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Object Storage Node Lab</title>
|
||||
<section xml:id="operator-object-storage-node-lab-schedule">
|
||||
<title>Day 9, 13:30 to 14:45, 15:00 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<section xml:id="operator-object-lab-getting-started">
|
||||
<title>Installing Object Node</title>
|
||||
<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>
|
||||
</section>
|
||||
<section xml:id="operator-object-lab-configuring-nodes">
|
||||
<title>Configuring Object Node</title>
|
||||
<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>
|
||||
</section>
|
||||
<section xml:id="operator-object-lab-configuring-proxy">
|
||||
<title>Configuring Object Proxy</title>
|
||||
<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>
|
||||
</section>
|
||||
<section xml:id="operator-object-lab-start-nodes">
|
||||
<title>Start Object Node Services</title>
|
||||
<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>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -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="operator-object-storage-node-quiz">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Object Storage Node Quiz</title>
|
||||
<section xml:id="operator-object-storage-quiz-schedule">
|
||||
<title>Day 9, 16:40 to 17:00</title>
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@ -1,36 +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="operator-object-storage-node">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>Object Storage Node</title>
|
||||
<section xml:id="operator-object-node-morning-schedule">
|
||||
<title>Day 9, 09:00 to 11:00, 11:15 to 12:30</title>
|
||||
<para> </para>
|
||||
</section>
|
||||
<section xml:id="operator-intro-object-store">
|
||||
<title>Review Associate Introduction to Object Storage</title>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-intro.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_objectstorage-intro']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-features.xml"/>
|
||||
<section xml:id="operator-object-store-node-administration-tasks">
|
||||
<title>Review Associate Administration Tasks</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-characteristics.xml"/>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-components.xml"/>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-ringbuilder.xml"/>
|
||||
<section xml:id="operator-swift-more-concepts">
|
||||
<title>More Swift Concepts</title>
|
||||
<xi:include href="../common/section_more-concepts.xml"
|
||||
xpointer="xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = 'section_more-concepts']/*[not(self::db:title)])">
|
||||
</xi:include>
|
||||
</section>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-arch.xml"/>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-account-reaper.xml"/>
|
||||
<xi:include href="http://git.openstack.org/cgit/openstack/openstack-manuals/plain/doc/common/section_objectstorage-replication.xml"/>
|
||||
</chapter>
|
||||
@ -1,78 +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="architecture">
|
||||
<title>Architecture</title>
|
||||
<section xml:id="header">
|
||||
<title>Header</title>
|
||||
<para>
|
||||
Copyright 2010-2011 United States Government as represented by the
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
All Rights Reserved.
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
not use this file except in compliance with the License. You may obtain
|
||||
a copy of the License at
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Cinder-System-Architecture">
|
||||
<title>Block Storage System Architecture</title>
|
||||
<para>
|
||||
The OpenStack Block Storage service is intended to run on one or more nodes.
|
||||
Block Storage uses a SQL-based central database that is shared by all Block Storage services in the system. The amount and depth of the data fits into a SQL database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, Block Storage will be moving towards multiple data stores with some kind of aggregation system.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Components">
|
||||
<title>Components</title>
|
||||
<para>
|
||||
Below you will a brief explanation of the different components.
|
||||
/- ( LDAP )
|
||||
[ Auth Manager ] ---
|
||||
| \- ( DB )
|
||||
|
|
||||
|
|
||||
cinderclient |
|
||||
/ \ |
|
||||
[ Web Dashboard ]- -[ API ] -- [ AMQP ] -- [ scheduler ] -- [ volume ] -- ( iSCSI )
|
||||
\ / |
|
||||
novaclient |
|
||||
|
|
||||
|
|
||||
|
|
||||
[ REST ]
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>DB: SQL database for data storage. Used by all
|
||||
components (LINKS NOT SHOWN)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Web Dashboard: potential external component that talks to the
|
||||
API</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>API: component that receives HTTP requests, converts commands
|
||||
and communicates with other components via the queue or HTTP</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Auth Manager: component responsible for users/projects/and
|
||||
roles. Can use as back-end a database or LDAP. This is not a
|
||||
separate binary, but rather a python class that is used by most
|
||||
components in the system.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>scheduler: decides which host gets each volume</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>volume: manages dynamically attachable block devices.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,145 +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="development.environment">
|
||||
<title>Development.Environment</title>
|
||||
<section xml:id="header">
|
||||
<title>Header</title>
|
||||
<para>
|
||||
..
|
||||
Copyright 2010-2011 United States Government as represented by the
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
All Rights Reserved.
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
not use this file except in compliance with the License. You may obtain
|
||||
a copy of the License at
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Setting-Up-a-Development-Environment">
|
||||
<title>Setting-Up-A-Development-Environment</title>
|
||||
<para>
|
||||
====================================
|
||||
This page describes how to setup a working Python development
|
||||
environment that can be used in developing cinder on Ubuntu, Fedora or
|
||||
Mac OS X. These instructions assume you're already familiar with
|
||||
git. Refer to GettingTheCode_ for additional information.
|
||||
.. _GettingTheCode: http://wiki.openstack.org/GettingTheCode
|
||||
Following these instructions will allow you to run the cinder unit
|
||||
tests. If you want to be able to run cinder (i.e., launch VM instances),
|
||||
you will also need to install libvirt and at least one of the
|
||||
`supported hypervisors`_. Running cinder is currently only supported on
|
||||
Linux, although you can run the unit tests on Mac OS X. See
|
||||
:doc:`../quickstart` for how to get a working version of OpenStack
|
||||
Compute running as quickly as possible.
|
||||
.. _supported hypervisors: http://wiki.openstack.org/HypervisorSupportMatrix
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Virtual-environments">
|
||||
<title>Virtual-Environments</title>
|
||||
<para>
|
||||
--------------------
|
||||
Cinder development uses `virtualenv [http://pypi.python.org/pypi/virtualenv]`__ to track and manage Python
|
||||
dependencies while in development and testing. This allows you to
|
||||
install all of the Python package dependencies in a virtual
|
||||
environment or "virtualenv" (a special subdirectory of your cinder
|
||||
directory), instead of installing the packages at the system level.
|
||||
.. note::
|
||||
Virtualenv is useful for running the unit tests, but is not
|
||||
typically used for full integration testing or production usage.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Linux-Systems">
|
||||
<title>Linux-Systems</title>
|
||||
<para>
|
||||
-------------
|
||||
.. note::
|
||||
This section is tested for Cinder on Ubuntu (12.04-64) and
|
||||
Fedora-based (RHEL 6.1) distributions. Feel free to add notes and
|
||||
change according to your experiences or operating system.
|
||||
Install the prerequisite packages.
|
||||
On Ubuntu::
|
||||
sudo apt-get install python-dev libssl-dev python-pip git-core libmysqlclient-dev libpq-dev
|
||||
On Fedora-based distributions like Fedora, RHEL, CentOS and Scientific Linux::
|
||||
sudo yum install python-devel openssl-devel python-pip git libmysqlclient-dev libqp-dev
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Mac-OS-X-Systems">
|
||||
<title>Mac-Os-X-Systems</title>
|
||||
<para>
|
||||
----------------
|
||||
Install virtualenv::
|
||||
sudo easy_install virtualenv
|
||||
Check the version of OpenSSL you have installed::
|
||||
openssl version
|
||||
If you have installed OpenSSL 1.0.0a, which can happen when installing a
|
||||
MacPorts package for OpenSSL, you will see an error when running
|
||||
``cinder.tests.auth_unittest.AuthTestCase.test_209_can_generate_x509``.
|
||||
The stock version of OpenSSL that ships with Mac OS X 10.6 (OpenSSL 0.9.8l)
|
||||
or Mac OS X 10.7 (OpenSSL 0.9.8r) works fine with cinder.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Getting-the-code">
|
||||
<title>Getting-The-Code</title>
|
||||
<para>
|
||||
----------------
|
||||
Grab the code::
|
||||
git clone https://github.com/openstack/cinder.git
|
||||
cd cinder
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Running-unit-tests">
|
||||
<title>Running-Unit-Tests</title>
|
||||
<para>
|
||||
------------------
|
||||
The unit tests will run by default inside a virtualenv in the ``.venv``
|
||||
directory. Run the unit tests by doing::
|
||||
./run_tests.sh
|
||||
The first time you run them, you will be asked if you want to create a virtual
|
||||
environment (hit "y")::
|
||||
No virtual environment found...create one? (Y/n)
|
||||
See :doc:`unit_tests` for more details.
|
||||
.. _virtualenv:
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Manually-installing-and-using-the-virtualenv">
|
||||
<title>Manually-Installing-And-Using-The-Virtualenv</title>
|
||||
<para>
|
||||
--------------------------------------------
|
||||
You can manually install the virtual environment instead of having
|
||||
``run_tests.sh`` do it for you::
|
||||
python tools/install_venv.py
|
||||
This will install all of the Python packages listed in the
|
||||
``requirements.txt`` file into your virtualenv. There will also be some
|
||||
additional packages (pip, setuptools) that are installed
|
||||
by the ``tools/install_venv.py`` file into the virutalenv.
|
||||
If all goes well, you should get a message something like this::
|
||||
Cinder development environment setup is complete.
|
||||
To activate the Cinder virtualenv for the extent of your current shell session
|
||||
you can run::
|
||||
$ source .venv/bin/activate
|
||||
Or, if you prefer, you can run commands in the virtualenv on a case by case
|
||||
basis by running::
|
||||
$ tools/with_venv.sh [your command]
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Contributing-Your-Work">
|
||||
<title>Contributing-Your-Work</title>
|
||||
<para>
|
||||
----------------------
|
||||
Once your work is complete you may wish to contribute it to the project. Add
|
||||
your name and email address to the ``Authors`` file, and also to the ``.mailmap``
|
||||
file if you use multiple email addresses. Your contributions can not be merged
|
||||
into trunk unless you are listed in the Authors file. Cinder uses the Gerrit
|
||||
code review system. For information on how to submit your branch to Gerrit,
|
||||
see GerritWorkflow_.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,113 +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="drivers">
|
||||
<title>Drivers</title>
|
||||
<!--<section xml:id="header">
|
||||
<title>Header</title>
|
||||
<para>
|
||||
..
|
||||
Copyright (c) 2013 OpenStack Foundation
|
||||
All Rights Reserved.
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
not use this file except in compliance with the License. You may obtain
|
||||
a copy of the License at
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Drivers">
|
||||
<title>Drivers</title>-->
|
||||
<para>Cinder exposes an API to enable users to interact with
|
||||
different storage back-end solutions. The following standards are
|
||||
required across all drivers for Cinder services to properly
|
||||
interact with a driver.</para>
|
||||
<para>Minimum features are enforced to avoid having a grid of which
|
||||
features are supported by which drivers in which releases. Cinder
|
||||
core requires that all drivers implement the following minimum
|
||||
features.</para>
|
||||
<section xml:id="havana">
|
||||
<title>Havana</title>
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Volume Create/Delete</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Volume Attach/Detach</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Snapshot Create/Delete</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Create Volume from Snapshot</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Get Volume Stats</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Copy Image to Volume</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Copy Volume to Image</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Clone Volume</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Icehouse">
|
||||
<title>Icehouse</title>
|
||||
<para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>All of the above plus</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Extend Volume</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Volume-Stats">
|
||||
<title>Volume-Stats</title>
|
||||
<para>Volume stats are used by the different schedulers for the
|
||||
drivers to provide a report on their current state of the back
|
||||
end. A driver must provide these stats:</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>driver_version</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>free_capacity_gb</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>reserved_percentage</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>storage_protocol</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>total_capacity_gb</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>vendor_name</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>volume_backend_name</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>If the driver cannot provide a value for
|
||||
<literal>free_capacity_gb</literal> or
|
||||
<literal>total_capacity_gb</literal>, the driver can provide
|
||||
keywords instead. If the array cannot report the value, use
|
||||
<literal>unknown</literal>. If the array has no upper limit,
|
||||
use <literal>infinite</literal>.</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,65 +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="threading">
|
||||
<title>Threading</title>
|
||||
<section xml:id="header">
|
||||
<title>Header</title>
|
||||
<para>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Threading-model">
|
||||
<title>Threading-Model</title>
|
||||
<para>
|
||||
===============
|
||||
<itemizedlist>
|
||||
<listitem><para>model of threading, implemented</para></listitem>
|
||||
</itemizedlist>
|
||||
through using the Python `eventlet [http://eventlet.net/]`_ and
|
||||
`greenlet [http://packages.python.org/greenlet/]`_ libraries.
|
||||
Green threads use a cooperative model of threading: thread context
|
||||
switches can only occur when specific eventlet or greenlet library calls are
|
||||
made. For example, sleep and certain I/O calls. From the operating system's point of
|
||||
view, each OpenStack service runs in a single thread.
|
||||
The use of green threads reduces the likelihood of race conditions, but does
|
||||
not completely eliminate them. In some cases, you may need to use the
|
||||
``@utils.synchronized(...)`` decorator to avoid races.
|
||||
In addition, since there is only one operating system thread, a call that
|
||||
blocks that main thread will block the entire process.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Yielding-the-thread-in-long-running-tasks">
|
||||
<title>Yielding-The-Thread-In-Long-Running-Tasks</title>
|
||||
<para>
|
||||
-----------------------------------------
|
||||
If a code path takes a long time to execute and does not contain any methods
|
||||
that trigger an eventlet context switch, the long-running thread will block
|
||||
any pending threads.
|
||||
This scenario can be avoided by adding calls to the eventlet sleep method
|
||||
in the long-running code path. The sleep call will trigger a context switch
|
||||
if there are pending threads, and using an argument of 0 will avoid introducing
|
||||
delays in the case that there is only a single green thread::
|
||||
from eventlet import greenthread
|
||||
...
|
||||
greenthread.sleep(0)
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="MySQL-access-and-eventlet">
|
||||
<title>Mysql-Access-And-Eventlet</title>
|
||||
<para>
|
||||
-------------------------
|
||||
Queries to the MySQL database will block the main thread of a service. This is
|
||||
because OpenStack services use an external C library for accessing the MySQL
|
||||
database. Since eventlet cannot use monkey-patching to intercept blocking
|
||||
calls in a C library, the resulting database query blocks the thread.
|
||||
The Diablo release contained a thread-pooling implementation that did not
|
||||
block, but this implementation resulted in a `bug`_ and was removed.
|
||||
See this `mailing list thread`_ for a discussion of this issue, including
|
||||
a discussion of the `impact on performance`_.
|
||||
.. _bug: https://bugs.launchpad.net/cinder/+bug/838581
|
||||
.. _mailing list thread: https://lists.launchpad.net/openstack/msg08118.html
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,149 +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="unit_tests">
|
||||
<title>Unit_Tests</title>
|
||||
<section xml:id="header">
|
||||
<title>Header</title>
|
||||
<para>
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Unit-Tests">
|
||||
<title>Unit-Tests</title>
|
||||
<para>
|
||||
==========
|
||||
Cinder contains a suite of unit tests, in the cinder/tests directory.
|
||||
Any proposed code change will be automatically rejected by the OpenStack
|
||||
Jenkins server [#f1]_ if the change causes unit test failures.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Running-the-tests">
|
||||
<title>Running-The-Tests</title>
|
||||
<para>
|
||||
-----------------
|
||||
Run the unit tests by doing::
|
||||
./run_tests.sh
|
||||
This script is a wrapper around the `nose`_ testrunner and the `pep8`_ checker.
|
||||
.. _nose: http://code.google.com/p/python-nose/
|
||||
.. _pep8: https://github.com/jcrocholl/pep8
|
||||
Flags
|
||||
-----
|
||||
The ``run_tests.sh`` script supports several flags. You can view a list of
|
||||
flags by doing::
|
||||
run_tests.sh -h
|
||||
This will show the following help information::
|
||||
Usage: ./run_tests.sh [OPTION]...
|
||||
Run Cinder's test suite(s)
|
||||
-V, --virtual-env Always use virtualenv. Install automatically if not present
|
||||
-N, --no-virtual-env Don't use virtualenv. Run tests in local environment
|
||||
-s, --no-site-packages Isolate the virtualenv from the global Python environment
|
||||
-r, --recreate-db Recreate the test database (deprecated, as this is now the default).
|
||||
-n, --no-recreate-db Don't recreate the test database.
|
||||
-x, --stop Stop running tests after the first error or failure.
|
||||
-f, --force Force a clean re-build of the virtual environment. Useful when dependencies have been added.
|
||||
-p, --pep8 Just run pep8
|
||||
-P, --no-pep8 Don't run pep8
|
||||
-c, --coverage Generate coverage report
|
||||
-h, --help Print this usage message
|
||||
--hide-elapsed Don't print the elapsed time for each test along with slow test list
|
||||
Because ``run_tests.sh`` is a wrapper around nose, it also accepts the same
|
||||
flags as nosetests. See the `nose options documentation`_ for details about
|
||||
these additional flags.
|
||||
.. _nose options documentation: http://readthedocs.org/docs/nose/en/latest/usage.html#options
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Running-a-subset-of-tests">
|
||||
<title>Running-A-Subset-Of-Tests</title>
|
||||
<para>
|
||||
-------------------------
|
||||
Instead of running all tests, you can specify an individual directory, file,
|
||||
class, or method that contains test code.
|
||||
To run the tests in the ``cinder/tests/scheduler`` directory::
|
||||
./run_tests.sh scheduler
|
||||
To run the tests in the ``cinder/tests/test_libvirt.py`` file::
|
||||
./run_tests.sh test_libvirt
|
||||
To run the tests in the `HostStateTestCase` class in
|
||||
``cinder/tests/test_libvirt.py``::
|
||||
./run_tests.sh test_libvirt:HostStateTestCase
|
||||
To run the `ToPrimitiveTestCase.test_dict` test method in
|
||||
``cinder/tests/test_utils.py``::
|
||||
./run_tests.sh test_utils:ToPrimitiveTestCase.test_dict
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Suppressing-logging-output-when-tests-fail">
|
||||
<title>Suppressing-Logging-Output-When-Tests-Fail</title>
|
||||
<para>
|
||||
------------------------------------------
|
||||
By default, when one or more unit test fails, all of the data sent to the
|
||||
logger during the failed tests will appear on standard output, which typically
|
||||
consists of many lines of text. The logging output can make it difficult to
|
||||
identify which specific tests have failed, unless your terminal has a large
|
||||
scrollback buffer or you have redirected output to a file.
|
||||
You can suppress the logging output by calling ``run_tests.sh`` with the nose
|
||||
flag::
|
||||
--nologcapture
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Virtualenv">
|
||||
<title>Virtualenv</title>
|
||||
<para>
|
||||
----------
|
||||
By default, the tests use the Python packages installed inside a
|
||||
virtualenv [#f2]_. (This is equivalent to using the ``-V, --virtualenv`` flag).
|
||||
If the virtualenv does not exist, it will be created the first time the tests are run.
|
||||
If you wish to recreate the virtualenv, call ``run_tests.sh`` with the flag::
|
||||
-f, --force
|
||||
Recreating the virtualenv is useful if the package dependencies have changed
|
||||
since the virtualenv was last created. If the ``requirements.txt`` or
|
||||
``tools/install_venv.py`` files have changed, it's a good idea to recreate the
|
||||
virtualenv.
|
||||
By default, the unit tests will see both the packages in the virtualenv and
|
||||
the packages that have been installed in the Python global environment. In
|
||||
some cases, the packages in the Python global environment may cause a conflict
|
||||
with the packages in the virtualenv. If this occurs, you can isolate the
|
||||
virtualenv from the global environment by using the flag::
|
||||
-s, --no-site packages
|
||||
If you do not wish to use a virtualenv at all, use the flag::
|
||||
-N, --no-virtual-env
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Database">
|
||||
<title>Database</title>
|
||||
<para>
|
||||
--------
|
||||
Some of the unit tests make queries against a SQLite database [#f3]_. By
|
||||
default, the test database (``tests.sqlite``) is deleted and recreated each
|
||||
time ``run_tests.sh`` is invoked (This is equivalent to using the
|
||||
``-r, --recreate-db`` flag). To reduce testing time if a database already
|
||||
exists it can be reused by using the flag::
|
||||
-n, --no-recreate-db
|
||||
Reusing an existing database may cause tests to fail if the schema has
|
||||
changed. If any files in the ``cinder/db/sqlalchemy`` have changed, it's a good
|
||||
idea to recreate the test database.
|
||||
</para>
|
||||
</section>
|
||||
<section xml:id="Gotchas">
|
||||
<title>Gotchas</title>
|
||||
<para>
|
||||
-------
|
||||
<itemizedlist>
|
||||
<listitem><para></para></listitem>
|
||||
</itemizedlist>
|
||||
If you are running the unit tests from a shared folder, you may see tests start
|
||||
to fail or stop completely as a result of Python lockfile issues [#f4]_. You
|
||||
can get around this by manually setting or updating the following line in
|
||||
``cinder/tests/conf_fixture.py``::
|
||||
CONF['lock_path'].SetDefault('/tmp')
|
||||
Note that you may use any location (not just ``/tmp``!) as long as it is not
|
||||
a shared folder.
|
||||
.. rubric:: Footnotes
|
||||
.. [#f1] See :doc:`jenkins`.
|
||||
.. [#f2] See :doc:`development.environment` for more details about the use of
|
||||
virtualenv.
|
||||
.. [#f3] There is an effort underway to use a fake DB implementation for the
|
||||
unit tests. See https://lists.launchpad.net/openstack/msg05604.html
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@ -1,220 +0,0 @@
|
||||
# Copyright 2013 Yahoo! Inc. All Rights Reserved
|
||||
# Copyright 2013 OpenStack Foundation
|
||||
# Copyright 2010 United States Government as represented by the
|
||||
# Administrator of the National Aeronautics and Space Administration.
|
||||
# All Rights Reserved.
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
# not use this file except in compliance with the License. You may obtain
|
||||
# a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
# License for the specific language governing permissions and limitations
|
||||
# under the License.
|
||||
|
||||
|
||||
'''
|
||||
The code must executed within ./openstack-manuals/doc/training-manuals/sources/.
|
||||
The code will automagically create the 7 'core' openstack repositories and convert the
|
||||
rst docs to xml.
|
||||
'''
|
||||
|
||||
|
||||
import os
|
||||
import re
|
||||
import sys
|
||||
|
||||
def create_repo(directory):
|
||||
#clone remote to local repo root, ignore error if exist
|
||||
for x in directory:
|
||||
os.system("git clone https://git.openstack.org/openstack/" + x + ".git")
|
||||
|
||||
|
||||
def pull_repo_updates(directory):
|
||||
#pull remote repo updates
|
||||
for x in directory:
|
||||
os.chdir("./" + x)
|
||||
os.system("git pull origin master")
|
||||
os.chdir("../")
|
||||
|
||||
|
||||
def patternmatch(directory, docs_location, rstfile):
|
||||
#simple pattern matching source rst to output docbook5.0 xml
|
||||
good_file = {"addmethod.openstackapi", "architecture",
|
||||
"development.environment", "drivers", "threading", "unit_tests"}
|
||||
try:
|
||||
#open the file to convert
|
||||
infile = open(directory + docs_location + rstfile)
|
||||
except IOError:
|
||||
#if file is a directory then recurse
|
||||
print("patternmatch:in IOError:directory:" + directory + ", docs_location: " + docs_location + ", rstfile: " + rstfile)
|
||||
os.mkdir(os.path.expanduser("./openstack-manuals/doc/training-guides/sources/" + directory + rstfile))
|
||||
walkdirectories(directory + docs_location, rstfile +"/")
|
||||
#docs_location and rstfile are both directories in this case
|
||||
return
|
||||
outfilenamepart = infile.name.split(".rst")
|
||||
outfilename = outfilenamepart[0].split("/")
|
||||
matchslash = re.search(r'(.*/.*/.*/.*)', directory)
|
||||
if matchslash:
|
||||
#if recursion match is good
|
||||
print("patternmatch:matchslash:directory:" + directory + ", docs_location: " + docs_location + ", rstfile: " + rstfile)
|
||||
try:
|
||||
if outfilenamepart[-1]:
|
||||
#TODO if not rst file, then copy image files
|
||||
return
|
||||
except:
|
||||
pass
|
||||
directory = directory.split("/")
|
||||
good_file_found = "false"
|
||||
for filename in good_file:
|
||||
#check for good file name, else skip to next file
|
||||
if filename == outfilename[-1]:
|
||||
good_file_found = "true"
|
||||
continue
|
||||
if good_file_found == "false":
|
||||
#jump out of called routine
|
||||
return
|
||||
outfile = open("./openstack-manuals/doc/training-guides/sources/" +
|
||||
directory[0] + "/" + docs_location + outfilename[-1] + ".xml", "w+")
|
||||
print(directory[0] + "/" + docs_location + outfilename[-1] + ".xml")
|
||||
else:
|
||||
print("patternmatch:not matchslash:directory:" + directory + ", docs_location: " + docs_location + ", rstfile: " + rstfile)
|
||||
try:
|
||||
if outfilenamepart[-1]:
|
||||
#TODO if not rst file, then copy image files
|
||||
#createfile(directory, docs_location, outfilename)
|
||||
return
|
||||
except:
|
||||
pass
|
||||
good_file_found = "false"
|
||||
for filename in good_file:
|
||||
#check for good file name, else skip to next file
|
||||
if filename == outfilename[-1]:
|
||||
good_file_found = "true"
|
||||
continue
|
||||
if good_file_found == "false":
|
||||
#jump out of called routine
|
||||
return
|
||||
outfile = open("./openstack-manuals/doc/training-guides/sources/" +
|
||||
directory + outfilename[-1] + ".xml", "w+")
|
||||
print(directory + outfilename[-1] + ".xml")
|
||||
#header of new xml file
|
||||
outfile.write("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n")
|
||||
outfile.write(" <section xmlns=\"http://docbook.org/ns/docbook\"\n")
|
||||
outfile.write(" xmlns:xi=\"http://www.w3.org/2001/XInclude\"\n")
|
||||
outfile.write(" xmlns:xlink=\"http://www.w3.org/1999/xlink\"\n")
|
||||
outfile.write(" version=\"5.0\"\n")
|
||||
#xml_section_name = outfilename.replace(" ", "-")
|
||||
outfile.write(" xml:id=\"" + outfilename[-1] + "\">\n")
|
||||
outfile.write("<title>" + outfilename[-1].title() + "</title>\n")
|
||||
#start header
|
||||
xml_section_name = "header"
|
||||
outfile.write("<section xml:id=\"" + xml_section_name.strip() + "\">\n")
|
||||
outfile.write("<title>" + xml_section_name.title() + "</title>\n")
|
||||
outfile.write("<para>\n")
|
||||
#always read two lines at a time, once pattern match on multiple char, previous line is section id and title
|
||||
prevline = "empty"
|
||||
startitemizedlist = 0
|
||||
for line in infile:
|
||||
#match single line ahead for section titles
|
||||
match1 = re.search(r'(.*)(=======)(.*)', line)
|
||||
match2 = re.search(r'(.*)(-------)(.*)', line)
|
||||
match3 = re.search(r'(.*)(~~~~~~~)(.*)', line)
|
||||
match4 = re.search(r'(\s*)(\*\s)(.*)', prevline)
|
||||
match5 = re.search(r'(\s*)(\*\s)(.*)', line)
|
||||
#ignoring orderedlists for now
|
||||
#match6 = re.search(r'(\s*)([0-9]\.\s)(.*)', prevline)
|
||||
#match7 = re.search(r'(\s*)([0-9]\.\s)(.*)', line)
|
||||
if match1 or match2 or match3:
|
||||
#close previous para and section
|
||||
outfile.write("</para>\n")
|
||||
outfile.write("</section>\n")
|
||||
#start new section and para
|
||||
xml_section_name = prevline.replace(" ", "-")
|
||||
xml_section_name = xml_section_name.replace("\'", "-")
|
||||
xml_section_name = xml_section_name.replace("`", "-")
|
||||
xml_section_name = xml_section_name.replace("\"", "-")
|
||||
xml_section_name = xml_section_name.replace(":", "-")
|
||||
xml_section_name = xml_section_name.replace(",", "-")
|
||||
xml_section_name = xml_section_name.replace("(", "-")
|
||||
xml_section_name = xml_section_name.replace(")", "-")
|
||||
outfile.write("<section xml:id=\"" + xml_section_name.strip() + "\">\n")
|
||||
outfile.write("<title>" + xml_section_name.strip().title() + "</title>\n")
|
||||
outfile.write("<para>\n")
|
||||
elif not match4 and match5:
|
||||
#start itemizedlist
|
||||
startitemizedlist = 1
|
||||
outfile.write("<itemizedlist>\n")
|
||||
listitem = match5.group(3).replace("<","[")
|
||||
listitem = listitem.replace(">","]")
|
||||
listitem = listitem.replace("&","-")
|
||||
outfile.write("<listitem><para>" + listitem + "</para></listitem>\n")
|
||||
elif match4 and match5:
|
||||
#continue itemizedlist
|
||||
listitem = match5.group(3).replace("<","[")
|
||||
listitem = listitem.replace(">","]")
|
||||
listitem = listitem.replace("&","-")
|
||||
outfile.write("<listitem><para>" + listitem + "</para></listitem>\n")
|
||||
elif match4 and not match5:
|
||||
#close itemizedlist
|
||||
startitemizedlist = 0
|
||||
outfile.write("</itemizedlist>\n")
|
||||
elif prevline != "empty" and not prevline.isspace():
|
||||
#no match, so inside section and para
|
||||
prevline = prevline.replace("<","[")
|
||||
prevline = prevline.replace(">","]")
|
||||
prevline = prevline.replace("&","-")
|
||||
outfile.write(prevline)
|
||||
#save previous line for pattern matching
|
||||
prevline = line
|
||||
#catch end of file, missing close itemized list
|
||||
if startitemizedlist == 1:
|
||||
outfile.write("</itemizedlist>\n")
|
||||
#close last para and section
|
||||
outfile.write("</para>\n")
|
||||
outfile.write("</section>\n")
|
||||
outfile.write("</section>")
|
||||
|
||||
|
||||
def walkdirectories(projectdirectory, sourcedirectory):
|
||||
#print("walkdirectories: " + projectdirectory + sourcedirectory)
|
||||
print("walkdirectories:current directory is ")
|
||||
os.system("pwd")
|
||||
for rstfile in os.listdir(projectdirectory + sourcedirectory):
|
||||
#walk files in the directory
|
||||
if rstfile.startswith('.'):
|
||||
#ignore hidden files
|
||||
continue
|
||||
patternmatch(projectdirectory, sourcedirectory, rstfile)
|
||||
|
||||
|
||||
def convert_rst_docbook5(repository_hash):
|
||||
for item in repository_hash:
|
||||
print("convert_rst_docbook5:start convert rst: " + item + repository_hash[item])
|
||||
os.system("rm -R ./openstack-manuals/doc/training-guides/sources/" + item)
|
||||
try:
|
||||
#use try for when the remove directory fails
|
||||
os.mkdir("./openstack-manuals/doc/training-guides/sources/" + item)
|
||||
except OSError:
|
||||
pass
|
||||
walkdirectories(item, repository_hash[item])
|
||||
#os.chdir("../")
|
||||
print("convert_rst_docbook5:completed convert rst: " + item + repository_hash[item])
|
||||
|
||||
|
||||
repository_hash = {'cinder/':"/doc/source/devref/"}
|
||||
'''
|
||||
'nova/':"/doc/source/devref/",
|
||||
'glance/':"/doc/source/",
|
||||
'neutron/':"/doc/source/devref/",
|
||||
'swift/':"/doc/source/",
|
||||
'keystone/':"doc/source/",
|
||||
'horizon/':"/doc/source/"}'''
|
||||
os.chdir("../../../../")#root of repository directories in relation to ./training-guides/sources
|
||||
create_repo(repository_hash)
|
||||
pull_repo_updates(repository_hash)
|
||||
convert_rst_docbook5(repository_hash)
|
||||
@ -1,124 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<set xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
version="5.0"
|
||||
xml:id="st-training-guides">
|
||||
<title>OpenStack Training Guides</title>
|
||||
<?rax title.font.size="28px" subtitle.font.size="28px"?>
|
||||
<?rax
|
||||
status.bar.text.font.size="40px"
|
||||
status.bar.text="Training Guides Icehouse"?>
|
||||
<?rax subtitle.font.size="17px" title.font.size="32px"?>
|
||||
|
||||
<titleabbrev>OpenStack Training Guides</titleabbrev>
|
||||
<info>
|
||||
<copyright>
|
||||
<year>2013</year>
|
||||
<year>2014</year>
|
||||
<holder>OpenStack Foundation</holder>
|
||||
</copyright>
|
||||
<productname>OpenStack Training Guides</productname>
|
||||
<pubdate/>
|
||||
<legalnotice role="apache2">
|
||||
<annotation>
|
||||
<remark>Copyright details are filled in by the
|
||||
template.</remark>
|
||||
</annotation>
|
||||
</legalnotice>
|
||||
<legalnotice role="cc-by-sa">
|
||||
<annotation>
|
||||
<remark>Copyright details are filled in by the
|
||||
template.</remark>
|
||||
</annotation>
|
||||
</legalnotice>
|
||||
<abstract>
|
||||
<para>OpenStack™ Training Guides offer the open source
|
||||
community software training for cloud administration
|
||||
and management for any organization.</para>
|
||||
</abstract>
|
||||
<revhistory>
|
||||
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
|
||||
<revision>
|
||||
<date>2014-12-17</date>
|
||||
<revdescription>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Icehouse released, adds support for automated labs installation.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2014-05-29</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>migrate training guides to separate
|
||||
repository</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2013-11-04</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>major restructure of guides</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2013-09-11</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>first training guides sprint
|
||||
held</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2013-08-07</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>rough draft published to the
|
||||
web</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2013-07-09</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>first draft released</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
<revision>
|
||||
<date>2013-06-18</date>
|
||||
<revdescription>
|
||||
<itemizedlist spacing="compact">
|
||||
<listitem>
|
||||
<para>blueprint created</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</revdescription>
|
||||
</revision>
|
||||
</revhistory>
|
||||
</info>
|
||||
<xi:include href="under-contruction-notice.xml"/>
|
||||
<xi:include href="bk_preface.xml"/>
|
||||
<xi:include href="associate-guide/bk_associate-training-guide.xml"/>
|
||||
<xi:include href="operator-guide/bk_operator-training-guide.xml"/>
|
||||
<xi:include href="developer-guide/bk_developer-training-guide.xml"/>
|
||||
<xi:include href="architect-guide/bk_architect-training-guide.xml"/>
|
||||
</set>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user