[BUGFIX] Remove redundant ExtraConfig virt_type from config_download#1292
Conversation
imatza-rh
force-pushed
the
remove-extraconfig-virt-type-downstream
branch
2 times, most recently
from
f521b76 to
96fe581
Compare
imatza-rh
force-pushed
the
remove-extraconfig-virt-type-downstream
branch
2 times, most recently
from
5db8d34 to
177252b
Compare
imatza-rh
changed the title
|
LGTM if it passes the downstream multi-cell adoption jobs, @auniyal61 @ashu-011 FYI |
|
/lgtm |
|
This PR is stale because it has been for over 15 days with no activity. |
|
@openstack-k8s-operators/adoption-core-reviewers hey folks, since there's already a |
|
I recommend not modify this unless we restore the downstream multi-cell adoption CI job |
The ComputeExtraConfig and ControllerExtraConfig entries for nova::compute::libvirt::virt_type and libvirt_virt_type in config_download.yaml files map to TripleO's role_extraconfig hiera (priority 7), which overrides the --libvirt-type CLI arg's service_configs hiera (priority 11). This makes it impossible to switch libvirt type via CLI arg overrides. Remove the redundant virt_type entries from all 14 config_download files, letting the --libvirt-type CLI arg be the sole source of truth. Scenarios that need qemu (the default) are unaffected since qemu is the default. Scenarios on baremetal (KVM-capable) hardware can now use stack_args overrides to set --libvirt-type kvm without the ExtraConfig silently reverting it. DCN scenarios preserve non-virt_type entries in ControllerExtraConfig (nova::availability_zone). Signed-off-by: Itay Matza <imatza@redhat.com>
imatza-rh
force-pushed
the
remove-extraconfig-virt-type-downstream
branch
from
177252b to
b5a5a44
Compare
|
New changes are detected. LGTM label has been removed. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
4 participants
These ExtraConfig entries duplicate what
--libvirt-type qemualreadysets via stack_args in every scenario (example: uni01alpha.yaml L42).
The duplication is harmless for the default qemu case, but it blocks
overrides due to TripleO's hiera priority chain.
The mechanism: TripleO's hieradata_files hierarchy
(from
overcloud.j2.yamlin tripleo-heat-templates) resolves entriestop-down, first match wins:
Both sources set the same Puppet keys (
nova::compute::libvirt::virt_type),so the ExtraConfig at position 7 silently wins over the CLI arg at
position 11. Any
--libvirt-type kvmoverride via stack_args getsignored.
What's removed:
ComputeExtraConfigandControllerExtraConfigblocksComputeExtraConfigblocksnova::availability_zonepreserved inControllerExtraConfigNo other consumer of these entries exists in
ci-framework/adoption_osp_deploy
or DPA adoption roles.
Tested - full adoption pipeline (7/7 stages, ~10h):
deploy-infra → deploy-osp → deploy-ocp → install-operators →
install-shiftstack → run-adoption → run-shiftstack-after
Related-Issue: #OSPRH-27919