Reported by olahaye74 on 27 Nov 2013 17:09 UTC
Unify testing in oscar so /usr/bin/system-sanity 0 acts similar to actual /usr/bin/system-sanity and /usr/bin/system-sanity 8 acts similar to current step 8 testing.
The aim is to provide for each step level a sanity test for previous steps so if the user quits the interface modify the system and comes back to oscar_wizard, the next steps doesn't fail because something has changed.
For example, avoid deploying nodes if ipv6 has been enabled otherwise torque postinstall would fail.
Maybe a good solution would be to have something similar to initscripts.
a testing dir for all tests and step{0-8} with links for each steps.
similar to /etc/init.d and /etc/rc{0-6}.d
Also we should forget to keep install_test.apb and validation_test.apb. The 1st one would check that installation is ok (example: torque services started and enabled, workq created) and the second one would try to sumbmit a testjob to the queue and check if it runs ok).
Reported by olahaye74 on 27 Nov 2013 17:09 UTC Unify testing in oscar so /usr/bin/system-sanity 0 acts similar to actual /usr/bin/system-sanity and /usr/bin/system-sanity 8 acts similar to current step 8 testing.
The aim is to provide for each step level a sanity test for previous steps so if the user quits the interface modify the system and comes back to oscar_wizard, the next steps doesn't fail because something has changed. For example, avoid deploying nodes if ipv6 has been enabled otherwise torque postinstall would fail.
Maybe a good solution would be to have something similar to initscripts. a testing dir for all tests and step{0-8} with links for each steps. similar to /etc/init.d and /etc/rc{0-6}.d
Also we should forget to keep install_test.apb and validation_test.apb. The 1st one would check that installation is ok (example: torque services started and enabled, workq created) and the second one would try to sumbmit a testjob to the queue and check if it runs ok).