openstack/openstack-manuals
Code Issues Proposed changes

Merge "bug 1192994 Describe the project code name change from Quantum to Neutron. Replace the Quantum references for Neutron in preface, install, use and config sections."

Browse Source
This commit is contained in:
Jenkins 2013-06-30 03:01:32 +00:00 committed by Gerrit Code Review
commit 5826c91473
4 changed files with 43 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/docbkx/openstack-network-connectivity-admin/ch_config.xml
View File

@ -211,13 +211,11 @@ catalog.$Region.network.name = Network Service</programlisting>
</section>
<section xml:id="nova_config_metadata">
<title>Metadata Configuration</title>
<para>The OpenStack Compute service allows VMs to query metadata
associated with a VM by making a web request to a special
169.254.169.254 address. Quantum supports proxying those
requests to nova-api, even when the requests are made from isolated
networks, or from multiple networks that use overlapping IP addresses.
Enabling this requires setting the following fields in nova.conf:
</para>
<para>The OpenStack Compute service allows VMs to query metadata associated with a VM by
making a web request to a special 169.254.169.254 address. Neutron supports proxying
those requests to nova-api, even when the requests are made from isolated networks,
or from multiple networks that use overlapping IP addresses. Enabling this requires
setting the following fields in nova.conf: </para>
<itemizedlist>
<listitem>
<para>

4
doc/src/docbkx/openstack-network-connectivity-admin/ch_install.xml
View File

@ -389,8 +389,8 @@ interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver
</section>
<section xml:id="install_quantum-l3">
<title>Install L3 Agent</title>
<para>Quantum has a widely used API extension to allow administrators and tenants to create "routers" that
connect to L2 networks.</para>
<para>Neutron has a widely used API extension to allow administrators and tenants to
create "routers" that connect to L2 networks.</para>
<para>Many plugins rely on the L3 service agent to implement this L3 functionality.
However, the following plugins have built in L3 capabilities:
</para>

29
doc/src/docbkx/openstack-network-connectivity-admin/ch_preface.xml
View File

@ -4,11 +4,18 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="ch_preface">
<title>Preface</title>
<para>OpenStack Networking was created to provide a rich and
tenant-facing API for defining network connectivity and
addressing in the cloud. The project, code-named "quantum,"
gives operators the ability to leverage different networking
technologies to power their cloud networking.   </para>
<para>OpenStack Networking was created to provide a rich and tenant-facing
API for defining network connectivity and addressing in the cloud.
The project, code-named "Neutron" (formerly known as Quantum), gives
operators the ability to leverage different networking technologies to
power their cloud networking. </para>
<para>The Board of Directors and Technical Committee members involved in
Networking related development and documentation has decided to change
the project name to "Neutron", as part of a legal agreement with Quantum
Corporation, the owner of the "Quantum" trademark.</para>
<para>Any references to the previous project code name will be removed in this guide whenever is
possible, all the configuration files will change in Havana release and this guide will be
updated respectively.</para>
<section xml:id="Intended_Audience-d1e85">
<title>Intended Audience</title>
<para>This guide assists OpenStack administrators in
@ -87,19 +94,17 @@
</section>
<section xml:id="resources">
<title>Resources</title>
<para>For more information on OpenStack Networking and the
other network-related projects, see the project page on
the OpenStack wiki (<link
xlink:href="http://wiki.openstack.org/Quantum"
>wiki.openstack.org/Quantum</link>). </para>
<para>For more information on OpenStack Networking and the other network-related projects,
see the project page on the OpenStack wiki (<link
xlink:href="https://wiki.openstack.org/wiki/Neutron"
>wiki.openstack.org/Neutron</link>). </para>
<para>For information about programming against the OpenStack
Networking API, see the <link
xlink:href="http://docs.openstack.org/api/openstack-network/2.0/content/"
><citetitle>OpenStack Networking API Guide
(v2.0)</citetitle></link>.</para>
<para>We welcome feedback, comments, and bug reports at <link
xlink:href="http://bugs.launchpad.net/Quantum"
>bugs.launchpad.net/Quantum</link>. </para>
xlink:href="https://bugs.launchpad.net/neutron">bugs.launchpad.net/Neutron</link>. </para>
</section>
<?hard-pagebreak?>
</preface>

