| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
The default balance-tcp is causing issues with deployments.
Defaulting to active-backup.
After ~ 100 guests (total) connectivity to each guest would become spotty
(simple pings would fail, then become successful.) In /var/log/messages
we saw :
"overcloud-controller-1 kernel: openvswitch: ovs-system: deferred action
limit reached, drop recirc action"
For more details, refer to this link:
http://openvswitch.org/pipermail/discuss/2015-October/019168.html
Change-Id: Ia0f2592a289e13472b98d97057cd516c5048fe59
|
|
Because many of the service endpoints URLs use the same patterns for
generating the URLs it makes sense to use the same templates to reduce
the copy and paste.
In the process also adds support for explicitly specifying hostnames
for use in the endpoints. Note: DNS must be pre-configured. The
Heat templates do not directly configure DNS.
Change-Id: Ie3270909beca3d63f2d7e4bcb04c559380ddc54d
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
|
|
This change adds a set of network interface configurations for use
with network isolation. The multiple-nics templates includes one
separate NIC per network, and assumes that nic1 is used for the
provisioning network (ctlplane). Also included is an environment
file for including the multiple-nics configuration in a deployment.
This revision changes the ordering of the NICs. By doing that, it
is possible to wire up only a subset of the NICs for the storage
nodes, and it is possilbe to leave the External NIC only configured
on the controllers.
rdo: Updated this commit for static control plane configuration
Co-Authored-By: Rhys Oxenham <roxenham@redhat.com>
Change-Id: Ic878d1ed1a85b5705295d087a743570ca8213504
|
|
This patch adds a new optional DnsServers parameter
which can be used to provide a custom list of DNS
resolvers which will be configured in resolv.conf.
Change-Id: I2bb7259ebc09d786dc56da18694c862f802091b1
Depends-On: I9edecfdd4e1d0f39883b72be554cd92c5685881d
|
|
This patch updates all network configuration templates so that
we configure the ctlplane network interface with a static IP
instead of using DHCP.
The IP address used for the static IP is passed into each
nested stack network configuration template via the ControlPlaneIp
parameter.
Three new nested stack parameters called ControlPlaneSubnetCidr,
ControlPlaneDefaultRoute, and EC2MetadataIp have been added to help
configure the CIDR, default route, and EC2 metadata route on the ctlplane
statically. These parameters can be customized via the
parameter_defaults section in the heat environment.
A single new template called net-config-static-bridge.yaml has
been added to help migrate towards using the static
configuration templates when not using network isolation.
Depends-On: I257e1cba6dee16f73f75512d1284e1e3b9d4c831
Change-Id: Ib267e6dcf2d5ff77f7a82ee20a123965c2d07565
|
|
The latest Heat API is a bit more strict in validating
the datatypes for the OS::Neutron::Net value_specs.
This patch converts the default parameter types for
these from string to json.
Change-Id: Iaad6ee6417d3ae55c52ffe2f4e6ed79124161923
Closes-bug: #1493502
|
|
When using network isolation you might want to selective
move one of the services back to the default ctlplane network
by simply using the ServiceNetMap parameter. This patch
adds ctlplane to the output parameters for both
the net_ip_map and net_ip_list_map nested stacks so that
this is possible.
As part of this patch we also split out the NetIpSubnetMap
into its own unique nested stack so that the Heat input
parameters for this stack are more clearly named.
Change-Id: Iaa2dcaebeac896404e87ec0c635688b2a59a9e0f
|
|
This change removes a hardcoded value for the bond name in the NIC
config for the compute node in the bond-with-vlan NIC config
templates. When this hardcoded value of "br-bond" is used, then the
Neutron bridge mappings must be set to set to datacentre:br-bond in
order for VLAN mode networking to recognize the bridge. By using the
input value for bridge_name we will ensure that the controller and
compute nodes have the same bridge name (defaults to "br-ex"), and
that the defaults will work with VLAN mode.
Change-Id: I28654ab93e3c10a8597c8b877f3f2f6b3eca887c
|
|
This change adds a default setting for the OVS bond options to the
bond-with-vlans controller.yaml. This default will attempt to bring
up LACP bonding, but should that fail it will bring up the bond in
active/backup mode. This is a safe configuration if the switch is
not configured for bonding.
Change-Id: I91aad1e061ed1ecf26636e60da7a9a6e9cde50a5
|
|
This change brings PublicVirtualIP in line with the rest of the
VIPs in how it is created. This allows the network where
PublicVirtualIP is instantiated to be on cltplane when network
isolation is not used, and on the external network when network
isolation is used. This change removes the PublicVirtualNetwork
parameter, since it is no longer used. In order to continue to
support the PublicVirtualFixedIPs parameter, which is used to
provide a specific IP for the PublicVirtualIP, the FixedIP
parameter was added to cltplane_vip.yaml, vip.yaml, and
noop.yaml. The value of PublicVirtualIP is passed to FixedIP
in the VIP templates. This change also moves the default
network for keystone public api to the external net (which will
fallback to ctlplane if network isolation isn't used).
Change-Id: I3f5d35cbe55d3a148e95cf49dfbaad4874df960b
|
|
|
|
This change adds a parameter for ExternalInterfaceDefaultRoute
and uses that parameter to set the default route on the controller
nodes. This allows Horizon and the public APIs to be reachable from
routed networks outside the overcloud.
Co-Authored-By: Dan Prince <dprince@redhat.com>
Change-Id: I67a72767342237049f53f5085a6faf891fbf0c30
|
|
The bridge that is built on the bonds in the bond-with-vlans
example has an extraneous bridge on the storage and compute
templates, and an incorrect bridge on the controller template.
There is no reason to do anything on nic1, which is assumed to
be the provisioning interface, because it will be configured by
DHCP. Also, on the controller template we actually want br-ex
to contain the VLAN with the external network, rather than be
configured on the provisioning interface.
Change-Id: Ibe2343d5281f7b63a7b63b17d96d8442d0b96105
|
|
There are two files in network/ports which control the VIP
behavior called ctlplane_vip.yaml and vip.yaml. One of these
files was missing ControlPlaneNetwork, since it wasn't used
inside the template. Unfortunately, tuskar chokes on this,
even though Heat can build the stack just fine. This change
makes the vip.yaml and ctlplane_vip.yaml equivalent by adding
ControlPlaneNetwork to the vip.yaml template.
Change-Id: Ic20281e58a1130afe18d5aec505a3df199841fd5
|
|
|
|
|
|
|
|
The file network/external.yaml has a typo in the last commit. It
should have been a get_param instead of a get_resource. This
change fixes that line in that file.
Change-Id: Ibc0db0510e9b5dae3c4669a620c642357906cbc2
|
|
This patch adds parameters to configure the various
vlan IDs to all of the bond-with-vlans and single-nic-vlans
network config templates.
Change-Id: Ia6196735927777b73879e8086568f8a435597c6c
|
|
|
|
|
|
The redis_vip should come from a Neutron Port as its cidr depends
on the Neutron Network configuration. This change adds 2 new files
and modifies 1 in the network/ports directory:
- noop.yaml - Passes through the ctlplane Controller IP (modified)
- ctlplane_vip.yaml - Creates a new VIP on the control plane
- vip.yaml - Creates a VIP on the named network (for isolated nets)
Also, changes to overcloud-without-mergepy.yaml create the
Redis Virtual IP. The standard resource registry was modified to
use noop.yaml for the new Redis VIP. The Puppet resource registry
was modified to use ctlplane_vip.yaml by default, but can be made
to use vip.yaml when network isolation is used by using an
environment file. vip.yaml will place the VIP according to the
ServiceNetMap, which can also be overridden.
We use this new VIP port definition to assign a VIP to Redis,
but follow-up patches will assign VIPs to the rest of the
services in a similar fashion.
Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
|
|
This patch adds new '<net name>AllocationPool' parameters
to all of the isolated network nested stacks so that users
can easily control the allocation ranges on these networks.
Change-Id: I44b564831446c62e3489a69d992e0fb1f642b085
|
|
This patch adds a new BondInterfaceOvsOptions to the
bond-with-vlans network config templates. This can
be used to configure things like LACP or the bonding mode
via a nested stack heat parameter.
The patch also removes the hard coded ovs_options relating
to both bond-with-vlans and single-nic-with-vlans configurations
which do not actually require this setting to be hard coded
because by default OVS trunks vlan ports automatically.
Change-Id: I3effbccba8ed7ed28d6ba715e5709275d4e7f984
|
|
None of the storage roles have Heat parameters for the bridge
name. Instead of wiring in Heat parameters for bridge name
this patch hard codes the bridge name for the storage roles
to 'br-storage'.
This functionally fixes the network config scripts for each
of the storage roles.
For the single-nic-vlans storage roles we also remove
the 'bond1' reference which was also incorrectly specified.
Change-Id: I460d1a17e44ee49e960117ec85edd3ae25894333
|
|
|
|
|
|
For VIP ports we set an explicit name on the ports. This
patch adds an optional PortName parameter to the ports
objects which can be used to specify a name.
Change-Id: Iad0f5e4cfc31a931dbb574d9e589570125e9465c
|
|
This patch adds a new NetIpListMap abstraction which we can use
to make the all-nodes-config IP list network assignments
configurable. Ip address lists for all overcloud services
which require IPs were added to all-nodes-config so
that puppet manifests can be directly supplied the
correct network list for each service.
Change-Id: I209f2b4f97a4bb78648c54813dad8615770bcf1a
|
|
This patch adds 5 new role templates to help configure
a vlans on top for each of the overcloud roles. This
patch adds vlans on top of a single NIC attached to
the control plane network (already used for provisioning).
The patch also includes an environment file to
enable configuration of vlans by simply sourcing this file.
Change-Id: Ibc40e452dec9b372ff10442aab2bddaf382b0a2f
|
|
Change-Id: Ifa59cf2f1f6b16bc785b19aef215659b95876237
|
|
This patch adds 5 new role templates to help configure
an OVS bond with vlans on top for each of the overcloud
roles.
These are meant to represent a more production network
which might use isolated nets, and should help facilitate
create a CI job which configures a bond w/ vlans on it.
The patch also includes an environment file to
enable configuration of bonded vlans by simply
sourcing this file.
Change-Id: Ibe4c9d933445014ce3bec5fb3d7e3139fc40cb32
|
|
This patch adds a resource which constructs a Json output
parameter called net_ip_map which will allow us to easily
extract arbitrary IP addresses for each network using the
get_attr function in heat.
The goal is to use this data construct in each role
template to obtain the correct IP address on each
network.
Change-Id: I1a8c382651f8096f606ad38f78bbd76314fbae5f
|
|
This patch adds a set of templates to create ports on isolated
networks via Heat. There are 5 port templates in total
which are split out according to the available overcloud
networks.
Change-Id: I5175ef48c1960ea0d13fc8518328db53921c70cd
|
|
This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.
Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
|
|
This patch adds a new abstraction for network creation
within Heat. This (optional) set of templates may be disabled
if you wish to create Neutron networks for the undercloud
via Heat templates... instead of using os-cloud-config
JSON to do so. Creating networks with Heat has the benefit
of being parameter driven so that users can quickly
enable networks using the resource registry and parameters.
There are 5 networks to start with which are roughly modeled
around networks an Overcloud user might want to use to isolate
their traffic. The intent is to make these opt-in and
configurable for end users.
The networks.yaml template can be used to create all of the
networks using parameters in the resource registry.
Change-Id: I5f2b3356378eb263d90d428cc83c7f5b141957e1
|
Jenkins
Joe Talerico
Mark Chappell
Dan Sneddon
Dan Prince
Giulio Fidente
Ben Nemec