PR for SRVLOGIC-310: Document "Job Service" section in the OSL docs

_attributes/common-attributes.adoc

@@ -112,7 +112,7 @@
 :ServerlessOperatorName: OpenShift Serverless Operator
 :ServerlessLogicOperatorName: OpenShift Serverless Logic Operator
 :FunctionsProductName: OpenShift Serverless Functions
-:ServerlessProductVersion: 1.33.0
+:ServerlessProductVersion: 1.34.0
 //service mesh v2
 :product-dedicated: Red Hat OpenShift Dedicated
 :SMProductName: Red Hat OpenShift Service Mesh

modules/serverless-logic-job-service-leader-election.adoc

@@ -0,0 +1,22 @@
+// Module included in the following assemblies:
+//
+// * serverless/serverless-logic/serverless-logic-job-service.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="serverless-logic-job-service-leader-election_{context}"]
+= Job service leader election process
+
+The Job service operates as a singleton service, meaning only one active instance can schedule and execute jobs.
+
+To prevent conflicts when the service is deployed in the cloud, where multiple instances might be running, the Job service supports a leader election process. Only the instance that is elected as the leader manages external communication to receive and schedule jobs.
+
+Non-leader instances remain inactive in a standby state but continue attempting to become the leader through the election process. When a new instance starts, it does not immediately assume leadership. Instead, it enters the leader election process to determine if it can take over the leader role.
+
+If the current leader becomes unresponsive or if it is shut down, another running instance takes over as the leader.
+
+[NOTE]
+====
+This leader election mechanism uses the underlying persistence backend, which is currently supported only in the PostgreSQL implementation.
+====
+
+

serverless-logic/serverless-logic-supporting-services/serverless-logic-job-service.adoc

@@ -8,4 +8,15 @@ toc::[]
 
 The Job service schedules and executes tasks in a cloud environment. Independent services implement these tasks, which can be initiated through any of the supported interaction modes, including HTTP calls or Knative Events delivery.
 
-//I will include more modules in smaller, incremental PRs to avoid having one large PR. Currently building the directory structure for the OSL content. 
+In {ServerlessLogicProductName}, the Job service is responsible for controlling the execution of the time-triggered actions. Therefore, all the time-based states that you can use in a workflow, are handled by the interaction between the workflow and the Job service.
+
+For example, every time the workflow execution reaches a state with a configured timeout, a corresponding job is created in the Job service, and when the timeout is met, an HTTP callback is executed to notify the workflow.
+
+The main goal of the Job service is to manage active jobs, such as scheduled jobs that need to be executed. When a job reaches its final state, the Job service removes it. To retain jobs information in a permanent repository, the Job service produces status change events that can be recorded by an external service, such as the Data Index Service.
+
+[NOTE]
+====
+You do not need to manually install or configure the Job service if you are using the {ServerlessOperatorName} to deploy workflows. The Operator handles these tasks automatically and manages all necessary configurations for each workflow to connect with it.
+====
+
+include::modules/serverless-logic-job-service-leader-election.adoc[leveloffset=+1]