CN117501240A

CN117501240A - Automated operating system migration in infrastructure systems

Info

Publication number: CN117501240A
Application number: CN202280042448.2A
Authority: CN
Inventors: 周云清; 朱海宇; 郭方鹏; 龚文鑫; 丁望祥; J·B·阿林格尔
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2022-03-10
Filing date: 2022-03-10
Publication date: 2024-02-02
Also published as: WO2023168641A1

Abstract

The present disclosure provides methods and apparatus for automated Operating System (OS) migration in an infrastructure system, and provides an infrastructure system that supports automated OS migration. An OS update event associated with a current OS in the infrastructure system may be monitored. OS information of the updated OS indicated by the OS update event may be obtained. At least one test machine installed with the updated OS may be supplied according to the OS information. At least one validation job may be performed on at least one test machine. It may be determined whether the updated OS is applicable based on a verification result of the at least one verification job.

Description

Automated operating system migration in infrastructure systems

Background

Infrastructure systems, also known as Information Technology (IT) infrastructure systems, are a collection of components required for the operation and management of IT products or services and IT environments. For example, an infrastructure system may include hardware, software, networks, facilities, etc. required to develop, test, deliver, monitor, control, or support IT products or services. There are various types of infrastructure systems, such as a conventional infrastructure system installed locally for use by only a company or private use, a cloud infrastructure system accessible via the internet without being installed locally, and so on. An Operating System (OS) is a core software component in an infrastructure system that can manage system resources, manage hardware components, establish a connection between a software product and physical resources, and so forth.

Disclosure of Invention

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Embodiments of the present disclosure propose a method and apparatus for automated Operating System (OS) migration in an infrastructure system, and propose an infrastructure system supporting automated OS migration. An OS update event associated with a current OS in the infrastructure system may be monitored. OS information of the updated OS indicated by the OS update event may be obtained. At least one test machine installed with the updated OS may be supplied according to the OS information. At least one validation job may be performed on at least one test machine. It may be determined whether the updated OS is applicable based on a verification result of the at least one verification job.

It is noted that one or more of the aspects above include the features specifically pointed out in the following detailed description and the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative of but a few of the various ways in which the principles of various aspects may be employed and the present disclosure is intended to include all such aspects and their equivalents.

Drawings

The disclosed aspects will be described below in conjunction with the drawings, which are provided to illustrate and not limit the disclosed aspects.

Fig. 1 illustrates an exemplary infrastructure system according to an embodiment.

FIG. 2 illustrates an exemplary process of automated OS migration in an infrastructure system, according to an embodiment.

FIG. 3 illustrates an exemplary process of automated OS migration in an infrastructure system, according to an embodiment.

Fig. 4 illustrates an exemplary process of verification work according to an embodiment.

FIG. 5 illustrates a flowchart of an exemplary method for automated OS migration in an infrastructure system, according to an embodiment.

FIG. 6 illustrates an exemplary apparatus for automated OS migration in an infrastructure system, according to an embodiment.

FIG. 7 illustrates an exemplary apparatus for automated OS migration in an infrastructure system, according to an embodiment.

Detailed Description

The present disclosure will now be discussed with reference to several example implementations. It should be understood that the discussion of these implementations is merely intended to enable one skilled in the art to better understand and thus practice embodiments of the present disclosure and is not intended to imply any limitation on the scope of the present disclosure.

Various software products may be run on an infrastructure system. The execution of these software products is supported at least by the OS in the infrastructure system. Often, providers or operators of software products and infrastructure systems are concerned with continuously updating versions of software products in order to improve the performance and user experience of the software products, while little is concerned with updating the OS in the infrastructure system. The OS in the infrastructure system will remain unchanged for a significant period of time even though the OS provider of the OS has released an updated version of the OS. Thus, the current OS in the infrastructure system is not always up-to-date. Even if it is desired to implement an OS migration in an infrastructure system, e.g. update a current OS to a new version, such OS migration typically needs to be performed manually. For example, for a new version of the OS, the software engineer should manually perform the entire OS migration process, which is time consuming and inefficient, because the OS migration process involves many steps and regressions (regressions), and requires the software engineer to spend a great deal of time and effort to manually perform these steps and regressions. Furthermore, the above-described limitations of manual migration of the OS further prevent the provider or operator of the infrastructure system from gaining motivation to update the OS in the infrastructure system.

Embodiments of the present disclosure propose an automatic OS migration mechanism in an infrastructure system. The automatic OS migration mechanism may facilitate automatic, efficient, and easy migration of updated versions of the OS into the infrastructure system at very low time costs, such that the OS in the infrastructure system is always up-to-date. Embodiments of the present disclosure may be implemented to continuously update an OS in an infrastructure system, thereby eliminating the gap between the current OS and the latest version of OS released by an OS provider in the infrastructure system, benefiting from an automatic OS migration mechanism. Timely updating of the OS will improve availability, security, scale, etc. of the infrastructure system, so that these software products running in the infrastructure system can benefit from the timely updated OS, thereby achieving better performance and user experience. The terms "product," "service," "application," and the like are used interchangeably herein, and may refer broadly to various products that employ software and hardware resources in an infrastructure system, etc., running on an OS in the infrastructure system based at least on a software implementation.

