WO2023168641A1

WO2023168641A1 - Automatic operating system migration in an infrastructure system

Info

Publication number: WO2023168641A1
Application number: PCT/CN2022/080056
Authority: WO
Inventors: Yunqing ZHOU; Haiyu ZHU; Fangpeng Guo; Wenxin GONG; Wangxiang DING; John Brent ALINGER
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2022-03-10
Filing date: 2022-03-10
Publication date: 2023-09-14
Anticipated expiration: 2024-09-10
Also published as: CN117501240A

Abstract

The present disclosure provides methods and apparatuses for automatic operating system (OS) migration in an infrastructure system, and provides an infrastructure system supporting automatic OS migration. An OS updating event associated with the current OS in the infrastructure system may be monitored. OS information of an updated OS indicated by the OS updating event may be obtained. At least one test machine installed with the updated OS may be provisioned according to the OS information. At least one validation job may be performed on the at least one test machine. It may be determined whether the updated OS is applicable based on a validation result of the at least one validation job.

Description

AUTOMATIC OPERATING SYSTEM MIGRATION IN AN INFRASTRUCTURE SYSTEM

BACKGROUND

Infrastructure system is also referred to as information technology (IT) infrastructure system, which is a set of components needed for the operation and management of IT products or services and IT environments. For example, an infrastructure system may comprise hardware, software, networks, facilities, etc. that are required to develop, test, deliver, monitor, control or support IT products or services. There are several types of infrastructure system, e.g., traditional infrastructure system which is installed on-premises for company-only use or private use, cloud infrastructure system which is accessible via the Internet without the need of being installed on-premises, etc. Operating system (OS) is a core software component in an infrastructure system, which may manage system resources, manage hardware components, establish connections between software products and physical resources, etc.

SUMMARY

This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. It 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 methods and apparatuses for automatic operating system (OS) migration in an infrastructure system, and propose an infrastructure system supporting automatic OS migration. An OS updating event associated with the current OS in the infrastructure system may be monitored. OS information of an updated OS indicated by the OS updating event may be obtained. At least one test machine installed with the updated OS may be provisioned according to the OS information. At least one validation job may be performed on the at least one test machine. It may be determined whether the updated OS is applicable based on a validation result of the at least one validation job.

It should be noted that the above one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the drawings set forth in detail certain illustrative features of the one or more aspects. These features are only indicative of the various ways in which the principles of various aspects may be employed, and this disclosure is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosed aspects will hereinafter be described in connection with the appended drawings that are provided to illustrate and not to limit the disclosed aspects.

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

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

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

FIG. 4 illustrates an exemplary process of a validation job according to an embodiment.

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

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

FIG. 7 illustrates an exemplary apparatus for automatic 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 is to be understood that these implementations are discussed only for enabling those skilled in the art to better understand and thus implement the embodiments of the present disclosure, rather than suggesting any limitations on the scope of the present disclosure.

Various software products can run on an infrastructure system. The running of these software products is supported at least by an OS in the infrastructure system. Generally, providers or operators of the software products and the infrastructure system focus on constantly updating the versions of the software products so as to improve performance and user experience of the software products, but pay little attention to the updating of the OS in the infrastructure system. The OS in the infrastructure system will keep unchanged for a rather long time, even an OS provider of the OS has published updated versions of the OS. Thus, the current OS in the infrastructure system is always not the latest. Even an OS migration is desired to implement in the infrastructure system, e.g., updating the current OS to a new version, such OS migration commonly needs to be performed manually. For example, for a new version of the OS, software engineers should carry out the whole OS migration process manually, which is time-consuming and inefficient because this OS migration process involves many steps and regressions and requires the software engineers to manually carry out these steps and regressions with much time and great efforts. Moreover, the above limits of manual OS migration further hinder the provider or operator of the infrastructure system to get 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 to automatically, efficiently and easily migrate an updated version of an OS into the infrastructure system with a very low time cost, thus making the OS in the infrastructure system always the latest. Benefiting from the automatic OS migration mechanism, the embodiments of the present disclosure may be implemented for constantly updating the OS in the infrastructure system, thus removing the gap between the current OS in the infrastructure system and the latest version of the OS published by an OS provider. Timely updating of the OS will improve the availability, security, scale, etc. of the infrastructure system, and thus those software products running in the infrastructure system could get benefits of the timely-updated OS and accordingly achieve better performance and user experience. Herein, the terms “product” , “service” , “application” , etc. may be used interchangeably, and may widely refer to various products that are implemented based at least on software, running on the OS in the infrastructure system, employing software and hardware resources in the infrastructure system, etc.

