Merge "plug-in needs a boost! :)"

doc/admin-guide-cloud/networking/section_networking-scenarios.xml

@@ -587,7 +587,7 @@ physical_interface_mappings = physnet2:eth1</programlisting></para>
     </section>
     <section xml:id="ml2_scenarios">
         <title>ML2</title>
-        <para>The Modular Layer 2 plugin allows OpenStack Networking
+        <para>The Modular Layer 2 plug-in allows OpenStack Networking
             to simultaneously utilize the variety of layer 2 networking
             technologies found in complex real-world data centers.
             It currently includes drivers for the local, flat, VLAN,
@@ -675,7 +675,7 @@ l2_population = True</programlisting></para>
         </section>
         <section xml:id="ml2_l2_security_group">
             <title>Enable security group API</title>
-            <para>Since the ML2 plugin can concurrently support
+            <para>Since the ML2 plug-in can concurrently support
             different L2 agents (or other mechanisms) with different
             configuration files, the actual <option>firewall_driver
             </option> value in the <filename>ml2_conf.ini</filename>

doc/install-guide/section_neutron-single-flat.xml

@@ -11,7 +11,7 @@
         nodes should have one interface for management traffic and one
         or more interfaces for traffic to and from VMs. The management
         network is 100.1.1.0/24 with controller node at 100.1.1.2. The example uses the Open vSwitch
-        plugin and agent.</para>
+        plug-in and agent.</para>
     <note>
         <para>You can modify this set up to make use of another
             supported plug-in and its agent.</para>

doc/security-guide/ch013_node-bootstrapping.xml

@@ -355,8 +355,8 @@
       <para>Network intrusion detection tools complement the
         host-based tools. OpenStack doesn't have a specific network
         IDS built-in, but OpenStack's networking component, Neutron,
-        provides a plugin mechanism to enable different technologies
+        provides a plug-in mechanism to enable different technologies
-        via the Neutron API. This plugin architecture will allow
+        via the Neutron API. This plug-in architecture will allow
         tenants to develop API extensions to insert and configure
         their own advanced networking services like a firewall, an
         intrusion detection system, or a VPN between the VMs.</para>

doc/security-guide/ch031_neutron-architecture.xml

@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://docbook.org/ns/docbook" xmlns:db="http://docbook.org/ns/docbook" version="5.0" xml:id="ch031_neutron-architecture"><?dbhtml stop-chunking?>
     <title>Networking Architecture</title>
-    <para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plugins for additional processing.</para>
+    <para>OpenStack Networking is a standalone service that often involves deploying several processes across a number of nodes. These processes interact with each other and with other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plug-ins for additional processing.</para>
     <para>OpenStack Networking components encompasses the following elements:</para>
     <itemizedlist><listitem>
         <para><emphasis role="bold">neutron server</emphasis>  (<literal>neutron-server</literal> and <literal>neutron-*-plugin</literal>): This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server and plugin agents require access to a database for persistent storage and access to a message queue for inter-communication.</para>
@@ -10,10 +10,10 @@
         <para><emphasis role="bold">plugin agent</emphasis>  (<literal>neutron-*-agent</literal>): Runs on each compute node to manage local virtual switch (vswitch) configuration. The agents to be run will depend on which plugin you are using. This service requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
       </listitem>
 <listitem>
-        <para><emphasis role="bold">DHCP agent</emphasis>  (<literal>neutron-dhcp-agent</literal>): Provides DHCP services to tenant networks. This agent is the same across all plugins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
+        <para><emphasis role="bold">DHCP agent</emphasis>  (<literal>neutron-dhcp-agent</literal>): Provides DHCP services to tenant networks. This agent is the same across all plug-ins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.</para>
       </listitem>
 <listitem>
