Bug 1099911

(In reply to Nikolai Sednev from comment #3)
> is there a way during HE--deploy to change this without
> aborting the whole procedure? 

Currently no.

> 
> If there isn't, the procedure may be improved/enhanced, at least pop up
> message should be added, that FQDN entered during deploy doesn't match real
> host's FQDN, there is another possibility to avoid this, simply by providing
> additional field for IP of engine additionally for it's FQDN at that very
> final step, so then deploy will check if real engine's FQDN matches entered
> by user FQDN within the setup and if engine reachable by provided IP, then
> will automatically change it to real FQDN, it's not simple/comfortable/easy
> to get the whole procedure start from the beginning, because of one mistake
> made in FQDN, when it even had not existed yet, after VM imaged and updated
> and engine installed on it, and around 45 minutes already gone for that
> process.
> 
> Please consider changing this from a bug to enhancement, related to
> described above.

But why this specific value and not some other? There are many ways in which wrong input can break the installation, should we pause at any such failure and ask the user for correct input? Some can be verified beforehand, which is done, some obviously can't.

I admit that this specific case (FQDN of engine in hosted-engine setup) also beat me personally several times during development, but I can't really find a good reason to exclude it and not others. The only reason is that it takes a long time between wrong input and resulting failure (45 minutes in your case).

I don't mind keeping it as an RFE for now (and I changed summary accordingly), but I really think that solving it properly probably means doing significantly more fundamental changes to all of our setup scripts and not add just this one "annoying" case.

I personally really aware of a huge work that this change will lead, I'm not the guy to decide on this, hence absolutely agree with you, PM ack is required here, I only would like to take a look at something as described bellow, it's taken from my personal experience with the system and it's usability, also taken from some of my working with networking:

IP may change during the time of installation by DHCP, FQDN also may change as DHCP may give another FQDN to HE-VM, then were asked previously, and mostly important, FQDN/IP not even exists during the asking phase of deployment, as VM created later on and even rebooted afterwards at least once, as initial run started to obtain an image from pxe for example, then procedure restarts the VM, so engine could be installed, here we may have at least two IP address changes or FQDN changes, so final step is very important one, it's where VM is running OK with all requirements, installed and updated, OS&RHEVM both to latest and greatest versions, running without any need to be rebooted any-more, meaning that only now it's IP and FQDN is stable.
Single incorrect FQDN value entered at the initial step incorrectly, even when HE-VM not even existed, will cause now for the whole process of deployment to abort, customer not always may know the exact IP/FQDN, which will be assigned to HE-VM during it's deployment, as he/she probably won't even have the rights to change things within DHCP server and most important, next time deploy will run over again, IP will change, as well as FQDN (this is what happens at LAB-QA environment here at least), customer don't have to rely on DHCP predictability, customer only have to enter FQDN once and if not matches, system should provide him/her ability to change back it via IP->FQDN or retype FQDN as it really appears on HE-VM.

We also have to take in consideration cases, where FQDN won't be available at all, as there will be no DNS servers in the customer's environment, may be they're working only with static IP addresses or with dynamically assigned IP addresses without DNS, what's then? Then installation of HE will demand minimal requirements of DNS service running at customers environment? There also may happen that DNS will be simply filtered for security reasons or because they're too chatty and causing for too much traffic, or military installations with static IP's only without DNS at all?

IMHO flexibility here should be taken in focus and usability as well, once incorrect FQDN entered we're done, the process can't check it's legibility from the beginning, it simply continues forward, until customer have all the environment, without an option to change anything, but to start over the whole process again, it's not flexible and not user friendly.

Just a note: While in principle I agree with most of the points raised here (and also stated that above), in practice I think there are mainly two scenarios:

1. A non-critical, not-important installation. E.g. for QA, testing, getting some experience, POC, whatever. In this case, adding whatever entries you feel like to the local /etc/hosts of host and engine VM should be enough.

2. A production installation. For this case, careful design/planning/preparation are expected. This includes (among probably many other things, such as storage, redundancy, etc.) choosing host names for all initial hosts and engine, perhaps also choosing some aliases for them (DNS CNAMEs), editing the DNS, etc. For this case, we provide the option to choose the MAC address of the engine VM, or accept the default. This should be enough to let the user setup DHCP beforehand so that when the engine VM boots, it automatically gets the intended IP address and hostname.

(In reply to Yedidyah Bar David from comment #7)
> Just a note: While in principle I agree with most of the points raised here
> (and also stated that above), in practice I think there are mainly two
> scenarios:
> 
> 1. A non-critical, not-important installation. E.g. for QA, testing, getting
> some experience, POC, whatever. In this case, adding whatever entries you
> feel like to the local /etc/hosts of host and engine VM should be enough.
> 
> 2. A production installation. For this case, careful
> design/planning/preparation are expected. This includes (among probably many
> other things, such as storage, redundancy, etc.) choosing host names for all
> initial hosts and engine, perhaps also choosing some aliases for them (DNS
> CNAMEs), editing the DNS, etc. For this case, we provide the option to
> choose the MAC address of the engine VM, or accept the default. This should
> be enough to let the user setup DHCP beforehand so that when the engine VM
> boots, it automatically gets the intended IP address and hostname.

Regarding topic 1, I managed in the past to do that, got failures as IP changed from DHCP right between my legs and I tried to figure out why that my deployment can't finish properly, until checked that IP has been changed, so hosts may work, yet it's a nightmare mainly because it's not automated and making the whole process much more complicated to accomplish, while manual IP should be configured at 3 places:
a)Hosting machine.
b)HE-VM.
c)Second hosting machine or multiply it by "n" machines the customer would like to add as it scales up, not that flexible indeed.

