Description of problem: In current T-H-T in downstream and upstream, HeatApiPolicies parameter is defined for heat-api. However, the custom heat policy file is also required for heat-engine. By the lack of the implementation in T-H-T and puppet-heat, heat-engine cannot handle the stack request based on the custom policy. Version-Release number of selected component (if applicable): OSP16.1, OSP16.2 and Upstream. How reproducible: Always Steps to Reproduce: 1. Define custom policy with HeatApiPolicies and deploy it. 2. Confirm policy.json is created for heat-api and heat-engine 3. Actual results: heat-engine doesn't have the policy.json. By the lack of the file, stack create will fail due to unauthorized request. Expected results: heat-engine has a policy.json. Additional info:
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