Notes on Multi-client jobs and recurring jobs

From Scire Wiki

Recurring Jobs

Scire will have a very flexible interface that will give users the ability to create jobs that are recurring (i.e. occur at a defined interval). They will be defined with their initial settings, such as the script to run, the permissions necessary on the client(s), etc. They will then define the start and end time ranges for the job, as well as the period (time interval) between executions.

Internally, the backend will query the recurring jobs table each time a client makes a query (will need an index on clientid I guess), and look to see if any recurring jobs need to be scheduled.

Question: How does the backend know if the last time this job was deployed it didn't fail? Should that job be retried automatically or halted pending user intervention? My feeling is to keep deploying, as it will likely be more likely that problems with these jobs would be temporary failures.
When the backend gets confirmation of job completion, it will update the last_completed field for that recurring job entry. This won't necessarily be useful in indicating a previous failure, but we hope that an admin will notice the failed job, especially since he'll probably have scire setup to email him failed job reports.

Multi-Client Jobs

Jobs can be assigned to multiple clients at once, and it certainly makes sense to want to deal with deployments of updates to lots of machines at once that you would treat it as one overall "upgrade" or job. Scire will be able to provide the job view from both ends of the spectrum: modifying all of the jobs at once (assuming they have not yet deployed), or working with the individual per-jobs that are created from the multi-client job. A feature discussed was the ability to define a client to be the "Staging" client of a multi-client job where you would deploy an update for example to the staging box and see how it works and once verified, the rest of the clients could then be updated.

Ideally the multi-client table in the database will be very lightweight and have a row per client with a multi-client jobid and then a clientid for each client receiving the job. The rest of the information needed can be gathered by looking at any of the individual jobs' information. We had discussed only allowing a multi-client jobs to be applied to a "group".

Deleting a multi-client job represents a difficult scenario in which you may have jobs already created and sent to some of the clients. A more thorough discussion on the best ways to handle this situation still needs to occur.

Multi-Client Recurring Jobs

Multi-Client Recurring Jobs are the most complicated of the 3 special cases of jobs, but are just a combination of the above two cases. In a perfect world the multi-client job table in the database should be able to handle both regular jobs and recurring jobs simultaneously.