Execution plan generating method and apparatus, and computing device cluster

Abstract

An execution plan generating method, comprising: acquiring state information of an infrastructure, and on the basis of the content of the state information of the infrastructure, obtaining a target state of the infrastructure; acquiring the current state of the infrastructure, and comparing the current state of the infrastructure with the target state of the infrastructure to obtain first-level execution topology information; and parsing an EL expression on the basis of each operation in a change operation to obtain second-level execution topology information. According to the present application, in the method, after the first-level execution topology information of an execution plan is obtained, EL is used to perform code-based description on a change trend of a resource attribute, and the EL expression is parsed on the basis of the change operation for each differential resource to obtain fine-grained internal operations of the change operation for each differential resource, so that the content of the execution plan is enriched, the transparency of a resource change execution process is improved, users can intuitively understand a detailed resource change process, and the risks and costs related to manual change verification are significantly reduced.

Description

An execution plan generation method, apparatus, and computing device cluster

[0001] This application claims priority to Chinese Patent Application No. 202411718108.4, filed on November 27, 2024, entitled “A Method, Apparatus and Cluster of Computing Devices for Generating an Execution Plan”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention relates to the field of cloud computing technology, and in particular to an execution plan generation method, apparatus, and computing device cluster. Background Technology

[0003] With the rapid advancement of digital transformation, enterprises face increasing pressure regarding the scale and complexity of their information technology (IT) infrastructure. Traditional infrastructure management methods, including the configuration and deployment of resources such as servers, network devices, and databases, typically require manual intervention. This approach is not only inefficient and labor-intensive but also prone to introducing errors. This makes it difficult to maintain environmental consistency, thus posing significant challenges to system stability, security, and subsequent operation and maintenance. Summary of the Invention

[0004] To address the aforementioned issues, embodiments of this application provide an execution plan generation method that can improve the transparency of infrastructure change execution and reduce the risks and costs associated with manual change confirmation. Furthermore, this application also provides an execution plan generation apparatus and a computing device cluster corresponding to this execution plan generation method.

[0005] Therefore, the following technical solutions are adopted in the embodiments of this application:

[0006] In a first aspect, this application provides a method for generating an execution plan. The method is applied to a cloud service platform for managing infrastructure, which includes at least one node storing the state of the infrastructure. The method includes: acquiring the state information of the infrastructure and obtaining a target state of the infrastructure based on the content of the state information; acquiring the current state of the infrastructure and comparing it with the target state to obtain first-level execution topology information; the first-level execution topology information includes at least one change operation for a differential resource, where the differential resource refers to a resource in the infrastructure whose current state and target state are different, and the change operation includes at least one of creation, update, and deletion; parsing an Expression Language (EL) expression based on each of the change operations to obtain second-level execution topology information; the second-level execution topology information includes at least one sub-operation corresponding to the change operation of the at least one differential resource.

[0007] In this implementation, after obtaining the first-level execution topology information of the execution plan, the method can use EL to codedly describe the change trend of resource attributes, and parse the EL expression based on the change operations of each different resource to obtain the fine-grained internal operations of the change operations of each different resource. This makes the content of the execution plan richer, improves the transparency of the resource change execution process, and allows users to intuitively grasp the detailed process of resource changes, thereby significantly reducing the risk and cost of manual confirmation of changes.

[0008] In one implementation, parsing the Expression Language (EL) expression based on each operation in the change operation to obtain secondary execution topology information specifically includes: determining the type of each operation in the change operation; matching the operation context corresponding to each operation in the change operation based on the operation type; calculating the EL expression in the operation context corresponding to each operation in the change operation to obtain the secondary execution topology information; the secondary execution topology information includes at least one sub-operation corresponding to the change operation of at least one differential resource.

[0009] In this embodiment, the method finds the corresponding operation context based on the type of each operation in the change operation of the difference resource, and then calculates the EL expressions defined in the operation context one by one to generate fine-grained internal operations for each resource, thereby improving the visibility of the execution process.

[0010] In one implementation, obtaining the current state of the infrastructure specifically includes: obtaining the state of the infrastructure after the last change from the stack, and / or obtaining the recorded running state of the infrastructure from the node, to obtain the current state of the infrastructure.

[0011] In one embodiment, the method further includes: arranging at least one sub-operation corresponding to the change operation of the at least one differential resource according to a flow orchestration topology; the flow orchestration topology is used to define the preorder and successor relationships between sub-operations.

[0012] In this embodiment, the method performs topological sorting on these sub-operations based on the preorder and successor relationships declared in the process orchestration topology definition of operation association, to ensure that change operations can be performed in an orderly manner.

[0013] In one embodiment, the method further includes: selecting at least one specific sub-operation from each operation in the at least one difference resource change operation according to a preset filtering rule; activating a monitoring field of the at least one specified sub-operation; the monitoring field instructing the orchestration engine to pause the execution of the next sub-operation.

[0014] In this implementation, the method adds observability checkpoints by activating the monitoring fields of selected specific sub-operations. When the orchestration process reaches the observability checkpoint set by the monitoring field according to the execution plan, the system automatically pauses the execution flow so that the user can check whether the changes have caused any unexpected anomalies and decide whether to continue executing subsequent operations.

[0015] In one embodiment, the method further includes: receiving a user-input instruction, and, based on the instruction, activating and / or deactivating a monitoring field for at least one specific sub-operation; the monitoring field instructs the orchestration engine to pause execution of the next sub-operation.

[0016] In this implementation, the method can set the location and number of observable checkpoints according to the user's needs, which can improve the flexibility of monitoring.

[0017] In one implementation, after the orchestration engine pauses execution of the next sub-operation, the method further includes: displaying a status interface; the status interface is used to display the status of the infrastructure when it reaches an observability checkpoint where the monitoring field is activated.

[0018] In this embodiment, the method displays a status interface, allowing users to directly understand whether resources have encountered anomalies after the sub-operation was executed, without the need for active searching, thereby improving the convenience of inspection.

[0019] In one embodiment, the method further includes: detecting whether each sub-operation in the secondary execution topology information matches a preset risk level or operation type; if each sub-operation in the secondary execution topology information matches the preset risk level or operation type, sending the secondary execution topology information to the orchestration engine; if each sub-operation in the secondary execution topology information does not match the preset risk level or operation type, modifying the status template.

[0020] In this implementation, the method can match the generated execution plan with the risk level and operation type recorded in the change request form. Based on the matching result, it can determine whether to execute the execution plan or modify the status template to ensure that the execution plan is carried out within a controllable risk range, thereby reducing potential risks in operation and maintenance and improving the overall operation and maintenance security and reliability.