In one aspect, embodiments of the present disclosure may automatically monitor in real-time whether an updated version of a current OS in an infrastructure system exists. The presence of an updated OS will trigger a further determination of the suitability of the updated OS, e.g. by at least a verification procedure to determine whether the updated OS is suitable. Herein, the applicability of an updated OS may refer to whether the updated OS can be provisioned in an infrastructure system to well support the operation of a software product in a product environment, which may refer broadly to the actual deployment or working environment of the software product provided by the infrastructure system.

In one aspect, a test machine in which an updated OS is installed may be automatically supplied or provisioned in response to the occurrence of the updated OS. The test machine may further be used to implement a verification process.

In one aspect, a verification process may be performed to determine whether the updated OS is capable of operating stably in a test environment, providing basic functionality correctly, etc., as appropriate for an infrastructure system in a production environment. Herein, a test environment may refer broadly to an environment provided by an infrastructure system that is particularly used to verify an updated OS. In some implementations, the verification process may utilize functional tests associated with software products running in the infrastructure system to determine whether the updated OS is suitable. For example, the validation process may include automatically performing validation work on the test machine, wherein the validation work is associated with the software product. If the verification effort associated with the software product is passed, i.e. the software product can run correctly on the updated OS, this indicates that the updated OS is able to support the running of the software product well and is therefore applicable.

In one aspect, in response to the updated OS being applicable, embodiments of the present disclosure may automatically determine or suggest to provision the updated OS in the infrastructure system.

In one aspect, embodiments of the present disclosure may monitor in real time whether the software product has an updated version, optionally in addition to monitoring for the presence of an updated OS. The presence of the updated software product will trigger a further verification process. In this way, by checking whether the updated software product can run correctly on the updated OS, the applicability of the updated OS can be further determined.

Processing in an automatic OS migration mechanism can be automatically, timely and efficiently performed. Thus, the OS in the infrastructure system can keep up with the latest version of the OS, so the infrastructure system can better support the running of the software product. Furthermore, since the automatic OS migration mechanism can be performed in time, the update frequency of the OS in the infrastructure system can be as high as the update frequency of the OS by the OS provider. For example, in response to each new updated version of the OS published by the OS provider, an automatic OS migration mechanism will be triggered to verify the updated OS. Accordingly, embodiments of the present disclosure may reduce the number of possible problems in the authentication process and reduce the processing complexity of each attempt to update the OS in the infrastructure system, thereby further increasing the pass rate of the authentication process and improving the efficiency of OS migration, as compared to authenticating an updated OS derived from the current OS by several updated versions.

Embodiments of the present disclosure are not limited to any particular type of infrastructure system, but may be applied to various types of infrastructure systems. Furthermore, embodiments of the present disclosure are not limited to any particular software product involved in the verification process, but rather may employ various types of software products in the verification process, e.g., various cloud-based services, etc.

Fig. 1 illustrates an exemplary infrastructure system 100 according to an embodiment. Infrastructure system 100 may implement an automated OS migration mechanism in accordance with embodiments of the present disclosure, such that automated OS migration may be supported.

Infrastructure system 100 may include, for example, an OS update monitor 110, an OS migration manager 120, a machine supply unit 130, a verification unit 140, an optional product update monitor 150, and the like. It should be appreciated that for simplicity, FIG. 1 shows only exemplary components that may be involved in an automated OS migration mechanism in infrastructure system 100, and that infrastructure system 100 may actually include many more other software and hardware components.

The OS update monitor 110 may be configured to automatically monitor in real-time whether an updated version of the current OS in the infrastructure system 100 exists. In one implementation, the OS update monitor 110 may monitor OS update events associated with a current OS in the infrastructure system 100. The OS update event may refer to an updated version of the current OS in the infrastructure system 100, e.g., an updated OS published by an OS provider of the OS. The OS update monitor 110 may monitor OS update events in a variety of ways, such as receiving notifications from an OS provider regarding OS update events, retrieving or retrieving information from the OS provider's website regarding OS update events, and so forth. Embodiments of the present disclosure are not limited to any particular method of monitoring for OS update events. As an example, the OS update monitor 110 may call an API to monitor for OS update events.

In response to the occurrence of the OS update event, the OS update monitor 110 may also obtain OS information of the updated OS indicated by the OS update event. The OS information may include various types of information related to the updated OS, for example, a version number of the updated OS, an OS image of the updated OS, and the like. The OS image may be an installed file that may be used to install the updated OS, e.g., a VHDX file corresponding to the updated OS, etc. The OS information obtained by the OS update monitor 110 may also include any other type of information related to the updated OS.

The OS update monitor 110 may automatically and continuously monitor for OS update events. Thus, once a new updated version of the OS is released, OS update monitor 110 may monitor the OS update event in a timely manner and subsequent processing in the automatic OS migration mechanism will be triggered accordingly.

The OS migration manager 120 is a core management component of the automatic OS migration mechanism, which may be configured to store various types of information related to OS migration (e.g., updated OS information and a verification result of a verification process), thereby indicating a test machine or an operation machine to which the updated OS is installed, and the like. In one implementation, the OS migration manager 120 may receive OS information from the OS update monitor 110 and store the OS information in a database. In response to the received OS information, the OS migration manager 120 may instruct the machine supply unit 130 to supply the test machine with the updated OS installed by transmitting a test machine supply instruction to the machine supply unit 130.

