core: pass he_admin_username to subsequent ansible-playbook invocation

[ppanon2022]

The Set admin username task in 04_engine_final_tasks.yml correctly populates he_admin_username, and misc.py reads the value back into the otopi environment as ohostedcons.EngineEnv.ADMIN_USERNAME. However, the value is not added to the extra_vars dict used for the next ansible-playbook invocation, so auth_sso.yml runs with he_admin_username undefined and the SDK call fails with:

Cannot authenticate user 'None@N/A':
No valid profile found in credentials.

Add he_admin_username to the extra_vars dict next to the existing he_admin_password entry, mirroring the existing pattern.

Fixes: ovirt-engine issue 1141

[dupondje]

Hi,

Thanks for the effort already!

I've spend some time looking at the issue.
Seems like OVIRT_USERNAME was changed to a variable in the following commit: oVirt/ovirt-ansible-collection@3f131a5

But as you see it sets the otopi_he_admin_username in 04_engine_final_tasks.yml already.

And that value is then used in https://github.com/oVirt/ovirt-hosted-engine-setup/blob/master/src/plugins/gr-he-ansiblesetup/core/misc.py#L517 to set the ADMIN_USERNAME.

So I was wondering in which step the setup fails without your patch.
Next to that, I don't see directly why this would only give issues when doing a restore. This should then also fail when doing a clean install? Even with Keycloak. Or I'm missing something :)

[dupondje]

No feedback, feel free to reopen.

[ppanon2022]

Sorry, in fact the problem was different but I misunderstood it because the error message was misleading. The error Cannot authenticate user 'None@N/A': seemed to indicate that the username was not being passed and that seemed to be how it was being lost, but we didn't have the chance to retest it until a later maintenance window.

In fact, the real underlying problem seems to be that we were using signed certificates for the web service, with the signing CA being our internal PKI. That CA cert had been added to the machine certificate store in the old hosted engine where the backup was made, so it worked fine in that environment, but it wasn't present in the newly deployed hosted engine, Thus, when the newly deployed engine tried to connect with itself to set the admin password, the connection failed because the server cert for the TLS tunnel could not be validated. We wound up using one of the ansible hooks to download the CA certs and update the ca cert list after the VM was created but before that failing step.