Final release notes and relgen fix

Signed-off-by: Dj Walker-Morgan <[email protected]>

Author: djw-m

product_docs/docs/tpa/23/rel_notes/src/tpa_23.35_rel_notes.yml

@@ -11,120 +11,123 @@ highlights: |
   - Support for RedHat Enterprise Linux 9 for ARM architectures.
   - Support for PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server 17.
 relnotes:
-  - details:
-      "`PermissionsStartOnly` has been deprecated and is now achieved via `ExecStartPost=+/bin/bash...`
-      syntax"
+  - details: >-
+      `PermissionsStartOnly` has been deprecated and is now achieved via
+      `ExecStartPost=+/bin/bash...` syntax
     impact: low
     jira:
       - TPA-762
     relnote: Remove deprecated `PermissionStartOnly` in postgres.service.j2 template
     type: Change
-  - details:
-      Fixed a bug whereby the test that ensures the current pgd-proxy configuration
-      matches the expected configuration would fail for version < 5.5.0. This fix ensures
-      that TPA won't try to query configuration keys added in version 5.5.0.
+  - details: >-
+      Fixed a bug whereby the test that ensures the current pgd-proxy
+      configuration matches the expected configuration would fail for version <
+      5.5.0. This fix ensures that TPA won't try to query configuration keys
+      added in version 5.5.0.
     impact: low
     jira:
       - TPA-819
     relnote: Fix tpaexec test for pgd-proxy config verification
     type: Bug Fix
-  - details:
-      The PostGIS package will automatically be added when a user specifies `postgis`
-      as an entry in either `postgres_extensions` or the list of extensions named under
-      `postgres_databases`. Also enables the CRB (Code Ready Builder) repository for
-      RHEL-compatible distributions so PostGIS dependencies can be installed.
+  - details: >-
+      The PostGIS package will automatically be added when a user specifies
+      `postgis` as an entry in either `postgres_extensions` or the list of
+      extensions named under `postgres_databases`. Also enables the CRB (Code
+      Ready Builder) repository for RHEL-compatible distributions so PostGIS
+      dependencies can be installed.
     impact: low
     jira:
       - TPA-771
     relnote: Add `postgis` to list of recognized extensions
     type: Enhancement
-  - details:
+  - details: >-
       Certain required privileges are granted to Postgres role, `barman_role`,
-      which is then granted to the `barman` Postgres user. This avoids creating the
-      `barman` user as a superuser. This role can also be granted to other Postgres
-      users by adding it to their `granted_roles` list using `postgres/createuser`.
-      The `barman_role` is created as part of the Barman tasks; if Barman is not used,
-      this role will not be created. Therefore, the task that grants privileges to this
-      role is only executed if the `barman_role` username is in the list of Postgres
-      users that are created. The 'barman' user now has `NOSUPERUSER` explicitly specified
-      as a role attribute. If a cluster was deployed with a previous TPA version (which
-      created the 'barman' user as a superuser), deploying with this version will remove
-      the `superuser` role attribute from the `barman` user.
+      which is then granted to the `barman` Postgres user. This avoids creating
+      the `barman` user as a superuser. This role can also be granted to other
+      Postgres users by adding it to their `granted_roles` list using
+      `postgres/createuser`. The `barman_role` is created as part of the Barman
+      tasks; if Barman is not used, this role will not be created. Therefore,
+      the task that grants privileges to this role is only executed if the
+      `barman_role` username is in the list of Postgres users that are created.
+      The 'barman' user now has `NOSUPERUSER` explicitly specified as a role
+      attribute. If a cluster was deployed with a previous TPA version (which
+      created the 'barman' user as a superuser), deploying with this version
+      will remove the `superuser` role attribute from the `barman` user.
     impact: low
     jira:
       - TPA-148
       - TPA-818
     relnote: The `barman` Postgres user is no longer a superuser
     type: Change
-  - details:
+  - details: >-
       Add new optional var `harp_local_etcd_only` available when using etcd with
-      HARP. This option tells HARP manager to connect to local etcd node. This recommendation
-      follows the best practices learnt by doing the same when `bdr` as consensus procotol
-      is being used. The default mode of adding multiple endpoints can lead to performance
-      issues in some cases. This option is added to give more control to the user.
+      HARP. This option tells HARP manager to connect to local etcd node. This
+      recommendation follows the best practices learnt by doing the same when
+      `bdr` as consensus procotol is being used. The default mode of adding
+      multiple endpoints can lead to performance issues in some cases. This
+      option is added to give more control to the user.
     impact: low
     jira:
       - TPA-821
     relnote: Add new option `harp_local_etcd_only` when using etcd with HARP
     type: Change
