Figure out a way to get something in the compliance job – like an EO – to error if the server isn’t compliant.
Why can’t you run the rest of the jobs in the batch job ? will that cause some harm to the server ?
The batch job is used to add a node to the a cluster. The sequence of jobs within the batch:
1. Compliance Job w/50+ rules. Rules continue to be added. These validate the state of the node, OS config, hw status, etc.
2. File Deploy Job - distribute latest config files.
3. BLPackage Deploy - execute misc commands that make the node live in the cluster.
If Compliance finds a problem, we want to stop processing so that the node isn't brought online within the cluster. Rules are continuously added by users and any non-compliant rule should stop processing. We do not want to remediate if an error is found. Can you elaborate on your idea?
A possible solution would be -
1. Create a NSH script job to check the result of the compliance job
2. Make this script job as job#2 in your batch job
3. If script job finds non-compliant rules in the compliance job result, add abort condition inside the script
4. At the batch job level, set the option to 'Continue executing batch when individual jobs return non-zero exit code' to false. It will stop the execution of the batch job
Blas - This issue is not solved but I am working on it on behalf of Jonas. The way I see it is that blcli is unable to provide a current RunKey/ID for an NSH script job, so I have to work through checking each job run against the start time of the nsh script and hope that two jobs weren't kicked off at the exact same time. Once I get over this hump I will be back to invoke commands to get the ParentJob runkey/id and then find the compliance job in the batch and check results from there. It's unfortunately not as easy as "just do this"
I will add an update when I have this working
Do you need to do it in a batch?
Do it w/ a nsh script job controlling everything, not the batch.
I suppose the jobs could be "batched" via NSH script via execute rather the intrinsic batch. Everything is currently batched up to use the discovery-remediate-compliance model so just trying to tack onto that now, will investigate driving the jobs from NSH but that could require more manual intervention to spin up the same style job for other types of compliance
Take the jobs you want to run as args to the script.
what is causing problem if you follow as per Naveen ?
Bill Robinson - Was thinking the same - definitely going to look into that method to see how feasible it would be for Admins to duplicate
Monoj Padhy - As I just said, BLCLI does not provide the current run key for anything, its all a guessing game. The only definite information it can provide is last run which is fine if you have an environment where only one job runs at a time. This will be troublesome once we start running multiples of the same job. The only way to confirm the info is to grab all the keys, loop through them to get their start time and match it to an internal script variable