diff --git a/doc/source/index.rst b/doc/source/index.rst
index e58e449..8ff37d8 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -14,6 +14,7 @@ on for the upcoming release. This is the output of those discussions:
    :glob:
    :maxdepth: 1
 
+   priorities/rocky-priorities
    priorities/queens-priorities
    priorities/pike-priorities
    priorities/ocata-priorities
@@ -28,6 +29,7 @@ Here you can find the specs, and spec template, for each release:
    :glob:
    :maxdepth: 1
 
+   specs/rocky/index
    specs/queens/index
    specs/pike/index
    specs/ocata/index
diff --git a/doc/source/specs/queens/approved b/doc/source/specs/queens/approved
deleted file mode 120000
index 01ec4c2..0000000
--- a/doc/source/specs/queens/approved
+++ /dev/null
@@ -1 +0,0 @@
-../../../../specs/queens/approved
\ No newline at end of file
diff --git a/doc/source/specs/queens/backlog b/doc/source/specs/queens/backlog
deleted file mode 120000
index b7c6c52..0000000
--- a/doc/source/specs/queens/backlog
+++ /dev/null
@@ -1 +0,0 @@
-../../../../specs/queens/backlog/
\ No newline at end of file
diff --git a/doc/source/specs/rocky/approved b/doc/source/specs/rocky/approved
new file mode 120000
index 0000000..d06bcef
--- /dev/null
+++ b/doc/source/specs/rocky/approved
@@ -0,0 +1 @@
+../../../../specs/rocky/approved
\ No newline at end of file
diff --git a/doc/source/specs/rocky/backlog b/doc/source/specs/rocky/backlog
new file mode 120000
index 0000000..fcc991d
--- /dev/null
+++ b/doc/source/specs/rocky/backlog
@@ -0,0 +1 @@
+../../../../specs/rocky/backlog
\ No newline at end of file
diff --git a/doc/source/specs/rocky/index.rst b/doc/source/specs/rocky/index.rst
new file mode 100644
index 0000000..6ee8873
--- /dev/null
+++ b/doc/source/specs/rocky/index.rst
@@ -0,0 +1,34 @@
+===========================
+Charm Rocky Specifications
+===========================
+
+Template:
+
+.. toctree::
+   :maxdepth: 1
+
+   Specification Template (Rocky release) <template>
+
+Rocky implemented specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   implemented/*
+
+Rocky approved (but not implemented) specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   approved/*
+
+Rocky backlog (carried over from previous cycle) specs:
+
+.. toctree::
+   :glob:
+   :maxdepth: 1
+
+   backlog/*
diff --git a/specs/queens/approved/ceph-charm-migration.rst b/specs/queens/implemented/ceph-charm-migration.rst
similarity index 100%
rename from specs/queens/approved/ceph-charm-migration.rst
rename to specs/queens/implemented/ceph-charm-migration.rst
diff --git a/specs/queens/approved/designate-neutron.rst b/specs/queens/implemented/designate-neutron.rst
similarity index 100%
rename from specs/queens/approved/designate-neutron.rst
rename to specs/queens/implemented/designate-neutron.rst
diff --git a/specs/queens/approved/charm-panko.rst b/specs/rocky/approved/charm-panko.rst
similarity index 100%
rename from specs/queens/approved/charm-panko.rst
rename to specs/rocky/approved/charm-panko.rst
diff --git a/specs/queens/approved/controlled-service-restarts.rst b/specs/rocky/approved/controlled-service-restarts.rst
similarity index 100%
rename from specs/queens/approved/controlled-service-restarts.rst
rename to specs/rocky/approved/controlled-service-restarts.rst
diff --git a/specs/queens/approved/keystone-federation.rst b/specs/rocky/approved/keystone-federation.rst
similarity index 100%
rename from specs/queens/approved/keystone-federation.rst
rename to specs/rocky/approved/keystone-federation.rst
diff --git a/specs/queens/approved/keystone-preferred-api-v3-as-default.rst b/specs/rocky/approved/keystone-preferred-api-v3-as-default.rst
similarity index 100%
rename from specs/queens/approved/keystone-preferred-api-v3-as-default.rst
rename to specs/rocky/approved/keystone-preferred-api-v3-as-default.rst
diff --git a/specs/queens/approved/neutron-dynamic-routing.rst b/specs/rocky/approved/neutron-dynamic-routing.rst
similarity index 97%
rename from specs/queens/approved/neutron-dynamic-routing.rst
rename to specs/rocky/approved/neutron-dynamic-routing.rst
index 7002f28..bc7e6e0 100644
--- a/specs/queens/approved/neutron-dynamic-routing.rst
+++ b/specs/rocky/approved/neutron-dynamic-routing.rst
@@ -33,9 +33,9 @@ ways, a way of communicating changes between OpenStack and external routers is
 needed.
 
 Since networks in OpenStack are self serviced, any addition or removal of
-OpenStack network should not depend on network administrator’s actions. Network
-limitations should be set up front. This is further facilitated by the use of
-subnet pools in OpenStack.
+OpenStack network should not depend on network administrator’s actions.
+Network limitations should be set up front. This is further facilitated by
+the use of subnet pools in OpenStack.
 
 Other implications include decoupling subnets from layer 2, allowing different
 next-hops for floating IPs.
@@ -101,8 +101,8 @@ number of connections grows. In cloud, where many VMs can establish connections
 to various external peers, this can require significant memory and cpu
 resources. Neutron gateway doesn't really scale without manual intervention. On
 top of that, if only NAT is used, peers can’t really know which instance
-established connection, they only know connection came ‘from the cloud’. Same
-problems apply to DVR.
+established connection, they only know connection came ‘from the cloud’.
+Same problems apply to DVR.
 
 Static routes on physical gateways are the closest thing to BGP solution. The
 only drawback is operational; in case address scope in Neutron changes, these
diff --git a/specs/queens/approved/routed-provider-networks-neutron-charms.rst b/specs/rocky/approved/routed-provider-networks-neutron-charms.rst
similarity index 73%
rename from specs/queens/approved/routed-provider-networks-neutron-charms.rst
rename to specs/rocky/approved/routed-provider-networks-neutron-charms.rst
index 27249d9..994f6f9 100644
--- a/specs/queens/approved/routed-provider-networks-neutron-charms.rst
+++ b/specs/rocky/approved/routed-provider-networks-neutron-charms.rst
@@ -12,9 +12,9 @@
   http://sphinx-doc.org/rest.html To test out your formatting, see
   http://www.tele3.cz/jbar/rest/rest.html
 
-===============================
+===========================================
 Routed Provider Networks for Neutron Charms
-===============================
+===========================================
 
 As L3-oriented fabrics get more widely deployed in DCs there is a need to
 support multi-segment networks in Neutron charms. Routed provider networks
@@ -32,7 +32,7 @@ define isolated broadcast domains and should have different subnets
 used on them for proper addressing and routing to be implemented.
 
 Provider Networks in Neutron used to have a single segment but starting with
-`Newton <https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html>`__ 
+`Newton <https://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html>`__
 there is support for multi-segment networks which are called routed provider
 networks. From the data model perspective a subnet is associated with a
 network segment and a given provider network becomes multi-segment as a
@@ -76,7 +76,7 @@ Also, from the Charm and Juju perspective the following needs to be addressed:
 * Appropriate placement of units to make sure necessary agents are deployed.
 
 Deployment Scenarios
-+++++++++++++++++++++++
+--------------------
 
 Deployment scenarios should include both setups with charm-neutron-gateway and
 without it. Moreover, for the use-case where charm neutron-gateway is present
@@ -95,9 +95,9 @@ Given that there are certain limitations in how routed provider networks are
 implemented in Newton release this spec is targeted at Ocata release.
 
 Segments Service Plugin
-+++++++++++++++++++++++
+-----------------------
 
-`A related Ocata documentation section <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html#example-configuration>`__ contains 3 major configuration requirements: 
+`A related Ocata documentation section <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html#example-configuration>`__ contains 3 major configuration requirements:
 
 * "segments" needs to be added to the service_plugins list (neutron-api);
 * A compute placement API section needs to be added to neutron.conf;
@@ -129,7 +129,7 @@ This distiction is what allows unconditional addition of this service plugin
 for the standard ML2 core plugin.
 
 Multiple L2 Networks (Switch Fabrics)
-+++++++++++++++++++++++
+-------------------------------------
 
 Each network segment includes `network type information <https://github.com/openstack/neutron/blob/3e34db0c19cdcc86cd5f1b72d6374c3eca0faa7e/neutron/db/models/segment.py#L30-L54>`__ this means that for ML2 plugin flat_networks and network_vlan_ranges
 options there may be different values depending on a switch fabric. In this
@@ -159,125 +159,127 @@ connected to will have identical configuration, we need to account for a
 general case.
 
 Multi-application approach allows to avoid any charm modifications besides
-charm-neutron-api and have the following content in bundle.yaml::
+charm-neutron-api and have the following content in bundle.yaml:
 
-        variables:
-          data-port:           &data-port           br-data:bond1
-          vlan-ranges:         &vlan-ranges         provider-fab1:2:3 provider-fab2:4:5 provider-fab3:6:7
-          bridge-mappings-fab1: &bridge-mappings-fab1 provider-fab1:br-data
-          bridge-mappings-fab2: &bridge-mappings-fab2 provider-fab2:br-data
-          bridge-mappings-fab3: &bridge-mappings-fab3 provider-fab3:br-data
-          vlan-ranges-fab1:     &vlan-ranges-fab1     provider-fab1:2:3
-          vlan-ranges-fab2:     &vlan-ranges-fab2     provider-fab2:4:5
-          vlan-ranges-fab3:     &vlan-ranges-fab3     provider-fab3:6:7
+.. code-block:: yaml
 
-        # allocate machines such that there are enough
-        # machines in attached to each switch fabric
-        # fabrics do not necessarily correspond to
-        # availability zones
-        machines:
-          "0":
-            constraints: tags=compute,fab1
-          "1":
-            constraints: tags=compute,fab1
-          "2":
-            constraints: tags=compute,fab1
-          "3":
-            constraints: tags=compute,fab1
-          "4":
-            constraints: tags=compute,fab1
-          "5":
-            constraints: tags=compute,fab2
-          "6":
-            constraints: tags=compute,fab2
-          "7":
-            constraints: tags=compute,fab2
-          "8":
-            constraints: tags=compute,fab2
-          "9":
-            constraints: tags=compute,fab3
-          "10":
-            constraints: tags=compute,fab3
-          "11":
-            constraints: tags=compute,fab3
-          "12":
-            constraints: tags=compute,fab3
-        services:
-          nova-compute-kvm-fab1:
-            charm: cs:nova-compute
-            num_units: 5
-            bindings:
-            # ...
-            options:
-            # ...
-              default-availability-zone: az1
-            to:
-            - 0
-            - 1
-            - 2
-            - 3
-            - 4
-          nova-compute-kvm-fab2:
-            charm: cs:nova-compute
-            num_units: 5
-            bindings:
-            # ...
-            options:
-            # ...
-              default-availability-zone: az2
-            to:
-            - 5
-            - 6
-            - 7
-            - 8
-          nova-compute-kvm-fab3:
-            charm: cs:nova-compute
-            num_units: 5
-            bindings:
-            # ...
-            options:
-            # ...
-              default-availability-zone: az3
-            to:
-            - 9
-            - 10
-            - 11
-            - 12
-          neutron-openvswitch-fab1:
-            charm: cs:neutron-openvswitch
-            num_units: 0
-            bindings:
-              data: *overlay-space-fab1
-            options:
-              bridge-mappings: *bridge-mappings-fab1
-              vlan-ranges: *vlan-ranges-fab1
-              prevent-arp-spoofing: True
-              data-port: *data-port
-              enable-local-dhcp-and-metadata: True
-          neutron-openvswitch-fab2:
-            charm: cs:neutron-openvswitch
-            num_units: 0
-            bindings:
-              data: *overlay-space-fab2
-            options:
-              bridge-mappings: *bridge-mappings-fab2
-              vlan-ranges: *vlan-ranges-fab2
-              prevent-arp-spoofing: True
-              data-port: *data-port
-              enable-local-dhcp-and-metadata: True
-          neutron-openvswitch-fab3:
-            charm: cs:neutron-openvswitch
-            num_units: 0
-            bindings:
-              data: *overlay-space-fab3
-            options:
-              bridge-mappings: *bridge-mappings-fab3
-              vlan-ranges: *vlan-ranges-fab3
-              prevent-arp-spoofing: True
-              data-port: *data-port
-              enable-local-dhcp-and-metadata: True
-        # each of the apps needs to be related appropriately
+   variables:
+      data-port:           &data-port           br-data:bond1
+      vlan-ranges:         &vlan-ranges         provider-fab1:2:3 provider-fab2:4:5 provider-fab3:6:7
+      bridge-mappings-fab1: &bridge-mappings-fab1 provider-fab1:br-data
+      bridge-mappings-fab2: &bridge-mappings-fab2 provider-fab2:br-data
+      bridge-mappings-fab3: &bridge-mappings-fab3 provider-fab3:br-data
+      vlan-ranges-fab1:     &vlan-ranges-fab1     provider-fab1:2:3
+      vlan-ranges-fab2:     &vlan-ranges-fab2     provider-fab2:4:5
+      vlan-ranges-fab3:     &vlan-ranges-fab3     provider-fab3:6:7
+
+   # allocate machines such that there are enough
+   # machines in attached to each switch fabric
+   # fabrics do not necessarily correspond to
+   # availability zones
+   machines:
+      "0":
+        constraints: tags=compute,fab1
+      "1":
+        constraints: tags=compute,fab1
+      "2":
+        constraints: tags=compute,fab1
+      "3":
+        constraints: tags=compute,fab1
+      "4":
+        constraints: tags=compute,fab1
+      "5":
+        constraints: tags=compute,fab2
+      "6":
+        constraints: tags=compute,fab2
+      "7":
+        constraints: tags=compute,fab2
+      "8":
+        constraints: tags=compute,fab2
+      "9":
+        constraints: tags=compute,fab3
+      "10":
+        constraints: tags=compute,fab3
+      "11":
+        constraints: tags=compute,fab3
+      "12":
+        constraints: tags=compute,fab3
+    services:
+      nova-compute-kvm-fab1:
+        charm: cs:nova-compute
+        num_units: 5
+        bindings:
         # ...
+        options:
+        # ...
+          default-availability-zone: az1
+        to:
+        - 0
+        - 1
+        - 2
+        - 3
+        - 4
+      nova-compute-kvm-fab2:
+        charm: cs:nova-compute
+        num_units: 5
+        bindings:
+        # ...
+        options:
+        # ...
+          default-availability-zone: az2
+        to:
+        - 5
+        - 6
+        - 7
+        - 8
+      nova-compute-kvm-fab3:
+        charm: cs:nova-compute
+        num_units: 5
+        bindings:
+        # ...
+        options:
+        # ...
+          default-availability-zone: az3
+        to:
+        - 9
+        - 10
+        - 11
+        - 12
+      neutron-openvswitch-fab1:
+        charm: cs:neutron-openvswitch
+        num_units: 0
+        bindings:
+          data: \*overlay-space-fab1
+        options:
+          bridge-mappings: \*bridge-mappings-fab1
+          vlan-ranges: \*vlan-ranges-fab1
+          prevent-arp-spoofing: True
+          data-port: \*data-port
+          enable-local-dhcp-and-metadata: True
+      neutron-openvswitch-fab2:
+        charm: cs:neutron-openvswitch
+        num_units: 0
+        bindings:
+          data: \*overlay-space-fab2
+        options:
+          bridge-mappings: \*bridge-mappings-fab2
+          vlan-ranges: \*vlan-ranges-fab2
+          prevent-arp-spoofing: True
+          data-port: \*data-port
+          enable-local-dhcp-and-metadata: True
+      neutron-openvswitch-fab3:
+        charm: cs:neutron-openvswitch
+        num_units: 0
+        bindings:
+          data: \*overlay-space-fab3
+        options:
+          bridge-mappings: \*bridge-mappings-fab3
+          vlan-ranges: \*vlan-ranges-fab3
+          prevent-arp-spoofing: True
+          data-port: \*data-port
+          enable-local-dhcp-and-metadata: True
+    # each of the apps needs to be related appropriately
+    # ...
 
 The above bundle part is for a setup without charm-neutron-gateway, although
 it can be added easily using the same approach. Given that there are no
@@ -287,7 +289,7 @@ is the infrastructure routing for overlay networks on different fabrics so
 that VXLAN or other tunnels can be created between endpoints.
 
 Documented Requirements and Limitations
-+++++++++++++++++++++++
+---------------------------------------
 
 The Ocata Routed Provider Networks `guide mentions scheduler limitations, <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html#limitations>`__
 however, they are made in reference to Newton and are likely outdated. Looking
@@ -310,6 +312,11 @@ This might be considered a serious limitation, however:
 An `RFE <https://pad.lv/1667329>`__ exists to address this limitation based on
 `subnet service types <https://specs.openstack.org/openstack/neutron-specs/specs/newton/subnet-service-types.html>`__ and `dynamic routing <https://docs.openstack.org/newton/networking-guide/config-bgp-dynamic-routing.html>`__.
 
+Alternatives
+------------
+
+N/A
+
 Implementation
 ==============
 
@@ -327,7 +334,7 @@ to this spec.
 
 .. code-block:: bash
 
-    git-review -t 1743743-fe-routed-provider-networks
+   git-review -t 1743743-fe-routed-provider-networks
 
 Work Items
 ----------
diff --git a/specs/queens/approved/swift-extended-cluster-operations.rst b/specs/rocky/approved/swift-extended-cluster-operations.rst
similarity index 100%
rename from specs/queens/approved/swift-extended-cluster-operations.rst
rename to specs/rocky/approved/swift-extended-cluster-operations.rst
diff --git a/specs/queens/backlog/cells.rst b/specs/rocky/backlog/cells.rst
similarity index 100%
rename from specs/queens/backlog/cells.rst
rename to specs/rocky/backlog/cells.rst
diff --git a/specs/queens/backlog/ceph-storage-action.rst b/specs/rocky/backlog/ceph-storage-action.rst
similarity index 100%
rename from specs/queens/backlog/ceph-storage-action.rst
rename to specs/rocky/backlog/ceph-storage-action.rst
diff --git a/specs/queens/backlog/charm-layering.rst b/specs/rocky/backlog/charm-layering.rst
similarity index 100%
rename from specs/queens/backlog/charm-layering.rst
rename to specs/rocky/backlog/charm-layering.rst
diff --git a/specs/queens/backlog/charm-openstack-ovn.rst b/specs/rocky/backlog/charm-openstack-ovn.rst
similarity index 72%
rename from specs/queens/backlog/charm-openstack-ovn.rst
rename to specs/rocky/backlog/charm-openstack-ovn.rst
index d14850e..e31d50c 100644
--- a/specs/queens/backlog/charm-openstack-ovn.rst
+++ b/specs/rocky/backlog/charm-openstack-ovn.rst
@@ -16,50 +16,62 @@
 OpenStack with OVN
 ===============================
 
-Openstack can be deployed with a number of SDN solutions (e.g. ODL). OVN provides
-virtual-networking for Open vSwitch (OVS). OVN has a lot of desirable features and
-is designed to be integrated into Openstack, among others.
+Openstack can be deployed with a number of SDN solutions (e.g. ODL). OVN
+provides virtual-networking for Open vSwitch (OVS). OVN has a lot of desirable
+features and is designed to be integrated into Openstack, among others.
 
-Since there is already a networking-ovn project under openstack, it is the obvious
-next step to implement a Juju charm that provides this service.
+Since there is already a networking-ovn project under openstack, it is the
+obvious next step to implement a Juju charm that provides this service.
 
 Problem Description
 ===================
 
 Currently, Juju charms have support for deploying openstack, either with it's
 default SDN solution (Neutron), or with others such as ODL. This project
-will expand the deployment scenarios under Juju for openstack by including OVN in the
-list of available SDN solutions.
+will expand the deployment scenarios under Juju for openstack by including OVN
+in the list of available SDN solutions.
 
-This will also benefit OPNFV's JOID installer in providing another scenario in its deployment.
+This will also benefit OPNFV's JOID installer in providing another scenario in
+its deployment.
 
 Proposed Change
 ===============
 
-Charms implementing neutron-api, ovn-controller and neutron-ovn will need to be implemented.
-These will be written using the new reactive framework of Juju.
-
+Charms implementing neutron-api, ovn-controller and neutron-ovn will need to
+be implemented. These will be written using the new reactive framework
+of Juju.
 
 Charm : neutron-ovn
 -------------------
-This charm will be deployed alongside nova-compute deployments. This will be a subordinate
-charm to nova-compute, that installs and runs openvswitch and the ovn-controller.
+
+This charm will be deployed alongside nova-compute deployments. This will be
+a subordinate charm to nova-compute, that installs and runs openvswitch and
+the ovn-controller.
 
 Charm : ovn-controller
 ----------------------
-This charm will deploy ovn itself. It will start the OVN services (ovsdb-server, ovn-northd).
-Since there can only be a single instance of ovsdb-server and ovn-northd in a deployment,
-we can also implement passive HA, but this can be included in further revisions of this charm.
+
+This charm will deploy ovn itself. It will start the OVN services
+(ovsdb-server, ovn-northd). Since there can only be a single instance of
+ovsdb-server and ovn-northd in a deployment, we can also implement passive
+HA, but this can be included in further revisions of this charm.
 
 Charm : neutron-api-ovn
 -----------------------
-This charm will provide the api only integration of neutron to OVN. This charm will need to be
-subordinate to the existing neutron-api charm. The main task of this charm is to setup the
-"neutron.conf" and "ml2_ini.conf" config files with the right parameters for OVN.
-The principal charm, neutron-api, handles the install and restart for neutron-server.
+
+This charm will provide the api only integration of neutron to OVN. This charm
+will need to be subordinate to the existing neutron-api charm. The main task
+of this charm is to setup the "neutron.conf" and "ml2_ini.conf" config files
+with the right parameters for OVN. The principal charm, neutron-api, handles
+the install and restart for neutron-server.
 
 Refer for more information : https://docs.openstack.org/networking-ovn/latest/install/manual.html
 
+Alternatives
+------------
+
+N/A
+
 Implementation
 ==============
 
diff --git a/specs/queens/backlog/keystone-federation.rst b/specs/rocky/backlog/keystone-federation.rst
similarity index 100%
rename from specs/queens/backlog/keystone-federation.rst
rename to specs/rocky/backlog/keystone-federation.rst
diff --git a/specs/queens/backlog/mistral.rst b/specs/rocky/backlog/mistral.rst
similarity index 100%
rename from specs/queens/backlog/mistral.rst
rename to specs/rocky/backlog/mistral.rst
diff --git a/specs/queens/backlog/murano.rst b/specs/rocky/backlog/murano.rst
similarity index 100%
rename from specs/queens/backlog/murano.rst
rename to specs/rocky/backlog/murano.rst
diff --git a/specs/queens/backlog/openstack-load-balancer.rst b/specs/rocky/backlog/openstack-load-balancer.rst
similarity index 100%
rename from specs/queens/backlog/openstack-load-balancer.rst
rename to specs/rocky/backlog/openstack-load-balancer.rst
diff --git a/specs/queens/backlog/service-discovery.rst b/specs/rocky/backlog/service-discovery.rst
similarity index 100%
rename from specs/queens/backlog/service-discovery.rst
rename to specs/rocky/backlog/service-discovery.rst
diff --git a/specs/queens/backlog/trove.rst b/specs/rocky/backlog/trove.rst
similarity index 100%
rename from specs/queens/backlog/trove.rst
rename to specs/rocky/backlog/trove.rst
diff --git a/specs/rocky/redirects b/specs/rocky/redirects
new file mode 100644
index 0000000..e69de29