[0021] Secondly, this application provides an execution plan generation apparatus, comprising: a first generation module, configured to acquire the status information of the infrastructure and, based on the content of the status information of the infrastructure, obtain the target status of the infrastructure; and acquire the current status of the infrastructure and, based on the comparison between the current status of the infrastructure and the target status of the infrastructure, obtain first-level execution topology information; the first-level execution topology information includes at least one change operation for a differential resource, wherein the differential resource refers to a resource in the infrastructure whose current status and target status are different, and the change operation includes at least one operation among creation, update, and deletion; and a second generation module, configured to parse an Expression Language (EL) expression based on each operation in the change operation to obtain second-level execution topology information; the second-level execution topology information includes at least one sub-operation corresponding to the change operation of the at least one differential resource.

[0022] In one implementation, the second generation module is specifically used to determine the type of each operation in the change operation; based on the type of operation, match the operation context corresponding to each operation in the change operation; calculate the EL expression in the operation context corresponding to each operation in the change operation to obtain the secondary execution topology information; the secondary execution topology information includes at least one sub-operation corresponding to the change operation of at least one differential resource.

[0023] In one implementation, the first generation module is specifically used to obtain the state of the infrastructure after the last change from the stack, and / or obtain the recorded running state of the infrastructure from the node, to obtain the current state of the infrastructure.

[0024] In one embodiment, the second generation module is further configured to arrange at least one sub-operation corresponding to the change operation of the at least one differential resource according to the process orchestration topology; the process orchestration topology is used to define the preorder and successor relationships between sub-operations.

[0025] In one embodiment, the apparatus further includes: a point generation module, configured to select at least one specific sub-operation from each operation in the at least one differential resource change operation according to a preset filtering rule of the infrastructure; activate a monitoring field of the at least one specified sub-operation; and the monitoring field instructs the orchestration engine to pause the execution of the next sub-operation.

[0026] In one implementation, the point generation module is further configured to receive instructions input by the user, and, according to the instructions, activate and / or deactivate at least one monitoring field for a specific sub-operation; the monitoring field instructs the orchestration engine to pause the execution of the next sub-operation.

[0027] In one implementation, the point generation module is further configured to display a status interface after the orchestration engine pauses execution of the next sub-operation; the status interface is configured to display the status of the infrastructure when it reaches the observability checkpoint activated by the monitoring field.

[0028] In one implementation, the point generation module is further configured to detect whether each sub-operation in the secondary execution topology information matches a preset risk level or operation type; if each sub-operation in the secondary execution topology information matches the preset risk level or operation type, the secondary execution topology information is sent to the orchestration engine; if each sub-operation in the secondary execution topology information does not match the preset risk level or operation type, the status template is modified.

[0029] Thirdly, embodiments of this application provide a computing device, including: at least one memory; and at least one processor, the processor being configured to execute instructions stored in the memory to cause the computing device to perform the various possible implementations of the first aspect.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium including computer program instructions, which, when executed by a computing device, perform the various possible implementations of the first aspect.

[0031] Fifthly, this application provides a computer program product containing instructions, characterized in that the computer program product stores instructions that, when executed by a computing device, cause the computing device to implement various possible implementations of the first aspect.

[0032] In a sixth aspect, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, such that the computing device cluster performs the various possible implementations of the first aspect.

[0033] In a seventh aspect, embodiments of this application provide a computer-readable storage medium including computer program instructions that, when executed by a cluster of computing devices, perform the various possible implementations of the first aspect.

[0034] Eighthly, this application provides a computer program product containing instructions, characterized in that the computer program product stores instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to implement various possible implementations of the first aspect. Attached Figure Description

[0035] The accompanying drawings used in the description of the embodiments or prior art are briefly introduced below.

[0036] Figure 1 is a schematic diagram of the process of generating an execution plan using the IaC tool in related technologies;

[0037] Figure 2 is a schematic diagram of a scenario for generating an execution plan using an execution plan generation system provided in an embodiment of this application;

[0038] Figure 3 is a schematic diagram of the process of generating a secondary execution topology by an execution plan generation system provided in an embodiment of this application;

[0039] Figure 4(a) is a schematic diagram of a user using the execution plan generation system provided in the embodiments of this application;

[0040] Figure 4(b) is a schematic diagram of the structure of the resource orchestration system provided in the embodiments of this application;

[0041] Figure 5 is a flowchart of an execution plan generation method provided in an embodiment of this application;

[0042] Figure 6 is a schematic diagram of the scenario in which the execution plan generation system provided in the embodiments of this application generates an execution plan;

[0043] Figure 7 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0044] Figure 8 is a schematic diagram of the architecture of a computing device cluster provided in an embodiment of this application;

[0045] Figure 9 is a schematic diagram of another computing device cluster architecture provided in the embodiments of this application. Detailed Implementation

[0046] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0047] In this article, the term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The symbol " / " in this article indicates that the related objects are in an "or" relationship; for example, A / B means A or B.

[0048] The terms "first" and "second," etc., used in the specification and claims herein are used to distinguish different objects, not to describe a specific order of objects. For example, "first response message" and "second response message," etc., are used to distinguish different response messages, not to describe a specific order of response messages.

[0049] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0050] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0051] Before introducing the technical solution protected by this application, several technical terms involved in the technical solution protected by this application will be explained in advance, namely:

[0052] Expression Language (EL) is a computer programming language specifically designed for calculating and expressing values ​​in programs. EL consists of a set of basic elements, including variables, operators, functions, and constants, which give it powerful data processing and parsing capabilities. EL supports multiple data types and provides a rich library of built-in functions. This language is widely used in web template engines, scripting, and other scenarios that require dynamically generated or calculated values.

[0053] Infrastructure as Code (IaC) is a software development methodology that automates the construction and management of infrastructure. IaC allows IT professionals to transform traditional manual configuration tasks into code, enabling them to define, deploy, and manage IT infrastructure such as servers, virtual machines, network components, load balancers, and storage solutions just like developing software. This approach eliminates manual configuration and scripted operations, instead using code to configure infrastructure, making the entire process more replicable, consistent, and automated, significantly improving management efficiency and system reliability. IaC makes infrastructure configuration and deployment more precise and efficient, reduces human error, and can quickly adapt to changes.

[0054] Infrastructure forms the cornerstone of an enterprise's technology architecture, encompassing the hardware, software, network resources, and services necessary to maintain the operation of information systems. These elements collectively support the enterprise's daily operations and business processes. The stability, security, and performance of infrastructure have a decisive impact on an enterprise's continuous operation and work efficiency. With the continuous advancement of cloud computing and virtualization technologies, modern infrastructure increasingly integrates cloud services and software-defined solutions, which not only enhances system flexibility but also improves its scalability.

[0055] Next, the technical solution provided in this application will be introduced.

[0056] Generally, against the backdrop of rapid development in information technology, Infrastructure as a Service (IaC), as a new method for automating the management and deployment of infrastructure, has become a key practice in modern software development and operations. Currently, commonly used IaC tools in the industry include HashiCorp Terraform, AWS CloudFormation, and Huawei Cloud Resource Formation Service (RFS).

[0057] As shown in Figure 1, in the current IT industry, popular IaC tools typically follow two main steps when handling infrastructure changes: change preview and change execution.