In an aspect, the embodiments of the present disclosure may automatically monitor whether there is an updated version of the current OS in an infrastructure system in real time. The occurrence of an updated OS would trigger a further determination of the applicability of the updated OS, e.g., determining whether the updated OS is applicable through at least a validation process. Herein, the applicability of the updated OS may refer to whether the updated OS can be provisioned in the infrastructure system for supporting the running of the software products in a product environment well, wherein the product environment may widely refer to an actual deploying or working environment of the software products that is provided by the infrastructure system.

In an aspect, in response to the occurrence of the updated OS, test machines may be automatically provisioned or supplied, in which the updated OS is installed. The test machines may be further applied for implementing the validation process.

In an aspect, the validation process may be performed for determining whether the updated OS can operate stably, provide basic functions properly, etc. in a test environment, and thus is applicable into the infrastructure system in the product environment. Herein, the test environment may widely refer to an environment provided by the infrastructure system especially for validating the updated OS. In some implementations, the validation process may utilize functional tests associated with the software products running in the infrastructure system for determining whether the updated OS is applicable. For example, the validation process may comprise automatically performing validation jobs on the test machines, wherein the validation jobs are associated with the software products. If the validation jobs associated with the software products are passed, i.e., the software products can properly run on the updated OS, this would indicate that the updated OS can support the running of the software products well and thus is applicable.

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

In an aspect, optionally, besides monitoring the occurrence of the updated OS, the embodiments of the present disclosure may also monitor whether there is an updated version of the software products in real time. The occurrence of updated software products would trigger a further validation process. In this way, the applicability of the updated OS may be further determined through checking whether the updated software products can properly run on the updated OS.

The processings in the automatic OS migration mechanism can be performed automatically, timely and efficiently. Thus, the OS in the infrastructure system can be evergreen through constantly keeping up with the latest version of the OS, and accordingly the infrastructure system may better support the running of the software products. Moreover, since the automatic OS migration mechanism can be performed timely, the updating frequency of the OS in the infrastructure system can be as high as the updating 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, the automatic OS migration mechanism will be triggered to validate the updated OS. Accordingly, as compared to validating an updated OS which is derived from the current OS through several updated versions, the embodiments of the present disclosure may reduce the number of possible issues in the validation process and reduce processing complexity in every attempt of updating the OS in the infrastructure system, thus further increasing the pass rate of the validation process and improving the efficiency of OS migration.

The embodiments of the present disclosure are not limited to any specific type of infrastructure system, but can be applied for various types of infrastructure system. Moreover, the embodiments of the present disclosure are not limited to any specific software products involved in the validation process, but can adopt, in the validation process, various types of software products, e.g., various cloud-based services, etc.

FIG. 1 illustrates an exemplary infrastructure system 100 according to an embodiment. The infrastructure system 100 may implement the automatic OS migration mechanism according to the embodiments of the present disclosure, and thus may support automatic OS migration.

The infrastructure system 100 may comprise, e.g., an OS updating monitor 110, an OS migration manager 120, a machine provisioning unit 130, a validation unit 140, an optional product updating monitor 150, etc. It should be understood that, for the sake of simplicity, FIG. 1 merely shows exemplary components of the infrastructure system 100 that may be involved in the automatic OS migration mechanism, and the infrastructure system 100 may actually comprise more other software and hardware components.

The OS updating monitor 110 may be configured for automatically monitoring whether there is an updated version of the current OS in the infrastructure system 100 in real time. In an implementation, the OS updating monitor 110 may monitor an OS updating event associated with the current OS in the infrastructure system 100. The OS updating event may refer to that an updated version of the current OS in the infrastructure system 100, e.g., an updated OS, is published by an OS provider of the OS. The OS updating monitor 110 may monitor the OS updating event through various approaches, e.g., receiving an notification about the OS updating event from the OS provider, fetching or retrieving information about the OS updating event from a website of the OS provider, etc. The embodiments of the present disclosure are not limited to any specific approaches of monitoring the OS updating event. As an example, an API may be invoked by the OS updating monitor 110 for monitoring the OS updating event.

In response to the occurrence of the OS updating event, the OS updating monitor 110 may further obtain OS information of the updated OS indicated by the OS updating event. The OS information may comprise various types of information related to the updated OS, e.g., the version number of the updated OS, an OS image of the updated OS, etc. The OS image may be a file that is usable for the installation of the updated OS, e.g., a VHDX file corresponding to the updated OS, etc. The OS information obtained by the OS updating monitor 110 may also comprise any other types of information related to the updated OS.

The OS updating monitor 110 may monitor the OS updating event automatically and constantly. Thus, once a new updated version of the OS is published, the OS updating monitor 110 may monitor this OS updating event timely, and subsequent processings in the automatic OS mitigation mechanism would be triggered accordingly.