Regarding topic 2, I agree totally with you here, it was a brilliant idea to let the customer simply fill in the wanted MAC of his/hers choice, that's making the whole thing easier, especially as HE-VM's MAC derived from vinet interfaces MAC and it may be not the same MAC's, when running the deployment procedure from different hosts respectively (please correct me if I'm wrong at this one)...

(In reply to Nikolai Sednev from comment #8)
> (In reply to Yedidyah Bar David from comment #7)
> > Just a note: While in principle I agree with most of the points raised here
> > (and also stated that above), in practice I think there are mainly two
> > scenarios:
> > 
> > 1. A non-critical, not-important installation. E.g. for QA, testing, getting
> > some experience, POC, whatever. In this case, adding whatever entries you
> > feel like to the local /etc/hosts of host and engine VM should be enough.
> > 
> > 2. A production installation. For this case, careful
> > design/planning/preparation are expected. This includes (among probably many
> > other things, such as storage, redundancy, etc.) choosing host names for all
> > initial hosts and engine, perhaps also choosing some aliases for them (DNS
> > CNAMEs), editing the DNS, etc. For this case, we provide the option to
> > choose the MAC address of the engine VM, or accept the default. This should
> > be enough to let the user setup DHCP beforehand so that when the engine VM
> > boots, it automatically gets the intended IP address and hostname.
> 
> Regarding topic 1, I managed in the past to do that, got failures as IP
> changed from DHCP right between my legs

Believe me, I understand what you are talking about. If you search the net
a bit you'll see that quite a long time ago I also spent lots of time on dhcp
stability. But,

> and I tried to figure out why that
> my deployment can't finish properly, until checked that IP has been changed,
> so hosts may work, yet it's a nightmare mainly because it's not automated
> and making the whole process much more complicated to accomplish,
> while
> manual IP should be configured at 3 places:
> a)Hosting machine.
> b)HE-VM.

For any reasonable use of hosted engine, you'll need stable IP addresses for
your hosts and engine. Either manually-assigned, or provided by a well-behaving
dhcp server. This is unrelated to this bug.

> c)Second hosting machine or multiply it by "n" machines the customer would
> like to add as it scales up, not that flexible indeed.

Never heard of a "case/topic 1" installation with n>2.

> 
> Regarding topic 2, I agree totally with you here, it was a brilliant idea to
> let the customer simply fill in the wanted MAC of his/hers choice, that's
> making the whole thing easier, especially as HE-VM's MAC derived from vinet
> interfaces MAC and it may be not the same MAC's, when running the deployment
> procedure from different hosts respectively (please correct me if I'm wrong
> at this one)...

Regarding stable environment, I agree, but that doesn't happen in practice that much often, there always a short-cuts...

N>2 tested at QA.

Reducing severity, since this is an improvement / RFE

Can you please open a proper public RFE on oVirt and close this UPSTREAM?