Lock management for distributed application pods

Patent metadata

Field	Value
Publication number	US-12346304-B2
Application number	US-202017068020-A
Country	US
Kind code	B2
Filing date	Oct 12, 2020
Priority date	Oct 12, 2020
Publication date	Jul 1, 2025
Grant date	Jul 1, 2025

Abstract

Instances of an application pod may be deployed to many different computing environments spanning native cloud installations, SaaS providers, and on-premise data centers. In order to make uniform changes to a distribution of an application pod, a lock manager may receive and schedule lock requests from many different types of utilities. These utilities may schedule exclusive locks on the application pod throughout the different computing environments, such that patches, updates, security protocols, and other changes may be instituted without interference from changes made concurrently by other utilities. The lock manager may schedule immediate and future locks, with lock extensions and lock overrides available for flexibility.

First claim

What is claimed is:

1. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving, at a central pod lock manager, a request from a utility to place a lock on an application pod, wherein a plurality of instances of the application pod are installed across a plurality of operating environments, and the utility provides a process configured to change each of the plurality of instances of the application pod when the lock on the application pod is granted to the utility;
determining, by the central pod lock manager, that the lock on the application pod can be granted to the utility;
granting, by the central pod lock manager, the lock on the application pod to the utility; and
sending, from the central pod lock manager, an indication that the lock on the application pod has been granted to the utility, wherein the lock on the application pod prevents processes provided by other utilities in a plurality of utilities from updating any the plurality of instances of the application pod that are installed across the plurality of operating environments while the lock on the application pod is held by the utility, each of the plurality of application pods remains available to users while the lock on the application pod is held by the utility, and the process changes each of the plurality of instances of the application pod while the lock on the application pod is held by the utility.

2. The non-transitory computer-readable medium of claim 1 , wherein the plurality of operating environments comprises a plurality of cloud platforms and an on-premise data center.

3. The non-transitory computer-readable medium of claim 1 , wherein the operations further comprise:
prior to receiving the request from the utility, receiving a status request from the utility to determine whether a lock is already in place from another utility in the plurality of utilities.

4. The non-transitory computer-readable medium of claim 1 , wherein the process configured to change each of the plurality of instances of the application pod comprises a process that upgrades the application operating in each of the plurality of instances of the application pod to a new version of the application.

5. The non-transitory computer-readable medium of claim 1 , wherein the process configured to change each of the plurality of instances of the application pod comprises a process that applies a patch to the application operating in each of the plurality of instances of the application pod.

6. The non-transitory computer-readable medium of claim 1 , wherein the process configured to change each of the plurality of instances of the application pod comprises a process that increases a capacity associated with the application pod.

7. The non-transitory computer-readable medium of claim 1 , wherein the operations further comprise maintaining a schedule of locks associated with the application pod.

8. The non-transitory computer-readable medium of claim 1 , wherein determining whether the lock on the application pod can be granted to the utility comprises:
determining whether another utility in the plurality of utilities currently holds a lock on the application pod.

9. The non-transitory computer-readable medium of claim 1 , wherein determining whether the lock on the application pod can be granted to the utility further comprises:
determining whether a lock on the application pod currently held by another utility in the plurality of utilities can be overridden.

10. The non-transitory computer-readable medium of claim 1 , wherein the application pod comprises a computer resource, network resource, a storage resource, and executable code for the application.

11. The non-transitory computer-readable medium of claim 1 , wherein the operations further comprise:
receiving a request from the utility to extend the lock on the application pod; and
determining whether extending the lock on the application pod would interfere with a future lock scheduled by another utility in the plurality of utilities.

12. The non-transitory computer-readable medium of claim 1 , wherein the request from the utility to place the lock on the application pod comprises a lock duration and a future time at which the lock should be scheduled to begin.

13. The non-transitory computer-readable medium of claim 1 , wherein the request from the utility to place the lock on the application pod comprises an identifier of the utility, an activity description of the process configured to change each of the plurality of instances of the application pod, and an indication of whether a lock override is requested.

14. The non-transitory computer-readable medium of claim 1 , wherein the operations further comprise:
generating an alert to the utility when the lock on the application pod is expired.

15. The non-transitory computer-readable medium of claim 1 , wherein the operations further comprise:
providing a user interface that displays locks that have been granted or reserved for a plurality of application pods.

16. A method of managing changes to distributions of application pods, the method comprising:
receiving, at a central pod lock manager, a request from a utility to place a lock on an application pod, wherein a plurality of instances of the application pod are installed across a plurality of operating environments, and the utility provides a process configured to change each of the plurality of instances of the application pod when the lock on the application pod is granted to the utility;
determining, by the central pod lock manager, that the lock on the application pod can be granted to the utility;
granting, by the central pod lock manager, the lock on the application pod to the utility; and
sending, from the central pod lock manager, an indication that the lock on the application pod has been granted to the utility, wherein the lock on the application pod prevents processes provided by other utilities in a plurality of utilities from updating any the plurality of instances of the application pod that are installed across the plurality of operating environments while the lock on the application pod is held by the utility, each of the plurality of application pods remains available to users while the lock on the application pod is held by the utility, and the process changes each of the plurality of instances of the application pod while the lock on the application pod is held by the utility.

17. A system comprising:
one or more processors; and
one or more memory devices comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving, at a central pod lock manager, a request from a utility to place a lock on an application pod, wherein a plurality of instances of the application pod are installed across a plurality of operating environments, and the utility provides a process configured to change each of the plurality of instances of the application pod when the lock on the application pod is granted to the utility;
determining, by the central pod lock manager, that the lock on the application pod can be granted to the utility;
granting, by the central pod lock manager, the lock on the application pod to the utility; and
sending, from the central pod lock manager, an indication that the lock on the application pod has been granted to the utility, wherein the lock on the application pod prevents processes provided by other utilities in a plur

Assignees

• Oracle Int Corp

Inventors

• Rangasamy Venkatachalam
• Jeyapaul Jaganathan
• Trent Jeffrey
• Hiremath Jay
• Somasundaram Senthilkumar
• Sundaram Krithika Bharathi
• Unnikrishnan Parvathy
• Mula Vijay Bhasker
• Sharma Esha

Classifications

• G06F8/65

  Updates (security arrangements therefor G06F21/57) · CPC title

• G06F9/526

  Mutual exclusion algorithms · CPC title

• G06F9/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) · CPC title

• G06F9/5077 Primary

  Logical partitioning of resources; Management or configuration of virtualized resources (specific details on emulation or internal functioning of virtual machines G06F9/455) · CPC title

• G06F8/658

  Incremental updates; Differential updates · CPC title