diff --git a/doc/training-guides/common/section_openstack-architecture.xml b/doc/training-guides/common/section_openstack-architecture.xml
index 10e01f4b..1af629e0 100644
--- a/doc/training-guides/common/section_openstack-architecture.xml
+++ b/doc/training-guides/common/section_openstack-architecture.xml
@@ -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