wking
commented
5 years ago Dup of #1428. See also #1777, closed yesterday.
/close
Closed schmaustech closed 5 years ago
wking
commented
5 years ago Dup of #1428. See also #1777, closed yesterday.
/close
openshift-ci-robot
commented
5 years ago @wking: Closing this issue.
Version
4.1.0 rc.5
Platform (aws|libvirt|openstack):
Baremetal - but virtualized (ie Ravello and/or libvirt)
What happened?
When using the kni-installer for baremetal in a virtualized setting, as for CI environments or classroom lab settings, the apiTimeout wait of 30m is not enough for the bootstrap VM to instantiate due to the reduced speed of nested virtualization.
I have noticed in these nested virtualized environments that job:
A start job is running for Ignition (disks) [ **] A start job is running for Ignition (disks) (14min 11s / no limit)
can take anywhere from 12m to 22m to complete depending on the underlying disk in the nested environment. By that time rhcos has already been laid down on the master nodes who have been waiting for the api but the bootstrap VM is still in process of coming up and the 30m timer is already running.
I use to make the timeout adjustment myself in create.go but now that we are working with release payloads where that is bundled in there I do not have that ability.
What you expected to happen?
The installation should run through and complete and depending on timing of certain virtualized environments it does finish. But I can take the same configuration and move it to another server and it might not finish due to timeout exceed.
How to reproduce it (as minimally and precisely as possible)?
I have a virtualized DCI environment where I reproduced the failure a couple of times I also have a virtualized DCI environment where it has worked as well
Anything else we need to know?
Can we please increase the timeout values from 30 to 60? Keep in mind that there will be others who will want to use virtualization as a way to provide training, demos.
References