-        <para><emphasis role="bold">l3 agent</emphasis>  (<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. <emphasis>Optional depending on plugin.</emphasis></para>
+        <para><emphasis role="bold">l3 agent</emphasis>  (<literal>neutron-l3-agent</literal>): Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. <emphasis>Optional depending on plug-in.</emphasis></para>
       </listitem>
 <listitem>
         <para><emphasis role="bold">network provider services</emphasis>  (SDN server/services). Provide additional networking services that are provided to tenant networks. These SDN services may interact with the neutron-server, neutron-plugin, and/or plugin-agents via REST APIs or other communication channels.</para>
@@ -44,7 +44,7 @@
             <para><emphasis role="bold">Management network</emphasis> Used for internal communication between OpenStack Components. The IP addresses on this network should be reachable only within the data center and is considered the Management Security Domain.</para>
           </listitem>
 <listitem>
-            <para><emphasis role="bold">Guest network</emphasis> Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plugin in use and the network configuration choices of the virtual networks made by the tenant. This network is considered the Guest Security Domain.</para>
+            <para><emphasis role="bold">Guest network</emphasis> Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the OpenStack Networking plug-in in use and the network configuration choices of the virtual networks made by the tenant. This network is considered the Guest Security Domain.</para>
           </listitem>
 <listitem>
             <para><emphasis role="bold">External network</emphasis> Used to provide VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet and is considered to be in the Public Security Domain.</para>

doc/security-guide/ch032_networking-best-practices.xml

@@ -47,29 +47,29 @@
             <para>Rate-limiting on a per port/network/tenant basis.</para>
           </listitem>
 <listitem>
-            <para>Port mirroring (via open source or third-party plugins)</para>
+            <para>Port mirroring (via open source or third-party plug-ins)</para>
           </listitem>
 <listitem>
-            <para>Flow analysis (via open source or third-party plugins)</para>
+            <para>Flow analysis (via open source or third-party plug-ins)</para>
           </listitem>
 </itemizedlist>
-        <para>Tenant traffic port mirroring or Network Flow monitoring is currently not an exposed feature in OpenStack Networking. There are third-party plugin extensions that do provide Port Mirroring on a per port/network/tenant basis. If Open vSwitch is used on the networking hypervisor, it is possible to enable sFlow and port mirroring, however it will require some operational effort to implement.</para>
+        <para>Tenant traffic port mirroring or Network Flow monitoring is currently not an exposed feature in OpenStack Networking. There are third-party plug-in extensions that do provide Port Mirroring on a per port/network/tenant basis. If Open vSwitch is used on the networking hypervisor, it is possible to enable sFlow and port mirroring, however it will require some operational effort to implement.</para>
       </section>
       <section xml:id="ch032_networking-best-practices-idp69408">
         <title>Load Balancing</title>
-        <para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plugins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
+        <para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and should likely not be run in a production environment. The current reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.</para>
       </section>
       <section xml:id="ch032_networking-best-practices-idp71664">
         <title>Firewalls</title>
-        <para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plugins in development for extensions in OpenStack Networking to support this.</para>
+        <para>FW-as-a-Service (FWaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. FWaaS will address the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. There are third-party plug-ins in development for extensions in OpenStack Networking to support this.</para>
         <para>It is critical during the design of an OpenStack Networking infrastructure to understand the current features and limitations of network services that are available. Understanding where the boundaries of your virtual and physical networks will help you add the required security controls in your environment.</para>
       </section>
     </section>
     <section xml:id="ch032_networking-best-practices-idp74544">
       <title>Network Services Extensions</title>
-      <para>Here is a list of known plugins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
+      <para>Here is a list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking:</para>
       <para>Big Switch Controller Plugin, Brocade Neutron Plugin Brocade Neutron Plugin, Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Open vSwitch Plugin, PLUMgrid Plugin, Ruijie Networks Plugin, Ryu OpenFlow Controller Plugin, VMware NSX plugin</para>
-      <para>For a more detailed comparison of all features provided by plugins as of the Folsom release, see <link xlink:href="http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/">Sebastien Han's comparison</link>.</para>
+      <para>For a more detailed comparison of all features provided by plug-ins as of the Folsom release, see <link xlink:href="http://www.sebastien-han.fr/blog/2012/09/28/quantum-plugin-comparison/">Sebastien Han's comparison</link>.</para>
     </section>
     <section xml:id="ch032_networking-best-practices-idp78032">
       <title>Networking Services Limitations</title>
@@ -82,7 +82,7 @@
           <para><emphasis role="bold">Multi-Host DHCP-agent</emphasis> &#x2014; OpenStack Networking supports multiple l3-agent and dhcp-agents with load balancing. However, tight coupling of the location of the virtual machine is not supported.</para>
         </listitem>
 <listitem>
-          <para><emphasis role="bold">No IPv6 Support for L3 agents</emphasis> &#x2014; The neutron-l3-agent, used by many plugins to implement L3 forwarding, supports only IPv4 forwarding.</para>
+          <para><emphasis role="bold">No IPv6 Support for L3 agents</emphasis> &#x2014; The neutron-l3-agent, used by many plug-ins to implement L3 forwarding, supports only IPv4 forwarding.</para>
         </listitem>
 </itemizedlist>
     </section>

doc/security-guide/ch046_data-residency.xml

@@ -111,14 +111,14 @@
       </section>
       <section xml:id="ch046_data-residency-idp78448">
         <title>Cinder volume data</title>
-        <para>Plugins to OpenStack Block Storage will store data in a variety of ways. Many plugins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plugin to another, from one vendor's solution to another, and from one filesystem to another.</para>
+        <para>Plugins to OpenStack Block Storage will store data in a variety of ways. Many plug-ins are specific to a vendor or technology, whereas others are more DIY solutions around filesystems such as LVM or ZFS. Methods to securely destroy data will vary from one plugin to another, from one vendor's solution to another, and from one filesystem to another.</para>
-        <para>Some backends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other backends such as LVM may not natively support this, thus the Cinder plugin takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume backend provides and to see what mediations may be available for those assurances not provided.</para>
+        <para>Some backends such as ZFS will support copy-on-write to prevent data exposure. In these cases, reads from unwritten blocks will always return zero. Other backends such as LVM may not natively support this, thus the Block Storage plug-in takes the responsibility to override previously written blocks before handing them to users. It is important to review what assurances your chosen volume backend provides and to see what mediations may be available for those assurances not provided.</para>
         <para>Finally, while not a feature of OpenStack, vendors and implementors may choose to add or support encryption of volumes. In this case, destruction of data is as simple as throwing away the key.</para>
       </section>
       <section xml:id="ch046_data-residency-idp81664">
         <title>Compute instance ephemeral storage</title>
-        <para>The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plugin.</para>
+        <para>The creation and destruction of ephemeral storage will be somewhat dependent on the chosen hypervisor and the OpenStack Compute plug-in.</para>
-        <para>The libvirt plugin for compute may maintain ephemeral storage directly on a filesystem, or in LVM. Filesystem storage generally will not overwrite data when it is removed, although there is a guarantee that dirty extents are not provisioned to users.</para>
+        <para>The libvirt plug-in for compute may maintain ephemeral storage directly on a filesystem, or in LVM. Filesystem storage generally will not overwrite data when it is removed, although there is a guarantee that dirty extents are not provisioned to users.</para>
         <para>When using LVM backed ephemeral storage, which is block-based, it is necessary that the OpenStack Compute software securely erases blocks to prevent information disclosure. There have in the past been information disclosure vulnerabilities related to improperly erased ephemeral block storage devices.</para>
         <para>Filesystem storage is a more secure solution for ephemeral block storage devices than LVM as dirty extents cannot be provisioned to users. However, it is important to be mindful that user data is not destroyed, so it is suggested to encrypt the backing filesystem.</para>
       </section>

doc/security-guide/ch051_vss-intro.xml

@@ -31,7 +31,7 @@
       at the hypervisor level becomes paramount. The requirement for
       secure isolation holds true across commercial, government, and
       military communities.</para>
-      <para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plugins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations as they pertain to feature sets that are critical to security. However, these considerations are not meant to be an exhaustive investigation into the pros and cons of particular hypervisors. NIST provides additional guidance in Special Publication 800-125, "<emphasis>Guide to Security for Full Virtualization Technologies</emphasis>".</para>
+      <para>Within the framework of OpenStack you can choose from any number of hypervisor platforms and corresponding OpenStack plug-ins to optimize your cloud environment. In the context of the OpenStack Security guide, we will be highlighting hypervisor selection considerations as they pertain to feature sets that are critical to security. However, these considerations are not meant to be an exhaustive investigation into the pros and cons of particular hypervisors. NIST provides additional guidance in Special Publication 800-125, "<emphasis>Guide to Security for Full Virtualization Technologies</emphasis>".</para>
     </section>
     <section xml:id="ch051_vss-intro-idp242144">
       <title>Selection Criteria</title>

doc/training-guides/module001-ch004-openstack-architecture.xml

@@ -313,14 +313,14 @@
       <itemizedlist>
         <listitem>
           <para>neutron-server accepts API requests and then routes
-            them to the appropriate Neutron plugin for action.</para>
+            them to the appropriate Neutron plug-in for action.</para>
         </listitem>
         <listitem>
-          <para>Neutron plugins and agents perform the actual actions
+          <para>Neutron plug-ins and agents perform the actual actions
             such as plugging and unplugging ports, creating networks
-            or subnets and IP addressing. These plugins and agents
+            or subnets and IP addressing. These plug-ins and agents
             differ depending on the vendor and technologies used in
-            the particular cloud. Neutron ships with plugins and
+            the particular cloud. Neutron ships with plug-ins and
             agents for: Cisco virtual and physical switches, NEC
             OpenFlow products, Open vSwitch, Linux bridging, the Ryu
             Network Operating System, and VMware NSX.</para>
@@ -333,7 +333,7 @@
           <para>Most Neutron installations will also make use of a
             messaging queue to route information between the
             neutron-server and various agents as well as a database to
-            store networking state for particular plugins.</para>
+            store networking state for particular plug-ins.</para>
         </listitem>
       </itemizedlist>
       <para>Neutron will interact mainly with Nova, where it will

doc/training-guides/module002-ch001-networking-in-openstack.xml

@@ -56,14 +56,14 @@
     <para>The original OpenStack Compute network implementation
         assumed a very basic model of performing all isolation through
         Linux VLANs and IP tables. OpenStack Networking introduces the
-        concept of a plugin, which is a pluggable back-end
+        concept of a plug-in, which is a pluggable back-end
-        implementation of the OpenStack Networking API. A plugin can
+        implementation of the OpenStack Networking API. A plug-in can
         use a variety of technologies to implement the logical API
-        requests. Some OpenStack Networking plugins might use basic
+        requests. Some OpenStack Networking plug-ins might use basic
         Linux VLANs and IP tables, while others might use more
         advanced technologies, such as L2-in-L3 tunneling or OpenFlow,
         to provide similar benefits.</para>
-    <para>The current set of plugins include:</para>
+    <para>The current set of plug-ins include:</para>
     <itemizedlist>
         <listitem>
             <para><emphasis role="bold">Big Switch, Floodlight REST
@@ -131,7 +131,7 @@
     </itemizedlist>
     <para>Plugins can have different properties in terms of hardware
         requirements, features, performance, scale, operator tools,
-        etc. Supporting many plugins enables the cloud administrator
+        etc. Supporting many plug-ins enables the cloud administrator
         to weigh different options and decide which networking
         technology is right for the deployment.</para>
     <para>Components of OpenStack Networking</para>
@@ -148,8 +148,8 @@
     <para>The main process of the OpenStack Networking server is
         quantum-server, which is a Python daemon that exposes the
         OpenStack Networking API and passes user requests to the
-        configured OpenStack Networking plugin for additional
+        configured OpenStack Networking plug-in for additional
-        processing. Typically, the plugin requires access to a
+        processing. Typically, the plug-in requires access to a
         database for persistent storage, similar to other OpenStack
         services.</para>
     <para>If your deployment uses a controller host to run centralized
@@ -164,21 +164,21 @@
             <para><emphasis role="bold">plugin agent
                     (quantum-*-agent):</emphasis>Runs on each
                 hypervisor to perform local vswitch configuration.
-                Agent to be run depends on which plugin you are using,
+                Agent to be run depends on which plug-in you are using,
-                as some plugins do not require an agent.</para>
+                as some plug-ins do not require an agent.</para>
         </listitem>
         <listitem>
             <para><emphasis role="bold">dhcp agent
                     (quantum-dhcp-agent):</emphasis>Provides DHCP
                 services to tenant networks. This agent is the same
-                across all plugins.</para>
+                across all plug-ins.</para>
         </listitem>
         <listitem>
             <para><emphasis role="bold">l3 agent
                     (quantum-l3-agent):</emphasis>Provides L3/NAT
                 forwarding to provide external network access for VMs
                 on tenant networks. This agent is the same across all
-                plugins.</para>
+                plug-ins.</para>
         </listitem>
     </itemizedlist>
     <para>These agents interact with the main quantum-server process
@@ -246,7 +246,7 @@
             <para><emphasis role="bold">Data network:</emphasis>Used
                 for VM data communication within the cloud deployment.
                 The IP addressing requirements of this network depend
-                on the OpenStack Networking plugin in use.</para>
+                on the OpenStack Networking plug-in in use.</para>
         </listitem>
         <listitem>
             <para><emphasis role="bold">External