Maintenance Mode

You can run Digital.ai Release in maintenance mode, which is a special mode of operating a single Digital.ai Release instance or an entire cluster. The primary use is to boot-up Release in maintenance mode for post-upgrade smoke testing and clean-up activities.

Note: You can put Release in maintenance mode on JVM-based setup only. Maintenance mode feature is not available with Operator-based setup. Additionally, it is not recommended to start up a cluster in this mode.

IMPORTANT: In case of a cluster, you must put all the nodes in maintenance mode. Having some nodes in maintenance mode and some in normal mode could leave the cluster unpredictable.

Functions That Are Disrupted in Maintenance Mode

The following Release functions are suspended while you run Release in maintenance mode.

• Automatic triggering of tasks and releases.
• Archiving—No releases are archived while in maintenance mode. However, releases that are completed in maintenance mode are pre-archived.
• Archive purging—Archived releases are purged once you turn off the maintenance mode.
• E-mail notifications—No email notifications are sent to any user, regardless of the role, permissions, and so on.
• Non-admin user access—Log-in to Release and access to REST APIs are restricted only to administrators.
• Task recovery—If there are tasks to recover after shutdown, the recovery happens only on the next regular start up of the Release server.

Put Release in Maintenance Mode

Maintenance mode is enabled by configuring it in the <distribution_root>/conf/xl-release.conf file.

Here's a list of xl-release.conf file keys that you must set to put Release in maintenance mode.

Path	Allowed values	Description
xl.maintenance.enabled	true/false	Enable or disable maintenance mode respectively
xl.maintenance.restrictApiAccess	true/false	If set to false, only administrators can access the REST API endpoints. If set to true, no one can access the REST API. All REST API invocations will result with HTTP 503 Service unavailable. Note that xl.maintenance.restrictApiAccess is evaluated only if xl.maintenance.enabled is set to true

Note: There is no way to get the Release server into maintenance mode or back into normal mode without shutting it down, enabling or disabling the maintenance mode, and starting it again.

What happens to the triggers that are blocked from being triggered while in maintenance mode?

Here's how different types of triggers—that should have been invoked—but were blocked due to the maintenance mode—are handled once you exit the maintenance mode.

Trigger Type	Missfire Handling
Fixed moment in time trigger. For example, releases that have the Start automatically on selected date check box selected	The trigger will be invoked on next server start up.
Simple repeating trigger. For example, Git poll every 10 seconds	No reattempt1
CRON-based trigger	No reattempt1

Footnotes

1. Suppose the system was in maintenance mode between 13:00 hours and 14:00 hours local time, and that there's an active Git:Poll trigger (with a poll rate of 1 minute) that was supposed to kick off a release for every new commit, and suppose there were several commits that happened during the maintenance mode. In this case, only the last commit would be built at the next poll in the first minute after 14:00 hours. ↩ ↩²