diff --git a/doc/openstack-ops/ch_arch_compute_nodes.xml b/doc/openstack-ops/ch_arch_compute_nodes.xml
index e90f0344..dcbef262 100644
--- a/doc/openstack-ops/ch_arch_compute_nodes.xml
+++ b/doc/openstack-ops/ch_arch_compute_nodes.xml
@@ -169,7 +169,7 @@
     <para>The best information available to support your choice is found on
       the <link xlink:href="http://docs.openstack.org/developer/nova/support-matrix.html"
     xlink:title="reference manual">Hypervisor Support Matrix</link> and in the
-    <link xlink:href="http://docs.openstack.org/juno/config-reference/content/section_compute-hypervisors.html"
+    <link xlink:href="http://docs.openstack.org/liberty/config-reference/content/section_compute-hypervisors.html"
     xlink:title="configuration reference">configuration
     reference</link>.</para>
 
diff --git a/doc/openstack-ops/ch_ops_advanced_configuration.xml b/doc/openstack-ops/ch_ops_advanced_configuration.xml
index 7df689b2..febf572f 100644
--- a/doc/openstack-ops/ch_ops_advanced_configuration.xml
+++ b/doc/openstack-ops/ch_ops_advanced_configuration.xml
@@ -211,10 +211,7 @@
     <section xml:id="adv-config-ipv6">
       <title>Enabling IPv6 Support</title>
 
-      <para>The Havana release with OpenStack Networking (neutron) does not
-      offer complete support of IPv6. Better support has been delivered in the
-      Kilo release, and will continue to improve in Liberty.
-      You can follow along the progress being made by
+      <para>You can follow the progress being made on IPV6 support by
       watching the <link xlink:href="https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam">neutron IPv6
       Subteam at work</link>.<indexterm class="singular">
           <primary>Liberty</primary>
@@ -237,36 +234,18 @@
       enabled cloud”</link>.</para>
     </section>
 
-    <section xml:id="specific-advanced-config-period-tasks">
-      <title>Periodic Task Frequency for Compute</title>
-
-      <para>Before the Grizzly release, the frequency of periodic tasks was
-      specified in seconds between runs. This meant that if the periodic task
-      took 30 minutes to run and the frequency was set to hourly, then the
-      periodic task actually ran every 90 minutes, because the task would wait
-      an hour after running before running again. This changed in Grizzly, and
-      we now time the frequency of periodic tasks from the start of the work
-      the task does. So, our 30 minute periodic task will run every hour, with
-      a 30 minute wait between the end of the first run and the start of the
-      next.<indexterm class="singular">
-          <primary>configuration options</primary>
-
-          <secondary>periodic task frequency</secondary>
-        </indexterm></para>
-    </section>
-
     <section xml:id="adv-config-geography">
       <title>Geographical Considerations for Object Storage</title>
 
-      <para>Enhanced support for global clustering of object storage servers
-      continues to be added since the Grizzly (1.8.0) release, when regions
-      were introduced. You would implement these global clusters to ensure
-      replication across geographic areas in case of a natural disaster and
-      also to ensure that users can write or access their objects more quickly
-      based on the closest data center. You configure a default region with
-      one zone for each cluster, but be sure your network (WAN) can handle the
-      additional request and response load between zones as you add more zones
-      and build a ring that handles more zones. Refer to <link
+      <para>Support for global clustering of object storage servers
+      is available for all supported releases. You would implement these global
+      clusters to ensure replication across geographic areas in case of a
+      natural disaster and also to ensure that users can write or access their
+      objects more quickly based on the closest data center. You configure a
+      default region with one zone for each cluster, but be sure your network
+      (WAN) can handle the additional request and response load between
+      zones as you add more zones and build a ring that handles more zones.
+      Refer to <link
       xlink:href="http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters">Geographically Distributed
       Clusters</link> in the documentation for additional
       information.<indexterm class="singular">
diff --git a/doc/openstack-ops/ch_ops_projects_users.xml b/doc/openstack-ops/ch_ops_projects_users.xml
index 3fbe7262..35f24a92 100644
--- a/doc/openstack-ops/ch_ops_projects_users.xml
+++ b/doc/openstack-ops/ch_ops_projects_users.xml
@@ -178,8 +178,7 @@
     <section xml:id="set_image_quotas">
       <title>Set Image Quotas</title>
 
-      <para>OpenStack Havana introduced a basic quota feature for the Image
-      service, so you can now restrict a project's image storage by total
+      <para>You can restrict a project's image storage by total
       number of bytes. Currently, this quota is applied cloud-wide, so if you
       were to set an Image quota limit of 5 GB, then all projects in your
       cloud will be able to store only 5 GB of images and snapshots.<indexterm
@@ -201,14 +200,12 @@
       <programlisting language="ini">user_storage_quota = 5368709120</programlisting>
 
       <note>
-        <para>In the Icehouse release, there is a configuration option in
+        <para>There is a configuration option in
         <filename>glance-api.conf</filename> that limits the number of members
         allowed per image, called <code>image_member_quota</code>, set to 128
         by default. That setting is a different quota from the storage
         quota.<indexterm class="singular">
-            <primary>Icehouse</primary>
-
-            <secondary>image quotas</secondary>
+            <primary>image quotas</primary>
           </indexterm></para>
       </note>
     </section>
@@ -488,8 +485,7 @@
     <section xml:id="cli_set_object_storage_quotas">
       <title>Set Object Storage Quotas</title>
 
-      <para>Object Storage quotas were introduced in Swift 1.8 (OpenStack
-      Grizzly). There are currently two categories of quotas for Object
+      <para>There are currently two categories of quotas for Object
       Storage:<indexterm class="singular">
           <primary>account quotas</primary>
         </indexterm><indexterm class="singular">