| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
Dan Sneddon
Dan Prince
Jenkins
Ben Nemec