[0058] During the change preview phase, the IaC tool compares the user-defined target state (i.e., the target state) with the currently deployed infrastructure state (i.e., the current state) recorded in the orchestration engine stack, generating an execution plan that showcases the expected changes. The execution plan provides the user with a clear view of the upcoming changes to the resources. It details three key operations: CREATE (for adding new resources), UPDATE (for modifying existing resources), and DELETE (for removing resources that are no longer needed). These operations ensure that resource changes are executed precisely according to the plan.

[0059] During the change execution phase, once users confirm that the execution plan meets their expected changes, they will approve and execute the plan, thereby applying the changes to the infrastructure.

[0060] However, when certain attributes or combinations of attributes of existing resources change, the execution plan will only show UPDATE operations. This requires users to have a deep understanding of each attribute of every resource. Taking Huawei Cloud as an example, RFS provides more than 1,000 types of resources, and Kubernetes Deployment resources alone have more than 500 attributes. Therefore, manually reviewing execution plans is quite costly.

[0061] When implementing risk management for resource changes, relying solely on CREATE, DELETE, and UPDATE operations to assess risk is insufficiently granular. For example, in the Kubernetes Deployment resource's replicas field, increasing the number of replicas means expanding the Pod instance count, while decreasing it means shrinking it; these two operations have different risk levels. Clearly, simply identifying UPDATE operations in the execution plan is insufficient to comprehensively assess the risks associated with the change.

[0062] In addition, relying solely on the CREATE, UPDATE, and DELETE operations can take several minutes to complete, during which time the user cannot know the specific progress of the operation. Furthermore, once these operations begin, they cannot be interrupted or allowed to be intervened by the user.

[0063] In view of this, embodiments of this application provide a method for generating an execution plan. After obtaining the first-level execution topology information of the execution plan, the method can use EL to codedly describe the change trend of resource attributes, and parse the EL expression based on the change operations of each different resource to obtain the fine-grained internal operations of the change operations of each different resource. This makes the content of the execution plan richer, improves the transparency of the resource change execution process, and allows users to intuitively grasp the detailed process of resource changes, thereby significantly reducing the risk and cost of manual confirmation of changes.

[0064] In addition, this method can activate monitoring fields and set observability checkpoints before and after specific sub-operations, allowing users to intervene in the change process without breaking the existing declarative final state resource definition, thereby improving the flexibility and controllability of final state orchestration execution.

[0065] Figure 2 is a schematic diagram of an execution plan generation system provided in this application embodiment, illustrating the generation of an execution plan. As shown in Figure 2, the execution plan generation system 200 can be divided into a first generation module 210, a second generation module 220, and a point generation module 230 according to the execution function.

[0066] The first generation module 210 is used to obtain the status information of the infrastructure and, based on the content of the status information of the infrastructure, obtain the target status of the infrastructure.

[0067] For example, when generating the execution plan, the first generation module 210 provides the user with an infrastructure status template, allowing the user to record the expected target status information of the infrastructure in the infrastructure status template. After receiving the infrastructure status template input by the user, the first generation module 210 can parse the infrastructure status template to obtain the user's expected target status of the infrastructure.

[0068] Infrastructure state templates can be IaC templates. IaC templates define the target state of the infrastructure, typically including resource definitions, configuration parameters, dependencies, environment variables, service and application configurations, deployment and version control, monitoring and logging, scaling and resilience, cost and performance optimization, compliance, and security.

[0069] The first generation module 210 is also used to obtain the current state of the infrastructure based on the target state of the infrastructure, and compare the target state of the infrastructure with the current state of the infrastructure to obtain first-level execution topology information.

[0070] For example, after obtaining the target state of the infrastructure, the first generation module 210 can identify the resources that need to be changed from the stack, obtain the current state of the resources that need to be changed, and obtain the state of the resources that need to be changed from the cloud service platform. In the IaC environment, the orchestration engine records the latest state update in the stack after each infrastructure change for subsequent tracking and maintenance. The state of the resource obtained by the first generation module 210 from the stack is actually the state of the resource after the last change. Since the cloud service platform can track the state of running resources, the resource state obtained by the first generation module 210 is the actual state of the resource that needs to be changed.

[0071] An orchestration engine is a software component whose primary responsibility is to manage and coordinate the execution order of multiple services or applications. The core function of this engine is to ensure that tasks are executed correctly according to a predetermined order and dependencies.

[0072] The first generation module 210 compares the target state of the infrastructure with its current state to generate an initial execution plan, which is also the first-level execution topology information of the execution plan. The execution plan details the change operations required to transform the current state into the target state. Change operations can include CREATE, DELETE, and UPDATE operations. A CREATE operation creates a new resource. A DELETE operation removes an old resource. An UPDATE operation modifies an existing resource.

[0073] Therefore, the first-level execution topology information of the execution plan in this application may include at least one change operation for a differential resource. A differential resource refers to a resource in the infrastructure whose target state is different from its current state. Change operations for differential resources include at least one of the operations CREATE, DELETE, and UPDATE.

[0074] The second generation module 220 is used to parse the EL expression based on each operation in the change operation to obtain the secondary execution topology information.

[0075] The core function of EL is expression parsing and evaluation. Expression components can include property value references, built-in functions, operators, etc. Expression parsing and evaluation refers to using EL's capabilities to write complex logical expressions, including logical and arithmetic operators, allowing the expression to dynamically determine whether to perform specific operations based on conditions.

[0076] In EL, attribute value referencing allows you to reference resource attribute values, enabling the orchestration engine to generate more detailed operations based on EL expressions, resulting in a more comprehensive execution plan. Built-in functions include string manipulation, mathematical calculations, date and time processing, and more, which can be used to generate more complex operational logic. The execution plan, through built-in functions, can implement conditional judgments, data transformations, and complex decision-making logic. Operators include mathematical operators (such as addition, subtraction, multiplication, division), logical operators (such as AND &, OR ||), relational operators (such as equal to =, greater than >, less than <), and bitwise operators, allowing for complex calculations in expressions.

[0077] In one embodiment, taking SpEL as an example, attribute value referencing in SpEL refers to injecting it into the function context as a macro variable, using the format "#macro_name.attribute_name". Expression parsing and computation refers to supporting various mathematical operations (addition, subtraction, multiplication, and division) and logical operations (AND, OR, and NOT). Built-in functions refer to defining a series of system-default pre-configured general functions that encapsulate complex calculations or operations, improving the orchestration engine's support for comparing complex resource attributes. Built-in functions are referenced using the format "#function_name(...)".

[0078] For example, the second generation module 220 can extract change operations for differential resources from the first-level execution topology information of the execution plan, identifying the operation type to be performed for each resource, including CREATE, DELETE, or UPDATE. Based on these operation types, the second generation module 220 can match the corresponding operation context from the pre-stored EL context. For example, for a CREATE operation, it will look up createContext; for an UPDATE operation, it will look up updateContext; and for a DELETE operation, it will look up deleteContext.

