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
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
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