The subnet property is added to puppet/role.role.j2.yaml as
`{{role}}ControlPlaneSubnet`. Roles with a different subnet specified
can be used to deploy a routed network architecture by using one
role per routed network.
When enabling the neutron segments plug-in to support routed-networks
the neutron IPAM code will defer ipallocation unless the port create
request contain enough details. (Ref: LP Bug: #1695740) By adding the
subnet to port create request this change enables tripleo deployment
on an undercloud with Neutron segments plug-in and routed networks.
This depends on a Heat change that improves network logic in server
resource to not replace the current port if new props match what is
on the current interface. Without this adding the subnet property on
update/upgrades would cause a port replacement, which in turn would
cause IPAM info in undercloud neutron to miss-match the deployed
overcloud nodes.
Depends-On: Iab75ec49b962617943017dcaf1b04b89f91a982e
Change-Id: I33804bfd105a13c25d6057e8414e09957939e8af
Implements: blueprint tripleo-routed-networks-deployment
Remove these from the j2 excludes and instead render all the networks
to avoid duplication.
Change-Id: Id8e14e06ffe959c50456b4c88fef306046a8b478
Partially-Implements: blueprint composable-networks
This change renders the network IP maps and hostname maps for
all networks defined in network_data.yaml. This should make it
possible to create custom networks that will be rendered for
all applicable roles.
Note that at this time all networks will be rendered whether
they are enabled or not. All networks will be present in all
roles, but ports will be associated with noop.yaml in roles
that do not use the network. This is in accordance with
previous behavior, although we may wish to change this in
the future to limit the size of the role definitions and
reduce the number of placeholder resources in deployments
with many networks.
Note that this patch is a replacement for original patch
https://review.openstack.org/#/c/486280, which I was having
trouble rebasing to current.
Change-Id: I445b008fc1240af57c2b76a5dbb6c751a05b7a2a
Depends-on: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a
Partially-implements: blueprint composable-networks
Use the network.network.j2.yaml to render these files, instead
of relying on the hard-coded versions.
Note this doesn't currently consider the _v6 templates as we may want
to deprecate these and instead rely on an ipv6 specific network_data file,
or perhaps make the network/network.network.j2.yaml generic and able to
detect the version from the cidr?
Change-Id: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a
Partially-Implements: blueprint composable-networks
This change modifies the templates to dynamically define the VIPs
based on network_data.yaml. If a network is defined and marked
with "vip: true" in network_data.yaml, it will be included in the
overcloud.yaml which defines the deployment-level resources.
This should make it possible to create custom networks and
use them for services which use high-availability through VIPs.
Also, extraconfig/nova_metadata/krb-service-pricipals.yaml
was modified to dynamically produce the FQDN map for VIPs on
isolated networks, to match overcloud.j2.yaml.
Depends-On: If074f87494a46305c990a0ea332c7b576d3c6ed8
Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab
Partially-implements: blueprint composable-networks
Closes-bug: 1667104
Change-Id: I71339a6ac41133e95dbc3f93abb7a9fdeb0f2da0
These are mostly the low hanging fruit that only required a few
minor changes to fix. There are more that require a lot of changes
or might be more controversial that will be done later.
Change-Id: I55cebc92ef37a3bb167f5fae0debe77339395e62
Partial-Bug: 1700664
This change adds templates that are used to create network and
port definition templates for each network that is defined in
network_data.yaml. In order to render the templates, additional
fields have been added to the network_data.yaml file. If this
optional data is present, it will be used to populate the default
parameter values in the network template.
The only required parameters in the network_data.yaml file is
the network name. If the network will have IPv6 addresses, then
ipv6: true must be set on the network.
The existing networks have been modeled in the network_data.yaml,
but until these templates are removed from the j2_excludes.yaml
file they will not be generated on the fly. Any additional
networks will have templates generated.
This change also removes an unnecessary conditional from the
networks.j2.yaml file, since InternalApiNetwork doesn't need
to be reformatted as InternalNetwork (it's only used in this
one file).
A follow-up patch will remove the existing network definitions
so all networks are created dynamically.
Change-Id: If074f87494a46305c990a0ea332c7b576d3c6ed8
Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab
Partially-Implements: blueprint composable-networks
Adds in the execution environment of the workflow steps a list of
per-service network IPs. This can be used by the workflows to
execute actions against the nodes hosting a given service.
Change-Id: Id7c735d53f04f6ad848b2f9f1adaa3c84ecd2fcd
Implements: blueprint tripleo-ceph-ansible
Add 2 new environments to faciltate deploying split-stack:
environments/overcloud-baremetal.j2.yaml
environments/overcloud-services.j2.yaml
The environments are used to deploy 2 separate Heat stacks, one for just
the baremetal+network configuration and one for the service
configuration.
In order to keep Heat's view of the server's hostname consistent across
the 2 stacks the 2 environments set the same HostnameFormat with
"overcloud" as the stack name.
implements blueprint split-stack-default
Change-Id: I0b3f282c08af6fecea8f136908b806db70bada46
This needs to handle a ServiceNetMap containing non-default
network names when they are overridden via the *NetName parameters.
Closes-Bug: #1651541
Change-Id: I95d808444642a37612a495e822e50449a7e7da63
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
In order to call commands that need to be run on a single node, we
create a new per-service variable that will contain the first node of
each role containing the service.
Change-Id: I03e8685f939e8ae1fcd8b16883b559615042505d
Partial-Bug: #1615983
These hard-coded references to the Controller role mean that
things won't work if the keystone service is moved to any other
role, so we need to generate the lists dynamically based on the
enabled services for each role.
Change-Id: I5f1250a8a1a38cb3909feeb7d4c1000fd0fabd14
Closes-Bug: #1629096
Without this, deployments using the from_service.yaml port for
service VIPs will fail with:
"Property error: : resources.RedisVirtualIP.properties: : Unknown
Property FixedIPs"
Change-Id: Ie0d3b940a87741c56fe022c9e50da0d3ae9b583b
Closes-Bug: 1627189
Previously [1] we updated from_pool_v6 to use str_split but mistakenly
copy/pasting lines referencing an attribute which isn't created in
these templates.
1. I282dbc025500b1628d4f08a49b54a2adefd38b5f
Closes-Bug: 1624412
Change-Id: I409ff5b36eab2a791db4d352dea5b68096c2dc21
This allows us to create $service_node_ips and $service_node_names
hiera entries for services not deployed on the Controller role.
Co-Authored-By: Thomas Herve <therve@redhat.com>
Change-Id: I688618dda05ff908293c32b9d8518697d57e9eb0
Partially-Implements: blueprint custom-roles
Some puppet interfaces require a comma separated list of hostnames
where a service is running, so generate it in a similar way to th
service ips.
Change-Id: Icdf5d993d089dc94035194bdbd52299fcbc793be
Partially-Implements: blueprint custom-roles
Currently we have a hard-coded list of ips for various services that
run on the controller, instead we can dynamically generate that list
of per-service ips, initially only for the controller but this approach
can be extended so it works for any role.
Change-Id: I3c8a946e439539d239ad7281a1395414df0893eb
Partially-Implements: blueprint custom-roles
Takes the net_ip_uri_map value from the *_uri values emitted
by net_ip_map instead.
Also removes TenantIp and TenantIpUri from net_vip_map_external
templates as there won't be any VIP on the tenant network.
Change-Id: Icdac3d58162891f5ca3d5c20f14fcdff1781996f
To allow per-node data such as bind_ip's to move into the
composable services templates, we do a value substitution
on the config settings hiera map, where e.g internal_api
will be replaced with the NetIpMap IP assigned to that.
To enable subnet/uri lookup via the same method, we add
all the subnet/uri mappings to the main net_ip_map output.
Change-Id: I7850d4dc8bf4db5f7ac6a6b53c1d900b561b4580
This change introduces the ability to use IPv6 addressing for the
management network by passing the network-management-v6.yaml
environment file. It also adjusts the network-management.yaml
environment file to point to the right network config templates.
Change-Id: I7f797c49f03b2623a08e033bdf45772edff0f08f
The str_split function was added after the 2015-04-30 release so
it wasn't working as intended.
Change-Id: Ib8827879182e6ea3bd2227b0cfa77f70aabb0ac6
Closes-Bug: 1575622
This might be useful if we switch to %{hiera()} calls to lookup
the bind address from within a service.
Also gets rid of NetIpSubnetMap and provides same output from
NetIpMap instead.
Change-Id: I328a417d1f1fff9c31e9ad7b2b5083ac19bc7329
This change modifies the network isolation templates that allow for
fixed IP addresses on the controllers' IPs and VIPs, and makes them
compatible with IPv6 addresses.
The latest version of the patchset creates an from_service_v6.yaml
in order to properly handle service VIPs on IPv6 networks.
Note that since OVS is not currently compatible with IPv6 tunnel
endpoints, this patch does not yet enable IPv6 for the Tenant
network by default.
Change-Id: If881b000c6000ec13b54c0ee39f1c8940f079ae3
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
This change adds a new set of network templates with IPv6 subnets
that can be used instead of the existing IPv4 networks. Each network
can use either the IPv4 or IPv6 template, and the Neutron subnet will
be created with the specified IP version.
The default addresses used for the IPv6 networks use the fd00::/8
prefix for the internal isolated networks (this range is reserved
for private use similar to 10.0.0.0/8), and 2001:db8:fd00:1000::/64
is used as an example default for the External network
(2001:db8::/32 are the documentation addresses [RFC3849]), but this
would ordinarily be a globally addressable subnet. These
parameters may be overridden in an environment file.
This change will require updates to the OpenStack Puppet
Modules to support IPv6 addresses in some of the hieradata values.
Many of the OPM modules already have IPv6 support to support IPv6
deployments in Packstack, but some OPM packages that apply only to
Instack/TripleO deployments need to be updated.
IPv6 addresses used in URLs need to be surrounded by brackets in
order to differentiate IP address from port number. This change
adds a new output to the network/ports resources for
ip_address_uri, which is an IP address with brackets in the case
of IPv6, and a raw IP address without brackets for IPv4 ports.
This change also updates some URLs which are constructed in Heat.
This has been tested and problems were found with Puppet not
accepting IPv6 addresses. This is addressed in the latest Puppet.
Additional changes were required to make this work with Ceph.
IPv6 tunnel endpoints with Open vSwitch are not yet supported
(although support is coming soon), so this review leaves the
Tenant network as an isolated IPv4 network for the time being.
Change-Id: Ie7a742bdf1db533edda2998a53d28528f80ef8e2
Id3d4f12235501ae77200430a2dc022f378dce336 added support for pre-allocated
IPs on the other overlay networks, but because the patch adding the
managment network (I0813a13f60a4f797be04b34258a2cffa9ea7e84f) was
under review around the same time, we missed adding the from_pool
capability to the ManagementNetwork.
Change-Id: If99f37634d5da7e7fb7cfc31232e926bd5ff074a
Previously we used an interim workaround which required a 2 digit subnet
but now heat (as of liberty) has str_split, which was implemented for this
purpose.
Change-Id: I29bb5f407b717e26a09c8c661954ee07fff72d71
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 change adds a new *_from_pool.yaml meant to return an IP from
a list instead of allocating a Neutron port, useful to pick an IP
from a pre-defined list and making it possible to configure, for
example an external balancer in advance (or dns), with the future
IPs of the controller nodes.
The list of IPs is provided via parameter_defaults (in the
ControllerIPs struct) using ControllerIPs param.
Also some additional VipPort types are created for the *VirtualIP
resources. The VIPs were previously created using the same port
resource used by the nodes, but when deploying with an external
balancer we want the VIP resource to be nooped instead.
Change-Id: Id3d4f12235501ae77200430a2dc022f378dce336
Changes VipMap into a new NetVipMap resource which defaults to
being the same as the 'old' VipMap. An environment file can be
used to map NetVipMap instead to the net_vip_map_external.yaml
which allows for passing in explicit Virtual IP addresses.
It also ensures that references to the Virtual IPs are gathered
from the VipMap resource and allows for an empty ControlPlaneIP
parameter in the neutron port templates where it can be.
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
Change-Id: Ifad32e18f12b9997e3f89e4afe3ebc4c30e14a86
This change adds to the internal_api, storage, storage_mgmt and
tenant network ports the FixedIPs param and make them consume it
when passed.
Change-Id: Ica2bca9f573b206cc60c9d572224a8cc7b9b8aa4
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 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
Harald Jensas