Resilient Scheduling of Broker Jobs for Asynchronous Tasks in a Multi-Tenant Platform-as-a-Service (PaaS) System

• US 20150205634A1
• Filed: 01/17/2014
• Published: 07/23/2015
• Est. Priority Date: 01/17/2014
• Status: Active Grant

• Current Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Original Assignee: Red Hat, Inc. (International Business Machines Corporation)
• Inventors: McPherson, Daniel, Gupta, Abhishek, Liggitt, Jordan
• Granted Patent: US 10,310,903 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 2209/5013 Request control
• CPC Class Codes: G06F 2209/5017 Task decomposition
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/5027 the resource being a machine, e.g. CPUs, Servers, Terminals
• CPC Class Codes: G06F 9/5038 considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration scheduling strategies G06F9/4881 and subgroups

Abstract

Implementations for resilient scheduling of broker jobs for asynchronous tasks in a multi-tenant Platform-as-a-Service (PaaS) system are disclosed. A method of the disclosure includes receiving, by the processing device of a broker of a multi-tenant PaaS system from a user of the multi-tenant PaaS system, a request to complete a job, adding, by the processing device, an entry corresponding to the requested job in a data store of the broker, adding, by the processing device, another entry corresponding to the requested job in a scheduler communicably coupled to the broker, and sending, by the processing device to the user, an acknowledgment of the request and an identifier (ID) of the job, wherein the job is processed asynchronous to the sending of the acknowledgment.

Claims

1. A method, comprising:

receiving, by a processing device of a broker of a multi-tenant Platform-as-a-Service (PaaS) system from a user of the multi-tenant PaaS system, a request to complete a job;

adding, by the processing device, an entry corresponding to the requested job in a data store of the broker;

adding, by the processing device, another entry corresponding to the requested job in a scheduler communicably coupled to the broker; and

sending, by the processing device to the user, an acknowledgment of the request and an identifier (ID) of the job, wherein the job is processed asynchronous to the sending of the acknowledgment.

2. The method of claim 1, wherein the job comprises at least one of creating a new application, adding a component to an existing application, building an application, deploying an application, deleting an application, scaling up/down an application, distributing Secure Shell (SSH) keys, or distributing environment variables.

3. The method of claim 1, wherein the entry added to the data store of the broker comprises at least one of a job identifier (ID) field, a job type field, a title field, a description field, an arguments, a child jobs field, a parent job field, a state field, a completion status field, a retry count field, a rollback retry count field, a percentage complete field, a result field, an object type field, an application ID field, an application name field, a domain name field, an owner login field, a creator login field, or an object Uniform Resource Locator (URL) field.

4. The method of claim 3, further comprising setting the state field of the entry to a ‘

scheduled’

status to indicate that the job has been added to the scheduler.

5. The method of claim 1, wherein the ID of the job is utilized by the user to request a processing status of the job from the broker.

6. The method of claim 1, wherein a worker component of a server device of the broker processes the job, the worker component comprising a processing thread of the server device that invokes a model of the broker.

7. The method of claim 6, wherein the worker component elaborates the job into a plurality of sub-operations that can each be rolled back and re-tried.

8. The method of claim 1, further comprising identifying operations in the data store of the broker that do not have a ‘

scheduled’

status in the state field to determine whether the identified operations are to be scheduled at the scheduler, wherein the identifying provides resiliency to the scheduler.

9. A system, comprising:

a memory; and

a processing device communicably coupled to the memory; and

a worker component executable from the memory by the processing device, the worker component to;

reserve a job from a scheduler of a multi-tenant Platform-as-a-Service (PaaS) system;

elaborate the job into a plurality of sub-operations;

store the sub-operations to a data store of the broker, the sub-operations corresponding to an entry for the job in the data store of the broker;

execute each sub-operation;

complete the job when all of the sub-operations are executed completely; and

for each sub-operation that does not execute completely, process the sub-operation according to a retry and rollback policy corresponding to the sub-operation.

10. The system of claim 9, wherein the worker component invokes a model of a broker of the multi-tenant PaaS system to elaborate the sub-operations.

11. The system of claim 9, wherein the job comprises at least one of creating a new application, adding a component to an existing application, building an application, deploying an application, deleting an application, scaling up/down an application, distributing Secure Shell (SSH) keys, or distributing environment variables.

12. The system of claim 9, wherein the scheduler separates processing of the job from a web request that requests completion of the job.

13. The system of claim 9, wherein when each sub-operation executes completely, the worker component to update a job status and job state for the job in the data store of the broker to reflect the execution completion of the sub-op.

14. The system of claim 9, wherein the worker component to update a job status and a job state for the job in the data store of the broker when all of the sub-operations have executed completely.

15. The system of claim 9, wherein the retry and rollback policy provides resiliency to the scheduler.

16. A non-transitory machine-readable storage medium including instructions that, when accessed by a processing device, cause the processing device to perform operations comprising:

receiving, by the processing device of a broker of a multi-tenant Platform-as-a-Service (PaaS) system from a user of the multi-tenant PaaS system, a request to complete a job;

adding, by the processing device, an entry corresponding to the requested job in a data store of the broker;

adding, by the processing device, another entry corresponding to the requested job in a scheduler communicably coupled to the broker; and

sending, by the processing device to the user, an acknowledgment of the request and an identifier (ID) of the job, wherein the job is processed asynchronous to the sending of the acknowledgment.

17. The non-transitory machine-readable storage medium of claim 16, wherein the job comprises at least one of creating a new application, adding a component to an existing application, building an application, deploying an application, deleting an application, scaling up/down an application, distributing Secure Shell (SSH) keys, or distributing environment variables.

18. The non-transitory machine-readable storage medium of claim 16, wherein the entry added to the data store of the broker comprises at least one of a job identifier (ID) field, a job type field, a title field, a description field, an arguments, a child jobs field, a parent job field, a state field, a completion status field, a retry count field, a rollback retry count field, a percentage complete field, a result field, an object type field, an application ID field, an application name field, a domain name field, an owner login field, a creator login field, or an object Uniform Resource Locator (URL) field.

19. The non-transitory machine-readable storage medium of claim 16, wherein a worker component of a server device of the broker processes the job, the worker component comprising a processing thread of the server device that invokes a model of the broker, wherein the worker component elaborates the job into a plurality of sub-operations that can each be rolled back and re-tried.

20. The non-transitory machine-readable storage medium of claim 16, further comprising identifying operations in the data store of the broker that do not have a ‘

scheduled’

status in the state field to determine whether the identified operations are to be scheduled at the scheduler, wherein the identifying provides resiliency to the scheduler.