The OS migration manager 120 is a core management component for the automatic OS migration mechanism, which may be configured for storing various types of information related to OS migration such as the OS information of the updated OS and a validation result of the validation process, instructing to provision test machines or operational machines installed with the updated OS, etc. In an implementation, the OS migration manager 120 may receive the OS information from the OS updating 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 provisioning unit 130 to provision the test machines installed with the updated OS, through sending a test machine provisioning instruction to the machine provision unit 130.

The machine provisioning unit 130 may be configured for, in response to receiving the test machine provisioning instruction from the OS migration manager 120, automatically provisioning at least one test machine installed with the updated OS according to the OS information. For example, the test machine provisioning instruction may comprise at least the OS information, and the machine provisioning unit 130 may install the updated OS on the at least one test machine according to, e.g., the version number or the image of the updated OS indicated by the OS information. Herein, the test machine may be a machine provided by the infrastructure system 100 especially for validating the updated OS in a test environment. The test machine may be, e.g., a physical machine or a virtual machine. In some scenarios, the infrastructure system 100 may previously designate a set of machines for validating an updated OS in the test environment, and the at least one test machine provisioned by the machine provisioning unit 130 may be any or all of these machines.

The validation unit 140 may be configured for automatically performing the validation process. In an implementation, the validation process may comprise automatically performing at least one validation job on the at least one test machine, and accordingly the validation unit 140 may perform the at least one validation job 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 100. For example, each software product may correspond to a validation job. The at least one validation job may utilize functional tests associated with the corresponding software product for determining whether the updated OS is applicable. Herein, a validation job may refer to a series of stages or processings related to validation of an updated OS. In an implementation, a validation job may comprise, e.g., a product building stage, a test machine configuring stage, a test running stage, etc.

Through performing the at least one validation job, the validation unit 140 may finally obtain a validation result of the at least one validation job. For example, in the case that the at least one validation job includes only one validation job, the validation unit 140 may produce the validation result of the validation job based on a result of the product building stage in the validation job, a result of the test machine configuring stage in the validation job, a result of the test running stage in the validation job, etc. For example, in the case that the at least one validation job includes two or more validation jobs, the validation unit 140 may first produce a sub validation result of each validation job, and then produce a final validation result of the two or more validation jobs through combining the sub validation results of these validation jobs.

In an implementation, the types of validation result may comprise success, failure and to-be-investigated. In the case that the at least one validation job includes only one validation job, the validation result of “success” may refer to that all the stages in the validation job succeed, the validation result of “failure” may refer to that at least one stage in the validation job fails, and the validation result of “to-be-investigated” may refer to that at least one result of at least one stage in the validation job needs to be investigated manually. In the case that the at least one validation job includes two or more validation jobs, the validation result of “success” may refer to that a predetermined number or ratio of the sub validation results of these validation jobs are success, the validation result of “failure” may refer to that a predetermined number or ratio of the sub validation results of these validation jobs are failure, and the validation result of “to-be-investigated” may refer to that a predetermined number or ratio of the sub validation results of these validation jobs are to-be-investigated. It should be understood that the embodiments of the present disclosure are not limited to classify the validation result into the above types of success, failure and to-be-investigated, but can classify the validation result into more or less types according to any predetermined criteria.

The validation unit 140 may send the produced validation result of the at least one validation job to the OS migration manager 120. The OS migration manager 120 may be configured for automatically storing the validation result, the version number of the at least one software product, etc. The OS migration manager 120 may also be configured for automatically determining whether the updated OS is applicable based on the validation result. For example, if the validation result is success, the updated OS may be determined as applicable. In an implementation, in response to that the updated OS is applicable, the OS migration manager 120 may further determine to provision the updated OS in the infrastructure system 100. In this case, the OS migration manager 120 may instruct the machine provisioning unit 130 to provision operational machines installed with the updated OS, through sending an operational machine provisioning instruction to the machine provision unit 130.

The machine provisioning unit 130 may be configured for, in response to receiving the operational machine provisioning instruction from the OS migration manager 120, automatically provisioning at least one operational machine installed with the updated OS in the infrastructure system 100, for supporting the running of the at least one software product. The operational machine may be a machine provided by the infrastructure system 100 especially for supporting the running of the at least one software product in a product environment. The operational machine may be, e.g., a physical machine or a virtual machine. In some scenarios, the infrastructure system 100 may previously designate a set of machines for supporting the running of the at least one software product in the product environment, and the at least one operational machine provisioned by the machine provisioning unit 130 may be any or all of these machines.