The machine supply unit 130 may be configured to: in response to receiving the test machine supply instruction from the OS migration manager 120, at least one test machine having the updated OS installed is automatically supplied according to the OS information. For example, the test machine supply instruction may include at least OS information, and the machine supply unit 130 may install the updated OS on at least one test machine according to, for example, a version number or an image of the updated OS indicated by the OS information. Herein, the test machine may be a machine provided by the infrastructure system 100 specifically for verifying the updated OS in the test environment. The test machine may be, for example, a physical machine or a virtual machine. In some scenarios, the infrastructure system 100 may pre-designate a set of machines for verifying the updated OS in the test environment, and the at least one test machine supplied by the machine supply unit 130 may be any or all of these machines.

The verification unit 140 may be configured to automatically perform a verification process. In one implementation, the validation process may include automatically performing at least one validation job on at least one test machine, so that the validation unit 140 may perform at least one validation job on at least one test machine. The at least one validation job may be associated with at least one software product running in the infrastructure system 100. For example, each software product may correspond to a verification job. At least one validation job may utilize a functional test associated with the corresponding software product to determine whether the updated OS is applicable. Herein, the validation effort may refer to a series of stages or processes related to the validation of the updated OS. In one implementation, the validation work may include, for example, a product build phase, a test machine configuration phase, a test run phase, and the like.

By performing at least one authentication job, the authentication unit 140 can finally obtain an authentication result of the at least one authentication job. For example, in the case where at least one verification job includes only one verification job, the verification unit 140 may generate a verification result of the verification job based on a result of a product build stage in the verification job, a result of a test machine configuration stage in the verification job, a result of a test run stage in the verification job, and the like. For example, in the case where at least one authentication job includes two or more authentication jobs, the authentication unit 140 may first generate sub-authentication results of each authentication job, and then generate final authentication results of the two or more authentication jobs by combining the sub-authentication results of the authentication jobs.

In one implementation, the types of verification results may include success, failure, and to-be-investigated. In the case where the at least one authentication job includes only one authentication job, the authentication result "success" may mean that all stages in the authentication job are successful, the authentication result "failure" may mean that at least one stage in the authentication job is failed, and the authentication result "to be investigated" may mean that at least one result of at least one stage in the authentication job requires manual investigation. In the case where at least one of the authentication works includes two or more authentication works, the authentication result "success" may refer to a predetermined number or proportion of sub-authentication results of the authentication works as success, the authentication result "failure" may refer to a predetermined number or proportion of sub-authentication results of the authentication works as failure, and the authentication result "to be investigated" may refer to a predetermined number or proportion of sub-authentication results of the authentication works as to be investigated. It should be appreciated that embodiments of the present disclosure are not limited to classifying the verification results into the types of success, failure, and investigation discussed above, but may classify the verification results into more or less types according to any predetermined criteria.

The authentication unit 140 may transmit the generated authentication result of at least one authentication job to the OS migration manager 120. The OS migration manager 120 may be configured to automatically store the verification result, a version number of at least one software product, and the like. The OS migration manager 120 may also be configured to automatically determine whether the updated OS is applicable based on the verification result. For example, if the verification result is successful, it may be determined that the updated OS is applicable. In one implementation, in response to the updated OS being applicable, the OS migration manager 120 may also determine to provision the updated OS in the infrastructure system 100. In this case, the OS migration manager 120 may instruct the machine supply unit 130 to supply the operating machine with the updated OS installed by transmitting an operating machine supply instruction to the machine supply unit 130.

The machine supply unit 130 may be configured to: in response to receiving the running machine provisioning instructions from the OS migration manager 120, at least one running machine installed with the updated OS is automatically provisioned in the infrastructure system 100 for supporting the running of at least one software product. The running machine may be a machine provided by the infrastructure system 100, which is particularly used to support the running of at least one software product in a product environment. The running machine may be, for example, a physical machine or a virtual machine. In some scenarios, infrastructure system 100 may pre-designate a set of machines for supporting the operation of at least one software product in a product environment, and the at least one operating machine supplied by machine supply unit 130 may be any or all of these machines.

Alternatively, in response to the updated OS being applicable, the OS migration manager 120 may suggest that the provider or operator of the at least one software product employ the updated OS in the infrastructure system 100 instead of determining to directly provision the updated OS. In this case, the OS migration manager 120 may transmit a suggestion to the provider or operator of the at least one software product to employ the updated OS, and determine to provision the updated OS only when a confirmation to employ the updated OS is received from the provider or operator of the at least one software product.

Optionally, in some implementations, the infrastructure system 100 may utilize the product update monitor 150 to trigger further verification processes for the updated OS. The product update monitor 150 may be configured to automatically monitor in real-time whether an updated version of the at least one software product exists. In one implementation, the product update monitor 150 may monitor product update events associated with at least one software product. A product update event may refer to the release of an updated version of a software product by a product provider of the software product. The product update monitor 150 may monitor the product update event in a variety of ways, such as receiving a notification from the product provider regarding the product update event, retrieving or retrieving information from the product provider's website regarding the product update event, and so forth. Embodiments of the present disclosure are not limited to any particular manner of monitoring for product update events. As an example, the product update monitor 150 may call an API to monitor for product update events. The product update monitor 150 may automatically and continuously monitor for product update events. Thus, once a new updated version of the software product is released, the product update monitor 150 can monitor the product update event in time and further verification processes will be triggered accordingly.

