Bug 2113819

As far as I look at the puppet-heat, api.pp and api_cfn.pp ::heat::policy.
~~~
--- manifests/api.pp
class heat::api (
  $package_ensure    = 'present',
  $manage_service    = true,
  $enabled           = true,
  $bind_host         = $::os_service_default,
  $bind_port         = $::os_service_default,
  $workers           = $::os_service_default,
  $use_ssl           = false,
  $cert_file         = $::os_service_default,
  $key_file          = $::os_service_default,
  $service_name      = $::heat::params::api_service_name,
) inherits heat::params {

  include ::heat
  include ::heat::deps
  include ::heat::params
  include ::heat::policy
~~~
--- manifests/api_cfn.pp
class heat::api_cfn (
  $package_ensure    = 'present',
  $manage_service    = true,
  $enabled           = true,
  $bind_host         = $::os_service_default,
  $bind_port         = $::os_service_default,
  $workers           = $::os_service_default,
  $use_ssl           = false,
  $cert_file         = $::os_service_default,
  $key_file          = $::os_service_default,
  $service_name      = $::heat::params::api_cfn_service_name,
) inherits heat::params {

  include ::heat
  include ::heat::deps
  include ::heat::params
  include ::heat::policy
~~~

To align engine.pp to api.pp and api_cfn.pp, adding 'include ::heat::policy' seems to be a solution for this issue.

Correction:
Wrong)api.pp and api_cfn.pp ::heat::policy.' should be
Correct) api.pp and api_cfn.pp include ::heat::policy.

Just leaving my comment to share what I've discussed with Keigo.

Currently all the policy class is included by the api classes in individual modules.
However adding class inclusion can break existing manifests, and requires change in order.

For example, the following example no longer works if we make heat::engine to include heat::policy.

class { 'heat::engine':
  ...
}
class { 'heat::policy':
  ...
}

While we can make the heat::engine class to include the heat::policy class in master to make
all implementations consistent, we'd better avoid backporting this to stable branches so that
we do not break existing usages.

I think the better approach here is to update the heat-engine manifest in puppet-tripleo so that
it includes the policy class instead. I've done a similar thing to enable policy setting for
nova-compute in the past and we can follow the same strategy here.

 https://review.opendev.org/c/openstack/puppet-tripleo/+/822991
 https://review.opendev.org/c/openstack/tripleo-heat-templates/+/822992

This also requires in fix in tht, as the HeatPolicies parameter now belongs to only HeatApi service.
I don't know how much popular to have heat-api and heat-engine running in separate nodes, but in that case
the required heat::policy parameter is not rendered into hieradata in the node where heat-engine runs.

Hi Kajinami-san,

If the fixes in upstream merged into stable/train branch, is it possible to backport the fixes into OSP16.1?
Currently, the target release of this bugzilla is OSP16.2. It will be great if we can backport it into OSP16.1.

Hi Noha-san,

The issue should be fixed in OSP16.2 first. That's why I set RHOSP16.2 as target.
Once the issue is fixed in stable/train and RHOSP16.2, clone this to RHOSP16.1
after quick assessment. So far the change looks tiny and reasonable, so I'm not
aware of any risks which would block backport to OSP16.1.

Hi Kajinami-san,

QA for OSP16.2z5 in other bugzillas seem to be started.
The patch in upstream seems to be merged into OSP16.2 trunk tree.
Can we move this bugzilla MODIFIED then add it to QA for OSP16.2z5?

Best Regards,
Keigo Noha

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenStack Platform 16.2.5 (Train) bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:1763