[0079] The context of EL refers to the scope of data that can be accessed and manipulated within an EL expression. In Java Web applications, EL provides a mechanism to access properties in different scopes, including PageScope, RequestScope, SessionScope, and ApplicationScope. EL's context allows developers to declaratively access variables in these scopes within Java server pages (JSPs) without writing Java code.

[0080] After finding the corresponding operation context, the second generation module 220 can parse and calculate each EL expression defined in the operation context. The second generation module 220 will evaluate the expressions defined in the operation context according to the changes in resource attributes. Since the software version or configuration of the target state and the current state are inconsistent, the EL expressions generally contain comparisons of changes in old and new attributes, such as "#OLD.version!=#NEW.version||#OLD.config!=#NEW.config".

[0081] Based on the calculation results of EL, the second generation module 220 obtains the sub-operations of the change operation for the differing resources. For example, when the calculation result of EL is true, the second generation module 220 will include the sub-operation associated with the expression in the secondary execution topology; when the calculation result of EL is false, the second generation module 220 will ignore the sub-operation associated with the expression, that is, the sub-operation will not be a step in the secondary execution topology. In this way, the second generation module 220 can generate fine-grained internal operations for each resource. This not only improves the visibility of the execution process, but also allows for manual intervention such as pausing and resuming, thereby enhancing the flexibility and control of change management.

[0082] If an operation includes one or more sub-operations, the second generation module 220 performs topological sorting on these sub-operations based on the preorder and successor relationships declared in the operation's associated flow orchestration topology definition. This process ensures that the sub-operations are executed in the correct order during resource change operations. The flow orchestration topology includes setting the operation order, defining decision points (e.g., if-else structures), and arranging loop structures (e.g., for or while), all of which are key elements controlling the program execution flow. In short, the second generation module 220 organizes and arranges the execution order of sub-operations matched according to EL expressions through flow orchestration topology, thereby ensuring that change operations can be performed in an orderly manner.

[0083] Optionally, as shown in Figure 3, when the second generation module 220 processes the CREATE operation in a change operation where the resource is a bucket, it can match a sub-operation based on an EL expression. This sub-operation is specifically used to create a bucket in the object storage service (OBS). That is, the function of this sub-operation is to implement the task of "create OBS Bucket".

[0084] When the second generation module 220 processes the UPDATE operation in the change operations of an application (APP), it can match two sub-operations based on EL expressions. First, the second generation module 220 can obtain a sub-operation called "upgrade software," which aims to update the application's software version to the latest version. Second, the second generation module 220 can obtain a sub-operation called "expand instance," which aims to increase the number of instances to improve processing capacity or achieve load balancing.

[0085] When the second generation module 220 processes an UPDATE operation within a change operation for a relational database service (RDS) resource, it can match three sub-operations based on EL expressions. First, the second generation module 220 can obtain a sub-operation called "change RDS flavor," used to adjust the RDS instance configuration, such as CPU and memory, according to performance requirements. Second, the second generation module 220 can obtain a sub-operation called "expand RDS disk," aimed at increasing the storage capacity of the RDS instance. Finally, the second generation module 220 can obtain a sub-operation called "upgrade RDS kernel," which aims to update the RDS instance's database kernel to the latest version.

[0086] Therefore, the secondary execution topology information of the execution plan in this application may include at least one sub-operation corresponding to at least one change operation of a differential resource. A sub-operation refers to a fine-grained operation within the change operation of the differential resource.

[0087] In this embodiment, the second generation module 220 introduces a two-level execution topology generation method and process based on EL-based final state orchestration execution plans, which can significantly improve the transparency of the execution process. This method enables cloud tenants to quickly and accurately preview the details of resource changes without needing to deeply understand resource attributes and their change risk levels. This refined execution topology allows users to intuitively grasp resource changes, thereby greatly reducing the risks and costs associated with manual confirmation of changes.

[0088] The second generation module 220 utilizes fine-grained execution topology to more accurately review execution plans, ensuring that changes are both expected and do not introduce risks, thereby simplifying the complexity of risk management.

[0089] The point generation module 230 is used to set observable checkpoints before and after sub-operations in the secondary execution topology information to obtain the execution plan.

[0090] Observable checkpoints refer to the points where execution of the next sub-operation is paused, typically expressed through monitoring fields. The monitoring field can be `pauseAfterExecution`, which indicates automatic pause after the sub-operation completes. Alternatively, it can be `pauseBeforeExecution`, which indicates automatic pause before the sub-operation begins. Other types of fields can also be monitored.

[0091] For example, before setting observability checkpoints, the point generation module 230 selects at least one specific sub-operation from multiple sub-operations in the secondary execution topology information that meets the preset filtering rules. The point generation module 230 can find the monitoring field in the specific sub-operation and activate that monitoring field, thereby setting observability checkpoints before and after the specific sub-operation. This method does not affect existing operations and sub-operation flows, nor does it increase additional workload. When the orchestration process runs according to the execution plan to the observability checkpoint set by the monitoring field, the system automatically pauses the execution flow so that the user can check whether the change has caused any unexpected anomalies and decide whether to continue executing subsequent operations.

[0092] In a preferred embodiment, when the orchestration process reaches the observable checkpoint set in the monitoring field according to the execution plan, the point generation module 230 can display a status interface showing the current status of the infrastructure. Users can directly understand from the status interface whether any abnormalities have occurred in the resources after the sub-operation was executed, without having to actively search for them, thus improving the convenience of inspection.

[0093] Optionally, the point generation module 230 can receive user input commands and, based on these commands, locate the monitoring field in at least one specific sub-operation, and activate and / or deactivate that monitoring field. The point generation module 230 can set the location and number of observable checkpoints according to user needs, thereby improving monitoring flexibility.

[0094] In one embodiment, as shown in Figure 3, the point generation module 230 can set an observability checkpoint between the "expand RDS disk" sub-operation and the "upgrade RDS kernel" sub-operation. That is, the point generation module 230 can activate the `pauseAfterExecution` field of the "expand RDS disk" sub-operation or the `pauseBeforeExecution` field of the "upgrade RDS kernel" sub-operation. After the orchestration engine completes the "expand RDS disk" sub-operation, the process reaches the observability checkpoint set in the monitoring field, and the system automatically pauses the execution flow. At this time, the user can observe whether there are any abnormalities in the actual running status of the RDS to decide whether to continue executing the process.

[0095] In this embodiment, the point generation module 230 sets observability checkpoints before and after sub-operations in the secondary execution topology information, enabling users to intervene in the change process without disrupting the existing declarative final state resource definition, thereby improving the flexibility and controllability of final state orchestration execution.

[0096] After receiving the execution plan, the orchestration engine can modify the state of the infrastructure through the cloud service platform. When making changes, the orchestration engine interacts with the cloud service platform through the application program interface (API), instructing the cloud service platform to execute various sub-operations to change the state of the infrastructure to the target state.

