Fix docs job errors and warnings

As seqdiag, blockdiag and nwdiag blocks in docs are no
longer supported with the latest pillow code, did the
following to fix the docs job:

  - Made screenshots of seqdiag/blockdiag/nwdiag images and
    removed code that built them, started using the images
  - Created *diag files of above for posterity
  - Removed unused footnotes in some other files
  - Removed unnecessary files
  - Removed unused requirements
  - Bumped sphinx>=2.2.0 to match neutron repo

Closes-bug: #2089157
Change-Id: Ie9a1a18af4a21057a6cf8380c664fc4d353d2d73

doc/requirements.txt

@@ -2,14 +2,6 @@
 # with g-r on purpose, as g-r is just for projects affecting the
 # integrated gate. Any sync must happen manually as recommended by
 # the openstack release team.
-sphinx>=2.0.0,!=2.1.0 # BSD
-actdiag
-blockdiag
-nwdiag
+sphinx>=2.2.0 # BSD
 openstackdocstheme>=2.2.1 # Apache-2.0
-seqdiag
-sphinxcontrib-actdiag
-sphinxcontrib-blockdiag # BSD
-sphinxcontrib-nwdiag
-sphinxcontrib-seqdiag # BSD
 yasfb>=0.5.1

doc/source/conf.py

@@ -28,10 +28,6 @@ import datetime
 extensions = [
               'sphinx.ext.todo',
               'sphinx.ext.viewcode',
-              'sphinxcontrib.blockdiag',
-              'sphinxcontrib.actdiag',
-              'sphinxcontrib.seqdiag',
-              'sphinxcontrib.nwdiag',
               'yasfb',
               'openstackdocstheme'
              ]

images/juno/cisco-apic-l3-flow.blockdiag

@@ -0,0 +1,5 @@
+blockdiag l2_apic {
+    Neutron -> APIC -> Nexus_9k;
+    Nexus_9k -> Compute1;
+    Nexus_9k -> Compute2;
+}

images/juno/db-migration-timeline.blockdiag

@@ -0,0 +1,10 @@
+blockdiag timeline {
+    orientation = portrait;
+    default_group_color = lightgreen;
+
+    '...' -> icehouse_release -> '....' -> db_healing;
+    db_healing -> '.....' -> juno_release -> '......';
+    group {
+      db_healing;
+    }
+}

images/juno/provider-network-slaac.nwdiag

@@ -0,0 +1,11 @@
+nwdiag {
+      inet [ shape = cloud ];
+      router;
+      inet -- router;
+      network public_v6 {
+          address = "fdf5:058c:1a36:0f5a::/64"
+          router [ address = "fe80::21c:73ff:fe03:11b3" ];
+          vm1 [ address = "fdf5:58c:1a36:f5a:211:22ff:fe33:4455" ];
+          vm2 [ address = "fdf5:58c:1a36:f5a:214:22ee:ef22:2142" ];
+      }
+}

images/liberty/driver-interface.blockdiag

@@ -0,0 +1,19 @@
+blockdiag admin {
+      group {
+          fontsize = 20;
+          label = "Plugins";
+          orientation = portrait;
+
+          NeutronDbPluginV2 -> Ml2Plugin, LinuxBridgePluginV2,
+                                              "...PluginV2" [dir = back];
+      }
+      NeutronDbPluginV2 -> IPAMDriver [ label = "uses" ];
+      group {
+          fontsize = 20;
+          label = "IPAM Drivers";
+          orientation = portrait;
+
+          IPAMDriver -> NeutronIPAM  [style = dotted, dir = back,
+                                      label = implements, fontsize = 8];
+      }
+}

images/liberty/interaction-example-1.seqdiag