Optionally, in response to that the updated OS is applicable, instead of determining to provision the updated OS directly, the OS migration manager 120 may suggest the provider or operator of the at least one software product to adopt the updated OS in the infrastructure system 100. In this case, the OS migration manager 120 may send a suggestion of adopting the updated OS to the provider or operator of the at least one software product, and determine to provision the updated OS only if receiving a confirmation of adopting the updated OS from the provider or operator of the at least one software product.

Optionally, in some implementations, the infrastructure system 100 may utilize the product updating monitor 150 to trigger further validation processes of the updated OS. The product updating monitor 150 may be configured for automatically monitoring whether there is an updated version of the at least one software product in real time. In an implementation, the product updating monitor 150 may monitor a product updating event associated with the at least one software product. The product updating event may refer to that an updated version of the software product is published by a product provider of the software product. The product updating monitor 150 may monitor the product updating event through various approaches, e.g., receiving a notification about the product updating event from the product provider, fetching or retrieving information about the product updating event from a website of the product provider, etc. The embodiments of the present disclosure are not limited to any specific approaches of monitoring the product updating event. As an example, an API may be invoked by the product updating monitor 150 for monitoring the product updating event. The product updating monitor 150 may monitor the product updating event automatically and constantly. Thus, once a new updated version of the software product is published, the product updating monitor 150 may monitor this product updating event timely, and a further validation process would be triggered accordingly.

In response to the occurrence of the product updating event, the validation unit 140 may automatically perform a further validation process. In an implementation, the further validation process may comprise automatically performing at least one further validation job on the at least one test machine, and accordingly the validation unit 140 may perform the at least one further validation job on the at least one test machine. The at least one further validation job may be associated with at least one updated software product indicated by the product updating event.

Through performing the at least one further validation job, the validation unit 140 may finally obtain a validation result of the at least one further validation job. The validation unit 140 may send the validation result of the at least one further validation job to the OS migration manager 120. The OS migration manager 120 may automatically store the validation 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 validation result. In response to that the updated OS is determined as applicable, the OS migration manager 120 may further determine to provision the updated OS in the infrastructure system 100, e.g., instructing the machine provisioning unit 130 to provision operational machines installed with the updated OS. Alternatively, the OS migration manager 120 may also suggest the provider or operator of the at least one updated software product to adopt the updated OS in the infrastructure system 100.

It should be understood that the components such as the OS updating monitor 110, the OS migration manager 120, the machine provisioning unit 130, the validation unit 140, the product updating monitor 150, etc. in the infrastructure system 100 may be implemented through various approaches, e.g., via software, hardware or a combination thereof. For example, in the software implementation, all or a part of these components may be implemented via software, and thus may be software modules that are implemented through computer program codes, etc. For example, in the hardware implementation, all or a part of these components may be implemented via hardware, and thus may be hardware modules that have processing capabilities, e.g., processors, special chips, etc. The embodiments of the present disclosure are not limited to any specific implementation approaches of the components shown in FIG. 1.

FIG. 2 illustrates an exemplary process 200 of automatic OS migration in an infrastructure system according to an embodiment. The process 200 may be performed for implementing the automatic OS migration mechanism proposed by the embodiments of the present disclosure. Operations or steps in the process 200 may be performed by, e.g., the corresponding components shown in FIG. 1.

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

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

At 230, at least one test machine installed with the updated OS may be provisioned according to the OS information. For example, the updated OS may be installed on the at least one test machine according to the OS information, and thus the at least one test machine may be further supplied for performing a validation process. In an implementation, the provisioning operation at 230 may be performed by the machine provisioning unit 130 in FIG. 1. For example, the machine provisioning unit 130 may install the updated OS on the at least one test machine according to the OS information which is obtained at 120, and provision the test machine installed with the updated OS for further operations. In a further implementation, the OS migration manager 120 in FIG. 1 may receive the OS information from the OS updating monitor 110, and instruct the machine provisioning unit 130 to provision the 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 an implementation, the performing operation at 240 may be performed by the validation unit 140 in FIG. 1.

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

According to the embodiments of the present disclosure, a validation job may be defined for each corresponding software product, and may comprise several stages. FIG. 4 illustrates an exemplary process of a validation job 400 according to an embodiment. It is assumed that the validation job 400 is defined for a target software product 402 running in the infrastructure system. As shown in FIG. 4, the validation job 400 may comprise, e.g., a product building stage 410, a test machine configuring stage 420, a test running stage 430, etc.

At the product building stage 410, product building may be performed for the software product 402. The product building stage 410 may adopt any techniques for software building. In an implementation, the product building may comprise at least compiling a source code file of the software product 402 into an executable file. It should be understood that, in the case that the software product 402 contains a plurality of source code files, the above compiling operation may also widely refer to compiling the plurality of source code files into a plurality of corresponding executable files respectively. Moreover, it should be understood that the embodiments of the present disclosure are not limited to any specific software building techniques, and the product building may further comprise any other operations besides the compiling operation.

