Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
In Newton, the ctlplane port on deployed-server was called
<hostname>-ctlplane-port. When this code was refactored in
I29fbc720c3d582cbb94385e65e4b64b101f7eac9, the -port suffix was dropped
in favor of <hostname>-<network> convention, and the port resource was
created directly in deployed-server.yaml instead of in a nested stack.
Both of those changes were backwards incompatible -- making it
impossible to upgrade to the new version of deployed-server.yaml without
the ctlplane port getting deleted/recreated, which causes a change in IP
address. The IP address change causes services to be misconfigured on
upgrade attempts.
Change-Id: I45991b60a151abf3c5e4d05a3aa7246b2d25ac5a
|
|
There are change of ServiceNetMapDefaults in service_net_map.j2.yaml but
were not reproduce in update-from-keystone-admin-internal-api.yaml
environment. Tested in newton.
Closes-Bug: #1646862
Change-Id: I307dcaabbc6d583896090bf3f046b442007fbc42
Signed-off-by: Cyril Lopez <cylopez@redhat.com>
Co-Authored-By: Gregory Charot <gcharot@redhat.com>
|
|
We introduce a new ServiceNetMap resource which enables some more flexible
mappings between the services and their networks.
Specifically this patch means:
1. ServiceNetMap no longer has to specify the entire list of all services,
operators may if they wish, but a subset is now valid where you want to
accept the defaults for some services (the defaults are now accessible via
the ServiceNetMapDefaults parameter.
2. We can map some keys which don't fit a pattern that enables conversion
from CamelCase to snake_case which is required for compatibility with the
service_names in puppet/services*
This should be backwards compatible, and in future when we remove internal
dependency on the CamelCase names, we could also enable operators to
specify e.g heat_api_network in ServiceNetMap which would be more consistent.
Change-Id: Ib60198adf76bb69ffbafbfac739e356d153f6194
Partially-Implements: blueprint custom-roles
|
|
As discussed at +bug/1569705 after an upgrade to liberty from an
older deployment, the hostname of the compute nodes is changed.
If we set the ComputeHostnameFormat in the upgrade-pacemaker-init
environment file parameter_defaults then we don't need to worry
about the new value being specified as default by the upgraded
overcloud.yaml since the parameter_defaults value is persisted
unless explicitly overridden with a new parameter_defaults value.
This is provided as a new environment file that needs to be
included in the first upgrade step when upgradinng from an
environment that has 'overcloud-compute-N' hostnames.
Change-Id: I2c12bd1abac65d7f13d8768f87c5ebda91164578
Related-Bug: 1569705
|
|
In the environments/ subdirectory of tripleo-heat-templates, we mostly
use parameter_defaults, but some of the environment files still use
parameters. This can lead to confusing behavior with respect to
parameter priority when passing environment files to deploy/update
commands. Users might expect that subsequent environment files take
priority over preceding ones, but that might not be the case if the
preceding environment files use `parameters`, while the subsequent ones
use `parameter_defaults`.
This commit switches all `parameters:` uses in environments/
subdirectory to `parameter_defaults:`.
Change-Id: Ie4c03c7e7f5a5004a0384d35817135f357e9719b
Closes-Bug: #1567837
|
|
In previous releases, when not using network isolation, we used to create
two different VIPs for the ControlVirtualIP and the PublicVirtualIP both on
the ctlplane network. Later we moved into a configuration with a single
VIP instead so we need a compatibility yaml for those updating from old
versions which preserves both the IPs; one of the two is deleted
otherwise.
Also updates README.md with a short description of the use case.
Change-Id: Iae08b938a255bf563d3df2fdc0748944a9868f8e
|
|
The original value for the ServiceNetMap parameter had the Keystone
Admin API service on the Internal API network. Later, it was moved to
the ctlplane network by default.
Users updating from clouds already deployed may not want to have the
service moved, and we've occassionly seen it cause issues with services
not getting restarted properly.
This sample environment file documents the old value so that users can
just optionally include it via -e to keep the services the same as they
were when they originally deployed.
Change-Id: I0b68542337a2f40e26df15fe7ac2da5aafe651d5
|