37
doc/src/docbkx/openstack-network-connectivity-admin/ch_using.xml
View File

@ -15,15 +15,12 @@
admin on behalf of the tenant.  </para>
<section xml:id="api_features">
<title>Core OpenStack Networking API Features</title>
<para>Once OpenStack Networking is installed and running, both tenants and
admins primarily interact with the service via
create-read-update-delete (CRUD) API operations performed
either directly against the API, or more commonly via the
'quantum' CLI tool.  Like other OpenStack CLI tools, the
'quantum' tool is just a basic wrapper around the OpenStack Networking
API, so any operation that can be performed via the CLI
has an equivalent API call that can be performed
programmatically.  </para>
<para>Once OpenStack Networking is installed and running, both tenants and admins primarily
interact with the service via create-read-update-delete (CRUD) API operations performed
either directly against the API, or more commonly via the 'neutron' CLI tool.  Like
other OpenStack CLI tools, the 'neutron' tool is just a basic wrapper around the
OpenStack Networking API, so any operation that can be performed via the CLI has an
equivalent API call that can be performed programmatically.  </para>
<para>The CLI supports many options for filtering results, limiting fields show, etc.  For
details, refer to the OpenStack Networking CLI documentation.   </para>
<section xml:id="api_abstractions">
@ -442,21 +439,25 @@ nova boot --image &lt;img&gt; --flavor &lt;flavor&gt; --nic port-id=&lt;port-id&
</section>
<section xml:id="enabling_ping_and_ssh">
<title>Security Groups (Enabling Ping and SSH on VMs)</title>
<para>If using a plugin that implements quantum security groups you can configure security group rules directly
by using quantum security-group-rule-create to enable access to your VMs. The example below allows <command>ping</command>
and <command>ssh</command> to your VMs.
<screen>
<para>If using a plugin that implements neutron security groups you can configure security
group rules directly by using quantum security-group-rule-create to enable access to
your VMs. The example below allows <command>ping</command> and
<command>ssh</command> to your VMs.
<screen>
<prompt>$</prompt> <userinput>quantum security-group-rule-create --protocol icmp --direction ingress default</userinput>
<prompt>$</prompt> <userinput>quantum security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress default</userinput>
</screen></para>
<para>If your plugin does not implement quantum security group, security groups can still be leveraged via OpenStack Compute.
This can be done using <command>nova secgroup-add-rule</command> or <command>euca-authorize</command> command to enable accesses to your VMs.
Below are the nova commands to allow <command>ping</command> and <command>ssh</command> to your VMs.</para>
<para>If your plugin does not implement neutron security group, security groups can still be
leveraged via OpenStack Compute. This can be done using <command>nova
secgroup-add-rule</command> or <command>euca-authorize</command> command to
enable accesses to your VMs. Below are the nova commands to allow
<command>ping</command> and <command>ssh</command> to your VMs.</para>
<screen>
<prompt>$</prompt> <userinput>nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0</userinput>
<prompt>$</prompt> <userinput>nova secgroup-add-rule default tcp 22 22 0.0.0.0/0</userinput></screen>
<note><para>If your plugin implements quantum security groups you can still leverage nova security groups by setting security_group_api = quantum in <filename>nova.conf</filename>.
After setting this all nova security group commands will be proxied to quantum.</para></note></section>
<note><para>If your plugin implements neutron security groups you can still leverage nova security groups
by setting security_group_api = quantum in <filename>nova.conf</filename>. After
setting this all nova security group commands will be proxied to quantum.</para></note></section>
</section>
</chapter>