In response to the occurrence of the product update event, the verification unit 140 may automatically perform a further verification process. In one implementation, the further validation process may include automatically performing at least one further validation job on the at least one test machine, so that validation unit 140 may perform the at least one further validation job on the at least one test machine. The at least one further verification job may be associated with at least one updated software product indicated by the product update event.

By performing the at least one further authentication job, the authentication unit 140 can finally obtain an authentication result of the at least one further authentication job. The authentication unit 140 may transmit the authentication result of the at least one further authentication job to the OS migration manager 120. The OS migration manager 120 may automatically store the verification result, the updated version number of the at least one software product, etc. The OS migration manager 120 may also automatically determine whether the updated OS is applicable based at least on the verification result. In response to the updated OS being determined to be applicable, the OS migration manager 120 may also determine to provision the updated OS in the infrastructure system 100, for example, instruct the machine provision unit 130 to provision the running machine in which the updated OS is installed. Alternatively, the OS migration manager 120 may also suggest that at least one provider or operator of the updated software product employ the updated OS in the infrastructure system 100.

It should be appreciated that components in the infrastructure system 100, such as the OS update monitor 110, the OS migration manager 120, the machine supply unit 130, the verification unit 140, the product update monitor 150, etc., may be implemented in various ways, for example, via software, hardware, or a combination thereof. For example, in a software implementation, all or a portion of these components may be implemented via software, and thus may be software modules implemented by computer program code or the like. For example, in a hardware implementation, all or a portion of these components may be implemented via hardware, and thus may be hardware modules with processing capabilities, e.g., processors, application-specific chips, etc. Embodiments of the present disclosure are not limited to any particular implementation of the components shown in fig. 1.

FIG. 2 illustrates an exemplary process 200 for automated OS migration in an infrastructure system, according to an embodiment. Process 200 may be performed for implementing the automated OS migration mechanism proposed by embodiments of the present disclosure. The operations or steps in process 200 may be performed by corresponding components, such as those shown in fig. 1.

At 210, an OS update event associated with a current OS in the infrastructure system may be monitored. The OS update event may indicate that an OS provider of the OS has released an updated version of the OS in the infrastructure system, e.g., an updated OS. In one implementation, the monitoring operation at 210 may be performed by the OS update monitor 110 in FIG. 1.

At 220, OS information of the updated OS indicated by the OS update event may be obtained. The OS information may include at least an OS image of the updated OS, a version number of the updated OS, and the like. In one implementation, the obtaining operation at 220 may be performed by the OS update monitor 110 in FIG. 1.

At 230, at least one test machine with the updated OS installed may be supplied according to the OS information. For example, the updated OS may be installed on at least one test machine according to the OS information, and thus the at least one test machine may be further supplied for performing the verification process. In one implementation, the feeding operation at 230 may be performed by the machine feeding unit 130 of fig. 1. For example, the machine supply unit 130 may install the updated OS on at least one test machine according to the OS information obtained at 120 and supply the test machine installed with the updated OS for further operation. In a further implementation, the OS migration manager 120 of fig. 1 may receive OS information from the OS update monitor 110 and instruct the machine supply unit 130 to supply at least one test machine installed with the updated OS according to the OS information.

At 240, at least one validation job may be performed on the at least one test machine. The at least one validation job may be associated with at least one software product running in the infrastructure system. In one implementation, the execution operation at 240 may be performed by the verification unit 140 in FIG. 1.

At 250, a validation result of at least one validation process may be generated. In one implementation, the generating operation at 250 may be performed by the verification unit 140 in FIG. 1.

According to embodiments of the present disclosure, a validation job may be defined for each corresponding software product, and the validation job may include several stages. Fig. 4 illustrates an exemplary process of a validation job 400 according to an embodiment. It is assumed that validation job 400 is defined for a target software product 402 running in the infrastructure system. As shown in FIG. 4, validation work 400 may include, for example, a product build phase 410, a test machine configuration phase 420, a test run phase 430, and the like.

At product build stage 410, product build may be performed for software product 402. Product build stage 410 may employ any technique for software build. In one implementation, product construction may include compiling at least source code files of software product 402 into executable files. It should be appreciated that where the software product 402 contains multiple source code files, the above-described compilation operations may also generally refer to compiling the multiple source code files into multiple corresponding executable files, respectively. Further, it should be understood that embodiments of the present disclosure are not limited to any particular software build technique, and that product build may also include any other operations in addition to compilation operations.

By executing the product build stage 410, the results 412 of the product build stage 410 may be obtained. For example, the results 412 may be success, failure, or to be surveyed, where "success" indicates that the product build was successful and there was no build time problem, "failure" indicates that the product build failed due to a possible build time problem, and "to be surveyed" indicates that the product build failed due to some unidentified problem or a strange (flag) build problem requiring manual survey. It should be appreciated that embodiments of the present disclosure are not limited to classifying the results 412 as success, failure, and type to be investigated as described above, but rather the results 412 may be classified as more or less types according to any predetermined criteria.