Through performing the product building stage 410, a result 412 of the product building stage 410 may be obtained. As an example, the result 412 may be success, failure or to-be-investigated, wherein “success” indicates that the product building succeeds and there is no building time issue, “failure” indicates that the product building fails because of possible building time issues, and “to-be-investigated” indicates that the product building fails because of some unidentified issues or flaky building issues that require to be investigated manually. It should be understood that the embodiments of the present disclosure are not limited to classify the result 412 into the above types of success, failure and to-be-investigated, but can classify the result 412 into more or less types according to any predetermined criteria.

At the test machine configuring stage 420, at least one test machine may be configured according to a corresponding software-installation configuration template 404. The at least one test machine has been installed with the updated OS. The software-installation configuration template 404 is predefined for instantiating the software product 402, a software context of the software product 402, etc. on the test machine. The software context may comprise, e.g., various tools, scripts, tasks, configurations, etc. on which the software product 402 depends. Accordingly, the software-installation configuration template 404 may define what a configured test machine shall be like. It should be understood that the software-installation configuration template 404 may be defined through various approaches, e.g., by using XML. Moreover, in the case that there are two or more test machines, each test machine may be applied by a respective software-installation configuration template, and software-installation configuration templates for these test machines may be the same, or may be different by specifying, e.g., different software contexts, etc.

In an implementation, a software-installation configuration template defined for a test machine may achieve various functions. For example, the software-installation configuration template may copy the executable file of the software product 402 obtained at the product building stage 410 to the test machine. For example, the software-installation configuration template may install software context of the software product 402 in the test machine. For example, the software-installation configuration template may install fundamental tools of functional tests in the test machine, wherein the functional tests are to be run at the test running stage 430, and the fundamental tools refer to any tools that are required by the functional tests. Moreover, the software-installation configuration template may also achieve any other functions.

Through performing the test machine configuring stage 420, a result 422 of the test machine configuring stage 420 may be obtained. As an example, the result 422 may be success, failure or to-be-investigated, wherein “success” indicates that the configuring of test machine succeeds, “failure” indicates that the configuring of test machine fails because of some identified issues such as the absence of a file to be installed, failure of launching a required service, etc., and “to-be-investigated” indicates that the configuring of test machine fails because of some unidentified issues that require to be investigated manually. It should be understood that the embodiments of the present disclosure are not limited to classify the result 422 into the above types of success, failure and to-be-investigated, but can classify the result 422 into more or less types according to any predetermined criteria.

At the test running stage 430, functional tests associated with the software product 402 may be run on the at least one test machine. The functional tests may refer to various tests for checking whether the functionality of the software product 402 or any part or aspect of the software product 402 is normal. For example, the functional tests may comprise checking whether the software product 402 is installed well, whether certain functions of the software product 402 can be invoked, whether communications among components of the software product 402 are normal, etc. The embodiments of the present disclosure are not limited to any specific functional tests.

Through performing the test running stage 430, a result 432 of the test running stage 430 may be obtained. As an example, the result 432 may be success, failure or to-be-investigated, wherein “success” indicates that a predetermined number or ratio of the functional tests are passed, “failure” indicates that a predetermined number or ratio of the functional tests are not passed, and “to-be-investigated” indicates that the reasons of failed functional tests require to be investigated manually. It should be understood that the embodiments of the present disclosure are not limited to classify the result 432 into the above types of success, failure and to-be-investigated, but can classify the result 432 into more or less types according to any predetermined criteria.

In an implementation, a validation result 440 of the validation job 400 may be produced based on the result 412 of the product building stage 410, the result 422 of the test machine configuring stage 420, and the result 432 of the test running stage 430. For example, if all of the

results

412, 422 and 432 are success, then the validation result 440 would be success; if at least one of the

results

412, 422 and 432 is failure, then the validation result 440 would be failure; and if at least one of the

results

412, 422 and 432 is to-be-investigated, then the validation result 440 would be to-be-investigated. It should be understood that the embodiments of the present disclosure are not limited to produce the validation result 440 through the above approach of combining the

results

412, 422 and 432, but can produce the validation result 440 with the

results

412, 422 and 432 in any other approaches.

It should be understood that FIG. 4 merely shows the exemplary validation job 400 corresponding to the software product 402, if the at least one validation job performed at 240 in FIG. 2 comprises two or more validation jobs corresponding to two or more software products running in the infrastructure system, each of these validation jobs may be performed in a similar approach as shown in FIG. 4, and a respective sub validation result of each validation job may be obtained accordingly. In this case, these sub validation results may be combined to produce a final validation result at 250 in FIG. 2. For example, if a predetermined number or ratio of the sub validation results is of a certain type, the final validation result would be of the same type.

