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 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 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?

Reply via email to