At test machine configuration stage 420, at least one test machine may be configured according to the corresponding software installation configuration template 404. At least one test machine has installed an updated OS. The software installation configuration template 404 is predefined for instantiating the software product 402, the software context of the software product 402, etc. on the test machine. The software context may include, for example, various tools, scripts, tasks, configurations, etc., upon which the software product 402 depends. Thus, the software installation configuration template 404 may define what the configured test machine should be. It should be appreciated that the software installation configuration template 404 may be defined by various methods (e.g., by using XML). Furthermore, in the case where there are two or more test machines, each test machine may be applied by a corresponding software installation configuration template, and the software installation configuration templates for these test machines may be the same or may be different by specifying, for example, different software contexts, or the like.

In one implementation, a software installation configuration template defined for a test machine may implement various functions. For example, the software installation configuration template may copy the executable file of the software product 402 obtained at the product build stage 410 to the test machine. For example, the software installation configuration template may install the software context of the software product 402 in the test machine. For example, the software installation configuration template may install a base tool of a functional test in the test machine, where the functional test is to be run at test run stage 430, and the base tool refers to any tool required for the functional test. In addition, the software installation configuration template may also implement any other functionality.

By executing the test machine configuration stage 420, the results 422 of the test machine configuration stage 420 may be obtained. For example, the results 422 may be success, failure, or to be investigated, where "success" indicates that the configuration of the test machine was successful, "failure" indicates that the configuration of the test machine was failed due to some identified problem (e.g., lack of files to install, failed to initiate required services, etc.), and "to be investigated" indicates that the configuration of the test machine was failed due to some unidentified problem requiring manual investigation. It should be appreciated that embodiments of the present disclosure are not limited to classifying the results 422 into the types of success, failure, and investigation discussed above, but rather, the results 422 may be classified into more or less types according to any predetermined criteria.

In the test run phase 430, functional tests associated with the software product 402 may be run on at least one test machine. Functional testing may refer to various tests for checking whether the function of the software product 402 or any portion or aspect of the software product 402 is normal. For example, the functional test may include checking whether the software product 402 is installed well, whether certain functions of the software product 402 may be invoked, whether communication between components of the software product 402 is normal, and so on. Embodiments of the present disclosure are not limited to any particular functional testing.

By executing the test run phase 430, the results 432 of the test run phase 430 can be obtained. As an example, the result 432 may be success, failure, or to be investigated, where "success" indicates that a predetermined number or proportion of functional tests pass, "failure" indicates that a predetermined number or proportion of functional tests fail, and "to be investigated" indicates that the cause of the functional test failure requires manual investigation. It should be appreciated that embodiments of the present disclosure are not limited to classifying results 432 into the types of success, failure, and investigation discussed above, but rather results 432 may be classified into more or less types according to any predetermined criteria.

In one implementation, the validation results 440 of the validation job 400 may be generated based on the results 412 of the product build phase 410, the results 422 of the test machine configuration phase 420, and the results 432 of the test run phase 430. For example, if all of the results 412, 422, and 432 were successful, the verification result 440 would be successful; if at least one of the results 412, 422, and 432 is failed, the verification result 440 will be failed; if at least one of the results 412, 422, and 432 is to be investigated, the verification result 440 will be to be investigated. It should be appreciated that embodiments of the present disclosure are not limited to generating verification result 440 by combining results 412, 422, and 432 in the manner described above, but that results 412, 422, and 432 may be utilized in any other manner to generate verification result 440.

It should be appreciated that if the at least one validation job performed at 240 in FIG. 2 includes two or more validation jobs corresponding to two or more software products running in the infrastructure system, FIG. 4 only shows an exemplary validation job 400 corresponding to software product 402, each of which may be performed in a manner similar to that shown in FIG. 4 and the corresponding sub-validation results of each of which may be obtained accordingly. In this case, these sub-verification results may be combined to produce a final verification result at 250 in FIG. 2. For example, if a predetermined number or proportion of sub-verification results are of a particular type, the final verification results will be of the same type.

Returning to process 200 in fig. 2, at 260, information related to the steps or operations in process 200 may be stored, for example, in at least one database in an infrastructure system. For example, the OS information obtained at 220, the verification results generated at 250, etc. may be stored at 260. In one implementation, the store operation at 260 may be performed by the OS migration manager 120 in FIG. 1.

At 270, it may be determined whether the updated OS is suitable based on the validation results of the at least one validation job. For example, if the verification result is successful, it may be determined that the updated OS is applicable. It should be appreciated that, although at least one validation job is performed with respect to at least one software product, the validation results of the at least one validation job may indicate whether the updated OS itself has satisfactory performance, because the functional test failures involved in the at least one validation job may be due to defects of the updated OS, e.g., code errors in the updated OS may result in memory access conflicts during the running of the software product, changes in underlying APIs in the updated OS may result in the current software context not supporting some functionality, and so on. In one implementation, the determining operation at 270 may be performed by the OS migration manager 120 in FIG. 1.

In response to determining that the updated OS is applicable at 270, provision of the updated OS in the infrastructure system may be determined at 280. In one implementation, the determination at 280 may be performed by the OS migration manager 120 in FIG. 1.