Returning back to the process 200 in FIG. 2, at 260, information related to the steps or operations in the process 200 may be stored in, e.g., at least one database in the infrastructure system. For example, the OS information obtained at 220, the validation result produced at 250, etc. may be stored at 260. In an implementation, the storing 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 applicable, based on the validation result of the at least one validation job. For example, if the validation result is success, the updated OS may be determined as applicable. It should be understood that although the at least one validation job is performed with respect to at least one software product, the validation result of the at least one validation job may indicate whether the updated OS itself has satisfied performance, because failure of functional tests involved in the at least one validation job may be resulted by defects of the updated OS, e.g., code bugs in the updated OS may cause memory access conflicts during the running of the software product, changes to underlying APIs in the updated OS may cause that some functions cannot be supported by the current software context, etc. In an implementation, the determining operation at 270 may be performed by the OS migration manager 120 in FIG. 1.

In response to determining at 270 that the updated OS is applicable, it may be determined at 280 to provision the updated OS in the infrastructure system. In an implementation, the determining operation 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, the process 200 may further comprise provisioning the updated OS through provisioning at least one operational machine installed with the updated OS in the infrastructure system, wherein the at least one operational machine may support the running of the at least one software product in a product environment. In an implementation, the above provisioning operation may be performed by the machine provisioning unit 130 in FIG. 1.

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

It should be understood that all the operations and their sequence orders in the process 200 are exemplary, and depending on actual application requirements and designs, these operations may be changed in any approaches and more or less steps may be included in the process 200. For example, the storing operation at 260 is optional, or it may be performed in any other order or position in the process 200. For example, although the storing operation at 260 is shown as a single step, it may be divided into several sub-operations for storing different information respectively. For example, before the determining operation at 280, in response to determining at 270 that the updated OS is applicable, a suggestion of adopting the updated OS may be sent by the OS migration manager 120 to the provider or operator of the at least one software product, and only if receiving a confirmation of adopting the updated OS from the provider or operator of the at least one software product, the determining operation at 280 would be performed. Moreover, all the operations in the process 200 may be performed automatically, and accordingly, the process 200 may implement OS migration in an automatic approach.

FIG. 3 illustrates an exemplary process 300 of automatic OS migration in an infrastructure system according to an embodiment. The process 300 is an improvement or variant of the process 200 in FIG. 2. The same reference numbers in FIG. 3 and FIG. 2 may refer to the same or similar operations.

Initially, after the

operations

210, 220 and 230 have been performed, the

operations

340, 350 and 360 may be performed in a similar approach with the

operations

240, 250 and 260 in FIG. 2. However, before performing the operation 270, the process 300 may comprise performing a further validation process in response to the updating of the at least one software product.

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

In response to the occurrence of the product updating event, a further validation process may be performed. For example, at 340, at least one further validation job may be performed on the at least one test machine. The at least one further validation job may be associated with at least one updated software product indicated by the product updating event. The at least one further validation job may be performed in a similar approach with the at least one validation job, except that all the stages in the at least one further validation job are performed with respect to the updated software product. For example, in the at least one further validation job, the product building stage may perform product building through at least compiling a source code file of the at least one updated software product into an executable file, the test machine configuring stage 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 running stage may run functional tests associated with the at least one updated software product. In an implementation, the performing operation at 340 may be performed by the validation unit 140 in FIG. 1.

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

At 360, the validation result of the at least one further validation process and the version number of the at least one updated software product may be further stored. In an implementation, the storing 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 applicable, based on the validation result of the at least one further validation job. Alternatively, the determining operation at 270 may be based on both the validation result of the at least one further validation job and the validation result of the at least one previous validation job. For example, if both of the validation results are success, the updated OS may be determined as applicable. In an implementation, the determining operation at 270 may be performed by the OS migration manager 120 in FIG. 1.

It should be understood that the above further validation process may be performed iteratively by constantly performing the monitoring operation at 370, and thus once a new updated version of the at least one software product is published, a new further validation process would be triggered. In this way, the applicability of the updated OS may be determined in consideration of both the at least one original software product and updated versions of the at least one software product.

It should be understood that all the operations and their sequence orders in the process 300 are exemplary, and depending on actual application requirements and designs, these operations may be changed in any approaches and more or less steps may be included in the process 300.

Moreover, although not shown, the process 200 in FIG. 2 or the process 300 in FIG. 3 may optionally comprise an operation of performing validation result analysis. The validation result analysis may comprise various types of analysis to the validation result, e.g., concluding and classifying the reasons leading to failure of functional tests, etc. Information of the validation result analysis may be further sent to the provider of the OS, such 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 automatic OS migration in an infrastructure system according to an embodiment.

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

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