-    addresses: 41931
-  - details:
+  - details: >-
       A `primary_slot_name` is configured on the primary node to ensure the old
-      primary uses a physical slot for replication during an EFM switchover. However,
-      'bdr_init_physical' attempts to use it for node initialisation and hangs indefinitely
-      since the slot does not exist in a PGD installation. This `primary_slot_name`
-      is now conditionally set explicitly when the `failover_manager` is EFM to avoid
-      setting it unnecessarily.
+      primary uses a physical slot for replication during an EFM switchover.
+      However, 'bdr_init_physical' attempts to use it for node initialisation
+      and hangs indefinitely since the slot does not exist in a PGD
+      installation. This `primary_slot_name` is now conditionally set explicitly
+      when the `failover_manager` is EFM to avoid setting it unnecessarily.
     impact: low
     jira:
       - TPA-712
-    relnote: "Fix case where `primary_slot_name` added for EFM compatibility interferes with `bdr_init_physical`"
+    relnote: >-
+      Fix case where `primary_slot_name` added for EFM compatibility interferes
+      with `bdr_init_physical`
     type: Bug Fix
-    addresses: 36064
-  - details:
-      If the `pgdcli_package_version` is specified in `config.yml`, the `bash-completion`
-      package is incorrectly named because the `packages_for` filter erroneously appends
-      the `pgdcli_package_version` to the package name. This results in an attempt to
-      download a nonexistant package. The `bash-completion` package is now appended
-      to the list after the `packages_for` filter, since it's version is independent
-      from the `pgdcli_package_version`.
+  - details: >-
+      If the `pgdcli_package_version` is specified in `config.yml`, the
+      `bash-completion` package is incorrectly named because the `packages_for`
+      filter erroneously appends the `pgdcli_package_version` to the package
+      name. This results in an attempt to download a nonexistant package. The
+      `bash-completion` package is now appended to the list after the
+      `packages_for` filter, since it's version is independent from the
+      `pgdcli_package_version`.
     impact: low
     jira:
       - TPA-794
     relnote: Download correct `bash-completion` package version
     type: Bug Fix
-    addresses: 38773
-  - details:
+  - details: >-
       TPA is now able to generate a PGD Lightweight architecture comprised of
-      three nodes in two locations (2 nodes in Primary and one in Disaster Recovery)
-      designed to ease migrations from physical replication. Users can now run `tpaexec
-      configure lw -a Lightweight --postgresql 15`.
-    impact: low
+      three nodes in two locations (2 nodes in Primary and one in Disaster
+      Recovery) designed to ease migrations from physical replication. Users can
+      now run `tpaexec configure lw -a Lightweight --postgresql 15`.
+    impact: medium
     jira:
       - TPA-838
     relnote: Add support for PGD Lightweight architecture
     type: Enhancement
-  - details:
+  - details: >-
       TPA now clears the error message stack after each task to ensure messages
       are not spuriously repeated
     impact: low
     jira:
       - TPA-812
-    relnote:
+    relnote: >-
       Fix an issue whereby in some cases error messages would be repeated even
       after successful tasks.
     type: Bug Fix
-  - details:
+  - details: >-
       Improve postgres-monitor script to better manage recoverable errors and
-      add retries on network errors to ensure that it won't return failure when it just
-      didn't allow enough time for postgres service to be fully started.
+      add retries on network errors to ensure that it won't return failure when
+      it just didn't allow enough time for postgres service to be fully started.
     impact: low
     jira:
       - TPA-796
     relnote: Improve postgres-monitor script
     type: Change
-    addresses: 39191
-  - details:
+  - details: >-
       Fixed an issue whereby new replicas in Patroni clusters would fail with
       errors related to replication slots.
     impact: low
@@ -133,99 +136,148 @@ relnotes:
       - TPA-781
     relnote: Fix issue that prevented the addition of replicas to Patroni clusters
     type: Bug Fix
