Age | Commit message (Collapse) | Author | Files | Lines |
|
This change updates the descriptions of bond paramters in the bonded network
interface templates. Previously, only OVS bond settings were mentioned,
and the description for the bond options constraints had extra whitespace.
This change mentions settings for Linux bonds, and removes extra spaces.
Change-Id: Id50c042ae4a3b9298e8de0364e315b9f8777b79f
|
|
Master is now the development branch for pike
changing the release alias name.
Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
|
|
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.
This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.
Change-Id: Ib415e7290fea27447460baa280291492df197e54
|
|
This change adds a NIC config to the multiple-nics sample NIC
config templates for a compute node running DVR. In order for
DVR to work on the compute nodes, they must share an external
bridge with the controllers. All of the other sample NIC
configs already have an external bridge (defaults to 'br-ex'),
but the multiple-nics compute role does not, so now the
compute-dvr.yaml NIC template will demonstrate DVR with
multiple NICs.
Change-Id: I80fe2e5842a67984e1d4d8aa295c7607c4f340ad
|
|
Wire in os-net-config via a normal script heat deployment, which has the
following advantages:
1. Improved error path, currently o-a-c deployments don't report any
errors, thus hang and eventually the deployment times out
2. It's far more hackable from a deployer perspective, e.g it's
much easier to change the os-net-config options or include a
mapping file
3. Reduces our dependencies on o-a-c (it's only os-net-config and hiera
which requires it), although the script does currently still use oac to
get the metadata IP.
4. May enable passing os-net-config yaml via a json parameter in future,
reducing the need for resource_registry mappings (although we'll have to
support that for backwards compatibility)
The script used is based directly on 20-os-net-config (from t-i-e
at cf94c5e, we can probably improve this now that we have an error path,
but for this initial commit it's a straight copy other than the changes to
replace o-a-c for rendering the json config file.
Co-Authored-By: Steven Hardy <shardy@redhat.com>
Change-Id: I0ed08332cfc49a579de2e83960f0d8047690b97a
|
|
This patch cleans up some inline comments that are a bit
non-standardly formatted so that we can more easily parse
these templates in an automated fashion.
Change-Id: Ibf91f3478fd894f9323d8805729ece9c5fab256f
|
|
|
|
Added an environment file to configure DPDK with OVS
by overriding ComputeNeutronOvsAgent. Also added nic
configs for configuring DPDK bridge and bond with
numbered nic format.
Implements: blueprint tripleo-ovs-dpdk
Co-Authored-By: Vijay Chundury <vchundur@redhat.com>
Change-Id: I82b6f66394a8928f8524706c939508edd08afa9b
|
|
This patch adds an allowed_pattern contraint that uses a negative
lookahead assertion to only allow options strings that do not contain
the 'balance-tcp' option.
Change-Id: Icf8874e4e585f9a42d38091f8b38c3685f403cf1
Partial-Bug: #1612786
|
|
This change adds the ManagementInterfaceDefaultRoute parameter
for setting the Management network as the default route in some
deployments. Notes were added to indicate that if the Management
network is used as the default gateway, then the default route
on the control plane should be commented out.
The sample network-environment.yaml was modified to include the
ManagementInterfaceDefaultRoute, but this is commented out like
the rest of the Management network parameters.
This change also adds the ControlPlaneDefaultRoute and
ExternalInterfaceDefaultRoute to all templates, so that if the
networks are customized, the NIC configs can be modified without
having to modify the parameters section of the template. The
default for the ExternalInterfaceDefaultRoute is '10.0.0.1', and
the default for ManagementInterfaceDefaultRoute is set to 'unset'.
This change also converts the single-nic-linux-bridge-vlans from
DHCP to static IPs on the Control Plane Interface, bringing these
templates in line with the rest of the NIC config templates. The
parameters needed to be updated in these templates as well.
The controller-v6.yaml templates had a default value of "10.0.0.1"
for the ExternalInterfaceDefaultRoute. This was confusing, and is
now undefined.
This change also sets a default gateway on the Control Plane in
controller-no-external.yaml templates.
Change-Id: I8ea6733fe46902e1baeff4ccfbcd42ecc5a1825f
|
|
For some reason the controller-no-external.yaml template is configured
for DHCP on the control plane interface. We switched to static control
plane IPs before the controller-no-external.yaml was created (IIRC), so
I'm not sure how that happened. This change brings the
controller-no-external.yaml in line with the rest of the bonded NIC
templates.
Change-Id: I2ac929e241707db72a0beabf9d5cd7fc14b90f76
|
|
This change adds Controller NIC configs for the sample NIC config
templates that are compatible with IPv6 on the External network.
These controller-v6.yaml templates include a default route for IPv6
on the External network, and a default route for IPv4 on the Control
Plane. The Heat parameters ExternalNetworkDefaultRoute and
ControlPlaneDefaultRoute are used to set these values.
Change-Id: Ifed8cb359eae1d9d623d3eb2fe40ea8a0d1d889a
|
|
Define environments to create VLANs attached to a single physical nic as
'single-nic-vlans' does, but using linux_bridge instead of ovs_bridge
Change-Id: I8c6fe9ec7028178f783e7d9c0a1cc67a1517eb3d
|
|
One of the interfaces was not indented at the same level as the
others in some of the templates.
Change-Id: Iabd835724848d754d5522968e1c8e3cf9f78e6c6
|
|
This change adds a system management network to all overcloud
nodes. The purpose of this network is for system administration,
for access to infrastructure services like DNS or NTP, or for
monitoring. This allows the management network to be placed on a
bond for redundancy, or for the system management network to be
an out-of-band network with no routing in or out. The management
network might also be configured as a default route instead of the
provisioning 'ctlplane' network.
This change does not enable the management network by default. An
environment file named network-management.yaml may be included to
enable the network and ports for each role. The included NIC config
templates have been updated with a block that may be uncommented
when the management network is enabled.
This change also contains some minor cleanup to the NIC templates,
particularly the multiple nic templates.
Change-Id: I0813a13f60a4f797be04b34258a2cffa9ea7e84f
|
|
The non-controller nodes in the network/config/multiple-nics
directory do not have a default route configured. This change
adds the default route to the non-controller nodes using the
ControlPlaneDefaultRoute parameter, which was already a part
of these templates.
Change-Id: Idaaeb2a539555ac14cc613b202c428108bc19a30
|
|
|
|
|
|
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
|
|
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
|
|
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 patch adds extra heat environments that can be used
to enable network isolation without using the external
network. Instead of a separate external network the ctlplane
will be used for all of the external/public traffic.
Change-Id: Ia542cee02121771d7d57ac701b62d7608e8d1855
|
|
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 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
|
|
|
|
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
|
|
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
|
|
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
|