Embodiments determine a patching sequence for applying software patches to correct a plurality of issues on a cloud system that comprises a plurality of pods. Embodiments receive a list of issues that occurred on each of the plurality of pods during a first time duration and, using a Frequent pattern growth algorithm, determine issues that frequently occur together and issues that likely follow other issues. Embodiments generate a matrix showing a number of each of the plurality of issues that occurred on each of the pods based on the list of issues during the first time duration, and update the matrix using matrix factorization to provide a relative ranking of each of the issues occurring on each pod. Embodiments then generate the patching sequence comprising a time ordered listing of combinations of pods and issues.
|
1. A method of determining a patching sequence for applying software patches to correct a plurality of issues on a cloud system that comprises a plurality of pods, the method comprising:
receiving a list of issues that occurred on each of the plurality of pods during a first time duration;
using a Frequent pattern growth (FP growth) algorithm, determining issues that frequently occur together and issues that likely follow other issues;
generating a matrix showing a number of each of the plurality of issues that occurred on each of the pods based on the list of issues during the first time duration;
updating the matrix using matrix factorization to provide a relative ranking of each of the issues occurring on each pod;
based on the determined issues that frequently occur together and issues that likely follow other issues and the relative ranking of each issues occurring on each pod, generating the patching sequence comprising a time ordered listing of combinations of pods and issues.
15. A predictive patching system for multi-tenant cloud system comprising a plurality of pods, the predictive patching system comprising:
one or more processors programmed to determine a patching sequence for applying software patches to correct a plurality of issues on the cloud system, the determining the patching sequence comprising:
receiving a list of issues that occurred on each of the plurality of pods during a first time duration;
using a Frequent pattern growth (FP growth) algorithm, determining issues that frequently occur together and issues that likely follow other issues;
generating a matrix showing a number of each of the plurality of issues that occurred on each of the pods based on the list of issues during the first time duration;
updating the matrix using matrix factorization to provide a relative ranking of each of the issues occurring on each pod;
based on the determined issues that frequently occur together and issues that likely follow other issues and the relative ranking of each issues occurring on each pod, generating the patching sequence comprising a time ordered listing of combinations of pods and issues.
8. A non-transitory computer-readable medium having instructions stored thereon that, when executed by one or more processors, cause the processors to determine a patching sequence for applying software patches to correct a plurality of issues on a cloud system that comprises a plurality of pods, the determining the patching sequence comprising:
receiving a list of issues that occurred on each of the plurality of pods during a first time duration;
using a Frequent pattern growth (FP growth) algorithm, determining issues that frequently occur together and issues that likely follow other issues;
generating a matrix showing a number of each of the plurality of issues that occurred on each of the pods based on the list of issues during the first time duration;
updating the matrix using matrix factorization to provide a relative ranking of each of the issues occurring on each pod;
based on the determined issues that frequently occur together and issues that likely follow other issues and the relative ranking of each issues occurring on each pod, generating the patching sequence comprising a time ordered listing of combinations of pods and issues.
2. The method of
3. The method of
4. The method of
selecting a first pod and first issue combination having a highest score and a second pod and second issue combination having a second highest score;
determining first additional issues that likely occur when the first issue and the second issue occur from the FP growth algorithm;
determining second additional issues that likely follow either the first issue or the second issue from the FP growth algorithm; and
generating the sequence comprising the first pod and the first issue and the first and second additional issues that correspond to the first pod, and the second pod and the second issue and the first and second additional issues that correspond to the second pod.
5. The method of
initializing with random values in factor matrices of lesser dimension comprising p×n and n×i matrices; and
updating the values in the factor matrices using gradient and regularization so that a dot product result matrix comes close to an initial matrix for existing values until a closest factor matrix is identified.
6. The method of
7. The method of
9. The computer-readable medium of
10. The computer-readable medium of
11. The computer-readable medium of
selecting a first pod and first issue combination having a highest score and a second pod and second issue combination having a second highest score;
determining first additional issues that likely occur when the first issue and the second issue occur from the FP growth algorithm;
determining second additional issues that likely follow either the first issue or the second issue from the FP growth algorithm; and
generating the sequence comprising the first pod and the first issue and the first and second additional issues that correspond to the first pod, and the second pod and the second issue and the first and second additional issues that correspond to the second pod.
12. The computer-readable medium of
initializing with random values in factor matrices of lesser dimension comprising p×n and n×i matrices; and
updating the values in the factor matrices using gradient and regularization so that a dot product result matrix comes close to an initial matrix for existing values until a closest factor matrix is identified.
13. The computer-readable medium of
14. The computer-readable medium of
16. The predictive patching system of
17. The predictive patching system of
18. The predictive patching system of
selecting a first pod and first issue combination having a highest score and a second pod and second issue combination having a second highest score;
determining first additional issues that likely occur when the first issue and the second issue occur from the FP growth algorithm;
determining second additional issues that likely follow either the first issue or the second issue from the FP growth algorithm; and
generating the sequence comprising the first pod and the first issue and the first and second additional issues that correspond to the first pod, and the second pod and the second issue and the first and second additional issues that correspond to the second pod.
19. The predictive patching system of
initializing with random values in factor matrices of lesser dimension comprising p×n and n×i matrices; and
updating the values in the factor matrices using gradient and regularization so that a dot product result matrix comes close to an initial matrix for existing values until a closest factor matrix is identified.
20. The predictive patching system of
|
One embodiment is directed generally to a cloud based computer system, and in particular to the patching and upgrading for a cloud based computer system.
“Cloud computing” is generally used to describe a computing model which enables on-demand access/availability to a shared pool of computing resources, such as computer networks, servers, software applications, storage and services, and which allows for rapid provisioning and release of resources with minimal management effort or service provider interaction.
Cloud computing provides services generally without direct active management by the user. Cloud computing systems generally describe data centers available to many users over the Internet. Large clouds, predominant today, often have functions distributed over multiple locations from central servers.
Embodiments determine a patching sequence for applying software patches to correct a plurality of issues on a cloud system that comprises a plurality of pods. Embodiments receive a list of issues that occurred on each of the plurality of pods during a first time duration and, using a Frequent Pattern Growth (“FP Growth”) algorithm, determine issues that frequently occur together and issues that likely follow other issues. Embodiments generate a matrix showing a number of each of the plurality of issues that occurred on each of the pods based on the list of issues during the first time duration, and update the matrix using matrix factorization to provide a relative ranking of each of the issues occurring on each pod. Based on the determined issues that frequently occur together and issues that likely follow other issues and the relative ranking of each issues occurring on each pod, embodiments then generate the patching sequence comprising a time ordered listing of combinations of pods and issues.
One embodiment uses predictive analysis to determine when to provide patches or bug fixes to selected cloud system instances or pods in order to optimize the priority of the patches.
Pods 101 that serve smaller customers may be one-to-many, multi-tenant instances. Others are dedicated to one-to-one to a single customer. Some are many-to-one, for example a cluster of pods 101 each serving the separate businesses of a large multi-national corporation. In one embodiment, cloud system 110 is the “Cloud Infrastructure” from Oracle Corp.
System 150 further includes a predictive patching system 10 that is externally coupled to cloud 110, and may be internally part of cloud 110. Predictive patching system 10 determines when to provide patches to one or more of cloud instances 101 in an optimized manner, and all other functionality disclosed herein.
System 10 includes a bus 12 or other communication mechanism for communicating information, and a processor 22 coupled to bus 12 for processing information. Processor 22 may be any type of general or specific purpose processor. System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System 10 further includes a communication device 20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system 10 directly, or remotely through a network, or any other method.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media.
Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”). A keyboard 26 and a cursor control device 28, such as a computer mouse, are further coupled to bus 12 to enable a user to interface with system 10.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include a predictive patching module 16 that uses predictive analysis to determine when to apply patches, and which instances should be “corrected” by the patches, and all other functionality disclosed herein. System 10 can be part of a larger system. Therefore, system 10 can include one or more additional functional modules 18 to include the additional functionality, such as the “Cloud Service” from Oracle Corp. A file storage device or database 17 is coupled to bus 12 to provide centralized storage for modules 16 and 18, including data regarding any type of issues generated by each of instances/pods 101. In one embodiment, database 17 is a relational database management system (“RDBMS”) that can use Structured Query Language (“SQL”) to manage the stored data.
In one embodiment, particularly when there are a large number of distributed files at a single device, database 17 is implemented as an in-memory database (“IMDB”). An IMDB is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. Main memory databases are faster than disk-optimized databases because disk access is slower than memory access, the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk.
In one embodiment, database 17, when implemented as an IMDB, is implemented based on a distributed data grid. A distributed data grid is a system in which a collection of computer servers work together in one or more clusters to manage information and related operations, such as computations, within a distributed or clustered environment. A distributed data grid can be used to manage application objects and data that are shared across the servers. A distributed data grid provides low response time, high throughput, predictable scalability, continuous availability, and information reliability. In particular examples, distributed data grids, such as, e.g., the “Oracle Coherence” data grid from Oracle Corp., store information in-memory to achieve higher performance, and employ redundancy in keeping copies of that information synchronized across multiple servers, thus ensuring resiliency of the system and continued availability of the data in the event of failure of a server.
In one embodiment, system 10 is a computing/data processing system including an application or collection of distributed applications for enterprise organizations, and may also implement logistics, manufacturing, and inventory management functionality. The applications and computing system 10 may be configured to operate with or be implemented as a cloud-based networking system, a software-as-a-service (“SaaS”) architecture, or other type of computing solution.
Referring again to
In contrast to known solutions, embodiments identify a set of pods that have the most immediate need to have patches applied, and also identify the set of patches that most need to be applied so that the occurrence of known critical issues is minimized. Embodiments use a predictive approach so the patching methodology is optimized. Embodiments use statistical and machine learning techniques in the context of cloud systems to identify the related issues and similar pods that could help in prioritizing the fixing of bugs as well as determining a patching sequence on different pods. Embodiments generate a patching sequence (i.e. a particular pod needs a patch quicker than the other patches based on the likelihood of a bug) and also prioritize the bugs that need to be fixed (i.e., prioritize bugs more likely to happen on a greater number of pods).
Example issues/bugs that may occur in a cloud based environment can include out of memory issues, heap pressure, segmentation violations, process crashes, race conditions and numerous other issues specific to applications and middleware depending on the programming languages and software/hardware platforms involved and based on the customer usage patterns, etc. These issues may be fixed through two mechanisms, patching and upgrading (e.g., new software releases). Patching involves applying patches for specific issues, while an upgrade process takes all of the pods 101 to a particular release/version that includes all of the bug fixes and enhancements. Embodiments are directed to the patching process, as opposed to the upgrading process.
Patching thousands of pods is a cumbersome process for any cloud provider. The challenges faced by a cloud provider are based on the logistical issues involved in applying all the patches on all of the pods at a single cycle. Further, if a patch results in negative side effects, it is a significant resource consuming task to roll all patches back. Therefore, known solutions divide all the pods into batches (i.e., a subsets of all of the pods) and apply the available patches to the batches in a linear manner. However, using this method, the pods where some patches are desperately needed may not be included in the initial set of patches.
In contrast to using batches, embodiments provide a fine grained predictive approach in prioritizing the patches on different pods based on association rules and recommender systems. Embodiments predict/decide the pods where critical issues are likely to happen and all other patches that need to applied on the given pod. Embodiments choose the pods and put the more relevant patches on each pod first, resulting in a more effective and optimized patching sequence and avoiding the problems that would have occurred if the patch were not applied earlier. Embodiments identify the issues that have the broadest impact, and use association rules in order to prioritize the fixes and patching the pods that have more likelihood of issues first. Embodiments improve the customer experience and also save time and effort for the cloud provider as multiple teams are typically involved in triaging the repeated issues on other pods.
Issues need to be prioritized because different customers will run different use cases at different points of time. An issue specific to a use case could occur on a pod because the customer executed the use. For example, issues/bugs that may occur during the execution/use of a cloud-based payroll processing application may include the functionality issues for corner cases/race conditions, server crashes or resource bottlenecks such as CPU, physical memory, heap pressure, etc. In the U.S., payroll may be processed twice a month, so any of these issues may appear for U.S. customers on the 15th of the month. However, in India, payroll may be processed only at the end of the month, so that the same issue may only appear for India customers at the end of the month. When other customers on other pods execute the use case in the future, the same issue could occur there too. Embodiments will predict the pods on which similar issues that could occur in the future, generate a timeline for the patches and apply them proactively.
Frequent Issue Set and Association Rules for the Issues
In operation, as an input, predictive patching system 10 receives a list of issues generated by all of the pods 101 for a fixed time period (e.g., 7 days).
Issues7days=[
Embodiments then convert the listing of issues into matrix form as follows (“Matrix 1”), in which, for each of the 7 days, a “1” indicates that the issue occurred on that day, and a “0” indicates the issue did not occur on that day:
Matrix 1
Issue1
Issue2
Issue3
Issue4
Issue5
Issue6
1
1
1
1
1
1
1
1
0
0
1
1
0
1
1
1
0
0
0
0
0
0
1
1
1
1
0
1
0
0
1
0
1
0
0
0
1
1
1
1
1
1
Embodiments then generate a frequent pattern (“FP”) tree using a Frequent Pattern Growth (“FP Growth”) algorithm. The FP Growth algorithm is a known algorithm for generating association rules and avoids inefficient candidate generation by parsing the dataset multiple times. The FP Growth algorithm builds an efficient FP-tree where the root is NULL and rest of the tree is formed so that each node represents the item in frequent item sets.
In one embodiment, the FP Growth algorithm is as follows: In the first pass, the algorithm counts the occurrences of items (attribute-value pairs) in the dataset of transactions and stores these counts in a “header table”. In the second pass, it builds the FP-tree structure by inserting transactions into a trie. Items in each transaction have to be sorted by descending order of their frequency in the dataset before being inserted so that the tree can be processed quickly. Items in each transaction that do not meet the minimum support requirement are discarded. If many transactions share most frequent items, the FP-tree provides high compression close to tree root. Recursive processing of this compressed version of the main dataset grows frequent item sets directly, instead of generating candidate items and testing them against the entire database. Growth begins from the bottom of the header table (i.e., the item with the smallest support) by finding all sorted transactions that end in that item (“I”). A new conditional tree is created which is the original FP-tree projected onto I. The supports of all nodes in the projected tree are re-counted with each node getting the sum of its children counts. Nodes (and hence subtrees) that do not meet the minimum support are pruned. Recursive growth ends when no individual items conditional on meet the minimum support threshold. The resulting paths from root to I will be frequent itemsets. After this step, processing continues with the next least-supported header item of the original FP-tree. Once the recursive process has completed, all frequent item sets will have been found, and association rule creation begins.
import pyfpgrowth
frequent_patterns=pyfpgrowth.find_frequent_patterns(Issues7 days, 3)
association_rules=pyfpgrowth.generate_association_rules(patterns, 0.7)
where 3 indicates the minimum support level (i.e., the number of occurrences that an issue or set needs to occur across all the samples) and 0.7 indicates the minimum probability that an association rule appears.
In the example, the following are the results of the issues occurring frequently together, which indicates that “Issue5” and “Issue6” occurred 4/7 days=57% of the time. Therefore, it is beneficial to have the patches available for these issues and apply them together. Similar results appear for “Issue 2” and “Issue 4”. A larger data set provides many more insights.
Sample frequent patterns
Association rules help in identifying the issues that follow others. The following illustrates example association rules for the issues:
Sample association rules
Identifying Pod Similarity and Predicting Issues
Embodiments receive as input a matrix of issues that occurred on various pods during a given time period (e.g., 7 days). A similarity of each of the pods can be determined based on the patterns of issues. The issues that occurred on the given pod and similar pods in the past provides a prediction that the same issues are likely to occur on similar pods in the near future. In embodiments, the matrix needs to be updated after every patch cycle so that fixed issues will not be included in the modelling. An example issue occurrence matrix for a period of 7 days, for 6 pods, and 6 different issues is as follows (“Matrix 2”) where each number is the amount/count of occurrences of that issue for that pod during the 7 day period. A question mark indicates that the issue did not occur on that specific pod during the time period and embodiments then determine the likelihood of the issue occurring on that pod corresponding to the cell. The value of the question mark is assigned as 0 when calculations need to be done during matrix factorization:
Matrix 2
Issue
Pod
Issue1
Issue2
Issue3
Issue4
Issue5
Issue6
Pod1
5
4
3
3
2
2
Pod2
4
5
3
?
2
2
Pod3
4
5
5
4
?
2
Pod4
?
?
?
1
1
1
Pod5
1
1
?
1
1
?
Pod6
1
?
1
?
?
1
Embodiments attempt to fill in the above pod and issue occurrence matrix (e.g., the question marks) to result in the best possible accuracy. The Matrix 2 is reasonably dense because it is a simplified example (i.e., relatively few question marks), but in reality, with thousands of pods, the matrix generally will be very sparse. Sparseness indicates the number of cells without values. In Matrix2, more ‘?’s indicate more sparseness. If an issue did not occur on a pod yet, the corresponding cell is empty(‘?’). Here only 6 pods are considered while in reality thousands of pods and tens of issues are considered. However, the matrix will generally be sparse as it is more likely that all issues did not occur yet in different pods as it depends on the use cases, system load, etc., in the selected time period.
Embodiments use matrix factorization algorithms to identify the likely issues on a given pod based on the issues in the other pods. Embodiments identify what issues that did not occur on a pod might occur in the future so that those pods can be proactively patched.
The Matrix 2, referred to as P_I is factorized into
P_I=IDPT (Equation 1)
where I is an Issue matrix, D is a diagonal matrix and PT is the Transpose of a Pod matrix.
If n is the number of times an issue i has occurred on a pod p, j is the row of I for a pod and q is the column of PT for a specific issue, Equation 1 becomes:
npi=jpqi (Equation 2)
When Equation 2 is solved with least error, embodiments determine the number of times an issue i can happen on a pod p. A matrix factorization algorithm is a class of collaborative filtering algorithms that work by decomposing the matrix into the product of two lower dimensionality rectangular matrices. One embodiment uses a matrix of p rows and i columns (i.e., an initial matrix of p by i dimensions). p represents the number of pods and i represents the number of issues. Embodiments start with random values in matrices (factors) of lesser dimension, for example p×n and n×i matrices. The dot product will give a p×i matrix, result matrix. Embodiments then keep updating the values in factor matrices using gradient and regularization so that their dot product result matrix comes close to the initial matrix for the existing values.
The closest factor matrices are identified and the dot product of which gives a fully filled result matrix, including the question marks replaced with a numerical rating. Each cell in the result matrix gives the relative rating of an issue on a pod. The higher the number in the result matrix, the higher the probability of the issue occurring on the given pod. The patches can be planned first for the issues that might happen more on the pod. The complete matrix could look like the following after using matrix factorization techniques (Matrix 3):
Matrix 3
Issue
Pod
Issue1
Issue2
Issue3
Issue4
Issue5
Issue6
Pod1
4.7
4.4
2.9
2.9
2.0
1.9
Pod2
4.3
4.4
3.3
3.1
2.1
2.0
Pod3
4.0
5.1
4.7
4.0
2.9
2.3
Pod4
1.3
1.6
1.5
1.2
0.9
0.7
Pod5
1.0
1.2
1.1
0.9
0.7
0.5
Pod6
0.9
1.3
1.3
1.1
0.8
0.6
One embodiment uses the following steps/calculations to generate Matrix 3 above:
(1) Step1: For the initial matrix of 6×6, start with lower order factors of 6×2 and 2×6 matrices with random numbers—
Initial Factor1 (6×2 matrix)
[[0.78 0.632]
[[0.544 0.411 0.342 0.505 0.382 0.76]
[[0.592 0.617 0.748 0.518 0.696 1.071]
[[4.408 3.383 2.251 2.48 1.302 0.925]
[[0.783 0.635]
[[0.546 0.413 0.343 0.506 0.382 0.76]
[[0.599 0.623 0.753 0.522 0.71.076]
[[4.401 3.376 2.245 2.476 1.298 0.92]
[[0.786 0.637]
[[0.549 0.416 0.345 0.507 0.383 0.761]
[[0.605 0.63 0.759 0.526 0.703 1.081]
[[4.395 3.37 2.24 2.472 1.295 0.915]
[[2. 1.]
And
[[1.9 1.5 0.5 0.9 0.5 0.8]
The following Python pseudocode code segments can be used for the above matrix factorization in some embodiments to generate the equivalent of Matrix 3:
#numpy package for matrix operations
import numpy as np
#Start with 2 factor matrices with random values
Factor1=np.random.rand(numRows, lowerOrder)
Factor2=np.random.rand(numCols, lowerOrder)
Ex: Factor1=np.random.rand(6, 2)
#Find the dot product of factors
resultMatrix=np.dot(Factor1, Factor2)
#Find the error/cost/difference
For all rows and columns
CostMatrix=InitialMatrix[row][col]−np.dot(Factor1[row,:],Factor2[:,col])
#Update values in the factor matrices with gradient and regularization
for rowNum in range(len(InitialMatrix)):
#Overall cost or difference or error ie. Sum of squares of difference in different elements
for rowNum in range(len(InitialMatrix)):
#The above is repeated for number of steps with updated values in factors
listOfStepsCost.append({“step”:step, “Cost”:e})
#Plot cost graph. Final factors are taken with minimum cost
pd.DataFrame(IistOfStepsError).plot.line(x=‘step’, y=‘Cost’)
Embodiment use Matrix 3 (or the generated ratings values of Matrix 3) to detect issues that are likely to happen on a given pod and the pods on which an issue is more likely to happen. For example, for Matrix 3, the following illustrates the priority of patches for Pod3 along with relative ratings:
Issue
Rating
Iesue2
5.1
Issue3
4.7
Issue4
4.0
Issua1
4.0
Issue5
2.9
The key issues that are likely to happen on more pods needs to be fixed and patched at higher priority. The following illustrates the importance of a patch relative to Issue1 on different pods:
Pod
Rating
Pod1
4.7
Pod2
4.3
Pad3
4.0
Pod4
1.3
Pod5
1.0
Embodiments then use the above information to choose the pods to patch in the immediate/initial waves. The pods where most critical issue(s) is/are likely to occur, can be selected in the immediate wave. Once the batch of pods is selected, the patches corresponding to the most likely issues to occur, using the above association determinations, are included in the patch bundle. For example, for the above examples, a sequence of patching can be as follows:
At 502, input data is received from pods 101 during a fixed period of time (e.g., 1 week, or 7 days) that includes an identity of the issues occurring on each pod during each day (or other time period such as each hour), as shown for example in Matrix 1, as well as the number of occurrences of each issue during the period of time, as shown for example in Matrix 2.
At 504, a FP growth algorithm is used to optionally generate an FP tree for the issues.
AT 506, based on the FP tree, or calculated directly without generating an FP tree, issues that frequently occur together (i.e., frequent issues sets) are determined, and issues that likely follow other issues or combination of issues (i.e., issue association rules) are determined.
At 508, a pod and issue matrix is generated (e.g., Matrix 2) that shows the number of each of the issues that occurred on each of the pods during the period of time.
At 510, matrix factorization is used to update the pod and issue matrix that provides a relative ranking of each issue occurring on each pod (e.g. Matrix 3).
At 512, the determination of 506 and 510 are used to determine a priority/order of applying which patches to which pods, and then the patches are applied. In embodiments, the starting point will be pod and issue combination with the high score in Matrix3. For example, assume PodX and IssueY are selected. Then other issues will be picked up based on the association rules and frequent issue sets where IssueY is part of. Then, for PodX, the list of other issues that are more likely to occur are retrieved from Matrix3. The associated issues are then determined for those issues. From both these combinations, PodX will have a plurality of issues that need to be patched. Similarly, and subsequently, other pods where the selected issues have high scores and other associated issues will be selected for patching.
As disclosed, for cloud system instances/pods, different issues happen at different times and patching is done to correct the issues. However, when the system includes thousands of pods, it is important to prioritize the batches of pods and batches of patches to be applied. Embodiments use data concerning different issues that occurred on different pods during a specific duration and provide a recommendation on the pods to be patched first and the additional patches to be applied on each pod. For example, if Issue3 occurs on some pods, embodiments determine the pods where Issue3 is more likely to happen as well and suggests those additional pods for patching. The model used by embodiments is updated every time a patching cycle occurs on the pods so that it is aware and does not predict an issue to occur if it is already patched.
Embodiments identify all the pods where a particular issue is likely to occur, and also for the given pod, what are the likely issues to happen with a relative rating. This helps in prioritizing the fixing of bugs and in identifying the pods that can be patched in the initial and other early batches. For the selected pod, embodiments determine what are the other patches that need to be applied. In contrast, known solutions generally take all the patches available, divide all the pods into batches, and apply them. Applying all the patches on all the pods all at once creates logistical issues. Further, if the patch creates an unwelcome side effect, the patch needs to be rolled back from all the pods. In contrast, embodiments provide a fine grained approach that helps in patching the pods first where the issue is more likely to happen even though it has not already occurred.
Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
Patent | Priority | Assignee | Title |
Patent | Priority | Assignee | Title |
8782664, | Jan 14 2004 | International Business Machines Corporation | Autonomic hardware assist for patching code |
9501541, | Sep 07 2012 | Oracle International Corporation | Separation of pod provisioning and service provisioning |
20060048130, | |||
20120151469, | |||
20140075031, | |||
20140142870, | |||
20140245283, | |||
20180011700, | |||
20180188961, | |||
20180349434, | |||
20190303127, | |||
20200334102, | |||
CN108415789, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Aug 10 2020 | VATTIKUTI, SRINIVAS | Oracle International Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 053454 | /0944 | |
Aug 11 2020 | Oracle International Corporation | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Aug 11 2020 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
Date | Maintenance Schedule |
Dec 21 2024 | 4 years fee payment window open |
Jun 21 2025 | 6 months grace period start (w surcharge) |
Dec 21 2025 | patent expiry (for year 4) |
Dec 21 2027 | 2 years to revive unintentionally abandoned end. (for year 4) |
Dec 21 2028 | 8 years fee payment window open |
Jun 21 2029 | 6 months grace period start (w surcharge) |
Dec 21 2029 | patent expiry (for year 8) |
Dec 21 2031 | 2 years to revive unintentionally abandoned end. (for year 8) |
Dec 21 2032 | 12 years fee payment window open |
Jun 21 2033 | 6 months grace period start (w surcharge) |
Dec 21 2033 | patent expiry (for year 12) |
Dec 21 2035 | 2 years to revive unintentionally abandoned end. (for year 12) |