Bug 1881250
Summary: | [RFE] validate engine FQDN if --restore-from-file | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Germano Veit Michel <gveitmic> | ||||
Component: | ovirt-hosted-engine-setup | Assignee: | Asaf Rachmani <arachman> | ||||
Status: | CLOSED ERRATA | QA Contact: | Nikolai Sednev <nsednev> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4.3.10 | CC: | arachman, lsurette, mavital, mperina, nsednev, sgoodman | ||||
Target Milestone: | ovirt-4.4.4 | Keywords: | FutureFeature, Triaged, ZStream | ||||
Target Release: | 4.4.4 | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | ovirt-hosted-engine-setup-2.4.8 | Doc Type: | Enhancement | ||||
Doc Text: |
Before this update, when restoring a self-hosted engine you needed to enter the same FQDN that you used in the backup. With this update, when you run `hosted-engine --deploy --restore-from-file=backup_file` deploy script fetches the FQDN from the backup file and you don't need to enter it.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2021-02-02 13:59:36 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Germano Veit Michel
2020-09-22 00:26:47 UTC
What should be exact steps for reproduction? What the patch is fixing? (In reply to Nikolai Sednev from comment #1) > What should be exact steps for reproduction? > What the patch is fixing? 1. Backup the engine 2. On a new host run hosted-engine --deploy --restore-from-file=backup_file Before this patch, you have to enter the same FQDN as you used in the backup. This patch fetches the FQDN from the backup file and you don't need to enter it during the deployment. Look at the steps from https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/migrating_from_a_standalone_manager_to_a_self-hosted_engine/restoring_the_backup_on_a_new_self-hosted_engine_migrating_to_she With the patch, we don't need step 8. Asaf, how's this for a release note? Before this update, when restoring a self-hosted engine you needed to enter the same FQDN that you used in the backup. With this update, when you run `hosted-engine --deploy --restore-from-file=backup_file` deploy script fetches the FQDN from the backup file and you don't need to enter it. The FQDN is inherited properly from backup file, but then comes question: [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from backup file. Please provide the domain name you would like to use for the engine appliance. Engine VM domain: [qa.lab.tlv.redhat.com] Why do I need to confirm an obvious "Engine VM domain" if it exists in backup file? Tested on: ovirt-ansible-collection-1.2.2-1.el8ev.noarch ansible-2.9.14-1.el8ae.noarch ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch rhvm-appliance-4.4-20201111.0.el8ev.x86_64 Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.3 (Ootpa) Please refine also "Engine VM domain". (In reply to Nikolai Sednev from comment #8) > The FQDN is inherited properly from backup file, but then comes question: > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > backup file. > Please provide the domain name you would like to use for the > engine appliance. > Engine VM domain: [qa.lab.tlv.redhat.com] > Why do I need to confirm an obvious "Engine VM domain" if it exists in > backup file? Can you please point me to where the "Engine VM domain" shows in the backup file? > > Tested on: > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > ansible-2.9.14-1.el8ae.noarch > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > x86_64 x86_64 GNU/Linux > Red Hat Enterprise Linux release 8.3 (Ootpa) > > Please refine also "Engine VM domain". (In reply to Asaf Rachmani from comment #9) > (In reply to Nikolai Sednev from comment #8) > > The FQDN is inherited properly from backup file, but then comes question: > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > backup file. > > Please provide the domain name you would like to use for the > > engine appliance. > > Engine VM domain: [qa.lab.tlv.redhat.com] > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > backup file? > > Can you please point me to where the "Engine VM domain" shows in the backup > file? > > > > > Tested on: > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > ansible-2.9.14-1.el8ae.noarch > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > x86_64 x86_64 GNU/Linux > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > Please refine also "Engine VM domain". I'm not aware of the direct place, the question comes right after FQDN being provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM domain" does not exists in the backup, we can get it from FQDN. Created attachment 1730495 [details]
backup file from engine
(In reply to Nikolai Sednev from comment #10) > (In reply to Asaf Rachmani from comment #9) > > (In reply to Nikolai Sednev from comment #8) > > > The FQDN is inherited properly from backup file, but then comes question: > > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > > backup file. > > > Please provide the domain name you would like to use for the > > > engine appliance. > > > Engine VM domain: [qa.lab.tlv.redhat.com] > > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > > backup file? > > > > Can you please point me to where the "Engine VM domain" shows in the backup > > file? > > > > > > > > Tested on: > > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > > ansible-2.9.14-1.el8ae.noarch > > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > > x86_64 x86_64 GNU/Linux > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > Please refine also "Engine VM domain". > > I'm not aware of the direct place, the question comes right after FQDN being > provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is > nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM > domain" does not exists in the backup, we can get it from FQDN. AFAIK the hostname in FQDN might contain a dot (.), so we cannot be sure what is the correct domain name. If you think the host cannot contain a dot, please open another RFE to remove the question about the domain name. Please note that we have the same question during the normal HE deployment (not restore from file). (In reply to Asaf Rachmani from comment #12) > (In reply to Nikolai Sednev from comment #10) > > (In reply to Asaf Rachmani from comment #9) > > > (In reply to Nikolai Sednev from comment #8) > > > > The FQDN is inherited properly from backup file, but then comes question: > > > > [ INFO ] Using Engine VM FQDN nsednev-he-2.qa.lab.tlv.redhat.com from > > > > backup file. > > > > Please provide the domain name you would like to use for the > > > > engine appliance. > > > > Engine VM domain: [qa.lab.tlv.redhat.com] > > > > Why do I need to confirm an obvious "Engine VM domain" if it exists in > > > > backup file? > > > > > > Can you please point me to where the "Engine VM domain" shows in the backup > > > file? > > > > > > > > > > > Tested on: > > > > ovirt-ansible-collection-1.2.2-1.el8ev.noarch > > > > ansible-2.9.14-1.el8ae.noarch > > > > ovirt-hosted-engine-setup-2.4.8-1.el8ev.noarch > > > > ovirt-hosted-engine-ha-2.4.5-1.el8ev.noarch > > > > rhvm-appliance-4.4-20201111.0.el8ev.x86_64 > > > > Linux 4.18.0-240.4.1.el8_3.x86_64 #1 SMP Wed Nov 11 08:19:41 EST 2020 x86_64 > > > > x86_64 x86_64 GNU/Linux > > > > Red Hat Enterprise Linux release 8.3 (Ootpa) > > > > > > > > Please refine also "Engine VM domain". > > > > I'm not aware of the direct place, the question comes right after FQDN being > > provided, the "Engine VM domain" is the qa.lab.tlv.redhat.com, while FQDN is > > nsednev-he-2.qa.lab.tlv.redhat.com, which means that even if "Engine VM > > domain" does not exists in the backup, we can get it from FQDN. > > AFAIK the hostname in FQDN might contain a dot (.), so we cannot be sure > what is the correct domain name. > If you think the host cannot contain a dot, please open another RFE to > remove the question about the domain name. > Please note that we have the same question during the normal HE deployment > (not restore from file). So if we have the same question during initial deployment, the this value have to be saved to backup file. Can you check if it is there? Please see the attached backup file. (In reply to Nikolai Sednev from comment #13) > So if we have the same question during initial deployment, the this value > have to be saved to backup file. Can you check if it is there? Please see > the attached backup file. We have it in the backup file. Please open another RFE/bug for that. Opened as required https://bugzilla.redhat.com/show_bug.cgi?id=1900551 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 (RHV RHEL Host (ovirt-host) 4.4.z [ovirt-4.4.4]), 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:0382 Due to QE capacity, we are not going to cover this issue in our automation |