openstack/charm-neutron-gateway
Code Issues Proposed changes

Documentation fixes in README and config

Browse Source
This commit is contained in:
Chris Johnston 2015-09-15 20:26:06 +00:00
parent 200e6fe388
commit 9761f44638
2 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
README.md
View File

@ -4,11 +4,11 @@ Overview
Neutron provides flexible software defined networking (SDN) for OpenStack.
This charm is designed to be used in conjunction with the rest of the OpenStack
related charms in the charm store) to virtualized the network that Nova Compute
related charms in the charm store to virtualize the network that Nova Compute
instances plug into.
Its designed as a replacement for nova-network; however it does not yet
support all of the features as nova-network (such as multihost) so may not
It's designed as a replacement for nova-network; however it does not yet
support all of the features of nova-network (such as multihost) so may not
be suitable for all.
Neutron supports a rich plugin/extension framework for propriety networking
@ -20,14 +20,14 @@ for more details.
Usage
-----
In order to use Neutron with Openstack, you will need to deploy the
In order to use Neutron with OpenStack, you will need to deploy the
nova-compute and nova-cloud-controller charms with the network-manager
configuration set to 'Neutron':
nova-cloud-controller:
network-manager: Neutron
This decision must be made prior to deploying Openstack with Juju as
This decision must be made prior to deploying OpenStack with Juju as
Neutron is deployed baked into these charms from install onwards:
juju deploy nova-compute
@ -43,7 +43,7 @@ The Neutron Gateway can then be added to the deploying:
The gateway provides two key services; L3 network routing and DHCP services.
These are both required in a fully functional Neutron Openstack deployment.
These are both required in a fully functional Neutron OpenStack deployment.
See upstream [Neutron multi extnet](http://docs.openstack.org/trunk/config-reference/content/adv_cfg_l3_agent_multi_extnet.html)
@ -53,14 +53,14 @@ Configuration Options
External Port Configuration
===========================
If the port to be used for external traffic is consistent accross all physical
If the port to be used for external traffic is consistent across all physical
servers then is can be specified by simply setting ext-port to the nic id:
neutron-gateway:
ext-port: eth2
However, if it varies between hosts then the mac addresses of the external
nics for each host can be passed as a space seperated list:
nics for each host can be passed as a space separated list:
neutron-gateway:
ext-port: <MAC ext port host 1> <MAC ext port host 2> <MAC ext port host 3>
@ -71,7 +71,7 @@ Multiple Floating Pools
If multiple floating pools are needed then an L3 agent (which corresponds to
a neutron-gateway for the sake of this charm) is needed for each one. Each
gateway needs to be deployed as a seperate service so that the external
gateway needs to be deployed as a separate service so that the external
network id can be set differently for each gateway e.g.
juju deploy neutron-gateway neutron-gateway-extnet1
@ -100,8 +100,8 @@ charm's instance-mtu option can be used to reduce instance MTU via DHCP.
juju set neutron-gateway instance-mtu=1400
OpenStack upstream documentation recomments a MTU value of 1400:
[Openstack documentation](http://docs.openstack.org/admin-guide-cloud/content/openvswitch_plugin.html)
OpenStack upstream documentation recommends a MTU value of 1400:
[OpenStack documentation](http://docs.openstack.org/admin-guide-cloud/content/openvswitch_plugin.html)
Note that this option was added in Havana and will be ignored in older releases.
@ -125,7 +125,7 @@ The minimum openstack-origin-git config required to deploy from source is:
Note that there are only two 'name' values the charm knows about: 'requirements'
and 'neutron'. These repositories must correspond to these 'name' values.
Additionally, the requirements repository must be specified first and the
neutron repository must be specified last. All other repostories are installed
neutron repository must be specified last. All other repositories are installed
in the order in which they are specified.
The following is a full list of current tip repos (may not be up-to-date):

10
config.yaml
View File

@ -38,7 +38,7 @@ options:
NOTE: updating this setting to a source that is known to provide
a later version of OpenStack will trigger a software upgrade.
NOTE: when openstack-origin-git is specified, openstack specific
NOTE: when openstack-origin-git is specified, OpenStack specific
packages will be installed from source rather than from the
openstack-origin repository.
openstack-origin-git:
@ -126,7 +126,7 @@ options:
Configure DHCP services to provide MTU configuration to instances
within the cloud. This is useful in deployments where its not
possible to increase MTU on switches and physical servers to
accomodate the packet overhead of using GRE tunnels.
accommodate the packet overhead of using GRE tunnels.
enable-l3-agent:
type: boolean
default: True
@ -147,7 +147,7 @@ options:
description: |
Used by the nrpe-external-master subordinate charm.
A string that will be prepended to instance name to set the host name
in nagios. So for instance the hostname would be something like:
in Nagios. So for instance the hostname would be something like:
juju-myservice-0
If you're running multiple environments with the same services in them
this allows you to differentiate between them.
@ -155,7 +155,7 @@ options:
default: ""
type: string
description: |
A comma-separated list of nagios servicegroups.
A comma-separated list of Nagios servicegroups.
If left empty, the nagios_context will be used as the servicegroup
bridge-mappings:
type: string
@ -201,7 +201,7 @@ options:
If True will enable Pacemaker to monitor the neutron-ha-monitor daemon
on every neutron-gateway unit, which detects neutron agents status and
reschedule resources hosting on failed agents, detects local errors and
release resources when network is unreachable or do neccessary recover
release resources when network is unreachable or do necessary recover
tasks. This feature targets to < Juno which doesn't natively support HA
in Neutron itself.
ha-bindiface: