diff --git a/doc/requirements.txt b/doc/requirements.txt index b8369d712..1c4c35305 100644 --- a/doc/requirements.txt +++ b/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 diff --git a/doc/source/conf.py b/doc/source/conf.py index 0febbe836..b6f4f9427 100644 --- a/doc/source/conf.py +++ b/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' ] diff --git a/images/juno/cisco-apic-l3-flow.blockdiag b/images/juno/cisco-apic-l3-flow.blockdiag new file mode 100644 index 000000000..285f47ffe --- /dev/null +++ b/images/juno/cisco-apic-l3-flow.blockdiag @@ -0,0 +1,5 @@ +blockdiag l2_apic { + Neutron -> APIC -> Nexus_9k; + Nexus_9k -> Compute1; + Nexus_9k -> Compute2; +} diff --git a/images/juno/cisco-apic-l3-flow.png b/images/juno/cisco-apic-l3-flow.png new file mode 100644 index 000000000..d982e16e8 Binary files /dev/null and b/images/juno/cisco-apic-l3-flow.png differ diff --git a/images/juno/db-migration-timeline.blockdiag b/images/juno/db-migration-timeline.blockdiag new file mode 100644 index 000000000..c3b36cee9 --- /dev/null +++ b/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; + } +} diff --git a/images/juno/db-migration-timeline.png b/images/juno/db-migration-timeline.png new file mode 100644 index 000000000..6db17e7d7 Binary files /dev/null and b/images/juno/db-migration-timeline.png differ diff --git a/images/juno/provider-network-slaac.nwdiag b/images/juno/provider-network-slaac.nwdiag new file mode 100644 index 000000000..5212e3282 --- /dev/null +++ b/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" ]; + } +} diff --git a/images/juno/provider-network-slaac.png b/images/juno/provider-network-slaac.png new file mode 100644 index 000000000..2a6da4909 Binary files /dev/null and b/images/juno/provider-network-slaac.png differ diff --git a/images/liberty/driver-interface.blockdiag b/images/liberty/driver-interface.blockdiag new file mode 100644 index 000000000..9ebc73efa --- /dev/null +++ b/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]; + } +} diff --git a/images/liberty/driver-interface.png b/images/liberty/driver-interface.png new file mode 100644 index 000000000..849dd1a3e Binary files /dev/null and b/images/liberty/driver-interface.png differ diff --git a/images/liberty/interaction-example-1.png b/images/liberty/interaction-example-1.png new file mode 100644 index 000000000..8d25c64b6 Binary files /dev/null and b/images/liberty/interaction-example-1.png differ diff --git a/images/liberty/interaction-example-1.seqdiag b/images/liberty/interaction-example-1.seqdiag new file mode 100644 index 000000000..3ab84341f --- /dev/null +++ b/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"]; +} diff --git a/images/liberty/interaction-example-2.png b/images/liberty/interaction-example-2.png new file mode 100644 index 000000000..fdd800020 Binary files /dev/null and b/images/liberty/interaction-example-2.png differ diff --git a/images/liberty/interaction-example-2.seqdiag b/images/liberty/interaction-example-2.seqdiag new file mode 100644 index 000000000..956ead710 --- /dev/null +++ b/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"]; +} diff --git a/images/mitaka/bgp-sample-topology-1.nwdiag b/images/mitaka/bgp-sample-topology-1.nwdiag new file mode 100644 index 000000000..03f12e621 --- /dev/null +++ b/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; + } + +} diff --git a/images/mitaka/bgp-sample-topology-1.png b/images/mitaka/bgp-sample-topology-1.png new file mode 100644 index 000000000..17dcd64de Binary files /dev/null and b/images/mitaka/bgp-sample-topology-1.png differ diff --git a/images/mitaka/bgp-sample-topology-2.nwdiag b/images/mitaka/bgp-sample-topology-2.nwdiag new file mode 100644 index 000000000..c5e68eb41 --- /dev/null +++ b/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; + } +} diff --git a/images/mitaka/bgp-sample-topology-2.png b/images/mitaka/bgp-sample-topology-2.png new file mode 100644 index 000000000..c28aabdeb Binary files /dev/null and b/images/mitaka/bgp-sample-topology-2.png differ diff --git a/images/pike/nova-live-migration-flow.png b/images/pike/nova-live-migration-flow.png new file mode 100644 index 000000000..88bf014c8 Binary files /dev/null and b/images/pike/nova-live-migration-flow.png differ diff --git a/images/pike/nova-live-migration-flow.seqdiag b/images/pike/nova-live-migration-flow.seqdiag new file mode 100644 index 000000000..27a8ddec4 --- /dev/null +++ b/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}"]; +} diff --git a/images/pike/rpc-portbinding-flow-seqdiag b/images/pike/rpc-portbinding-flow-seqdiag new file mode 100644 index 000000000..c875a12c2 --- /dev/null +++ b/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()"]; +} diff --git a/images/pike/rpc-portbinding-flow.png b/images/pike/rpc-portbinding-flow.png new file mode 100644 index 000000000..ae6d35e7e Binary files /dev/null and b/images/pike/rpc-portbinding-flow.png differ diff --git a/images/stein/state-machine-summary.blockdiag b/images/stein/state-machine-summary.blockdiag new file mode 100644 index 000000000..e394733a9 --- /dev/null +++ b/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 +} diff --git a/images/stein/state-machine-summary.png b/images/stein/state-machine-summary.png new file mode 100644 index 000000000..30a8c39df Binary files /dev/null and b/images/stein/state-machine-summary.png differ diff --git a/images/train/ipam-allocate.png b/images/train/ipam-allocate.png new file mode 100644 index 000000000..54ddb6ed1 Binary files /dev/null and b/images/train/ipam-allocate.png differ diff --git a/images/train/ipam-allocate.seqdiag b/images/train/ipam-allocate.seqdiag new file mode 100644 index 000000000..a1f1ed5cc --- /dev/null +++ b/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"]; +} diff --git a/specs/backlog/pike/portbinding_information_for_nova.rst b/specs/backlog/pike/portbinding_information_for_nova.rst index c942bd243..9624d26f8 100644 --- a/specs/backlog/pike/portbinding_information_for_nova.rst +++ b/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 diff --git a/specs/juno/apic-l3-service-plugin.rst b/specs/juno/apic-l3-service-plugin.rst index dedd75c08..414c1ee52 100644 --- a/specs/juno/apic-l3-service-plugin.rst +++ b/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 =================== diff --git a/specs/juno/db-migration-refactoring.rst b/specs/juno/db-migration-refactoring.rst index 5a1de6972..dba189053 100644 --- a/specs/juno/db-migration-refactoring.rst +++ b/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: diff --git a/specs/juno/ipv6-provider-nets-slaac.rst b/specs/juno/ipv6-provider-nets-slaac.rst index 6b1962076..03a4de598 100644 --- a/specs/juno/ipv6-provider-nets-slaac.rst +++ b/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 =============== diff --git a/specs/juno/security-group-rules-for-devices-rpc-call-refactoring.rst b/specs/juno/security-group-rules-for-devices-rpc-call-refactoring.rst index da228b9d9..c66cc8e16 100644 --- a/specs/juno/security-group-rules-for-devices-rpc-call-refactoring.rst +++ b/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/ diff --git a/specs/kilo/agent-child-processes-status.rst b/specs/kilo/agent-child-processes-status.rst index 51b28512e..855e1094d 100644 --- a/specs/kilo/agent-child-processes-status.rst +++ b/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 diff --git a/specs/kilo/subnet-allocation.rst b/specs/kilo/subnet-allocation.rst index 99125d7a6..5237e79a1 100644 --- a/specs/kilo/subnet-allocation.rst +++ b/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 diff --git a/specs/liberty/neutron-ipam.rst b/specs/liberty/neutron-ipam.rst index 7ec748ef6..e69273230 100644 --- a/specs/liberty/neutron-ipam.rst +++ b/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 ~~~~~~~~~~~~~~~ diff --git a/specs/mitaka/bgp-dynamic-routing.rst b/specs/mitaka/bgp-dynamic-routing.rst index 225cb76cd..91c2baa9a 100644 --- a/specs/mitaka/bgp-dynamic-routing.rst +++ b/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 diff --git a/specs/rocky/port-forwarding.rst b/specs/rocky/port-forwarding.rst index ee26b1ee9..a361f8289 100644 --- a/specs/rocky/port-forwarding.rst +++ b/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 diff --git a/specs/stein/neutron-interconnection.rst b/specs/stein/neutron-interconnection.rst index 7ba2cff58..54b654fa4 100644 --- a/specs/stein/neutron-interconnection.rst +++ b/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 --------------- diff --git a/specs/train/introduce-distributed-locks-to-ipam.rst b/specs/train/introduce-distributed-locks-to-ipam.rst index 98fae6552..b692f0e7e 100644 --- a/specs/train/introduce-distributed-locks-to-ipam.rst +++ b/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 ------------ diff --git a/specs/zed/placeholder.rst b/specs/zed/placeholder.rst deleted file mode 100644 index 8a0de9468..000000000 --- a/specs/zed/placeholder.rst +++ /dev/null @@ -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. -