-  - details: Previously the `pemserver` and `barman` nodes were
-      added to the `Allowed node host list` in EFM when they were not relevant to EFM
-      functions. Refactored the task that writes the `efm.node` configuration to only
+  - details: >-
+      Previously the `pemserver` and `barman` nodes were added to the `Allowed
+      node host list` in EFM when they were not relevant to EFM functions.
+      Refactored the task that writes the `efm.node` configuration to only
       include those nodes that have `efm` in their list of roles.
     impact: low
     jira:
       - TPA-817
     relnote: Only add nodes with `efm` role to cluster `efm.nodes` file
     type: Change
-  - details:
-      If `--enable-pem` and `--enable-pg-backup-api` are passed to `tpaexec configure`,
-      `pem-agent` is added twice to the `barman` node if it is also a `witness`. Fixed
-      by consolidating both `if` statements together to only evaluate the conditions
-      once.
+  - details: >-
+      If `--enable-pem` and `--enable-pg-backup-api` are passed to `tpaexec
+      configure`, `pem-agent` is added twice to the `barman` node if it is also
+      a `witness`. Fixed by consolidating both `if` statements together to only
+      evaluate the conditions once.
     impact: low
     jira:
       - TPA-793
     relnote: Add `pem-agent` role on barman nodes at most once for M1 architecture
     type: Bug Fix
-  - details:
-      Fixed a bug whereby if the user excluded the `pkg` selector, later PEM-related
-      tasks would fail because the `pem_python_executable` fact had not been set.
+  - details: >-
+      Fixed a bug whereby if the user excluded the `pkg` selector, later
+      PEM-related tasks would fail because the `pem_python_executable` fact had
+      not been set.
     impact: low
     jira:
       - TPA-814
     relnote: Set `pem_python_executable` outside of the `pkg` role
     type: Bug Fix
-  - details:
-      The `--efm-install-path` and `--efm-cluster-name` flags are set when a
-      PEM server is registered on an EFM node. The `Streaming Replication`, `Failover
-      Manager Node Status` and `Failover Manager Cluster Info` probes are enabled when
-      a PEM agent is registered on an EFM node.
+  - details: >-
+      The `--efm-install-path` and `--efm-cluster-name` flags are set when a PEM
+      server is registered on an EFM node. The `Streaming Replication`,
+      `Failover Manager Node Status` and `Failover Manager Cluster Info` probes
+      are enabled when a PEM agent is registered on an EFM node.
     impact: low
     jira:
       - TPA-586
     relnote: Enable EFM probes when a PEM agent is registered on an EFM node
     type: Enhancement
-  - details:
+  - details: >-
       TPA now supports command-line options to create a cluster configured to
-      conform to many of the requirements of the STIG and CIS security standards. These
-      options cause TPA to set postgresql.conf settings as defined in the relevant
-      standards, to install required extensions, to configure other aspects of system
-      behaviour such as filesystem permissions and user connection limits, and to check
-      for other requirements such as FIPS crypto standards which TPA can't directly
-      impose. The clusters thus generated are not certified by TPA to conform to the
-      standards, but much of the groundwork of creating a conforming cluster is now
-      automated.
-    impact: low
+      conform to many of the requirements of the STIG and CIS security
+      standards. These options cause TPA to set postgresql.conf settings as
+      defined in the relevant standards, to install required extensions, to
+      configure other aspects of system behaviour such as filesystem permissions
+      and user connection limits, and to check for other requirements such as
+      FIPS crypto standards which TPA can't directly impose. The clusters thus
+      generated are not certified by TPA to conform to the standards, but much
+      of the groundwork of creating a conforming cluster is now automated.
+    impact: high
     jira:
       - TPA-366
       - TPA-836
       - TPA-837
     relnote: Support STIG/CIS compliance
     type: Enhancement
-  - details:
-      The configure command will now automatically add a named network and static
-      IP addresses to config.yml when Docker is the selected platform. The network name
-      is the same as the cluster name and the address range follows the existing semantics
-      of the --network option with the exception that only one subnet is used for the
-      whole cluster rather than one per location. If a subnet prefix is not specified
-      by the user, TPA will attempt to select a prefix which results in a subnet large
-      enough to fit the whole cluster. The key `ip_address` may now be used to specify
-      a static IP for a Docker instance as long as a named network is specified in the
-      config.yml.
-    impact: low
+  - details: >-
+      The configure command will now automatically add a named network and
+      static IP addresses to config.yml when Docker is the selected platform.
+      The network name is the same as the cluster name and the address range
+      follows the existing semantics of the --network option with the exception
+      that only one subnet is used for the whole cluster rather than one per
+      location. If a subnet prefix is not specified by the user, TPA will
+      attempt to select a prefix which results in a subnet large enough to fit
+      the whole cluster. The key `ip_address` may now be used to specify a
+      static IP for a Docker instance as long as a named network is specified in
+      the config.yml.
+    impact: medium
     jira:
       - TPA-261
       - TPA-407
       - TPA-434
     relnote: Have `configure` create a user-defined network on Docker
     type: Enhancement
