| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch adds a new BondInterfaceOvsOptions to the bond.yaml.
Sometimes there is no need to use vlans and therefore bond-with-vlans
template files. This approach allows to setup things like LACP or
the bonding mode via a nested stack heat parameter.
Change-Id: I2d318aa738ab609bc76212bef49b2c5986d6dcdf
|
|
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 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 patch removes the custom config_id outputs and replaces
it with OS::stack_id which allows us to just call get_resource
in the parent stack.
The motivation for this change is we'll be adding more os-net-config
templates and it would be nice to take advantage of this newer
template feature.
Change-Id: I6fcb26024b94420779b86766e16d8a24210c4f8e
|
|
This patch adds parameters so that we can pass in the
ipaddress/subnet for each of the isolated overcloud
traffic nets to os-net-config templates. This
interface change will allow deployers to plug
in a custom version of an os-net-config template
that drives isolated network configuration.
Change-Id: I35bbe9a0bd81e79f9bfd531fe89c700af8b354c4
|
|
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 example extends the compute software configuration
so that heat metadata is used to model the os-net-config
YAML (ultimately JSON) directly. The existing
os-net-config element already supports this format.
Configuring the physical network layer in this manner
would supplant the ever growing list of Heat parameters
that we have and is something that could be automatically
generated via tuskar.
The default is to use net-config-noop.yaml which
will pass no config metadata into the os-net-config
element which will essentially disable it in favor
of using parameters w/ init-neutron-ovs.
Change-Id: I30f325b1751caaef5624537e63ee27c2e418d5c8
|
Eugene Bagdasaryan
Dan Sneddon
Dan Prince