Description of problem: My troubleshooting may be wrong, please correct me if I miss something. Customer reported that he is unable to build spine and leaf RHOSP 13 deployment with TLS everywhere: Aug 31 10:04:24 compute-0 os-collect-config: "Warning: Could not get certificate: Execution of '/usr/bin/getcert request -I libvirt-client-cert -f /etc/pki/libvirt/clientcert.pem -c IPA -N CN= -K libvirt/ -D -C systemctl reload libvirtd -w -k /etc/pki/libvirt/private/clientkey.pem' returned 2: New signing request \"libvirt-client-cert\" added.", Aug 31 10:04:24 compute-0 os-collect-config: "Error: /Stage[main]/Tripleo::Profile::Base::Certmonger_user/Tripleo::Certmonger::Libvirt[libvirt-client-cert]/Certmonger_certificate[libvirt-client-cert]: Could not evaluate: Could not get certificate: Server at https://idm.example.com/ipa/xml denied our request, giving up: 3007 (RPC failed at server. 'fqdn' is required).", From what I see there are 3 problems with getcert command: subjectname, principal name and dnsname are not provided. From THT and puppet-tripleo [1] I can see that NovaLibvirtNetwork is used to define those parameters. Obviously, this wouldn't work if there are a number of compute types with different internal API networks. There are multiple compute settings generated using NovaLibvirtNetwork from service net mapping, but our documentation recommends to adjust other hieradata parameters [2]. It is not the case for libvirt_certificates_specs. I kindly ask you to: 1. Help with a workaround (to define role-specific libvirt_certificates_specs) 2. Figure out permanent solution (adjust documentation, modify THT, etc) P.S. I tried to understand if other *certificates_specs definitions are broken. It looks like apache and haproxy are using dynamic lists of networks and are not affected by this issue. I ask to double-check this anyway. Thanks in advance. [1] https://github.com/openstack/tripleo-heat-templates/blob/stable/queens/puppet/services/nova-libvirt.yaml#L270 https://github.com/openstack/puppet-tripleo/blob/stable/queens/manifests/certmonger/libvirt.pp#L58 [2] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#assigning-routes-for-roles
@Ade, It seems we don't document the libvirt_certificates_specs and libvirt_vnc_certificates_specs, since the spine_leaf_networking book in doc's don't example TLS. We should enchance the docs. [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index
I think one way to verify would be to use the role-based parameter to map some service to a non-default network. If we deploy Compute and Controller roles, we can for example re-map some Nova stuff that is default on 'internal_api' to the 'storage' network. Ie: parameter_defaults: ControllerServiceNetMap: NovaMetadataNetwork: storage NovaVncProxyNetwork: storage NovaLibvirtNetwork: storage ComputeServiceNetMap: NovaMetadataNetwork: storage NovaVncProxyNetwork: storage NovaLibvirtNetwork: storage Then check that etc/nova.conf ``[vnc]/server_listen`` is set to the node's ip address on the storage network. Unless we have a spine-and-leaf OSP13 job with TLSe enabled? Then we should switch that to use the per-role ServiceNetMap functionaly this fix adds, and remove the hiera interpolation overrides. i.e replace the hiera interpolation overrides as exampled in the doc[1]: This ---- Compute1ServiceNetMap: NeutronTenantNetwork: tenant1 NovaApiNetwork: internal_api1 NovaLibvirtNetwork: internal_api1 NovaVncProxyNetwork: internal_api1 Not-this -------- Compute1ExtraConfig: nova::compute::libvirt::vncserver_listen: "%{hiera('internal_api1')}" nova::compute::vncserver_proxyclient_address: "%{hiera('internal_api1')}" neutron::agents::ml2::ovs::local_ip: "%{hiera('tenant1')}" cold_migration_ssh_inbound_addr: "%{hiera('internal_api1')}" live_migration_ssh_inbound_addr: "%{hiera('internal_api1')}" nova::migration::libvirt::live_migration_inbound_addr: "%{hiera('internal_api1')}" nova::my_ip: "%{hiera('internal_api1')}" tripleo::profile::base::database::mysql::client::mysql_client_bind_address: "%{hiera('internal_api1')}" https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html-single/spine_leaf_networking/index#assigning-routes-for-roles (step 4.)
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 13.0 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-2021:2385