Andy,
If you don't mind, could you do the copy/paste job. I have no way of
testing it either without re-setting up our testing infrastructure for that
integration project.
Also, a general thanks for applying updates to the esxthin.pm code so that
is stays relevant with the VCL project. In the f
This is an update on VCL-291. I have made the changes to all of the relevant
files except for esxthin.pm and committed them. I didn't want to touch
esxthin.pm in case Brian is working on it. The changes are currently being
tested/used in NCSU's production implementation and I have not seen an
I think having the provisioning modules call post_load() will allow for the
greatest flexibility. Since it shouldn't be much of an imposition and matches
how capture() works, I'll work on coding the following changes:
-call to $os->post_load() removed from new.pm
-call to $os->post_load() adde
That's a future item to work on.
A while back I had started to work on harvesting the node's ssh host keys.
I only got as far as adding the fields to the computer table, but never
made the time to complete it.
Today the user's update their known_host file or have turned off
stricthostkeychec
Aaron Peeler wrote:
makesshgkh is part of xcat1.3(which is EOL'd) and is used to collect the
ssh host keys after the install.
xCAT2.X does something different to collect the ssh host keys, so
eventually makesshgkh and the original xCAT.pm module will not be needed.
Ok, that makes sense.
makesshgkh is part of xcat1.3(which is EOL'd) and is used to collect the
ssh host keys after the install.
xCAT2.X does something different to collect the ssh host keys, so
eventually makesshgkh and the original xCAT.pm module will not be needed.
Aaron
--On January 19, 2010 4:44:26 PM -0500 S
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 t
Another option might be to have a $provision_module->post_load() routine.
Once the new.pm module detects the node is loaded and accessible, it could
call $provision_module->post_load() before moving on to the
$os->post_load().
Aaron
--On January 19, 2010 4:16:16 PM -0500 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
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
Sounds good.
On the vm modules, we'd need to decide on when a node is considered loaded.
With xcat there is a state we can check, install,image, boot, etc. With vm
we just start the vm, a couple of ideas are, maybe we wait some time period
or until it's pingable, or something else then return i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sounds like a good idea to me.
Josh
On Tuesday January 19, 2010, Andy Kurth wrote:
> I'd like to propose a design change for the modularized backend code. The
> provisioning modules (xCAT.pm, vmware.pm, etc) are currently responsible
> for monitorin
I'd like to propose a design change for the modularized backend code. The
provisioning modules (xCAT.pm, vmware.pm, etc) are currently responsible for
monitoring and waiting for the computer's OS to respond after an image has been
loaded. It would be better if this task were handled by the OS
13 matches
Mail list logo
