2:43 a.m.
On Tue, May 5, 2020 at 6:02 AM Charles Kozler <ckozleriii(a)gmail.com> wrote:
I'd like to share this with the list because its something that I changed for
convenience, in .bashrc, but had a not so obvious rippling impact on the ovirt self hosted
installer. I could imagine a few others doing this too and I'd rather save future them
hours of google time
Thanks!
Every install failed no matter what and it was always at the SSO step to revoke token
(here:
https://github.com/machacekondra/ansible/blob/71547905fab67a876450f95c9ca...)
and then reissue new token but the engine log yielded different information. The SSO
failure was a red herring
What do you mean by that? Usually (I am not a native English speaker),
"red herring" means, for me, "something that made me look at the error
not in the place where it actually occurred". In this case:
engine.log:2020-05-04 22:09:17,150-04 ERROR
[org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
(EE-ManagedThreadFactory-engine-Thread-1) [61038b68] Host installation failed for host
'672be551-9259-4d2d-823d-07f586b4e0f1', 'node1': Unexpected error during
execution: stty: standard input: Inappropriate ioctl for device
engine.log:2020-05-04 22:09:17,145-04 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog]
(EE-ManagedThreadFactory-engine-Thread-1) [61038b68] SSH error running command
root@node1:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t
ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null
2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar
--warning=no-timestamp -C "${MYTMP}" -x &&
"${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine
DIALOG/customization=bool:True': RuntimeException: Unexpected error during execution:
stty: standard input: Inappropriate ioctl for device
The error message does mention 'stty', and I guess this is
more-or-less the best the engine could have done, other than trying to
analyze your .bashrc.
I was on the hunt for this for the better part of 2 days or so, because who else has
anything to do during quarantine, wracking my brain and trying everything to figure out
what was going on
Well, it was my own fault
# cat .bashrc | grep -i stty
stty erase ^?
A common idiom for such cases is to check PS1 - bash should set it
only for interactive shells. E.g.:
if [ "$PS1" ]; then
stty erase ^?
fi
But you might better fix your terminal emulator instead.
With this set in the .bashrc of the node I was running the installer via cockpit from,
ovirt installer will fail to install
This was set for convenience to have backspace work in vim since at some point it stopped
working for me
:-(
(Used to be more common 20-30 years ago, when people actually had many
more different physical terminals, terminal emulators, and unix-like
OSes. Sadly our industry failed to fix this, requiring such
workarounds, so far. See also, likely way-out-of-date:
http://www.tldp.org/HOWTO/BackspaceDelete/ )
Should I file this as a bug?
You can, but not sure it will be handled, unless you provide very
concrete expected-behavior with sound reasoning...
The message generated is more of a warning then a failure but I do
not know the internals of ovirt like that. Commands still actually execute fine
ovirt-engine(a)192.168.222.84) # ssh 10.0.16.221 "uptime"
root(a)10.0.16.221's password:
stty: standard input: Inappropriate ioctl for device
22:30:01 up 22:45, 2 users, load average: 0.80, 0.62, 0.80
Checking the current 4.3 code, I see that we fail if there is anything
at all on stderr.
Trying to check git log finding out why we do that, I fail to find a
concrete reason - although, if you ask me, it might make sense.
Changing that is easy, but then might make real errors you should
actually notice, go unnoticed.
In 4.4 we do not have this code anymore, and use ansible instead for
host-deploy. Since 4.4 GA is expected soon (a few weeks?), and 4.3
will be EOLed soon after that, I do not see much point in investing in
this anyway.
One thing I think should be called out in the docs, and called out
very loud, is that the entire ovirt installer expects a clean 110% machine that is done
right after install and provided and IP and hostname. Its not that obvious, but it is now
Well, I wouldn't say "110%", but the fact that we try to do things
automatically, on remote machines, using tools that were mainly
intended for manual/interactive use, does mean that we are limited.
You are still welcome to open a documentation bug if you feel one is needed.
Again, thanks for the report!
Best regards,
--
Didi