[0097] In this embodiment of the application, after the execution plan generation system 200 generates the execution plan, it can detect whether each sub-operation in the execution plan matches the risk level and operation type recorded in the change request form, and determine whether to execute the execution plan or modify the status template based on the matching result.

[0098] For example, the execution plan generation system 200 can integrate the operational risk strategy from the change request form into the system, ensuring that each sub-operation conforms to the established risk management framework. Then, the execution plan generation system 200 can analyze the sequence of operations triggered by the change to identify the potential risks of each sub-operation. Next, the execution plan generation system 200 matches each sub-operation with the corresponding risk strategy definition in the change request form to determine the risk level of each sub-operation. Then, based on the matching results of the operation sequence and risk strategy, the execution plan generation system 200 performs a comprehensive risk assessment of the overall change operation. Finally, the execution plan generation system 200 compares the comprehensive risk assessment of the execution plan with the change operation planned in the standard operating procedure (SOP) of the change to check for consistency.

[0099] If the test results show that the overall rating of the execution plan is consistent with the change operation in the SOP plan, it indicates that the change operation is within the expected risk range, the risk assessment is passed, and the change is allowed to proceed. If they are inconsistent, it indicates that the user has triggered an unexpected operation, the risk exceeds the established SOP plan, the risk assessment fails, and the change will be blocked. Through this process, the execution plan generation system 200 can ensure that the execution plan is carried out within a controllable risk range, thereby reducing potential risks in operation and maintenance, and improving overall operation and maintenance security and reliability.

[0100] The implementation process of the technical solution protected by this application will be described below through an embodiment.

[0101] Assume that the execution plan generation system 200 compares the target state and current state of virtualized microservice resources to generate an execution plan that includes a secondary execution topology. The resources of the infrastructure orchestrated by the execution plan generation system 200 are as follows:

[0102] Resource type: huaweicloud_microservice

[0103] Resource attributes: as shown in the table below.

[0104] The target state (i.e., the objective state) of the infrastructure in the IaC template is:

[0105] The orchestration engine records the current state of the infrastructure (i.e., the current state) as follows:

[0106] The expression description for the EL expression used by the execution plan generation system 200 to generate the secondary execution topology of the execution plan:

[0107] It should be understood that the functional modules and devices involved in the aforementioned execution plan generation system 200 can all be implemented through software or hardware, depending on the actual situation, and are not limited here. Furthermore, the functional modules and devices involved in the aforementioned execution plan generation system 200 can be arranged individually or integrated, and are not limited here.

[0108] The above is a description of the execution plan generation system 200 provided in this application embodiment. It is understood that the execution plan generation system 200 can be configured on a cloud computing platform, for example, deployed on at least one virtual machine or container instance, so that the cloud computing platform can provide execution plan generation services. Of course, the execution plan generation system 200 can also be configured on nodes other than the cloud computing platform, for example, deployed in at least one data center or on at least one server, depending on the actual situation, and is not limited here. The cloud computing platform can provide pages related to public cloud services for users to remotely access public cloud services. In this embodiment, users can pre-purchase the execution plan generation services provided by the execution plan generation system 200 on the cloud computing platform. For ease of understanding, the interaction between the user and the cloud computing platform is described below.

[0109] As shown in Figure 4(a), the interaction between the user and the cloud computing platform mainly includes: the user logs into the cloud computing platform 400 through a web page on the client side, selects and purchases cloud services (i.e., execution plan generation services) related to the execution plan generation system 200 within the cloud computing platform 400, and after purchase, the user can generate the execution plan generation system 200 on the cloud computing platform 400 based on the functions provided by the execution plan generation service. The cloud computing platform 400 is primarily used to manage the infrastructure for running the execution plan generation service. For example, the infrastructure for the execution plan generation service may include multiple data centers located in different regions, each data center including multiple servers. Data centers can provide basic resources for the execution plan generation service, such as computing resources and storage resources. Therefore, when purchasing and using the execution plan generation service, the user mainly pays for the resources used. When using the execution plan generation service, the user can input their requirements for the execution plan generation service through the configuration interface, application program interface (API), or user interaction interface provided by the cloud computing platform 400. The cloud computing platform 400 can then generate an execution plan generation service that matches the user's (or other software / hardware, etc.) input requirements.

[0110] Alternatively, some modules in the execution plan generation system 200 can be configured on the cloud side and others on the client side, thereby realizing the execution plan generation service through client-cloud collaboration. Furthermore, the execution plan generation system 200 can also be configured entirely on the client side, depending on the actual situation; no specific limitation is made here.

[0111] For example, Figure 4(b) is a schematic diagram of the structure of the resource orchestration system provided in the embodiment of this application. As shown in Figure 4(b), the resource orchestration system may include site reliability engineering (SRE), resource orchestration, plugins, client library, APIs, and cloud infrastructure.

[0112] SRE is a practice that applies software engineering principles to IT infrastructure and operations, aiming to create highly reliable and scalable software systems.

[0113] Cloud infrastructure refers to the hardware and software components required to support the cloud computing model, including servers, storage, networks, virtualization software, services, and management tools. Cloud infrastructure is essentially the infrastructure mentioned above. SREs can provide operations to build cloud infrastructure on cloud service platforms.

[0114] Resource orchestration is a service for managing cloud computing resources. It achieves unified management and automated deployment of a set of cloud resources by defining templates. Resource orchestration, also known as the orchestration engine mentioned above, is responsible for managing resource stacks, displaying execution plans, and orchestrating and scheduling resources.

[0115] The plugin is responsible for maintaining the resource definitions of the infrastructure, as well as the registration and operation of the final state resource provider. The plugin can be built into the EL module and can be responsible for generating secondary execution topology information. Based on this, the plugin and resource orchestration work together via remote procedure calls (RPC) to implement the functions of the aforementioned execution plan generation system 200.

[0116] Client libraries are sets of APIs for specific programming languages ​​that allow developers to implement Robot Operating System (ROS) code, access and interact with core ROS concepts such as nodes, topics, and services. Client libraries support multiple programming languages, enabling developers to write ROS code in the language best suited to their applications. Client libraries call cloud service APIs, interacting with APIs registered with resource providers using the Hypertext Transfer Protocol (HTTP).

[0117] APIs are actually APIs for operating infrastructure. They are generally registered by resource providers to API gateways. The resource orchestration system triggers calls based on the execution plan to perform CRUD (i.e., CREATE, READ, UPDATE, and DELETE) operations on the cloud infrastructure, as well as trigger calls to execute fine-grained sub-operations on the cloud infrastructure.

[0118] The above is an introduction to the execution plan generation system provided in the embodiments of this application. Next, based on the above content, the simulation method provided in the embodiments of this application will be introduced.

[0119] For example, Figure 5 shows a flowchart of an execution plan generation method provided in an embodiment of this application. It can be understood that this execution plan generation method can be executed by the aforementioned execution plan generation system 200, and the specific implementation process is as follows:

[0120] Step S501: Obtain the status information of the infrastructure, and based on the content of the status information of the infrastructure, obtain the target status of the infrastructure.

