No I didn't ask for this, let me explain. Lets says you have the Batch job inside the batch job, there are two job individual jobs.
1. Scheduled patching job ( Rebooted not included )
2. Reboot Job.
I don't want the reboot jobs to be executed before commit phase is completed on scheduled patching job
Why is there a reboot job? The Patch Deploy Job can take care of any reboot requirements itself.
If you have some reason to put this into a separate member job then, what are the results when you run it?
It because of reboot tracking
When analysis is completed and remediation (Deployment jobs) are created and before even the stimulate phase starts the reboot job is kicked off. It like we have uncontrolled deployment jobs.
OK - so what is in the Batch Job Options => Execution Options
If you have "Execute jobs in parallel" then all the individual jobs in the Batch Job run against all targets simultaneously, so that behaviour would be as expected.
Try "Execute jobs sequentially" so that each individual job in the Batch Job runs against all specified targets before moving on to the next individual job listed in the jobs list.
Its already sequentially, so why I said it runs the analysis and creates the deployment jobs and that jobs goes into sleep till the time comes for execution but the reboot job is kicked off immediately when the deployment jobs are creation is completed thinking that job is completed
OK - I think that you should log a support ticket as follows to get this formally investigated with support/engineering
1. BSA BUILD VERSION PROBLEM OCCURS IN
The version of the BSA Application Server can be viewed from the Configuration / Infrastructure Management Console menu option. In the Infrastructure Management view select the Application Server of interest and the full version information will be reports in the right-side window pane as the BLManager Version value.
2. STEPS TO REPRODUCE:
Batch Job with member jobs for Patch Deploy and Server Reboot
Patch Deploy Job is configured to run simulate and stage only.
3. ACTUAL RESULTS:
Server Reboot job runs when Patch Deploy Job (simulate & stage) completes
4. EXPECTED RESULTS:
Server Reboot job should not run until Patch Deploy commit stage completes
5. BUSINESS IMPACT:
6. ADDITIONAL INFO:
Explain why you need to remove reboot responsibility from the Patch Deploy Job and put it in a separate job
Attach Job Run Logs
Thanks & Regards,
can you show a screenshot of your batch job and member job setup ?
right - so i'm pretty sure the issue is that you are using the advanced deploy options on the deploy job, so the batch job isn't actually going to run. the patching job runs, creates all its stuff and sets the schedules for the phases of the deploys, and then it's done. the patching job is only going to wait for the deploys to finish if you have the 'execute now' set in the deploy options. so the schedules get set, and then the reboot job runs because at that point the patching job is done, and the parent batch job moves on.
can you just set the reboot options in the deploy options in the remediation job settings ?
Yes, reboot can be set on the remediation jobs but problem is tracking down 1000`s of server at the same time. Also there are many server that won`t go down simply when user is logged in or for some other reason you cannot get the server rebooted by simple mechanism we need combine few techniques to get the server rebooted itself.
And also the reboot job is just an example only here.
ok, well then can you use the ‘execute now’ on the deploy job instead of the adv scheduling ?
Again its the same issue the number of the server on the scope during the outage window, don`t want to spend the time on analysis, staging inside the outage window.
i'm not sure i understand the problem. right now you are generating a bunch of deploy jobs that get scheduled to run at various times right ? so how is running a reboot job via the patch job going to help you track down systems ?