Notes on Deleting jobs
From Scire Wiki
Deleting or cancelling jobs is a very complicated process because it can often leave your clients in an unstable state. This complexity is compounded when dealing with mutli-client jobs and recurring jobs.
Contents |
Before Deployment
Before the deployment, the options for cancelling jobs will be expansive because this is a relatively "easy" task. Furthermore, it is a safe task because the jobs have not yet been deployed to the clients. If the job is a recurring job or multi-client job, and the individual client job(s) have not yet been created (which is the case if we are talking "before deployment"), the recurring job can be cancelled and the individual client job(s) not created. If the individual client job(s) have been created but not deployed these also will be able to be stopped before they go out
After Deployment, after execution
It's too late buddy, you're up a creek. But wait! We'll have rollback capabilities for packages using a package manager. Also, it should be possible to rollback changes to configuration files and such. Rollback capabilities for other job types can be added through the use of client-side plugins (in the future).
After Deployment, during execution
We will have an "emergency stop" feature to kill a job in progress and report back to the server the log of the job. Preferably immediately following this step a "gathering state" job or two will need to be run to determine the resultant state of the client.
