Maintenance Window Management

Current Situation

• JobScheduler supports a number of ways to introduce maintenance windows for jobs and job chains.
• At the same time more complex IT organizations who operate JobScheduduler in multi-client mode require more elaborate features to define maintenance windows based on specific client requirements.

Desired Behavior

• Object Relationship
  • First and most important: it's not the Jobs and Job Chains that require maintenance windows but the resources used by Jobs and Job Chains, e.g. the operating system of a JobScheduler Agent that requires updates.
  • Multi-client capability: resources are used by individual Jobs from the same or from a different client that JobScheduler Master is operated for. This translates to the requirement that resources are handled across a number of JobScheduler Master instances.
• Supported Objects
  • Resources
    • Resources include - but are not limited to - servers that jobs are executed for (process classes and Agent clusters) and services that jobs make use of, e.g. database services, SSH and file transfer services etc.
    • At any given time a resource is in one of the states to be available or not to be available.
    • Resources are assigned to individual jobs or to job chains to indicate that all included job nodes require availability of a resource. A single job can be assigned any number of resources.
  • Resource Downtimes
    • Resources are assigned Calendars that specify for which date a resource is not available (downtime schedule).
    • Resource downtimes include to specify the hours (begin..end) for which a resource is not available for the date indicated by the Calendar. Hours allow to specify a full day period.
    • Calendars allow to specify future resource downtimes in advance.
  • Actions
    • Actions define the way how JobScheduler responds to resource downtimes:
      • Run-time related Actions for Jobs and Orders:
        • suppress execution of a Job or an Order for a Job Chain (default),
        • anticipate execution to a previous date or postpone execution to a later date, The effective Action includes to set an individual execution date that can take place before, during or after a resource downtime period.
      • Job Chain related Actions:
        • File orders are put on hold until completion of the downtime period.
      • Job related Actions:
        • skip a job node affected by a resource downtime,
        • stop a job node.
    • Delimitation
      • Ad hoc orders that are added to a Job Chain via the JOC Cockpit user interface are executed independently from a resource downtime. This requirement considers the fact that users should not be prevented from adding Orders, e.g. for administrative purposes. If in doubt then apply permissions on a per user basis to allow/deny adding ad hoc Orders.
      • Actions are defined on a per resource base, i.e. they are applied to all jobs that are assigned the respective resource.
      • Actions can be configured to be executed just once for the next resource downtime or to be executed for all future downtimes of a resource. One-time Actions consider the fact that users want to configure Actions individually per resource downtime period. Permanent Actions are intended for automated execution with all future resource downtimes.
      • If a Job or Job Chain is not executed due to a resource downtime then this is visible from the JOC Cockpit user interface.
• Permissions
  • Permissions are required to
    • manage Resources, Resource Downtimes and Actions,
    • view Resources, Resource Downtimes and Actions.
  • Permissions are managed with the Shiro configuration.
• Supported Processes
  • Identify affected objects
    • For a given resource the dependent Jobs and Job Chains are visible from the JOC Cockpit user interface.
    • If a Job or Job Chain is configured to start before a scheduled Resource Downtime then this is visible from the JOC Cockpit. Visibility includes to display if the Job or Job Chain is likely to complete before the downtime based on the maximum execution time of the three most recent successful executions.
    • If a Job or Job Chain is configured to start after completion of a scheduled Resource Downtime then this is visible from the JOC Cockpit. 
    • Users can select to let run Jobs and Job Chains scheduled for execution before or after start or completion of the resource downtime or they can choose such Jobs and Job Chains to be subject to one of the configured Actions.
    • The list of affected objects is exportable from JOC Cockpit in an Excel-compatible format.
  • Manage Resource Downtimes
    • Allow CRUD operations to be performed on Resource Downtimes with the JOC Cockpit user interface.
    • Make Resource Downtimes visible with the JOC Cockpit Daily Plan view.
    • Terminate a Resource Downtime before completion, i.e. if the maintenance window ends earlier than planned then normal operation can be resumed immediately.

Implementation Strategy

• Resources and Resource Downtimes
  • are stored with database tables,
  • are available from the JOC Cockpit user interface with the "Resources" view,
  • are supported by web services that implement CRUD operations.
• Actions
  • are stored with database tables,
  • Run-time related Actions
    • are performed by injecting non-working days to Order and Job run-times.
  • Job Chain related Actions
    • are performed by stopping Job Chains
  • Job related Actions
    • are performed by skipping or stopping a job node.