@@ -0,0 +1,10 @@
+seqdiag {
+      "Neutron Plugin" -> NeutronDbPluginV2 [label = "create_subnet"];
+      NeutronDbPluginV2 -> "IPAM Driver" [label = "allocate_subnet"];
+      "IPAM Driver" -> "Pluggable IPAM" [label = "Allocate Subnet"];
+      "IPAM Driver" <- "Pluggable IPAM" [label = "subnet"];
+      NeutronDbPluginV2 <- "IPAM Driver" [label = "subnet"];
+      NeutronDbPluginV2 -> "Neutron DB" [label = "subnet"];
+      NeutronDbPluginV2 <- "Neutron DB";
+      "Neutron Plugin" <- NeutronDbPluginV2 [label = "subnet"];
+}

images/liberty/interaction-example-2.seqdiag

@@ -0,0 +1,13 @@
+seqdiag {
+      "Neutron Plugin"  ->  NeutronDbPluginV2 [label = "create_port"];
+      "Neutron Plugin"  ->  NeutronDbPluginV2 [label = "create_port"];
+      NeutronDbPluginV2 -> "IPAM Driver" [label = "get_subnet"];
+      NeutronDbPluginV2 <- "IPAM Driver" [label = "IPAMSubnet"];
+      NeutronDbPluginV2 -> IPAMSubnet [label = "allocate_ip"];
+      IPAMSubnet -> "Pluggable IPAM" [label = "Allocate IP"];
+      IPAMSubnet <- "Pluggable IPAM" [label = "IP"];
+      NeutronDbPluginV2 <- IPAMSubnet [label = "IP"];
+      NeutronDbPluginV2 -> "Neutron DB" [label = "port, IP data"];
+      NeutronDbPluginV2 <- "Neutron DB";
+      "Neutron Plugin" <- NeutronDbPluginV2 [label = "port, IP data"];
+}

images/mitaka/bgp-sample-topology-1.nwdiag

@@ -0,0 +1,27 @@
+nwdiag {
+
+    network external {
+      gateway_router[color = red];
+      tenant_router1;
+      tenant_router2;
+    }
+
+    group {
+      color = lightgreen;
+      //label = "OpenStack Deployment";
+      gateway_router;
+      tenant_router1;
+      tenant_router2;
+    }
+
+    network isp_net1 {
+      gateway_router;
+      uplink_router1;
+    }
+
+    network isp_net2 {
+      gateway_router;
+      uplink_router2;
+    }
+
+}

images/mitaka/bgp-sample-topology-2.nwdiag

@@ -0,0 +1,21 @@
+nwdiag {
+    network external {
+      tor_switch1;
+      tor_switch2;
+    }
+
+    tor_switch1 -- l2_network1;
+    tor_switch2 -- l2_network2;
+
+    group {
+      color = lightgreen;
+      tor_switch1;
+      l2_network1;
+    }
+
+    group {
+      color = yellow;
+      tor_switch2;
+      l2_network2;
+    }
+}

images/pike/nova-live-migration-flow.seqdiag

