Description of problem: Similarly to BZ1881250, customer provided the wrong answer on the question below during migration to SHE, causing more problems. ] = self.dialog.queryString( name='ovehosted_cluster_name', note=_( 'Please enter the name of the cluster where you want ' 'to deploy this hosted-engine host. ' '{restore_addition}' '[@DEFAULT@]: ' ).format( restore_addition=restore_addition, ), restore_addition = _( 'Please note that if you are restoring a backup that contains ' 'info about other hosted-engine hosts,\n' 'this value should exactly match the value used in the ' 'environment you are going to restore. ' ) Would it be possible to improve this by: a) Having no default option if --restore-from-file, so the user is forced to carefully read the question and manually type the cluster name to avoid mistakes b) The restore_addition is technically correct, but for the end customer it may be unclear. I think we would have something like: ~~~ Please note that if you are restoring a backup that contains hosted-engine, this value should be the cluster of the HostedEngine VM and hosts. If you are migrating from bare-metal to hosted-engine, this value should be the target cluster you wish to add the hosted-engine VM and this host to.' ~~~ c) This one would be harder to validate against the backup, as I don't think we have this info outside of the DB, but it would be a nice check to have too.
(In reply to Germano Veit Michel from comment #0) > Description of problem: > > Similarly to BZ1881250, customer provided the wrong answer on the question > below during migration to SHE, causing more problems. > > ] = self.dialog.queryString( > name='ovehosted_cluster_name', > note=_( > 'Please enter the name of the cluster where you want ' > 'to deploy this hosted-engine host. ' > '{restore_addition}' > '[@DEFAULT@]: ' > ).format( > restore_addition=restore_addition, > ), > > restore_addition = _( > 'Please note that if you are restoring a backup that > contains ' > 'info about other hosted-engine hosts,\n' > 'this value should exactly match the value used in the ' > 'environment you are going to restore. ' > ) > > > Would it be possible to improve this by: > a) Having no default option if --restore-from-file, so the user is forced to > carefully read the question and manually type the cluster name to avoid > mistakes That's easy. > > b) The restore_addition is technically correct, but for the end customer it > may be unclear. I think we would have something like: > ~~~ > Please note that if you are restoring a backup that contains hosted-engine, > this value should be the cluster of the HostedEngine VM and hosts. If you > are migrating from bare-metal to hosted-engine, this value should be the > target cluster you wish to add the hosted-engine VM and this host to.' > ~~~ OK for me, if that's the exact text you want. Otherwise, please refine it as needed... > > c) This one would be harder to validate against the backup, as I don't think > we have this info outside of the DB, but it would be a nice check to have > too. It's quite easy in principle, but requires having PG utils on the host. That's a slight waste of space and might be a slight inconvenience (having to enable yet another channel/module/etc. correctly). Not sure it's worth it, but do not have strong feelings either side. So: Please decide exactly what you want. Thanks!
I think we can do (a) and (b) then? I'm fine with the previously proposed text for (b), its easier for customers to understand.
Germano, I changed your text somewhat, in the linked PR. Perhaps you'd like to review on github? Thanks. Also added a TODO reminder in the commit message, mainly for myself: Do we want to add instructions about how to check the DC/cluster in the db dump? Sadly, these aren't going to be very short, if we want them to be complete - might require, for RHV, also registering, adding channels/modules, etc. Perhaps you can recheck the implications of providing wrong input? It might be easier to make HE deploy pause then, if not done already, letting the user fix stuff manually (if needed).
Or perhaps we can add a link to somewhere and provide more details there. Perhaps to a new or existing/updated section in the documentation. Would be somewhat complicated to make the link different for oVirt/RHV...
(In reply to Yedidyah Bar David from comment #5) > Germano, I changed your text somewhat, in the linked PR. Perhaps you'd like > to review on github? Thanks. Done, looks great, thanks for improving it. > > Also added a TODO reminder in the commit message, mainly for myself: Do we > want to add instructions about how to check the DC/cluster in the db dump? > Sadly, these aren't going to be very short, if we want them to be complete - > might require, for RHV, also registering, adding channels/modules, etc. Opening the DB I think its too much. Support can be involved if someone forgets and has no idea of the cluster name. However, if the user still has the old/source hosted-storage, we should be able to somewhat easily extract from there: [root@rhevh-7 ~]# egrep 'sdUUID|conf_' /etc/ovirt-hosted-engine/hosted-engine.conf sdUUID=b8c7af51-4e19-4a72-a34b-f2b7d6be0381 conf_volume_UUID=3f675208-c1fe-4145-bafb-f2bc82d4576c conf_image_UUID=b4c25131-5a10-4555-a5d1-4b3136a2eb13 [root@rhevh-7 ~]# grep -a "clusterName" /rhev/data-center/2b7b4442-a954-11ec-bbb5-00163e758d0e/b8c7af51-4e19-4a72-a34b-f2b7d6be0381/images/b4c25131-5a10-4555-a5d1-4b3136a2eb13/3f675208-c1fe-4145-bafb-f2bc82d4576c OVEHOSTED_ENGINE/clusterName=str:Default Maybe we just KCS the above? > Perhaps you can recheck the implications of providing wrong input? It might > be easier to make HE deploy pause then, if not done already, letting the > user fix stuff manually (if needed). But that is part of the problem. What is a right or wrong input. One user may want to move the HE to a different cluster that the one its currently in, another may be moving from standalone (any cluster is valid, including a new one), another may be doing disaster recovery and wants it in the same cluster it was before. I don't think we can validate this, the setup may even "succeed" when using the wrong cluster, so no trigger for a pause, but its not what the customer wants and will cause more problems down the road.
(In reply to Germano Veit Michel from comment #7) > (In reply to Yedidyah Bar David from comment #5) > > Germano, I changed your text somewhat, in the linked PR. Perhaps you'd like > > to review on github? Thanks. > > Done, looks great, thanks for improving it. Thanks for reviewing. > > > > > Also added a TODO reminder in the commit message, mainly for myself: Do we > > want to add instructions about how to check the DC/cluster in the db dump? > > Sadly, these aren't going to be very short, if we want them to be complete - > > might require, for RHV, also registering, adding channels/modules, etc. > > Opening the DB I think its too much. Support can be involved if someone > forgets and has no idea of the cluster name. Fine for me. Dropped the TODO. For reference: Somehow install postgresql rpm (we use 12, but perhaps an older version will work as well) mkdir tmp cd tmp tar xf /path/to/backup/file cd db To see the data center names: pg_restore engine_backup.db -a -t storage_pool -f - | awk '/^COPY/,/^$/ {if ($1!="COPY") print $2}' Cluster names: pg_restore engine_backup.db -a -t cluster -f - | awk '/^COPY/,/^$/ {if ($1!="COPY") print $2}' > However, if the user still has the old/source hosted-storage, we should be > able to somewhat easily extract from there: > > [root@rhevh-7 ~]# egrep 'sdUUID|conf_' > /etc/ovirt-hosted-engine/hosted-engine.conf > sdUUID=b8c7af51-4e19-4a72-a34b-f2b7d6be0381 > conf_volume_UUID=3f675208-c1fe-4145-bafb-f2bc82d4576c > conf_image_UUID=b4c25131-5a10-4555-a5d1-4b3136a2eb13 > > [root@rhevh-7 ~]# grep -a "clusterName" > /rhev/data-center/2b7b4442-a954-11ec-bbb5-00163e758d0e/b8c7af51-4e19-4a72- > a34b-f2b7d6be0381/images/b4c25131-5a10-4555-a5d1-4b3136a2eb13/3f675208-c1fe- > 4145-bafb-f2bc82d4576c > OVEHOSTED_ENGINE/clusterName=str:Default > > Maybe we just KCS the above? Definitely useful as well. > > > Perhaps you can recheck the implications of providing wrong input? It might > > be easier to make HE deploy pause then, if not done already, letting the > > user fix stuff manually (if needed). > > But that is part of the problem. What is a right or wrong input. One user > may want to move the HE to a different cluster that the one its currently > in, another may be moving from standalone (any cluster is valid, including a > new one), another may be doing disaster recovery and wants it in the same > cluster it was before. I don't think we can validate this, the setup may > even "succeed" when using the wrong cluster, so no trigger for a pause, but > its not what the customer wants and will cause more problems down the road. I completely agree. In light of this, my current text might also be slightly misleading - users that restore an HE backup but want to move it to a new DC/cluster, should create them beforehand and supply these - not the existing ones. Do you think we should add a third "If you are restoring..."?
(In reply to Yedidyah Bar David from comment #8) > (In reply to Germano Veit Michel from comment #7) > > (In reply to Yedidyah Bar David from comment #5) > > > Germano, I changed your text somewhat, in the linked PR. Perhaps you'd like > > > to review on github? Thanks. > > > > Done, looks great, thanks for improving it. > > Thanks for reviewing. > > > > > > > > > Also added a TODO reminder in the commit message, mainly for myself: Do we > > > want to add instructions about how to check the DC/cluster in the db dump? > > > Sadly, these aren't going to be very short, if we want them to be complete - > > > might require, for RHV, also registering, adding channels/modules, etc. > > > > Opening the DB I think its too much. Support can be involved if someone > > forgets and has no idea of the cluster name. > > Fine for me. Dropped the TODO. > > For reference: > > Somehow install postgresql rpm (we use 12, but perhaps an older version will > work as well) > > mkdir tmp > cd tmp > tar xf /path/to/backup/file > cd db > > To see the data center names: > > pg_restore engine_backup.db -a -t storage_pool -f - | awk '/^COPY/,/^$/ {if > ($1!="COPY") print $2}' > > Cluster names: > > pg_restore engine_backup.db -a -t cluster -f - | awk '/^COPY/,/^$/ {if > ($1!="COPY") print $2}' Yes, it will list them. But to really know it we would need to do a select on the vms view for HostedEngine. I think if it gets to this point customer can involve support, we just open the backup and do the SQL. I'll document this and the hosted-engine.conf one in a KCS, should be enough for edge cases. I'd expect most to know the cluster name and type it correctly instead of going with the defaults with the improvements you did. > > > However, if the user still has the old/source hosted-storage, we should be > > able to somewhat easily extract from there: > > > > [root@rhevh-7 ~]# egrep 'sdUUID|conf_' > > /etc/ovirt-hosted-engine/hosted-engine.conf > > sdUUID=b8c7af51-4e19-4a72-a34b-f2b7d6be0381 > > conf_volume_UUID=3f675208-c1fe-4145-bafb-f2bc82d4576c > > conf_image_UUID=b4c25131-5a10-4555-a5d1-4b3136a2eb13 > > > > [root@rhevh-7 ~]# grep -a "clusterName" > > /rhev/data-center/2b7b4442-a954-11ec-bbb5-00163e758d0e/b8c7af51-4e19-4a72- > > a34b-f2b7d6be0381/images/b4c25131-5a10-4555-a5d1-4b3136a2eb13/3f675208-c1fe- > > 4145-bafb-f2bc82d4576c > > OVEHOSTED_ENGINE/clusterName=str:Default > > > > Maybe we just KCS the above? > > Definitely useful as well. > > > > > > Perhaps you can recheck the implications of providing wrong input? It might > > > be easier to make HE deploy pause then, if not done already, letting the > > > user fix stuff manually (if needed). > > > > But that is part of the problem. What is a right or wrong input. One user > > may want to move the HE to a different cluster that the one its currently > > in, another may be moving from standalone (any cluster is valid, including a > > new one), another may be doing disaster recovery and wants it in the same > > cluster it was before. I don't think we can validate this, the setup may > > even "succeed" when using the wrong cluster, so no trigger for a pause, but > > its not what the customer wants and will cause more problems down the road. > > I completely agree. > > In light of this, my current text might also be slightly misleading - users > that restore an HE backup but want to move it to a new DC/cluster, should > create > them beforehand and supply these - not the existing ones. Do you think > we should add a third "If you are restoring..."? I don't think it needs to be created beforehand, typing an non existing one will create? This is a less frequent use case of backup restore, the two big ones we see are move hosted_storage (within same DC/SD) to a new SAN appliance and disaster recovery. But OK, maybe add this one too to cover the most obvious use cases. But let's stop at this one, otherwise this text may become a thesis on cluster names :)
(In reply to Germano Veit Michel from comment #9) > (In reply to Yedidyah Bar David from comment #8)> > For reference: > > > > Somehow install postgresql rpm (we use 12, but perhaps an older version will > > work as well) > > > > mkdir tmp > > cd tmp > > tar xf /path/to/backup/file > > cd db > > > > To see the data center names: > > > > pg_restore engine_backup.db -a -t storage_pool -f - | awk '/^COPY/,/^$/ {if > > ($1!="COPY") print $2}' > > > > Cluster names: > > > > pg_restore engine_backup.db -a -t cluster -f - | awk '/^COPY/,/^$/ {if > > ($1!="COPY") print $2}' > > Yes, it will list them. But to really know it we would need to do a select > on the vms view for HostedEngine. > I think if it gets to this point customer can involve support, we just open > the backup and do the SQL. > > I'll document this and the hosted-engine.conf one in a KCS, should be enough > for edge cases. +1 > I'd expect most to know the cluster name and type it correctly instead of > going with the defaults with the improvements you did. Hopefully. > > > > > > However, if the user still has the old/source hosted-storage, we should be > > > able to somewhat easily extract from there: > > > > > > [root@rhevh-7 ~]# egrep 'sdUUID|conf_' > > > /etc/ovirt-hosted-engine/hosted-engine.conf > > > sdUUID=b8c7af51-4e19-4a72-a34b-f2b7d6be0381 > > > conf_volume_UUID=3f675208-c1fe-4145-bafb-f2bc82d4576c > > > conf_image_UUID=b4c25131-5a10-4555-a5d1-4b3136a2eb13 > > > > > > [root@rhevh-7 ~]# grep -a "clusterName" > > > /rhev/data-center/2b7b4442-a954-11ec-bbb5-00163e758d0e/b8c7af51-4e19-4a72- > > > a34b-f2b7d6be0381/images/b4c25131-5a10-4555-a5d1-4b3136a2eb13/3f675208-c1fe- > > > 4145-bafb-f2bc82d4576c > > > OVEHOSTED_ENGINE/clusterName=str:Default > > > > > > Maybe we just KCS the above? > > > > Definitely useful as well. > > > > > > > > > Perhaps you can recheck the implications of providing wrong input? It might > > > > be easier to make HE deploy pause then, if not done already, letting the > > > > user fix stuff manually (if needed). > > > > > > But that is part of the problem. What is a right or wrong input. One user > > > may want to move the HE to a different cluster that the one its currently > > > in, another may be moving from standalone (any cluster is valid, including a > > > new one), another may be doing disaster recovery and wants it in the same > > > cluster it was before. I don't think we can validate this, the setup may > > > even "succeed" when using the wrong cluster, so no trigger for a pause, but > > > its not what the customer wants and will cause more problems down the road. > > > > I completely agree. > > > > In light of this, my current text might also be slightly misleading - users > > that restore an HE backup but want to move it to a new DC/cluster, should > > create > > them beforehand and supply these - not the existing ones. Do you think > > we should add a third "If you are restoring..."? > > I don't think it needs to be created beforehand, typing an non existing one > will create? Yes. > > This is a less frequent use case of backup restore, the two big ones we see > are move hosted_storage (within same DC/SD) to a new SAN appliance and > disaster recovery. > But OK, maybe add this one too to cover the most obvious use cases. But > let's stop at this one, otherwise this text may become a thesis on cluster > names :) Ok, please review. Thanks.
Please provide reproduction steps for verification.
(In reply to Nikolai Sednev from comment #11) > Please provide reproduction steps for verification. Already? We are still on POST... Please see end of comment 7 as to why "real reproduction" steps are not that relevant here. For what we eventually decided to do, the "reproduction" is as below, but with a broken/old build, both cases provide a default. See also from comment 5 to 8 about why we decided to give up on the subject of the bug ("Validate"). For _verification_: 1. hosted-engine --deploy --restore-from-file You should make sure that on the questions to provide the data center and cluster, we provide no default, and that the text is sane. 2. hosted-engine --deploy These questions have 'Default' as their default and the text is shorter (and sane...).
Just to put my 5 cents here, why doe we need to put default for the hosted engine host cluster and data center at all? Wouldn't it be more convenient to ask customer to provide them from the start?
(In reply to Nikolai Sednev from comment #13) > Just to put my 5 cents here, why doe we need to put default for the hosted > engine host cluster and data center at all? Wouldn't it be more convenient > to ask customer to provide them from the start? Perhaps I am missing something. We do ask. And continue to ask, on both new setups and restore. The only issue is whether to supply a default answer for the question - whether pressing 'Enter' blindly would work or not. Do you suggest to never supply a default? Always require some input? How is that "more convenient"? But speaking of convenience, your question made me think about something else: We do not really need these DC/cluster values so early. We can postpone asking for them to after the engine is already up - and then we can simply query the engine to see if the values are valid. Main theoretical disadvantage: we suppose that people prefer being asked all the questions "at once", and then they can go do something else while the machine does its stuff. I actually think this is the right thing to do, and wonder why we didn't right from the start of node-zero. I guess now it's a too-large change and not worth it.
(In reply to Yedidyah Bar David from comment #14) > (In reply to Nikolai Sednev from comment #13) > > Just to put my 5 cents here, why doe we need to put default for the hosted > > engine host cluster and data center at all? Wouldn't it be more convenient > > to ask customer to provide them from the start? > > Perhaps I am missing something. We do ask. And continue to ask, on both new > setups and restore. The only issue is whether to supply a default answer for > the question - whether pressing 'Enter' blindly would work or not. Do you > suggest to never supply a default? Always require some input? How is that > "more convenient"? It'll be more convenient for the customers not to think how to change meaningless default, after they already deployed environment. I don't like the idea of letting customer to press enter blindly, if its not required then it should be excluded. I don't think that default is vast majority of deployments, IMHO more than 90%, are using authentic names anyway, so why bother? > > But speaking of convenience, your question made me think about something > else: We do not really need these DC/cluster values so early. We can > postpone asking for them to after the engine is already up - and then we can > simply query the engine to see if the values are valid. Main theoretical > disadvantage: we suppose that people prefer being asked all the questions > "at once", and then they can go do something else while the machine does its > stuff. I actually think this is the right thing to do, and wonder why we > didn't right from the start of node-zero. I guess now it's a too-large > change and not worth it. I agree with you about time consumption and that it will be too late for this change.
(In reply to Nikolai Sednev from comment #15) > (In reply to Yedidyah Bar David from comment #14) > > (In reply to Nikolai Sednev from comment #13) > > > Just to put my 5 cents here, why doe we need to put default for the hosted > > > engine host cluster and data center at all? Wouldn't it be more convenient > > > to ask customer to provide them from the start? > > > > Perhaps I am missing something. We do ask. And continue to ask, on both new > > setups and restore. The only issue is whether to supply a default answer for > > the question - whether pressing 'Enter' blindly would work or not. Do you > > suggest to never supply a default? Always require some input? How is that > > "more convenient"? > It'll be more convenient for the customers not to think how to change > meaningless default, after they already deployed environment. > I don't like the idea of letting customer to press enter blindly, if its not > required then it should be excluded. I don't think that default is vast > majority of deployments, IMHO more than 90%, are using authentic names > anyway, so why bother? Germano, what do you say?
(In reply to Yedidyah Bar David from comment #16) > Germano, what do you say? I think your idea is ideal, to not have a default *if* its a --restore. So on initial deployments (not that many people should be doing them these days), one can continue just pressing enter without reading :)
Deployed ovirt-hosted-engine-ha-2.5.0-1.el8ev.noarch ovirt-hosted-engine-setup-2.6.4-1.el8ev.noarch ovirt-engine-setup-4.5.0.7-0.9.el8ev.noarch rhvm-appliance.x86_64 2:4.5-20220529.0.el8ev Please enter the name of the data center where you want to deploy this hosted-engine host. Data center [Default]: Please enter the name of the cluster where you want to deploy this hosted-engine host. Cluster [Default]: Made backup and restore and right from the start I noticed that the writings are not well organized like they were before this change in the code: [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup During customization use CTRL-D to abort. Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine. The provided engine backup file will be restored there, it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored. If a reference to this host is already contained in the backup file, it will be filtered out at restore time. The locally running engine will be used to configure a new storage domain and create a VM there. At the end the disk of the local VM will be moved to the shared storage. The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it. Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration. Are you sure you want to continue? (Yes, No)[Yes]: It has been detected that this program is executed through an SSH connection without using tmux. Continuing with the installation may lead to broken installation if the network connection fails. It is highly recommended to abort the installation and run it inside a tmux session using command "tmux". Do you want to continue anyway? (Yes, No)[No]: yes Configuration files: Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20220607191748-kblfdn.log Version: otopi-1.10.0 (otopi-1.10.0-1.el8ev) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection . . . [ INFO ] skipping: [localhost] Please indicate a nic to set ovirtmgmt bridge on (enp5s0f0) [enp5s0f0]: Please specify which way the network connectivity should be checked (ping, dns, tcp, none) [dns]: --== VM CONFIGURATION ==-- Please enter the name of the data center where you want to deploy this hosted-engine host. Please note: If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts. This can be useful for moving an existing hosted-engine setup to new storage which will be attached to the existing data center of HostedEngine. If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts. If you are migrating from a standalone engine to a hosted-engine, this value should be the target data center you wish to add the HostedEngine VM and this host to. The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct. Data center: Please enter the name of the cluster where you want to deploy this hosted-engine host. Please note: If you are restoring a backup of a hosted-engine, this value should be the cluster of the HostedEngine VM and hosts. This can be useful for moving an existing hosted-engine setup to new storage which will be attached to the existing cluster of HostedEngine. If you are restoring a backup of a hosted-engine, this value should be the cluster of the HostedEngine VM and hosts. If you are migrating from a standalone engine to a hosted-engine, this value should be the target cluster you wish to add the HostedEngine VM and this host to. The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct. Cluster: Why should I even provide anything for "Data center:" if its all already inside the backup and it "knows" how the data center should be called? In the original deployment it was already called "Default". The lines are not properly arranged. Same is for Cluster, its known value and exists inside the backup, I named it "Default" during initial deployment.
(In reply to Nikolai Sednev from comment #19) ... > Why should I even provide anything for "Data center:" if its all already > inside the backup and it "knows" how the data center should be called? In > the original deployment it was already called "Default". The lines are not > properly arranged. Same is for Cluster, its known value and exists inside > the backup, I named it "Default" during initial deployment. Because you may or may not want to deploy HE into a new DC and/or new CL. It could read the backup with some work, but it would only be a suggestion anyway, as the tool cannot predict what the user wants to do. As for the lines, Didi owns the patch, can you take a look?
(In reply to Nikolai Sednev from comment #19) > The lines are not properly arranged. Can you clarify exactly what you refer to? Thanks. It does not look to me worse than other long texts we output. If you only suggest to add additional line breaks, logical ones - which you'd expect regardless of terminal width - please say where and I'll add them. If it's the fact that longer lines wrap to the next line(s) (subject to terminal width), and there are not aligned with the lines before them, which makes the output somewhat ugly - I agree, but it's always been like this (since 3.3). It might be rather easy to fix, if the terminal is set correctly (e.g. if the output of `stty size` is correct). If you want to, please open a bug on otopi for this. This will impact basically all output from hosted-engine --deploy and engine-setup, so all of it should then be reviewed. That said, this isn't TeX, and our aim is not to produce perfect output.
(In reply to Yedidyah Bar David from comment #21) > (In reply to Nikolai Sednev from comment #19) > > The lines are not properly arranged. > > Can you clarify exactly what you refer to? Thanks. Lines are being wrapped. > > It does not look to me worse than other long texts we output. > > If you only suggest to add additional line breaks, logical ones - which > you'd expect regardless of terminal width - please say where and I'll add > them. > > If it's the fact that longer lines wrap to the next line(s) (subject to > terminal width), and there are not aligned with the lines before them, which > makes the output somewhat ugly - I agree, but it's always been like this > (since 3.3). Yes, I see in these lines wrapping: "Continuing will configure this host for serving as hypervisor and will create a local VM with a running engine." "it's strongly recommended to run this tool on an host that wasn't part of the environment going to be restored." "If a reference to this host is already contained in the backup file, it will be filtered out at restore time." "The old hosted-engine storage domain will be renamed, after checking that everything is correctly working you can manually remove it." "Other hosted-engine hosts have to be reinstalled from the engine to update their hosted-engine configuration." "If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts. This can be useful for moving an existing hosted-engine setup to new storage which will be attached to the existing data center of HostedEngine." "If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts." "If you are migrating from a standalone engine to a hosted-engine, this value should be the target data center you wish to add the HostedEngine VM and this host to." "The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct." "If you are restoring a backup of a hosted-engine, this value should be the cluster of the HostedEngine VM and hosts. This can be useful for moving an existing hosted-engine setup to new storage which will be attached to the existing cluster of HostedEngine." "If you are restoring a backup of a hosted-engine, this value should be the cluster of the HostedEngine VM and hosts." "If you are migrating from a standalone engine to a hosted-engine, this value should be the target cluster you wish to add the HostedEngine VM and this host to." "The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct." "You will be able to connect to the restored engine in order to manually review and remediate its configuration." "If you want to deploy with a custom engine appliance image, please specify the path to the OVA archive you would like to use." "You may provide an SSH public key, that will be added by the deployment script to the authorized_keys file of the root user in the engine appliance." > It might be rather easy to fix, if the terminal is set > correctly (e.g. if the output of `stty size` is correct). If you want to, > please open a bug on otopi for this. This will impact basically all output > from hosted-engine --deploy and engine-setup, so all of it should then be > reviewed. That said, this isn't TeX, and our aim is not to produce perfect > output. I agree. Moving this one to verified then. (In reply to Germano Veit Michel from comment #20) > (In reply to Nikolai Sednev from comment #19) > ... > > Why should I even provide anything for "Data center:" if its all already > > inside the backup and it "knows" how the data center should be called? In > > the original deployment it was already called "Default". The lines are not > > properly arranged. Same is for Cluster, its known value and exists inside > > the backup, I named it "Default" during initial deployment. > > Because you may or may not want to deploy HE into a new DC and/or new CL. If its only a basic restore of an existing environment, then why should it be changed? > It could read the backup with some work, but it would only be a suggestion I think we may enhance this one for basic restore purposes. Customer may have lost the engine and not even remember the names of host cluster or data center. > anyway, as the tool cannot predict what the user wants to do. It may simply ask the user: Is this a basic restore of the existing HE environment? Yes/No. If yes->grab the data automatically from the database and continue without 2 questions. Else->ask these questions as its an environment change. If its a basic restore of an existing HE environment, then HE have to use its old DC and host cluster values. In case of migration from bare metal to HE that would be completely different story. > > As for the lines, Didi owns the patch, can you take a look? Would you like me to open an RFE for this?
Created attachment 1887884 [details] wrapping lines
I've just added an example of wrapping lines I've mentioned.
(In reply to Nikolai Sednev from comment #22) > It may simply ask the user: > Is this a basic restore of the existing HE environment? Yes/No. > If yes->grab the data automatically from the database and continue without 2 > questions. > Else->ask these questions as its an environment change. Please see comment 3 and 4 about analyzing the backup automatically. > > If its a basic restore of an existing HE environment, then HE have to use > its old DC and host cluster values. In case of migration from bare metal to > HE that would be completely different story. > > > > As for the lines, Didi owns the patch, can you take a look? > > Would you like me to open an RFE for this? Please do. I already pushed and verified a patch [1]. With it, I get this, with my normal (wide) terminal: Please enter the name of the data center where you want to deploy this hosted-engine host. Please note: If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts. This can be useful for moving an existing hosted- engine setup to new storage which will be attached to the existing data center of HostedEngine. If you are restoring a backup of a hosted-engine, this value should be the data center of the HostedEngine VM and hosts. If you are migrating from a standalone engine to a hosted-engine, this value should be the target data center you wish to add the HostedEngine VM and this host to. The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct. Data center: If I narrow the window, I get: [ INFO ] skipping: [localhost] [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Validate selected bridge interface if management bridge does not exist] [ INFO ] skipping: [localhost] Please indicate a nic to set ovirtmgmt bridge on (ens3) [ens3]: Please specify which way the network connectivity should be checked (ping, dns, tcp, none) [dns]: --== VM CONFIGURATION ==-- Please enter the name of the data center where you want to deploy this hosted-engine host. Please note: If you are restoring a backup of a hosted- engine, this value should be the data center of the HostedEngine VM and hosts. This can be useful for moving an existing hosted-engine setup to new storage which will be attached to the existing data center of HostedEngine. If you are restoring a backup of a hosted- engine, this value should be the data center of the HostedEngine VM and hosts. If you are migrating from a standalone engine to a hosted-engine, this value should be the target data center you wish to add the HostedEngine VM and this host to. The default, for new deployments, is "Default", but is not supplied here, because you are restoring from a backup - please make sure that the value you supply is correct. Data center: I think that's an improvement. Took somewhat more work than I hoped. [1] https://github.com/oVirt/otopi/pull/22
(In reply to Nikolai Sednev from comment #22) > If its only a basic restore of an existing environment, then why should it > be changed? If its a "basic" restore, then no changes. But how you tell its just a basic restore? We can't tell based on any data, only the person doing it knows. And if we suggest a default value we go back to the initial problem: one does not read and just presses enter, deploy it in the wrong cluster/dc, causing more problems. > It may simply ask the user: > Is this a basic restore of the existing HE environment? Yes/No. > If yes->grab the data automatically from the database and continue without 2 > questions. > Else->ask these questions as its an environment change. > > If its a basic restore of an existing HE environment, then HE have to use > its old DC and host cluster values. In case of migration from bare metal to > HE that would be completely different story. > > Would you like me to open an RFE for this? OK, so we ask the user. Its a good idea, I like it. But maybe too much change/work at this stage of the product? The host would need to open the DB to get all the details, but it does not even have postgres packages available from the repo. The RFE would be nice, but I think what Didi did is good enough to prevent most incorrect redeployments.
Filed bug 2095135 on otopi.
Agreed, lets leave it as it is, at this stage of the product it will be probably too much efforts.
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) [ovirt-4.5.1] update), 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-2022:5583
Due to QE capacity, we are not going to cover this issue in our automation