[0121] Specifically, when generating and executing an execution plan, the execution plan generation system 200 provides the user with an infrastructure status template, allowing the user to record the desired target state of the infrastructure within the template. After receiving the infrastructure status template from the user, the execution plan generation system 200 parses the template to obtain the user's desired target state of the infrastructure. The infrastructure status template can be an IaC template.

[0122] Step S502: Obtain the current state of the infrastructure, and based on the current state and the target state of the infrastructure, obtain the first-level execution topology information.

[0123] Specifically, after the execution plan generation system 200 obtains the target state of the infrastructure, it can identify the resources that need to be changed from the stack, obtain the current state of the resources that need to be changed, and obtain the state of the resources that need to be changed from the cloud service platform. The state of the resources recorded in the stack is actually the state of the resource after the last change. Since the cloud service platform can track the state of running resources, the state in the cloud service platform is the true state of the resources.

[0124] The execution plan generation system 200 compares the target state of the infrastructure with its current state to generate an initial execution plan, which is also known as the first-level execution topology information. The first-level execution topology information may include at least one change operation for a differing resource. A differing resource refers to a resource in the infrastructure whose target state differs from its current state. Change operations for differing resources include at least one of the operations CREATE, DELETE, and UPDATE.

[0125] For example, referring to Figure 6, in the IaC domain, there is a resource of type huaweicloud_microservice and named app. This resource exists in both the target state and the current state, and the version and ips attributes change in both states. Therefore, the first-level operation expected to be performed on this resource in the execution plan is UPDATE. Thus, the execution plan generation system 200 includes the UPDATE operation in the first-level execution topology of the generated execution plan.

[0126] Step S503: Parse the EL expression based on each operation in the change operation to obtain the secondary execution topology information.

[0127] Specifically, the execution plan generation system 200 can extract change operations for differential resources from the first-level execution topology information of the execution plan, identifying the operation type to be performed for each resource, including CREATE, DELETE, or UPDATE. Based on these operation types, the execution plan generation system 200 can match the corresponding operation context from the pre-stored EL context. After finding the corresponding operation context, the execution plan generation system 200 can parse and calculate each EL expression defined in the operation context. The second generation module 220 will evaluate the expressions defined in the operation context according to the changes in resource attributes.

[0128] The execution plan generation system 200 generates sub-operations for the change operations of differing resources based on the calculation results of the EL (Execution Optimization) algorithm. For example, when the EL calculation result is true, the second generation module 220 includes the sub-operations associated with the expression in the secondary execution topology; when the EL calculation result is false, the second generation module 220 ignores the sub-operations associated with the expression, meaning that the sub-operation will not be a step in the secondary execution topology. In this way, the second generation module 220 can generate fine-grained internal operations for each resource. This not only improves the visibility of the execution process but also allows for manual intervention such as pausing and resuming, thereby enhancing the flexibility and control of change management.

[0129] For example, referring to Figure 6, the execution plan generation system 200 obtains the UPDATE operation for the resource from the first-level execution topology information of the execution plan. Following the operationContext.updateContext part of the topology generation rules, it sequentially matches it with operations such as ExpandInstance, OfflineInstance, and UpgradeApplication. The execution plan generation system 200 evaluates the expressions defined in the condition field based on the changes in resource attributes. If these expressions evaluate to true, it indicates that the changes in resource attributes match the corresponding change operations.

[0130] In this application, if an operation includes one or more sub-operations, the execution plan generation system 200 performs topological sorting on these sub-operations based on the preorder and successor relationships declared in the operation's associated flow orchestration topology definition. This process ensures that in resource change operations, each sub-operation can be executed in the correct order. The execution plan generation system 200 organizes and arranges the execution order between sub-operations matched according to EL expressions through flow orchestration topology, thereby ensuring that change operations can be performed in an orderly manner.

[0131] For example, as shown in Figure 6, when the execution plan generation system 200 matches multiple operations, it executes the topoSequences.updateContext part to determine the execution order of the multiple operations based on the predecessor and successor relationship description.

[0132] Observable checkpoints refer to the points where execution of the next sub-operation is paused, typically expressed through monitoring fields. The monitoring field can be `pauseAfterExecution`, which indicates automatic pause after the sub-operation completes. Alternatively, it can be `pauseBeforeExecution`, which indicates automatic pause before the sub-operation begins. Other types of fields can also be monitored.

[0133] In this application, before setting observability checkpoints, the execution plan generation system 200 selects at least one specific sub-operation from multiple sub-operations in the secondary execution topology information that meets the preset filtering rules. The execution plan generation system 200 can find monitoring fields in the specific sub-operation and activate those monitoring fields, thereby setting observability checkpoints before and after the specific sub-operation. This method does not affect existing operations and sub-operation flows, nor does it increase additional workload. When the orchestration process runs according to the execution plan to the observability checkpoint set by the monitoring field, the system automatically pauses the execution flow so that the user can check whether the changes have caused any unexpected anomalies and decide whether to continue executing subsequent operations.

[0134] The execution plan generation system 200 can receive user input instructions and, based on these instructions, locate the monitoring field in at least one specific sub-operation, and activate and / or deactivate that monitoring field. The execution plan generation system 200 can also set the location and number of observable checkpoints according to user needs, thereby improving monitoring flexibility.

[0135] In a preferred embodiment, when the orchestration process reaches the observable checkpoint set in the monitoring field according to the execution plan, the execution plan generation system 200 can display a status interface showing the current status of the infrastructure. Users can directly understand from the status interface whether resource anomalies have occurred after the sub-operation was executed, without the need for active searching, thereby improving the convenience of inspection.

[0136] For example, referring to Figure 6, the execution plan generation system 200 may define a `pauseAfterExecution` or `pauseBeforeExecution` field for each operation in the `operationContext.updateContext` section, indicating that the operation will automatically pause after execution or before execution, serving as a default observable checkpoint in the orchestration process. The execution plan generation system 200 can return an execution topology with a two-tier structure to the user. The user can delete the default observable checkpoint as needed, or add custom observable checkpoints between operations in the second-level execution topology. Specifically, adding an observable checkpoint can be done by setting `pauseAfterExecution:true` to `pauseAfterExecution:false`. Deleting an observable checkpoint can be done by setting `pauseAfterExecution:false` to `pauseAfterExecution:true`.

[0137] In this embodiment, after obtaining the first-level execution topology information of the execution plan, the method can use EL to codedly describe the change trends of resource attributes. Based on the change operations of each differentiated resource, the EL expression is parsed to obtain the fine-grained internal operations of each differentiated resource change operation. This enriches the content of the execution plan, improves the transparency of the resource change execution process, and allows users to intuitively grasp the detailed process of resource changes, thereby significantly reducing the risk and cost of manual confirmation of changes. Furthermore, this method can activate monitoring fields and set observability checkpoints before and after specific sub-operations, enabling users to intervene in the change process without disrupting the existing declarative final state resource definition, thus improving the flexibility and controllability of final state orchestration execution.

