Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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 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
|
|
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 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
|
|
|
|
Change-Id: Id63c1bcfc34058eb7285698ba9bf86d1cf2025a6
|
|
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 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
|
|
There are two files in network/ports which control the VIP
behavior called ctlplane_vip.yaml and vip.yaml. One of these
files was missing ControlPlaneNetwork, since it wasn't used
inside the template. Unfortunately, tuskar chokes on this,
even though Heat can build the stack just fine. This change
makes the vip.yaml and ctlplane_vip.yaml equivalent by adding
ControlPlaneNetwork to the vip.yaml template.
Change-Id: Ic20281e58a1130afe18d5aec505a3df199841fd5
|
|
The redis_vip should come from a Neutron Port as its cidr depends
on the Neutron Network configuration. This change adds 2 new files
and modifies 1 in the network/ports directory:
- noop.yaml - Passes through the ctlplane Controller IP (modified)
- ctlplane_vip.yaml - Creates a new VIP on the control plane
- vip.yaml - Creates a VIP on the named network (for isolated nets)
Also, changes to overcloud-without-mergepy.yaml create the
Redis Virtual IP. The standard resource registry was modified to
use noop.yaml for the new Redis VIP. The Puppet resource registry
was modified to use ctlplane_vip.yaml by default, but can be made
to use vip.yaml when network isolation is used by using an
environment file. vip.yaml will place the VIP according to the
ServiceNetMap, which can also be overridden.
We use this new VIP port definition to assign a VIP to Redis,
but follow-up patches will assign VIPs to the rest of the
services in a similar fashion.
Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
|