@@ -0,0 +1,27 @@
+seqdiag {
+    // Do not show activity line
+    activation = none;
+    edge_length = 400;
+    Nova; Neutron
+
+    === Nova boot instance ===
+    Nova -> Neutron [label = "Create the port
+        POST /v2.0/ports {host_id:src_host}"];
+
+    === Nova pre_live_migration ===
+    Nova -> Neutron [label = "Create the inactive binding
+        POST /v2.0/ports/{port_id}/bindings {binding:{
+                                             host_id:target-host_id}}"];
+
+    === Nova live_migration_operation ===
+    Nova -> Nova [label ="Update the instance \ndefinition and
+        start the migration"];
+
+    === Nova live_migration_operation - instance active on target===
+    Nova -> Neutron [label ="Set the inactive binding to active
+        PUT /v2.0/ports/{port_id}/bindings/{host_id}/activate"];
+
+    === Nova post_live_migration ===
+    Nova -> Neutron [label ="Remove the inactive binding
+        DELETE /v2.0/ports/{port_id}/bindings/{host_id}"];
+}

images/pike/rpc-portbinding-flow-seqdiag

@@ -0,0 +1,33 @@
+seqdiag {
+    // Do not show activity line
+    activation = none;
+    edge_length = 600;
+    nova; neutron_server; neutron_l2_agent_source; neutron_l2_agent_target
+
+    === Nova create inactive binding ===
+    nova -> neutron_server [label = "Create inactive binding
+        POST /v2.0/ports/{port_id}/bindings {binding:{
+            host_id:target-host_id}}"];
+    neutron_server -> neutron_server [label = "_create_binding()"];
+    neutron_server -> neutron_server [label =
+        "_bind_port_if_needed(notify=False)"];
+    neutron_server -> neutron_l2_agent_target [label = "bind_port()"];
+
+    === Nova activate inactive binding ===
+    nova -> neutron_server [label = "Set the inactive binding to active
+        PUT /v2.0/ports/{port_id}/bindings/{host_id}/activate"];
+    neutron_server -> neutron_server [label = "_update_binding_status()"];
+    neutron_server -> neutron_l2_agent_source [label = "port_delete()"];
+    neutron_l2_agent_source -> neutron_l2_agent_source [label =
+        "bypass update_device_list()"];
+    neutron_server -> neutron_l2_agent_target [label = "update_port()"];
+    neutron_l2_agent_target -> neutron_server [label = "get_devices_
+        details_list_and_failed_devices()"];
+    neutron_l2_agent_target -> neutron_l2_agent_target [label =
+        "if port['transition'] == 'activate': _send_garp()"];
+
+    === Nova post_live_migration ===
+    nova -> neutron_server [label ="Remove the inactive binding
+        DELETE /v2.0/ports/{port_id}/bindings/{host_id}"];
+    neutron_server -> neutron_server [label = "_delete_binding()"];
+}

images/stein/state-machine-summary.blockdiag

@@ -0,0 +1,19 @@
+blockdiag {
+     default_shape = roundedbox
+
+     BEFORE_CREATION [shape = beginpoint, label=""]
+     TO_VALIDATE
+     VALIDATED
+     ACTIVE
+     TEARDOWN
+     DELETED [shape = endpoint, label=""]
+
+     BEFORE_CREATION -> TO_VALIDATE [folded]
+     TO_VALIDATE -> VALIDATED
+     TO_VALIDATE -> TEARDOWN [folded]
+     VALIDATED -> ACTIVE
+     VALIDATED -> TEARDOWN [folded]
+     ACTIVE -> TEARDOWN [folded]
+     TEARDOWN -> DELETED [folded]
+     ACTIVE -> TO_VALIDATE
+}

images/train/ipam-allocate.seqdiag

@@ -0,0 +1,14 @@
+seqdiag {
+      "Neutron Plugin"  ->  NeutronDbPluginV2 [label = "create_port"];
+      NeutronDbPluginV2 -> "IPAM Driver" [label = "get_subnet"];
+      NeutronDbPluginV2 <- "IPAM Driver" [label = "IPAMSubnet"];
+      NeutronDbPluginV2 -> IPAMSubnet [label = "allocate_ip"];
+      IPAMSubnet -> "Pluggable IPAM" [label = "Allocate IP"];
+      "Pluggable IPAM" -> "Pluggable IPAM" [label = "lock ip by ip+subnet_id"];
+      IPAMSubnet <- "Pluggable IPAM" [label = "IP"];
+      NeutronDbPluginV2 <- IPAMSubnet [label = "IP"];
+      NeutronDbPluginV2 -> "Neutron DB" [label = "port, IP data"];
+      NeutronDbPluginV2 <- "Neutron DB";
+      "Neutron Plugin" <- NeutronDbPluginV2 [label = "port, IP data"];
+      "Neutron Plugin" -> "Neutron Plugin" [label = "release lock"];
+}

specs/backlog/pike/portbinding_information_for_nova.rst

@@ -128,35 +128,7 @@ Nova will utilize the expanded API, and the potential flow is as follows:
 * post_live_migration: Remove the inactive binding on the source
   compute host.
 
-.. seqdiag::
-
-   diagram {
-      // Do not show activity line
-      activation = none;
-      edge_length = 400;
-      Nova; Neutron
-
-      === Nova boot instance ===
-      Nova -> Neutron [label = "Create the port
-          POST /v2.0/ports {host_id:src_host}"];
-
-      === Nova pre_live_migration ===
-      Nova -> Neutron [label = "Create the inactive binding
-          POST /v2.0/ports/{port_id}/bindings {binding:{
-                                               host_id:target-host_id}}"];
-
-      === Nova live_migration_operation ===
-      Nova -> Nova [label ="Update the instance \ndefinition and
-          start the migration"];
-
-      === Nova live_migration_operation - instance active on target===
-      Nova -> Neutron [label ="Set the inactive binding to active
-          PUT /v2.0/ports/{port_id}/bindings/{host_id}/activate"];
-
-      === Nova post_live_migration ===
-      Nova -> Neutron [label ="Remove the inactive binding
-          DELETE /v2.0/ports/{port_id}/bindings/{host_id}"];
-   }
+.. image:: /images/pike/nova-live-migration-flow.png
 
 * If rollback is performed after the instance is active on target: From a
   Neutron standpoint, if the binding is active on the target host, Nova will
@@ -657,41 +629,7 @@ additional plumbing to occur as follows:
   In addition, the transition from active to inactive will be indicated in the
   rpc call, influencing the `update_device_list` to not update the port state.
 
-.. seqdiag::
-
-    diagram {
-        // Do not show activity line
-        activation = none;
-        edge_length = 600;
-        nova; neutron_server; neutron_l2_agent_source; neutron_l2_agent_target
-
-        === Nova create inactive binding ===
-        nova -> neutron_server [label = "Create inactive binding
-            POST /v2.0/ports/{port_id}/bindings {binding:{
-                host_id:target-host_id}}"];
-        neutron_server -> neutron_server [label = "_create_binding()"];
-        neutron_server -> neutron_server [label =
-            "_bind_port_if_needed(notify=False)"];
-        neutron_server -> neutron_l2_agent_target [label = "bind_port()"];
-
-        === Nova activate inactive binding ===
-        nova -> neutron_server [label = "Set the inactive binding to active
-            PUT /v2.0/ports/{port_id}/bindings/{host_id}/activate"];
-        neutron_server -> neutron_server [label = "_update_binding_status()"];
-        neutron_server -> neutron_l2_agent_source [label = "port_delete()"];
-        neutron_l2_agent_source -> neutron_l2_agent_source [label =
-            "bypass update_device_list()"];
-        neutron_server -> neutron_l2_agent_target [label = "update_port()"];
-        neutron_l2_agent_target -> neutron_server [label = "get_devices_
-            details_list_and_failed_devices()"];
-        neutron_l2_agent_target -> neutron_l2_agent_target [label =
-            "if port['transition'] == 'activate': _send_garp()"];
-
-        === Nova post_live_migration ===
-        nova -> neutron_server [label ="Remove the inactive binding
-            DELETE /v2.0/ports/{port_id}/bindings/{host_id}"];
-        neutron_server -> neutron_server [label = "_delete_binding()"];
-    }
+.. image:: /images/pike/rpc-portbinding-flow.png
 
 In the case where push-notifications are implemented for ports under Blueprint
 `[10]`_ the `get_devices_details_list_and_failed_devices` would not be adjusted

specs/juno/apic-l3-service-plugin.rst

@@ -10,13 +10,7 @@ using the Cisco APIC.
 
 Flows
 
-.. blockdiag::
-
-  blockdiag l2_apic {
-    Neutron -> APIC -> Nexus_9k;
-    Nexus_9k -> Compute1;
-    Nexus_9k -> Compute2;
-  }
+.. image:: /images/juno/cisco-apic-l3-flow.png
 
 Problem description
 ===================

specs/juno/db-migration-refactoring.rst

@@ -94,19 +94,7 @@ aspects:
 Migration Timeline
 ------------------
 
-.. blockdiag::
-
-  blockdiag timeline {
-    orientation = portrait;
-    default_group_color = lightgreen;
-
-    '...' -> icehouse_release -> '....' -> db_healing;
-    db_healing -> '.....' -> juno_release -> '......';
-    group {
-      db_healing;
-    }
-  }
-
+.. image:: /images/juno/db-migration-timeline.png
 
 .. _onlinedetails:
 

specs/juno/ipv6-provider-nets-slaac.rst

@@ -17,20 +17,7 @@ configured IPv6 on northbound networking devices, may wish to
 advertise IPv6 routes by having non-OpenStack hardware transmit
 ICMPv6 Router Advertisement packets.
 
-.. nwdiag::
-
-    nwdiag {
-        inet [ shape = cloud ];
-        router;
-        inet -- router;
-        network public_v6 {
-            address = "fdf5:058c:1a36:0f5a::/64"
-            router [ address = "fe80::21c:73ff:fe03:11b3" ];
-            vm1 [ address = "fdf5:58c:1a36:f5a:211:22ff:fe33:4455" ];
-            vm2 [ address = "fdf5:58c:1a36:f5a:214:22ee:ef22:2142" ];
-        }
-    }
-
+.. image:: /images/juno/provider-network-slaac.png
 
 Proposed change
 ===============

specs/juno/security-group-rules-for-devices-rpc-call-refactoring.rst

@@ -413,8 +413,6 @@ References
 
 .. [#n2nov_scaling] http://javacruft.wordpress.com/2014/06/18/168k-instances/
 
-.. [#iptables] http://www.fpaste.org/104431/40085672/
-
 .. [#sec_fanout] http://lists.openstack.org/pipermail/openstack-dev/2014-June/038374.html
 
 .. [#ipset_spec] https://review.openstack.org/#/c/100761/

specs/kilo/agent-child-processes-status.rst

@@ -329,12 +329,6 @@ References
 .. [#oslo_service_status]  Oslo service manager status notification spec
    http://docs-draft.openstack.org/48/97748/3/check/gate-oslo-specs-docs/ef96358/doc/build/html/specs/juno/service-status-interface.html]
 
-.. [#oslo_sn_review] Oslo spec review
-   https://review.openstack.org/#/c/97748/
-
-.. [#old_agent_service_status] Old agent service status blueprint
-   https://blueprints.launchpad.net/neutron/+spec/agent-service-status
-
 .. [#waitpid] http://linux.die.net/man/2/waitpid
 
 .. [#waitpid_non_child] http://stackoverflow.com/questions/1058047/wait-for-any-process-to-finish

specs/kilo/subnet-allocation.rst

@@ -282,10 +282,10 @@ between 32 and 64.
 
 There are certain parts of the IPv6 address space that are simply not specified
 for any kind of use (i.e. outside 2000::/3, fc00:/7 for ULA, and other specified
-scopes)[#]_.  Some validation is called for.  The following address spaces should
+scopes) [#ipv6-addr]_.  Some validation is called for.  The following address spaces should
 be allowed:
 
-.. [#] http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
+.. [#ipv6-addr] http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
 
 .. csv-table::
     :header: Addresses, Description
@@ -298,9 +298,9 @@ existing subnet allocations that happen to fall outside of the new ranges.
 
 This bp will start with the same shared model that we have now for networks.
 However, an RBAC mechanism can be added later similar to the one proposed for
-networks [#]_.
+networks [#network-rbac]_.
 
-.. [#] https://review.openstack.org/#/c/132661/
+.. [#network-rbac] https://review.openstack.org/#/c/132661/
 
 Security Impact
 ---------------
@@ -406,10 +406,9 @@ Work Items
 Dependencies
 ============
 
-This blueprint depends on the work in the neutron-ipam [#]_.  That blueprint
-adds some of the frame-work necessary to implement this new feature.
-
-.. [#] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
+This blueprint depends on the work in the neutron-ipam [#neutron-ipam]_ one.
+That blueprint adds some of the frame-work necessary to implement this
+new feature. For further information, see the Etherpad [#ipam-etherpad]_.
 
 Testing
 =======
@@ -462,4 +461,6 @@ N/A
 References
 ==========
 
-.. [#] https://etherpad.openstack.org/p/neutron-ipam
+.. [#neutron-ipam] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
+
+.. [#ipam-etherpad] https://etherpad.openstack.org/p/neutron-ipam

specs/liberty/neutron-ipam.rst

@@ -62,27 +62,7 @@ The Neutron Plugins will call into the driver for IPAM functionality.
 
 The driver interface will be synchronous.
 
-   .. blockdiag::
-
-    blockdiag admin {
-        group {
-            fontsize = 20;
-            label = "Plugins";
-            orientation = portrait;
-
-            NeutronDbPluginV2 -> Ml2Plugin, LinuxBridgePluginV2,
-                                                "...PluginV2" [dir = back];
-        }
-        NeutronDbPluginV2 -> IPAMDriver [ label = "uses" ];
-        group {
-            fontsize = 20;
-            label = "IPAM Drivers";
-            orientation = portrait;
-
-            IPAMDriver -> NeutronIPAM  [style = dotted, dir = back,
-                                        label = implements, fontsize = 8];
-        }
-    }
+.. image:: /images/liberty/driver-interface.png
 
 The IPAM implementation will define abstract Request classes for subnets and
 addresses. These classes enable the caller to request subnet or IP allocations
@@ -105,18 +85,7 @@ IPAM" represents an optional external IPAM system. These diagrams are intended
 as examples; the specific details of each flow will be defined during
 implementation.
 
-   .. seqdiag::
-
-    seqdiag {
-        "Neutron Plugin" -> NeutronDbPluginV2 [label = "create_subnet"];
-        NeutronDbPluginV2 -> "IPAM Driver" [label = "allocate_subnet"];
-        "IPAM Driver" -> "Pluggable IPAM" [label = "Allocate Subnet"];
-        "IPAM Driver" <- "Pluggable IPAM" [label = "subnet"];
-        NeutronDbPluginV2 <- "IPAM Driver" [label = "subnet"];
-        NeutronDbPluginV2 -> "Neutron DB" [label = "subnet"];
-        NeutronDbPluginV2 <- "Neutron DB";
-        "Neutron Plugin" <- NeutronDbPluginV2 [label = "subnet"];
-    }
+.. image:: /images/liberty/interaction-example-1.png
 
 Here is another flow demonstrating the call to create a port. In this case,
 the IPAM driver is called in order to retrieve a subnet, *or* allocate the
@@ -127,21 +96,7 @@ of the driver.
 
 The IPAMSubnet object is used for the IP allocation.
 
-   .. seqdiag::
-
-    seqdiag {
-        "Neutron Plugin"  ->  NeutronDbPluginV2 [label = "create_port"];
-        NeutronDbPluginV2 -> "IPAM Driver" [label = "get_subnet"];
-        NeutronDbPluginV2 <- "IPAM Driver" [label = "IPAMSubnet"];
-        NeutronDbPluginV2 -> IPAMSubnet [label = "allocate_ip"];
-        IPAMSubnet -> "Pluggable IPAM" [label = "Allocate IP"];
-        IPAMSubnet <- "Pluggable IPAM" [label = "IP"];
-        NeutronDbPluginV2 <- IPAMSubnet [label = "IP"];
-        NeutronDbPluginV2 -> "Neutron DB" [label = "port, IP data"];
-        NeutronDbPluginV2 <- "Neutron DB";
-        "Neutron Plugin" <- NeutronDbPluginV2 [label = "port, IP data"];
-    }
-
+.. image:: /images/liberty/interaction-example-2.png
 
 Driver Creation
 ~~~~~~~~~~~~~~~

specs/mitaka/bgp-dynamic-routing.rst

@@ -35,35 +35,7 @@ the cloud reachable through the remaining healthy link.
 
 **Sample Topology**
 
-.. nwdiag::
-
-  nwdiag {
-
-    network external {
-      gateway_router[color = red];
-      tenant_router1;
-      tenant_router2;
-    }
-
-    group {
-      color = lightgreen;
-      //label = "OpenStack Deployment";
-      gateway_router;
-      tenant_router1;
-      tenant_router2;
-    }
-
-    network isp_net1 {
-      gateway_router;
-      uplink_router1;
-    }
-
-    network isp_net2 {
-      gateway_router;
-      uplink_router2;
-    }
-
-  }
+.. image:: /images/mitaka/bgp-sample-topology-1.png
 
 Please note that in this diagram, the red gateway router is actually a linux
 machine with a software BGP speaker and a software router. This blueprint
@@ -92,30 +64,7 @@ to advertise the new routable subnets to uplink routers.
 
 **Sample Topology**
 
-.. nwdiag::
-
-  nwdiag {
-    network external {
-      tor_switch1;
-      tor_switch2;
-    }
-
-    tor_switch1 -- l2_network1;
-    tor_switch2 -- l2_network2;
-
-    group {
-      color = lightgreen;
-      tor_switch1;
-      l2_network1;
-    }
-
-    group {
-      color = yellow;
-      tor_switch2;
-      l2_network2;
-    }
-  }
-
+.. image:: /images/mitaka/bgp-sample-topology-2.png
 
 The topology of this use case can be seen as a generalization of the previous
 one, with a multi-homed OpenStack installation and leverage the fact that a

specs/rocky/port-forwarding.rst

@@ -560,8 +560,3 @@ References
 
 .. [#foot1] https://docs.docker.com/engine/userguide/networking/default_network/binding/
 .. [#foot2] https://review.openstack.org/#/c/485333/20
-.. [#foot3] https://ask.openstack.org/en/question/75190/neutron-port-forwarding-qrouter-vms/
-.. [#foot4] http://www.gossamer-threads.com/lists/openstack/dev/34307
-.. [#foot5] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-for-router-td46639.html
-.. [#foot6] http://openstack.10931.n7.nabble.com/Neutron-port-forwarding-from-gateway-to-internal-hosts-td32410.html
-.. [#foot7] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr

specs/stein/neutron-interconnection.rst

@@ -293,27 +293,7 @@ TEARDOWN
 (DELETED)
   implicit state corresponding to the resource not existing anymore
 
-.. blockdiag::
-
-    blockdiag {
-       default_shape = roundedbox
-
-       BEFORE_CREATION [shape = beginpoint, label=""]
-       TO_VALIDATE
-       VALIDATED
-       ACTIVE
-       TEARDOWN
-       DELETED [shape = endpoint, label=""]
-
-       BEFORE_CREATION -> TO_VALIDATE [folded]
-       TO_VALIDATE -> VALIDATED
-       TO_VALIDATE -> TEARDOWN [folded]
-       VALIDATED -> ACTIVE
-       VALIDATED -> TEARDOWN [folded]
-       ACTIVE -> TEARDOWN [folded]
-       TEARDOWN -> DELETED [folded]
-       ACTIVE -> TO_VALIDATE
-    }
+.. image:: /images/stein/state-machine-summary.png
 
 REST API Impact
 ---------------

specs/train/introduce-distributed-locks-to-ipam.rst

@@ -52,22 +52,8 @@ an OpenStack native project. We will support the configuration of tooz backend
 drivers in neutron.conf, such as adding [tooz] configuration items.
 
 The new IPAM allocate ip seqdiag.
-   .. seqdiag::
 
-    seqdiag {
-        "Neutron Plugin"  ->  NeutronDbPluginV2 [label = "create_port"];
-        NeutronDbPluginV2 -> "IPAM Driver" [label = "get_subnet"];
-        NeutronDbPluginV2 <- "IPAM Driver" [label = "IPAMSubnet"];
-        NeutronDbPluginV2 -> IPAMSubnet [label = "allocate_ip"];
-        IPAMSubnet -> "Pluggable IPAM" [label = "Allocate IP"];
-        "Pluggable IPAM" -> "Pluggable IPAM" [label = "lock ip by ip+subnet_id"];
-        IPAMSubnet <- "Pluggable IPAM" [label = "IP"];
-        NeutronDbPluginV2 <- IPAMSubnet [label = "IP"];
-        NeutronDbPluginV2 -> "Neutron DB" [label = "port, IP data"];
-        NeutronDbPluginV2 <- "Neutron DB";
-        "Neutron Plugin" <- NeutronDbPluginV2 [label = "port, IP data"];
-        "Neutron Plugin" -> "Neutron Plugin" [label = "release lock"];
-    }
+.. image:: /images/train/ipam-allocate.png
 
 Alternatives
 ------------

specs/zed/placeholder.rst

@@ -1,83 +0,0 @@
-..
- This work is licensed under a Creative Commons Attribution 3.0 Unported
- License.
-
- http://creativecommons.org/licenses/by/3.0/legalcode
-
-====================================
-Example Spec - The title of your RFE
-====================================
-
-Include the URL of your launchpad RFE:
-
-https://bugs.launchpad.net/neutron/+bug/example-id
-
-Introduction paragraph -- why are we doing this feature? A single paragraph of
-prose that **deployers, and developers, and operators** can understand.
-
-Do you even need to file a spec? Most features can be done by filing an RFE bug
-and moving on with life. In most cases, filing an RFE and documenting your
-design in the devref folder of neutron docs is sufficient. If the feature
-seems very large or contentious, then the drivers team may request a spec, or
-you can always file one if desired.
-
-
-Problem Description
-===================
-
-A detailed description of the problem:
-
-* For a new feature this should be a list of use cases. Ensure that you are clear
-  about the actors in each use case: End User vs Deployer. Ensure that you identify
-  which area of the core is being affected; for something completely new, it
-  should be clear why you are considering it being part of the core.
-
-* For a major reworking of something existing it would describe the
-  problems in that feature that are being addressed.
-
-Note that the RFE filed for this feature will have a description already. This
-section is not meant to simply duplicate that; you can simply refer to that
-description if it is sufficient, and use this space to capture changes to
-the description based on bug comments or feedback on the spec.
-
-
-Proposed Change
-===============
-
-How do you propose to solve this problem?
-
-This section is optional, and provides an area to discuss your high-level
-design at the same time as use cases, if desired.  Note that by high-level,
-we mean the "view from orbit" rough cut at how things will happen.
-
-This section should 'scope' the effort from a feature standpoint: how is the
-'neutron end-to-end system' going to look like after this change? What Neutron
-areas do you intend to touch and how do you intend to work on them? The list
-below is not meant to be a template to fill in, but rather a jumpstart on the
-sorts of areas to consider in your proposed change description.
-
-* Am I going to see new CLI commands?
-  * Is OpenStack CLI covered in addition to neutronclient?
-* How do you intend to support or affect aspects like:
-  * Address Management, e.g. IPv6, DHCP
-  * Routing, e.g. DVR/HA
-  * Plugins, ML2 Drivers, e.g. OVS, LinuxBridge
-  * Agents, e.g. metadata
-  * High level services, e.g. \*-aas.
-  * Scheduling, quota, and policy management, e.g. admin vs user rights
-  * API and extensions
-  * Clients
-  * Impact on services or out-of-tree plugins/drivers
-* What do you intend to not support in the initial release?
-
-You do not need to detail API or data model changes. Details at that level of
-granularity belong in the neutron devref docs.
-
-
-References
-==========
-
-Please add any useful references here. You are not required to have any
-reference. Moreover, this specification should still make sense when your
-references are unavailable.
-