At 530, at least one test machine installed with the updated OS may be provisioned 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 applicable based on a validation result of the at least one validation job.

In an implementation, the method 500 may further comprise: in response to that the updated OS is applicable, determining to provision the updated OS in the infrastructure system.

The method 500 may further comprise: provisioning at least one operational machine installed with the updated OS in the infrastructure system, for supporting the running of the at least one software product.

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

The software-installation configuration template may be for at least one of: copying the executable file to the at least one test machine; installing software context of the at least one software product in the at least one test machine; and installing fundamental tools of the functional tests in the at least one test machine.

The method 500 may further comprise: producing the validation result based on a result of the product building stage, a result of the test machine configuring stage, and a result of the test running stage.

In an implementation, the method 500 may further comprise: monitoring a product updating event associated with the 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 at least one updated software product indicated by the product updating event.

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

In an implementation, the validation result may comprise one of success, failure, and to-be-investigated.

In an implementation, the method 500 may further comprise: storing at least one of the OS information, the validation result, and a version number of the at least one software product.

Moreover, the method 500 may further comprise any steps/operations for automatic OS migration in an infrastructure system according to the above embodiments of the present disclosure.

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

The apparatus 600 may comprise: an OS updating event monitoring module 610, for monitoring an OS updating event associated with the current OS in the infrastructure system; an OS information obtaining module 620, for obtaining OS information of an updated OS indicated by the OS updating event; a test machine provisioning module 630, for provisioning at least one test machine installed with the updated OS according to the OS information; a validation job performing module 640, for 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 applicability determining module 650, for determining whether the updated OS is applicable, based on a validation result of the at least one validation job.

Moreover, the apparatus 600 may further comprise any other modules configured for automatic OS migration in an infrastructure system according to the above embodiments of the present disclosure.

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

The apparatus 700 may comprise at least one processor 710. The apparatus 700 may further comprise a memory 720 connected to the at least one processor 710. The memory 720 may store computer-executable instructions that, when executed, cause the at least one processor 710 to: monitor an OS updating event associated with the current OS in the infrastructure system; obtain OS information of an updated OS indicated by the OS updating event; provision at least one test machine installed with the updated OS according to the OS information; perform 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 determine whether the updated OS is applicable, based on a validation result of the at least one validation job.

Moreover, the at least one processor 710 may be further configured for performing any operations of the methods for automatic OS migration in an infrastructure system according to the above embodiments of the present disclosure.

The embodiments of the present disclosure propose an infrastructure system supporting automatic OS migration. The infrastructure system may comprise: an OS updating monitor, configured for monitoring an OS updating event associated with the current OS in the infrastructure system, and obtaining OS information of an updated OS indicated by the OS updating event; a machine provisioning unit, configured for provisioning at least one test machine installed with the updated OS according to the OS information; a validation unit, configured for 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 for determining whether the updated OS is applicable, based on a validation result of the at least one validation job.

In an implementation, the OS migration manager may be further configured for: in response to that the updated OS is applicable, determining to provision the updated OS in the infrastructure system.

The machine provisioning unit may be further configured for: provisioning at least one operational machine installed with the updated OS in the infrastructure system, for supporting the running of the at least one software product.

The validation unit may be further configured for: producing the validation result based on a result of the product building stage, a result of the test machine configuring stage, and a result of the test running stage.

In an implementation, the infrastructure system may further comprise: a product updating monitor, configured for monitoring a product updating event associated with the at least one software product. The validation unit may be further configured for: performing at least one further validation job 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 updating event.

In an implementation, the OS migration manager may be further configured for: storing at least one of the OS information, the validation result, and a version number of the at least one software product.

Moreover, the infrastructure system may further comprise any other units or components for supporting automatic OS migration according to the above embodiments of the present disclosure, and these units may be configured for performing any operations of the methods for automatic OS migration according to the above embodiments of the present disclosure.

The 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 that is executed by at least one processor for: monitoring an OS updating event associated with the current OS in the infrastructure system; obtaining OS information of an updated OS indicated by the OS updating event; provisioning at least one test machine installed 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 validation result of the at least one validation job. Moreover, the computer program may be further executed by the at least one processor for performing any other operations of the methods for automatic OS migration in an infrastructure system according to the above embodiments of the present disclosure.

The embodiments of the present disclosure may be embodied in a non-transitory computer-readable medium. The non-transitory computer-readable medium may comprise instructions that, when executed, cause one or more processors to perform any steps/operations of the methods for automatic OS migration in an infrastructure system according to the above embodiments of the present disclosure.

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