[0138] For example, an execution plan generation device is provided in this application embodiment. This device can be divided into a first generation module 210, a second generation module 220, and a point generation module 230 in the execution plan generation system 200 shown in FIG2, based on the execution function. The execution plan generation device can be an application, software code, etc., deployed on a computing device or a cluster of computing devices composed of multiple computing devices for execution. The computing device can be a server, computer, laptop, tablet, smartphone, etc. The execution plan generation device can be deployed on a cloud server. If the execution plan generation device is deployed on a cloud service, the designer can use a local device to call the cloud server to use the execution plan generation device to complete the corresponding task. The specific implementation process of the execution plan generation device is as follows:

[0139] The first generation module 210 is used to obtain the status information of the infrastructure and, based on the content of the status information, obtain the target status of the infrastructure; and to obtain the current status of the infrastructure and, based on the comparison between the current status and the target status, obtain first-level execution topology information; the first-level execution topology information includes at least one change operation for a differential resource, where the differential resource refers to a resource in the infrastructure whose current status and target status are different, and the change operation includes at least one of the operations of creation, update, and deletion; the second generation module 220 is used to parse the expression language EL expression based on each operation in the change operation to obtain second-level execution topology information; the second-level execution topology information includes at least one sub-operation corresponding to at least one change operation for a differential resource.

[0140] In one implementation, the second generation module 220 is specifically used to determine the type of each operation in the change operation; based on the type of operation, match the operation context corresponding to each operation in the change operation; calculate the EL expression in the operation context corresponding to each operation in the change operation to obtain secondary execution topology information; the secondary execution topology information includes at least one sub-operation corresponding to at least one change operation of at least one different resource.

[0141] In one implementation, the first generation module 210 is specifically used to obtain the state of the infrastructure after the last change from the stack, and / or obtain the recorded state of infrastructure operation from the node, to obtain the current state of the infrastructure.

[0142] In one implementation, the second generation module 220 is further configured to arrange at least one sub-operation corresponding to at least one change operation of at least one different resource according to the process orchestration topology; the process orchestration topology is used to define the preorder and successor relationships between sub-operations.

[0143] In one embodiment, the apparatus further includes: a point generation module 230 for selecting at least one specific sub-operation from each operation in at least one differential resource change operation according to a preset filtering rule of the infrastructure; activating a monitoring field of at least one specified sub-operation; and the monitoring field instructing the orchestration engine to pause the execution of the next sub-operation.

[0144] In one implementation, the point generation module 230 is further configured to receive instructions input by the user and, according to the instructions, activate and / or deactivate at least one monitoring field for a specific sub-operation; the monitoring field instructs the orchestration engine to pause execution of the next sub-operation.

[0145] In one implementation, the point generation module 230 is also used to display a status interface after the orchestration engine pauses execution of the next sub-operation; the status interface is used to display the status of the infrastructure when it runs to an observable checkpoint where the monitoring field is activated.

[0146] In one implementation, the point generation module 230 is further configured to detect whether each sub-operation in the secondary execution topology information matches a preset risk level or operation type; if each sub-operation in the secondary execution topology information matches the preset risk level or operation type, the secondary execution topology information is sent to the orchestration engine; if each sub-operation in the secondary execution topology information does not match the preset risk level or operation type, the status template is modified.

[0147] The first generation module 210, the second generation module 220, and the point generation module 230 can all be implemented in software or in hardware. For example, the implementation of the first generation module 210 will be described below. Similarly, the implementation of the second generation module 220 and the point generation module 230 can refer to the implementation of the first generation module 210.

[0148] As an example of a software functional unit, the first generation module 210 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, the first generation module 210 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0149] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0150] As an example of a hardware functional unit, the first generation module 210 may include at least one computing device, such as a server. Alternatively, the first generation module 210 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0151] The multiple computing devices included in the first generation module 210 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the first generation module 210 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the first generation module 210 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0152] It should be noted that, in other embodiments, the first generation module 210 can be used to execute any step in the execution plan generation method, the second generation module 220 can be used to execute any step in the execution plan generation method, and the point generation module 230 can be used to execute any step in the execution plan generation method. The steps implemented by the first generation module 210, the second generation module 220, and the point generation module 230 can be specified as needed. The execution plan generation device can realize all functions by implementing different steps in the execution plan generation method through the first generation module 210, the second generation module 220, and the point generation module 230 respectively.

[0153] Figure 7 is a schematic diagram of a computing device provided in an embodiment of this application. As shown in Figure 7, the computing device 700 includes a bus 710, a processor 720, a memory 730, and a communication interface 740. The processor 720, the memory 730, and the communication interface 740 communicate with each other via the bus 710. The computing device 700 can be a server, computer, laptop, server rack, etc. It should be understood that this application does not limit the number of processors and memories in the computing device 700.

[0154] Bus 710 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 7, but this does not imply that there is only one bus or one type of bus. Bus 710 can include pathways for transmitting information between various components of computing device 700 (e.g., processor 720, memory 730, communication interface 740).

[0155] The processor 720 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0156] The memory 730 may include volatile memory, such as random access memory (RAM). The memory 730 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0157] The memory 730 stores executable program code, which the processor 720 executes to implement the functions of the aforementioned modules, such as the first generation module 210, the second generation module 220, and the point generation module 230, thereby realizing the execution plan generation method. In other words, the memory 730 stores instructions for executing the execution plan generation method.

[0158] Alternatively, the memory 730 stores executable code, which the processor 720 executes to implement the functions of the aforementioned modules, thereby implementing the execution plan generation method. That is, the memory 730 stores instructions for executing the execution plan generation method.

[0159] The communication interface 740 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 700 and other devices or communication networks.

[0160] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0161] As shown in Figure 8, the computing device cluster includes at least one computing device 700. The memory 730 of one or more computing devices 700 in the computing device cluster may store the same instructions for executing the execution plan generation method.

[0162] In some possible implementations, the memory 730 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the execution plan generation method. In other words, a combination of one or more computing devices 700 can jointly execute the instructions for executing the execution plan generation method.

[0163] It should be noted that the memories 730 in different computing devices 700 within the computing device cluster can store different instructions, which are used to execute parts of the functions of the first generation module 210, the second generation module 220, and the point generation module 230. That is, the instructions stored in the memories 730 of different computing devices 700 can implement the functions of one or more of the first generation module 210, the second generation module 220, and the point generation module 230.

[0164] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 9 illustrates one possible implementation. As shown in Figure 9, two computing devices, computing device 700A and computing device 700B, are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 730 in computing device 700A stores instructions for executing some of the functions of the first generation module 210, the second generation module 220, and the point generation module 230. Simultaneously, the memory 730 in computing device 700B stores instructions for executing the functions of another portion of the functions of the first generation module 210, the second generation module 220, and the point generation module 230.

