aboutsummaryrefslogtreecommitdiffstats
path: root/environments/updates
AgeCommit message (Collapse)AuthorFilesLines
2017-04-10Replace references to the 192.0.2 networkGiulio Fidente1-0/+3
Following change I1393d65ffb20b1396ff068def237418958ed3289 the ctlplane network will be 192.168.24 by default and not 192.0.2 anymore. This change removes old references left to 192.0.2 network from the overcloud templates. Change-Id: I1986721d339887741038b6cd050a46171a4d8022
2017-01-16Merge "Add deployed-server backwards compatible template"Jenkins2-0/+5
2017-01-10Add deployed-server backwards compatible templateJames Slagle2-0/+5
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
2017-01-09Make update-from-keystone-admin-internal-api.yaml work on newton+Cyril Lopez1-28/+1
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>
2016-08-12Convert ServiceNetMap to a nested templateSteven Hardy1-3/+3
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
2016-04-14Retain existing ComputeHostnameFormat when upgrading older envsmarios1-0/+2
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
2016-04-11Always use parameter_defaults in environment filesJiri Stransky1-1/+1
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
2015-12-15Add update yaml backward compatibe with PublicVirtualIP on ctlplaneGiulio Fidente2-0/+5
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
2015-11-23Sample environment with old ServiceNetMap valueJames Slagle2-0/+42
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