Moreover, 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 the context to be directed to a singular form.

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

Processors have 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 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 the present disclosure may be implemented with a microprocessor, microcontroller, digital signal processor (DSP) , a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a state machine, gated logic, discrete hardware circuits, and other suitable processing components configured to perform the various functions described throughout the present disclosure. The functionality of a processor, any portion of a processor, or any combination of processors presented in the present disclosure may be implemented with software being executed by a microprocessor, microcontroller, DSP, or other suitable platform.

Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, threads of execution, procedures, functions, etc. The software may reside on a computer-readable medium. A computer-readable medium may include, by way of example, memory such as a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip) , an optical disk, a smart card, a flash memory device, random access memory (RAM) , read only memory (ROM) , programmable ROM (PROM) , erasable PROM (EPROM) , electrically erasable PROM (EEPROM) , a register, or a removable disk. Although memory is shown separate from the processors in the various aspects presented throughout the present disclosure, the memory may be internal to the processors, e.g., cache or register.

The previous 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. Thus, 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 the present disclosure that are known or later come to be known to those of ordinary skilled in the art are intended to be encompassed by the claims.

Claims

A method for automatic operating system (OS) migration in an infrastructure system, comprising:

monitoring an OS updating event associated with the current OS in the infrastructure system;

obtaining OS information of an updated OS indicated by the OS updating event;

provisioning at least one test machine installed 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 validation result of the at least one validation job.
The method of claim 1, further comprising:

in response to that the updated OS is applicable, determining to provision the updated OS in the infrastructure system.
The method of claim 2, further comprising:

provisioning at least one operational machine installed with the updated OS in the infrastructure system, for supporting the running of the at least one software product.
The method of claim 1, wherein the at least one validation job comprises:

a product building stage, for performing product building through at least compiling a source code file of the at least one software product into an executable file;

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

a test running stage, for running functional tests associated with the at least one software product on the at least one test machine.
The method of claim 4, wherein the software-installation configuration template is for at least one of:

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

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

installing fundamental tools of the functional tests in the at least one test machine.
The method of claim 4, further comprising:

producing the validation result based on a result of the product building stage, a result of the test machine configuring stage, and a result of the test running stage.
The method of claim 1, further comprising:

monitoring a product updating event associated with the 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 at least one updated software product indicated by the product updating event.
The method of claim 1, wherein

the OS information comprises at least an OS image of the updated OS and a version number of the updated OS.
The method of claim 1, wherein

the validation result comprises one of success, failure, and to-be-investigated.
The method of claim 1, further comprising:

storing at least one of the OS information, the validation result, and a version number of the at least one software product.
An infrastructure system supporting automatic operating system (OS) migration, comprising:

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

a machine provisioning unit, configured for: provisioning at least one test machine installed with the updated OS according to the OS information;

a validation unit, configured for: 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 for: determining whether the updated OS is applicable, based on a validation result of the at least one validation job.
The infrastructure system of claim 11, wherein the OS migration manager is further configured for:

in response to that the updated OS is applicable, determining to provision the updated OS in the infrastructure system.
The infrastructure system of claim 12, wherein the machine provisioning unit is further configured for:

provisioning at least one operational machine installed with the updated OS in the infrastructure system, for supporting the running of the at least one software product.
The infrastructure system of claim 11, wherein the at least one validation job comprises:

a product building stage, for performing product building through at least compiling a source code file of the at least one software product into an executable file;

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

a test running stage, for running functional tests associated with the at least one software product on the at least one test machine.
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;

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

installing fundamental tools of the functional tests in the at least one test machine.
The infrastructure system of claim 14, wherein the validation unit is further configured for:

producing the validation result based on a result of the product building stage, a result of the test machine configuring stage, and a result of the test running stage.
The infrastructure system of claim 11, further comprising:

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

wherein the validation unit is further configured for: performing at least one further validation job 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 updating event.
The infrastructure system of claim 11, wherein the OS migration manager is further configured for:

storing at least one of the OS information, the validation result, and a version number of the at least one software product.
An apparatus for automatic 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:

monitor an OS updating event associated with the current OS in the infrastructure system,

obtain OS information of an updated OS indicated by the OS updating event,

provision at least one test machine installed with the updated OS according to the OS information,

perform 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

determine whether the updated OS is applicable, based on a validation result of the at least one validation job.
A computer program product for automatic operating system (OS) migration in an infrastructure system, comprising a computer program that is executed by at least one processor for:

monitoring an OS updating event associated with the current OS in the infrastructure system;

obtaining OS information of an updated OS indicated by the OS updating event;

provisioning at least one test machine installed 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 validation result of the at least one validation job.