[0165] The connection method between the computing device clusters shown in Figure 9 can be considered as follows: taking into account that the execution plan generation method provided in this application requires a large amount of data storage, it is considered that the functions implemented by another part of the modules in the first generation module 210, the second generation module 220 and the point generation module 230 are handed over to the computing device 700B for execution.

[0166] It should be understood that the functions of computing device 700A shown in Figure 9 can also be performed by multiple computing devices 700. Similarly, the functions of computing device 700B can also be performed by multiple computing devices 700.

[0167] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection method of the computing device cluster described in Figures 7 and 8. The difference is that the memory 730 of one or more computing devices 700 in this computing device cluster can store the same instructions for executing the execution plan generation method.

[0168] In some possible implementations, the memory 730 of one or more computing devices 700 in the computing device cluster may also store partial instructions for executing the execution plan generation method. In other words, a combination of one or more computing devices 700 can jointly execute the instructions for executing the execution plan generation method.

[0169] It should be noted that the memory 730 in different computing devices 700 within the computing device cluster can store different instructions for executing some functions of the computing device 700. That is, the instructions stored in the memory 730 of different computing devices 700 can implement the functions of one or more of the modules described above: the first generation module 210, the second generation module 220, and the point generation module 230.

[0170] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform an execution plan generation method.

[0171] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a computing device to execute an execution plan generation method.

[0172] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for generating an execution plan, characterized in that, The method is applied to a cloud service platform for managing infrastructure, the infrastructure including at least one node, the at least one node storing the state of the infrastructure, and the method comprising: Obtain the status information of the infrastructure, and based on the content of the status information of the infrastructure, obtain the target status of the infrastructure; The current state of the infrastructure is obtained, and the current state of the infrastructure is compared with the target state of the infrastructure to obtain first-level execution topology information; the first-level execution topology information includes at least one change operation for a differential resource, wherein the differential resource refers to a resource in the infrastructure whose current state and target state are different, and the change operation includes at least one of creation, update and deletion operations; Based on each operation in the change operation, the Expression Language (EL) expression is parsed to obtain secondary execution topology information; the secondary execution topology information includes at least one sub-operation corresponding to the change operation of at least one differential resource.

2. The method according to claim 1, characterized in that, The step of parsing the Expression Language (EL) expression based on each operation in the change operation to obtain secondary execution topology information specifically includes: Determine the type of each operation in the change operation; Based on the type of operation, the operation context corresponding to each operation in the change operation is matched; The EL expressions in the operation context corresponding to each operation in the change operation are calculated to obtain the secondary execution topology information; the secondary execution topology information includes at least one sub-operation corresponding to the change operation of at least one differential resource.

3. The method according to claim 1 or 2, characterized in that, Obtaining the current state of the infrastructure specifically includes: The current state of the infrastructure is obtained by retrieving the state of the infrastructure after the last change from the stack and / or retrieving the recorded running state of the infrastructure from the node.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: At least one sub-operation corresponding to the change operation of the at least one different resource is arranged according to the process orchestration topology; the process orchestration topology is used to arrange the operation process in EL.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: According to preset filtering rules, at least one specific sub-operation is selected from each operation in the change operation of the at least one different resource; Activate the monitoring field of the at least one specified sub-operation; the monitoring field instructs the orchestration engine to pause the execution of the next sub-operation.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: The system receives user input instructions and, based on those instructions, activates and / or deactivates at least one monitoring field for a specific sub-operation; the monitoring field instructs the orchestration engine to pause execution of the next sub-operation.

7. The method according to claim 5 or 6, characterized in that, After the orchestration engine pauses execution of the next sub-operation, the method further includes: A status interface is displayed; the status interface is used to display the status of the infrastructure when it reaches the observability checkpoint activated by the monitoring field.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Detect whether each sub-operation in the secondary execution topology information matches the preset risk level or operation type; If each sub-operation in the secondary execution topology information matches the preset risk level or operation type, the secondary execution topology information is sent to the orchestration engine. If the sub-operations in the secondary execution topology information do not match the preset risk level or operation type, modify the status template.

9. An apparatus for generating an execution plan, characterized in that, include: The first generation module is used to obtain the status information of the infrastructure and, based on the content of the status information of the infrastructure, obtain the target status of the infrastructure. as well as The current state of the infrastructure is obtained, and the current state of the infrastructure is compared with the target state of the infrastructure to obtain first-level execution topology information; the first-level execution topology information includes at least one change operation for a differential resource, wherein the differential resource refers to a resource in the infrastructure whose current state and target state are different, and the change operation includes at least one of creation, update and deletion operations; The second generation module is used to parse the Expression Language (EL) expression based on each operation in the change operation to obtain secondary execution topology information; The secondary execution topology information includes at least one sub-operation corresponding to the change operation of the at least one differential resource.

10. The apparatus according to claim 9, characterized in that, The second generation module is specifically used to determine the type of each operation in the change operation; Based on the type of operation, the operation context corresponding to each operation in the change operation is matched; The EL expressions in the operation context corresponding to each operation in the change operation are calculated to obtain the secondary execution topology information; The secondary execution topology information includes at least one sub-operation corresponding to the change operation of the at least one differential resource.

11. The apparatus according to claim 9 or 10, characterized in that, The first generation module is specifically used to obtain the state of the infrastructure after the last change from the stack, and / or obtain the recorded running state of the infrastructure from the node, to obtain the current state of the infrastructure.

12. The apparatus according to any one of claims 9-11, characterized in that, The second generation module is further configured to arrange at least one sub-operation corresponding to the change operation of the at least one differential resource according to the process arrangement topology; the process arrangement topology is used to define the preorder and successor relationships between sub-operations.

13. The apparatus according to any one of claims 9-12, characterized in that, The device further includes: a point generation module, used to select at least one specific sub-operation from each operation in the change operation of the at least one differential resource according to a preset filtering rule; Activate the monitoring field of the at least one specified sub-operation; the monitoring field instructs the orchestration engine to pause the execution of the next sub-operation.

14. The apparatus according to any one of claims 9-13, characterized in that, The point generation module is also used to receive instructions input by the user, and according to the instructions, activate and / or deactivate at least one monitoring field of a specific sub-operation; the monitoring field instructs the orchestration engine to pause the execution of the next sub-operation.

15. The apparatus according to claim 13 or 14, characterized in that, The point generation module, after the orchestration engine pauses execution of the next sub-operation, is also used for... A status interface is displayed; the status interface is used to display the status of the infrastructure when it reaches the observability checkpoint activated by the monitoring field.

16. The apparatus according to any one of claims 9-15, characterized in that, The point generation module is also used to detect whether each sub-operation in the secondary execution topology information matches the preset risk level or operation type. If each sub-operation in the secondary execution topology information matches the preset risk level or operation type, the secondary execution topology information is sent to the orchestration engine. If the sub-operations in the secondary execution topology information do not match the preset risk level or operation type, modify the status template.

17. A computing device cluster, characterized in that, include: At least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-8.

18. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-8.

19. A computer program product containing instructions, characterized in that, The computer program product stores instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method described in any one of claims 1-8.

Images