Although not shown, in response to determining to provision the updated OS, process 200 may further include provisioning the updated OS by provisioning at least one running machine installed with the updated OS in the infrastructure system, wherein the at least one running machine may support the running of at least one software product in the product environment. In one implementation, the above-described feeding operations may be performed by the machine feeding unit 130 of fig. 1.

In response to determining at 270 that the updated OS is not applicable, process 200 may end at 290.

It should be understood that all of the operations in process 200 and their sequence order are exemplary and that these operations may be changed in any manner and that more or fewer steps may be included in process 200 depending on the actual application requirements and design. For example, the storage operations at 260 are optional, or they may be performed in any other order or location in process 200. For example, while the store operation at 260 is shown as a single step, it may be divided into several sub-operations for separately storing different information. For example, prior to the determining operation at 280, in response to determining that the updated OS is applicable at 270, the OS migration manager 120 may send a suggestion to the provider or operator of the at least one software product to employ the updated OS, and only perform the determining operation at 280 when a confirmation to employ the updated OS is received from the provider or operator of the at least one software product. Further, all operations in process 200 may be performed automatically, so process 200 may implement OS migration in an automatic manner.

FIG. 3 illustrates an exemplary process 300 for automated OS migration in an infrastructure system, according to an embodiment. Process 300 is a modification or variation of process 200 in fig. 2. The same reference numerals in fig. 3 and 2 may refer to the same or similar operations.

Initially, after operations 210, 220, and 230 have been performed, operations 340, 350, and 360 may be performed in a similar manner to operations 240, 250, and 260 in fig. 2. However, prior to performing operation 270, process 300 may include: a further verification process is performed in response to the update of the at least one software product.

At 370, a product update event associated with the at least one software product may be monitored. In one implementation, the monitoring operation at 370 may be performed by the product update monitor 150 of FIG. 1.

In response to the occurrence of a product update event, a further verification process may be performed. For example, at 340, at least one further validation job may be performed on at least one test machine. The at least one further verification job may be associated with at least one updated software product indicated by the product update event. The at least one further validation effort may be performed in a similar way as the at least one validation effort except that all phases of the at least one further validation effort are performed in relation to the updated software product. For example, in at least one further validation effort, the product build phase may perform product build by compiling at least a source code file of the at least one updated software product into an executable file, the test machine configuration phase may configure the at least one test machine according to a corresponding software installation configuration template defined for the at least one updated software product, and the test run phase may run a functional test associated with the at least one updated software product. In one implementation, the performing operation at 340 may be performed by the verification unit 140 in FIG. 1.

At 350, a validation result of at least one further validation process may be generated. In one implementation, the generating operation at 350 may be performed by the verification unit 140 in FIG. 1.

At 360, the verification result of the at least one further verification process and the version number of the at least one updated software product may also be stored. In one implementation, the store operation at 360 may be performed by the OS migration manager 120 in FIG. 1.

At 270, it may be determined whether the updated OS is suitable based on the validation results of the at least one further validation job. Alternatively, the determining operation at 270 may be based on both the validation results of the at least one further validation job and the validation results of at least one previous validation job. For example, if both verification results are successful, it may be determined that the updated OS is applicable. In one implementation, the determining operation at 270 may be performed by the OS migration manager 120 in FIG. 1.

It should be appreciated that the further verification process described above may be performed iteratively by continuously performing the monitoring operation at 370, thus triggering a new further verification process once a new updated version of the at least one software product is released. In this way, the suitability of the updated OS may be determined taking into account both the at least one original software product and the updated version of the at least one software product.

It should be understood that all of the operations in process 300 and their sequence order are exemplary and that these operations may be changed in any manner and that more or fewer steps may be included in process 300 depending on the actual application requirements and design.

Further, although not shown, process 200 in fig. 2 or process 300 in fig. 3 may optionally include operations to perform verification result analysis. The verification result analysis may include various types of analysis of verification results, such as summarizing and classifying the cause of failure of the functional test, and the like. The information of the verification result analysis may be further transmitted to the provider of the OS so that the provider of the OS may further optimize or update the OS accordingly.

FIG. 5 illustrates a flowchart of an exemplary method 500 for automated OS migration in an infrastructure system, according to an embodiment.

At 510, an OS update event associated with a current OS in the infrastructure system may be monitored.

At 520, OS information of the updated OS indicated by the OS update event may be obtained.

At 530, at least one test machine with the updated OS installed may be supplied according to the OS information.

At 540, at least one validation job may be performed on the at least one test machine. The at least one validation job may be associated with at least one software product running in the infrastructure system.

At 550, it may be determined whether the updated OS is suitable based on the validation results of the at least one validation job.

In one implementation, the method 500 may further include: in response to the updated OS being applicable, it is determined to provision the updated OS in the infrastructure system.

The method 500 may further include: at least one running machine with an updated OS installed is supplied in the infrastructure system for supporting the running of at least one software product.

In one implementation, the at least one validation job may include: a product build phase for performing product build by compiling at least a source code file of at least one software product into an executable file; a test machine configuration stage for configuring at least one test machine according to a corresponding software installation configuration template; and a test run phase for running a functional test associated with the at least one software product on the at least one test machine.

The software installation configuration template may be used for at least one of: copying the executable file to at least one test machine; installing a software context of at least one software product in at least one test machine; and installing a base tool for functional testing in at least one test machine.