-  - details: Packages are now published targeting RHEL 9 ARM64, and TPA supports
-      deployments using this architecture and OS. Also updated the list of supported
-      AWS images to include the RedHat 9 ARM64 AMI provided by Amazon. The default `instance_type`
-      for ARM64 EC2 instances has been updated from `a1` to `t4g`, which is the current
-      generation processor available for burstable general purpose workloads.
+  - details: >-
+      Packages are now published targeting RHEL 9 ARM64, and TPA supports
+      deployments using this architecture and OS. Also updated the list of
+      supported AWS images to include the RedHat 9 ARM64 AMI provided by Amazon.
+      The default `instance_type` for ARM64 EC2 instances has been updated from
+      `a1` to `t4g`, which is the current generation processor available for
+      burstable general purpose workloads.
     impact: low
     jira:
       - TPA-780
     relnote: Support RedHat Enterprise Linux 9 for ARM architectures
     type: Enhancement
-  - details:
+  - details: >-
       Clusters can be configured to use PostgreSQL, EDB Postgres Extended and
-      EDB Postgres Advanced Server version 17. Barman no longer needs to install the
-      postgres server package to get the `pg_receivewal` binary when using EDB Postgres
-      Advanced Server 17 or EDB Postgres Extended 17 since the binary has been added
-      to the client package for these versions. TPA raises an architecture error when a cluster
-      is configured with `repmgr` as the failover_manager as it is not available for
-      Postgres 17. Updated documentation to reflect supported versions.
+      EDB Postgres Advanced Server version 17. Barman no longer needs to install
+      the postgres server package to get the `pg_receivewal` binary when using
+      EDB Postgres Advanced Server 17 or EDB Postgres Extended 17 since the
+      binary has been added to the client package for these versions. TPA raises
+      an architecture error when a cluster is configured with `repmgr` as the
+      failover_manager as it is not available for Postgres 17. Updated
+      documentation to reflect supported versions.
     impact: low
     jira:
       - TPA-803
-    relnote:
-      Support PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced Server
-      17
+    relnote: >-
+      Support PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced
+      Server 17
+    type: Enhancement
+  - details: >-
+      When using an existing Barman node as a backup node in a new cluster,
+      users can set `barman_shared: true` in the Barman instance's vars with the
+      platform set to `bare` and other information supplied as usual for bare
+      instances. This change allows TPA to skip some configuration steps that
+      would otherwise fail due to usermod issues, as the Barman user already has
+      running processes from previous deployments. The shared Barman instance is
+      treated as a bare instance, so the required access, including the Barman
+      user's access to the target PostgreSQL instances, must be already in
+      place. Copying the Barman user's keys from the original cluster to the new
+      cluster can be used to achieve this, see the Barman section of the TPA
+      documentation for detailed information.
+    impact: medium
+    jira:
+      - TPA-777
+    relnote: >-
+      Added experimental support for using an existing Barman node as backup
+      node in new cluster
+    type: Enhancement
+  - details: >-
+      Expose a configurable `efm_user_password_encryption` variable which should
+      be set to either `'md5'` or `'scram-sha-256'` depending on user
+      requirements. This controls the `auth-method` for the `efm` Postgres user
+      in `pg_hba.conf` and the algorithm used for generating it's encrypted
+      password. In clusters deployed with `compliance` configured to `stig`, the
+      'efm' Postgres user's `auth-method` in `pg_hba.conf` will be set to
+      `scram-sha-256` since FIPS-enabled operating systems do not allow `md5` to
+      be used.
+    impact: low
+    jira:
+      - TPA-832
+      - TPA-836
+    relnote: Make `password_encryption` algorithm for `efm` Postgres user configurable.
+    type: Enhancement
+  - details: >-
+      When using the `--hostnames-from` option to `tpaexec configure`, you can
+      now include two ip addresses on each line, which will be included in the
+      generated config.yml as public_ip and private_ip.
+    impact: low
+    jira:
+      - TPA-841
+    relnote: Allow multiple addresses to be supplied with hostnames
     type: Enhancement