Andy Kurth wrote:
I would consider a node loaded from a provisioning module's standpoint as the
point when the bits are on the node's disk and it has been powered on. After
this point, the OS module is responsible. xCAT detecting the boot state would
be equivalent to successfully turning on the VM.
There is a bit of a dilemma though. xCAT's makesshgkh should be run after sshd
is up on the node to scan its keys or else a key mismatch error is displayed in
SSH output. I don't know of an elegant way around this. I like the idea of a
provisioning module only having to worry about putting the bits on the disk and
starting the node and then control gets passed back to new.pm and then handed
off to the OS module. This may limit flexibility though if the provisioning
module has to do things before and after the OS module.
One solution would be to have the provisioning module call $os->post_load()
instead of it being called from new.pm. This would match how image capture is
done (capture() calls $os->pre_capture()). The reasoning was because more
control needed to be given to the provisioning module for special situations.
The downside is that it imposes an additional requirement when creating a
provisioning module. I'm leaning this way at the moment.
I don't think having $provisioning->load() call $os->post_load() would
be such an imposition. However, if you want to have multiple attempts
at $os->post_load() as was mentioned in an earlier email, it'd be nice
to have a function defined in the OS module to do that looping.
I haven't used the xCAT module. What does makesshgkh do?