The method 500 may further include: the validation results are generated based on the results of the product build phase, the results of the test machine configuration phase, and the results of the test run phase.

In one implementation, the method 500 may further include: monitoring for a product update event associated with at least one software product; and performing at least one further validation job on the at least one test machine, the at least one further validation job being associated with the at least one updated software product indicated by the product update event.

In one implementation, the OS information may include at least an OS image of the updated OS and a version number of the updated OS.

In one implementation, the validation result may include one of the following: success, failure, and to be investigated.

In one implementation, the method 500 may further include: storing at least one of: OS information, verification results, and version number of at least one software product.

Furthermore, method 500 may also include any steps/operations for automated OS migration in an infrastructure system according to the above-described embodiments of the present disclosure.

FIG. 6 illustrates an exemplary apparatus 600 for automated OS migration in an infrastructure system, according to an embodiment.

The apparatus 600 may include: an OS update event monitoring module 610 for monitoring OS update events associated with a current OS in the infrastructure system; an OS information obtaining module 620 for obtaining OS information of the updated OS indicated by the OS update event; a test machine supply module 630 for supplying at least one test machine installed with the updated OS according to the OS information; a validation job execution module 640 for executing at least one validation job on at least one test machine, the at least one validation job associated with at least one software product running in the infrastructure system; and an OS applicability determination module 650 for determining whether the updated OS is applicable based on a verification result of the at least one verification job.

In addition, apparatus 600 may also include any other modules configured for automated OS migration in an infrastructure system according to the above-described embodiments of the present disclosure.

FIG. 7 illustrates an exemplary apparatus 700 for automated OS migration in an infrastructure system, according to an embodiment.

The apparatus 700 may include at least one processor 710. The apparatus 700 may further include a memory 720 coupled to the at least one processor 710. Memory 720 may store computer-executable instructions that, when executed, cause at least one processor 710 to: monitoring for an OS update event associated with a current OS in the infrastructure system; acquiring OS information of the updated OS indicated by the OS update event; supplying at least one test machine installed with the updated OS according to the OS information; performing at least one validation job on at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system; and determining whether the updated OS is applicable based on a verification result of the at least one verification job.

Further, the at least one processor 710 may also be configured to perform any operations of the method for automated OS migration in an infrastructure system according to the above-described embodiments of the present disclosure.

Embodiments of the present disclosure propose an infrastructure system supporting automated OS migration. The infrastructure system may include: an OS update monitor configured to: monitoring an OS update event associated with a current OS in the infrastructure system, and obtaining OS information of an updated OS indicated by the OS update event; a machine supply unit configured to: supplying at least one test machine installed with the updated OS according to the OS information; an authentication unit configured to: performing at least one validation job on at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system; and an OS migration manager configured to: it is determined whether the updated OS is applicable based on a verification result of the at least one verification job.

In one implementation, the OS migration manager may be further configured to: in response to the updated OS being applicable, it is determined to provision the updated OS in the infrastructure system.

The machine supply unit may be further configured to: at least one running machine with an updated OS installed is supplied in the infrastructure system for supporting the running of at least one software product.

The verification unit may be further configured to: the validation results are generated based on the results of the product build phase, the results of the test machine configuration phase, and the results of the test run phase.

In one implementation, the infrastructure system may further comprise: a product update monitor configured to monitor product update events associated with at least one software product. The verification unit may be further configured to: at least one further validation job is performed on the at least one test machine, the at least one further validation job being associated with the at least one updated software product indicated by the product update event.

In one implementation, the OS migration manager may be further configured to: storing at least one of: OS information, verification results, and version number of at least one software product.

Furthermore, the infrastructure system may also include any other units or components for supporting automated OS migration according to the above-described embodiments of the present disclosure, and these units may be configured to perform any operations of the method for automated OS migration according to the above-described embodiments of the present disclosure.

Embodiments of the present disclosure propose a computer program product for automatic OS migration in an infrastructure system. The computer program product may comprise a computer program for, when executed by at least one processor: monitoring for an OS update event associated with a current OS in the infrastructure system; acquiring OS information of the updated OS indicated by the OS update event; supplying at least one test machine installed with the updated OS according to the OS information; performing at least one validation job on at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system; and determining whether the updated OS is applicable based on a verification result of the at least one verification job. Furthermore, the computer program may also be executable by at least one processor to perform any other operations of a method for automated OS migration in an infrastructure system according to embodiments of the present disclosure described above.

Embodiments of the present disclosure may be embodied in a non-transitory computer readable medium. The non-transitory computer-readable medium may include instructions that, when executed, cause the one or more processors to perform any steps/operations of a method for automated OS migration in an infrastructure system in accordance with the above-described embodiments of the present disclosure.

It should be understood that all operations in the methods described above are merely exemplary, and the present disclosure is not limited to any operations in the methods or to the sequence order of these operations, but rather should cover all other equivalents under the same or similar concepts.

Furthermore, the articles "a" and "an" as used in this specification and the appended claims should generally be construed to mean "one" or "one or more" unless specified otherwise or clear from context to be directed to a singular form.

It should also be understood that all of the modules in the apparatus described above may be implemented in various ways. These modules may be implemented as hardware, software, or a combination thereof. Furthermore, any of these modules may be functionally further divided into sub-modules or combined together.

