> Not sure why it tries to remove the puppet cert, anyone know?
Wasn't there a previous host with the same name?
> Any help is very much welcomed.
Can you verify that foreman can really sign in the box manually? Meaning
that sshd does respond and accepts the ssh key which is generated in
Foreman's database. You need to make sure the public key gets injected
onto the instance. This is used for cloud provisioning using cloud-init
rather than libvirt.
To make this short - I don't think you want to use finish scripts with
libvirt. Make a provision script snipped and call it from the kickstart
template.
I'm assuming you're using a QCOW-backed image with your libvirt?
Normally, libvirt operates using PXE which (like bare metal) would
return to the host page immediately on submit, and wait for the host
to check back in at the end of the provisioning process via a wget
call.
The behaviour you're seeing is what I'd expect to to see when using
image-based provisioning, and in particular, you're seeing the 10
minute timeout that Foreman sits in waiting for the VM to be
accessible. It will first loop over pinging the IP you configured the
host with, waiting for it to respond. It will will then commence a
basic ssh test loop, checking it can log in using the name/password in
the Image configuration page, and finally, it will copy over the
finish template and execute it (sorry Lukas, finish templates are
always used for ssh provisioning of images, regardless of the OS :P)
As such, check the host is acquiring the IP you configured in Foreman,
and that the user/password in the Image config are valid for the base
image you're booting from. It's likely to be one of those two things.
I know this is an old topic, but I have made progress on this.
Currently using Foreman 1.7.0_RC1 (deb packages). Anyways, I have been
able to setup template provisioning via libvirt images.
The problem that I am having is the same as before in that the web UI is
unresponsive once I click provision. The difference now, is that once
provisioning completes, the UI drops back to the host.
Meaning, provisioning now works, its just the web ui is unresponsive until
provisioning completes.
I am using the finish scripts as that is what is recommended in the docs
when using the template image method of provisioning.
Any ideas of why the UI might be blocking?
···
On Monday, December 1, 2014 11:16:24 PM UTC+13, Greg Sutcliffe wrote:
>
> Michael,
>
> I'm assuming you're using a QCOW-backed image with your libvirt?
> Normally, libvirt operates using PXE which (like bare metal) would
> return to the host page immediately on submit, and wait for the host
> to check back in at the end of the provisioning process via a wget
> call.
>
> The behaviour you're seeing is what I'd expect to to see when using
> image-based provisioning, and in particular, you're seeing the 10
> minute timeout that Foreman sits in waiting for the VM to be
> accessible. It will first loop over pinging the IP you configured the
> host with, waiting for it to respond. It will will then commence a
> basic ssh test loop, checking it can log in using the name/password in
> the Image configuration page, and finally, it will copy over the
> finish template and execute it (sorry Lukas, finish templates are
> always used for ssh provisioning of images, regardless of the OS :P)
>
> As such, check the host is acquiring the IP you configured in Foreman,
> and that the user/password in the Image config are valid for the base
> image you're booting from. It's likely to be one of those two things.
>
> Greg
>
That's expected behaviour, the UI always blocks when doing image-based
provisioning, with the exception of user-data enabled images. As
libvirt is SSH based, you can't do anything about it. My earlier
comment was simply that 10mins is unusual, as QCOW backed image
creation is normally fast - admittedly my finish script is fairly
short (just an ssh key and a few config files), but it usually
completes in about 1min.
Is it still blocking for 10 mins for you? If so, I'd repeat my earlier
question about whether Foreman is actually logging in to this box
(i.e. is the finish script getting run?).
