openstack/training-guides
Code Issues Proposed changes

clean-up of module001-ch004-openstack-architecture

Browse Source 
Replaced Folsom with Icehouse
Made some minor sentance structure changes
Updated two sections per comments
Closes-Bug #1282197

Change-Id: Ic5c5ca7a366657a4c0ec93fc31f94b7deaebabfd
This commit is contained in:
Megan Rossetti 2014-07-14 15:35:14 -04:00 committed by Pranav Salunke
parent 9a5fd5ee8a
commit 7ae217e764
1 changed files with 6 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/training-guides/common/section_openstack-architecture.xml
View File

@ -152,13 +152,11 @@ as previously described:</para>
</listitem>
<listitem>
<para>nova-volume manages the creation, attaching and
detaching of z volumes to compute instances (similar
functionality to Amazon’s Elastic Block Storage). It can
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. A new OpenStack project,
Cinder, will eventually replace nova-volume functionality.
In the Folsom release, nova-volume and the Block Storage
service will have similar functionality.</para>
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
@ -167,8 +165,7 @@ as previously described:</para>
network (such as setting up bridging interfaces or
changing iptables rules). This functionality is being
migrated to Neutron, a separate OpenStack project. In the
Folsom release, much of the functionality will be
duplicated between nova-network and Neutron.</para>
Icehouse release, the functionality is duplicated between nova-network and Neutron.</para>
</listitem>
<listitem>
<para>The nova-schedule process is conceptually the simplest
@ -181,8 +178,7 @@ as previously described:</para>
<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). New to the Folsom release is support for Zero
MQ.</para>
Qpid and ZeroMQ).</para>
</listitem>
<listitem>
<para>The SQL database stores most of the build-time and