The processor has been described in connection with various apparatuses and methods. These processors may be implemented using electronic hardware, computer software, or any combination thereof. Whether such processors are implemented as hardware or software will depend upon the particular application and the overall design constraints imposed on the system. By way of example, a processor, any portion of a processor, or any combination of processors presented in this disclosure may be implemented with a microprocessor, microcontroller, digital Signal Processor (DSP), field Programmable Gate Array (FPGA), programmable Logic Device (PLD), state machine, gating logic, discrete hardware circuits, and other suitable processing components configured to perform the various functions described throughout this disclosure. The functions of the processors, any portion of the processors, or any combination of processors presented in this disclosure may be implemented with software executed by a microprocessor, microcontroller, DSP, or other suitable platform.

Software should be construed broadly to mean instructions, instruction sets, code segments, program code, programs, subroutines, software modules, applications, software packages, routines, subroutines, objects, threads of execution, procedures, functions, and the like. The software may reside on a computer readable medium. By way of example, computer-readable media can comprise memory such as magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips), optical disks, smart cards, flash memory devices, random Access Memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically Erasable PROM (EEPROM), registers, or removable disk. Although the memory is shown separate from the processor in various aspects presented throughout this disclosure, the memory may also be located internal to the processor (e.g., cache or registers).

The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Accordingly, the claims are not intended to be limited to the aspects shown herein. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the claims.

Claims

1. A method for automated Operating System (OS) migration in an infrastructure system, comprising:

monitoring for an OS update event associated with a current OS in the infrastructure system;

acquiring OS information of the updated OS indicated by the OS update event;

supplying at least one test machine provided with the updated OS according to the OS information;

performing at least one validation job on the at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system; and

determining whether the updated OS is applicable based on a verification result of the at least one verification job.

2. The method of claim 1, further comprising:

responsive to the updated OS being applicable, determining to provision the updated OS in the infrastructure system.

3. The method of claim 2, further comprising:

at least one running machine installed with the updated OS is supplied in the infrastructure system for supporting the running of the at least one software product.

4. The method of claim 1, wherein the at least one validation job comprises:

a product build stage for performing product build by compiling at least a source code file of the at least one software product into an executable file;

a test machine configuration stage for configuring the at least one test machine according to a corresponding software installation configuration template; and

a test run phase for running a functional test associated with the at least one software product on the at least one test machine.

5. The method of claim 4, wherein the software installation configuration template is used for at least one of:

copying the executable file to the at least one test machine;

Installing a software context of the at least one software product in the at least one test machine; and

installing the basic tool of the functional test in the at least one test machine.

6. The method of claim 4, further comprising:

the validation results are generated based on the results of the product build phase, the results of the test machine configuration phase, and the results of the test run phase.

7. The method of claim 1, further comprising:

monitoring for a product update event associated with the at least one software product; and

at least one further validation job is performed on the at least one test machine, the at least one further validation job being associated with at least one updated software product indicated by the product update event.

8. The method of claim 1, wherein,

the OS information includes at least an OS image of the updated OS and a version number of the updated OS.

9. The method of claim 1, wherein,

the verification result includes one of: success, failure, and to be investigated.

10. The method of claim 1, further comprising:

Storing at least one of: the OS information, the verification result, and a version number of the at least one software product.

11. An infrastructure system supporting automated Operating System (OS) migration, comprising:

an OS update monitor configured to: monitoring for an OS update event associated with a current OS in the infrastructure system; and obtaining OS information of the updated OS indicated by the OS update event;

a machine supply unit configured to: supplying at least one test machine provided with the updated OS according to the OS information;

an authentication unit configured to: performing at least one validation job on the at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system; and

an OS migration manager configured to: determining whether the updated OS is applicable based on a verification result of the at least one verification job.

12. The infrastructure system of claim 11, wherein the OS migration manager is further configured to:

13. The infrastructure system of claim 12, wherein the machine supply unit is further configured to:

14. The infrastructure system of claim 11, wherein the at least one validation job comprises:

15. The infrastructure system of claim 14, wherein the software installation configuration template is for at least one of:

copying the executable file to the at least one test machine;

16. The infrastructure system of claim 14, wherein the verification unit is further configured to:

17. The infrastructure system of claim 11, further comprising:

a product update monitor configured to: monitoring for a product update event associated with the at least one software product, and

wherein the verification unit is further configured to: at least one further validation job is performed on the at least one test machine, the at least one further validation job being associated with at least one updated software product indicated by the product update event.

18. The infrastructure system of claim 11, wherein the OS migration manager is further configured to:

19. An apparatus for automated Operating System (OS) migration in an infrastructure system, comprising:

At least one processor, and

a memory storing computer-executable instructions that, when executed, cause the at least one processor to:

monitoring for an OS update event associated with a current OS in the infrastructure system,

obtaining OS information of the updated OS indicated by the OS update event,

supplying at least one test machine installed with the updated OS based on the OS information,

performing at least one validation job on the at least one test machine, the at least one validation job being associated with at least one software product running in the infrastructure system, and

20. A computer program product for automated Operating System (OS) migration in an infrastructure system, comprising a computer program for execution by at least one processor for:

acquiring OS information of the updated OS indicated by the OS update event;