A method, system and terminal for cross-version hot upgrade based on an OpenStack cloud platform

Abstract

The application discloses a method, system and terminal for cross-version hot upgrading of an OpenStack cloud platform. The method comprises the following steps: backing up a business running database and OpenStack cloud platform configuration parameters of an OpenStack environment to be upgraded; importing a container image of a target OpenStack version into a current image warehouse; installing a basic package matched with the target OpenStack version according to the target OpenStack version identified; merging kolla-ansible deployment code by covering a deployment directory of the OpenStack version to be upgraded; customizing and modifying OpenStack cloud platform configuration parameters according to component differences between the OpenStack version to be upgraded and the target OpenStack version; and upgrading the target OpenStack version according to the customized and modified OpenStack cloud platform configuration parameters. The system comprises a backup module, a private library management module, a basic package installation and upgrading module, a deployment code merging module, a configuration parameter modification module and an upgrading module. Through the application, cross-version online quick upgrading of the OpenStack can be realized, and the upgrading efficiency is effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of OpenStack cluster version upgrade, and particularly relates to a method and system for cross-version hot upgrade of an OpenStack cloud platform and a terminal. BACKGROUND

[0002] OpenStack is an open-source cloud computing management platform project, which is a combination of a series of open-source software projects. Generally, OpenStack is updated once every six months or so. Therefore, how to upgrade the version of OpenStack is an important technical problem.

[0003] Kolla-ansible, as a mature and relatively simple project, is widely used in the industry and can be used to deploy, modify and upgrade OpenStack clusters. Although Kolla-ansible can upgrade the version, it is limited to the same openstack version and the upgrade of component code. Currently, when upgrading OpenStack across versions, an offline upgrade method is usually used. Specifically, the virtual machine needs to be shut down, the old version of OpenStack needs to be migrated or backed up, and then the virtual machine needs to be migrated to the new version of OpenStack, thereby completing the cross-version upgrade of OpenStack. Alternatively, the Kolla-ansible online upgrade method needs to modify the base package, deploy the code, migrate or backup the old version of OpenStack, and redeploy, etc.

[0004] However, in the current OpenStack cross-version upgrade method, if offline upgrade is used, it needs to be run in a virtual machine shutdown state, which will affect the normal operation of the virtual machine and thus affect the upgrade efficiency. If Kolla-ansible online upgrade is used, due to the large difference in base package versions, the old deployment code, and the large difference in component code, the migration or backup of the old version of OpenStack and the redeployment operation are relatively cumbersome, the upgrade threshold is high, and the upgrade efficiency will also be seriously affected. Therefore, the current OpenStack cross-version upgrade method has low upgrade efficiency. SUMMARY

[0005] The present application provides a method and system for cross-version hot upgrade of an OpenStack cloud platform and a terminal to solve the problem of low upgrade efficiency of the cross-version hot upgrade method of the OpenStack cloud platform in the prior art.

[0006] To solve the above technical problems, the embodiments of the present application disclose the following technical solutions:

[0007] A method for cross-version hot upgrade based on an OpenStack cloud platform, the method comprising:

[0008] Backuping a service running database and OpenStack cloud platform configuration parameters of an OpenStack environment to be upgraded, the OpenStack environment to be upgraded corresponding to an OpenStack version to be upgraded, the OpenStack cloud platform configuration parameters including: a / etc / kolla / config / directory, a globals.yml file, a multinode file, a passwords.yml file, a deployment directory, and a container image registry private library file;

[0009] Importing container images of a target OpenStack version into a current image warehouse, the current image warehouse including container images of the OpenStack version to be upgraded;

[0010] According to the identified target OpenStack version, installing an upgrade base package matched with the target OpenStack version;

[0011] Merging kolla-ansible deployment code by covering the deployment directory of the OpenStack version to be upgraded;

[0012] According to the component differences between the OpenStack version to be upgraded and the target OpenStack version, customizing and modifying OpenStack cloud platform configuration parameters;

[0013] According to the customizing and modifying of the OpenStack cloud platform configuration parameters, performing target OpenStack version upgrade.

[0014] Optionally, after customizing and modifying the OpenStack cloud platform configuration parameters according to the component differences between the OpenStack version to be upgraded and the target OpenStack version, the method further comprises:

[0015] Judging whether there is an upgrade error in the component deployment process;

[0016] If yes, modifying and re-deploying the components according to the upgrade error;

[0017] If no, continuing to the next step.

[0018] Optionally, the modifying and re-deploying the components according to the upgrade error comprises:

[0019] If the 443 port is occupied in the haproxy component deployment process, querying and killing the occupied process, and then re-deploying the haproxy component;

[0020] If a branch error occurs in the neutron component deployment process, the version number is rolled back in the business operation database of the OpenStack environment to be upgraded, and the neutron component is redeployed;

[0021] If the upgrade error is a pluto monitoring error, the pluto container is deleted and the pluto component is redeployed.

[0022] Optionally, the method of redeploying the components is to upgrade the components one by one or to upgrade all the components.

[0023] Optionally, the customized modification of the OpenStack cloud platform configuration parameters according to the component difference between the OpenStack version to be upgraded and the target OpenStack version comprises:

[0024] The globals.yml file of the OpenStack environment to be upgraded is modified, the components no longer maintained are deleted, and new components matching the target OpenStack version are added;

[0025] The password configuration of the new components matching the target OpenStack version is added in the passwords.yml file;

[0026] The multinode file is modified according to the multinode file of the target OpenStack version.

[0027] Optionally, the installation of the basic package matching the target OpenStack version according to the identified target OpenStack version comprises:

[0028] The kolla-ansible basic dependency package is installed according to the identified target OpenStack version.

[0029] The docker basic package is upgraded according to the identified target OpenStack version.

[0030] An OpenStack cloud platform cross-version hot upgrade system, the system comprises:

[0031] The backup module is configured to backup a service running database of a to-be-upgraded OpenStack environment and OpenStack cloud platform configuration parameters, the to-be-upgraded OpenStack environment corresponds to a to-be-upgraded OpenStack version, and the OpenStack cloud platform configuration parameters include: an / etc / kolla / config / directory, a globals.yml file, a multinode file, a passwords.yml file, a deployment directory, and a container image registry private library file;

[0032] The private library management module is configured to import container images of the target OpenStack version into a current image warehouse, and the current image warehouse includes container images of the to-be-upgraded OpenStack version.

[0033] The basic package installation and upgrade module is configured to install and upgrade a basic package matched with the target OpenStack version according to the identified target OpenStack version.

[0034] The deployment code merging module is configured to merge kolla-ansible deployment codes by covering the deployment directory of the to-be-upgraded OpenStack version.

[0035] The configuration parameter modification module is configured to customize and modify OpenStack cloud platform configuration parameters according to component differences between the to-be-upgraded OpenStack version and the target OpenStack version.

[0036] The upgrade module is configured to perform target OpenStack version upgrade according to the customized and modified OpenStack cloud platform configuration parameters.

[0037] Optionally, the system further includes:

[0038] The verification module is configured to determine whether there is an upgrade error in the component deployment process, and if so, modify and re-deploy the component according to the upgrade error, and if not, continue to perform the next step.

[0039] Optionally, the verification module includes:

[0040] The first verification unit is configured to, when a 443 port is occupied in the haproxy component deployment process, query and kill the occupied process, and then re-deploy the haproxy component.

[0041] The second verification unit is configured to, when a branch error occurs in the neutron component deployment process, roll back a version number in the service running database of the to-be-upgraded OpenStack environment, and then re-deploy the neutron component.

[0042] The third checking unit is configured to delete the pluto container and redeploy the pluto component when the upgrade error is a pluto monitoring error.

[0043] A terminal, comprising a processor and a memory connected to the processor in communication,

[0044] The memory stores instructions executable by the processor, and the instructions are executed by the processor to enable the processor to perform the method for cross-version hot upgrade based on an OpenStack cloud platform according to any one of the above.

[0045] The technical scheme provided by the embodiment of the application can include the following beneficial effects:

[0046] The application provides a method for cross-version hot upgrade based on an OpenStack cloud platform. The method first backs up the business running database of the OpenStack environment to be upgraded and the OpenStack cloud platform configuration parameters, then imports the container image of the target OpenStack version into the current image warehouse, so that the current image warehouse includes the container image of the OpenStack version to be upgraded and the original container image. Then, according to the identified target OpenStack version, the base package matching the target OpenStack version is installed and upgraded, the deployment directory of the OpenStack version to be upgraded is covered, the kolla-ansible deployment code is merged, and the OpenStack cloud platform configuration parameters are customized and modified according to the component differences between the OpenStack version to be upgraded and the target OpenStack version. Finally, the target OpenStack version is upgraded according to the customized and modified OpenStack cloud platform configuration parameters. In this embodiment, when the OpenStack cross-version upgrade is performed, the virtual machine does not need to be shut down, and the upgrade can be realized without affecting the normal operation of the virtual machine, so that the upgrade efficiency can be effectively improved. Moreover, by importing the container image of the target OpenStack version into the current image warehouse, private library management is realized. When the base package is installed and upgraded, the corresponding base package can be automatically installed according to different target OpenStack versions, the deployment configuration parameters are finally customized and modified, the components that need to be maintained are updated in time, and the newly added components are effectively avoided from being missed, and these operations can be automatically completed by one key, so that the OpenStack cross-version upgrade efficiency can be effectively improved. In addition, the embodiment also includes correction during component deployment. When an upgrade error occurs, the component is automatically modified and redeployed, so as to further improve the efficiency and accuracy of the upgrade. For different upgrade errors, the component can also be upgraded in full or a certain component can be upgraded alone, and the upgrade method is more flexible.

[0047] The application also provides a system for cross-version hot upgrade based on an OpenStack cloud platform, which mainly comprises a backup module, a private library management module, a basic package installation and upgrade module, a deployment code merging module, a configuration parameter modification module and an upgrade module. Through the backup module, the business operation database of the OpenStack environment to be upgraded and the OpenStack cloud platform configuration parameters can be backed up at one key, thereby improving the upgrade efficiency. Through the private library management module, the container image of the OpenStack version to be upgraded and the original container image can be saved to the image warehouse, thereby facilitating extraction and use and improving the cross-version upgrade efficiency. Through the basic package installation and upgrade module, the kolla-ansible basic dependency package can be automatically installed and upgraded at one key. Through the setting of the deployment code merging module, the kolla-ansible deployment code can be merged, and through the configuration parameter modification module, the OpenStack cloud platform configuration parameters can be customized and modified, thereby updating the components that need to be maintained in time and effectively avoiding the omission of newly added components, and these operations can be completed automatically at one key, thereby effectively improving the OpenStack cross-version upgrade efficiency.

[0048] The application also provides a terminal, which also has the corresponding technical effects of the method and system for cross-version hot upgrade based on an OpenStack cloud platform as described above, and details are not repeated here.

[0049] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the application. BRIEF DESCRIPTION OF DRAWINGS

[0050] The accompanying drawings incorporated in and forming a part of the specification, illustrate embodiments consistent with the application and serve to explain the principles of the application together with the description.

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0052] Figure 1 A flowchart of a method for cross-version hot upgrade based on an OpenStack cloud platform provided by the embodiments of the application;

[0053] Figure 2 A structural diagram of a system for cross-version hot upgrade based on an OpenStack cloud platform provided by the embodiments of the application. DETAILED DESCRIPTION

[0054] In order to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described in the following with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without any creative work should fall into the protection scope of the present application.

[0055] In order to better understand the present application, the embodiments of the present application will be explained in detail in the following with reference to the accompanying drawings.

[0056] Embodiment one

[0057] Referring to Figure 1 , Figure 1 The flowchart of a method for cross-version hot upgrade based on an OpenStack cloud platform provided by the embodiments of the present application. The method comprises the following steps of: Figure 1 It can be known that the method for cross-version hot upgrade based on the OpenStack cloud platform in the embodiments mainly comprises the following processes:

[0058] S1: Backup the business running database of the OpenStack environment to be upgraded and the OpenStack cloud platform configuration parameters. The OpenStack environment to be upgraded corresponds to the OpenStack version to be upgraded, and the OpenStack cloud platform configuration parameters include: / etc / kolla / config / directory, globals.yml file, multinode file, passwords.yml file, deployment directory and container image registry private library file. The deployment directory is / usr / share / kolla-ansible / .

[0059] S2: Import the container image of the target OpenStack version into the current image warehouse, and the current image warehouse includes the container image of the OpenStack version to be upgraded.

[0060] The private library management is realized through step S2, so as to ensure that there are both old version images and new version images in the image warehouse.

[0061] S3: According to the identified target OpenStack version, install the basic package matched with the target OpenStack version.

[0062] Specifically, step S3 comprises:

[0063] S31: Install kolla-ansible base dependency package according to the identified target OpenStack version.

[0064] S32: Upgrade docker base package according to the identified target OpenStack version.

[0065] In this embodiment, when installing and upgrading the base package, according to the identified different OpenStack versions, the corresponding kolla-ansible base dependency package and docker base package are automatically installed online, which can effectively save time and improve the efficiency of OpenStack cross-version upgrade.

[0066] S4: Merge kolla-ansible deployment code by covering the deployment directory of the OpenStack version to be upgraded.

[0067] Specifically, the kolla-ansible deployment code of the new version is decompressed and installed, covering the original deployment directory, so that the deployment code is merged.

[0068] S5: Customize and modify OpenStack cloud platform configuration parameters according to the component differences between the OpenStack version to be upgraded and the target OpenStack version.

[0069] Specifically, step S5 includes:

[0070] S51: Modify the globals.yml file of the OpenStack environment to be upgraded, delete the components that are no longer maintained, and add new components that match the target OpenStack version.

[0071] S52: Add password configuration of new components that match the target OpenStack version in the passwords.yml file.

[0072] S53: Modify the multinode file according to the multinode file of the target OpenStack version.

[0073] Since there are differences in components between the new version and the old version, through the above steps S51-S53, the upgrade tool will automatically modify the globals.yml file of the old version according to the identified OpenStack version to be upgraded, remove the components that are no longer maintained, and add new components, thereby saving space and improving upgrade efficiency. The multinode file is copied from the new version deployment directory and modified according to the old file to avoid missing new components and ensure the accuracy and efficiency of OpenStack cross-version upgrade.

[0074] S6: Perform target OpenStack version upgrade according to the customized modified OpenStack cloud platform configuration parameters.

[0075] In practical applications, the upgrade between different versions can be practiced multiple times to perfect the support of the upgrade tool for different versions, and finally realize the automatic upgrade of each openstack version from a low version to a high version.

[0076] Further, after step S5, step S7 is further included: judging whether there is an upgrade error in the component deployment process.

[0077] If there is an upgrade error in the component deployment process, step S8 is executed: modifying the upgrade error and re-deploying the component. If there is no upgrade error in the component deployment process, step S6 is continued to be executed: performing target OpenStack version upgrade according to the customized modified OpenStack cloud platform configuration parameters.

[0078] Specifically, step S8 includes the following processes:

[0079] S81: If the 443 port is occupied in the haproxy component deployment process, the occupied process is queried and killed, and the haproxy component is re-deployed.

[0080] That is, if the haproxy component is upgraded, the haproxy_skyline.pem is copied to the / etc / kolla / config / haproxy / directory before deployment. If the 443 port is occupied during deployment, the occupied process is queried and killed, and the component is re-deployed. The method of killing the occupied process is to execute the command kill-9 process number in the operating system.

[0081] S82: If a branch error occurs in the neutron component deployment process, the version number is rolled back in the business running database of the OpenStack environment to be upgraded, and the neutron component is re-deployed.

[0082] S83: If the upgrade error is a pluto monitoring error, the pluto container is deleted and the pluto component is re-deployed.

[0083] Through the above steps S81-S83, the component can be automatically modified and deployed according to different situations, thereby further improving the upgrade efficiency.

[0084] The method of re-performing component deployment in this embodiment is to upgrade multiple components one by one or to perform full upgrade on multiple components. That is, multiple execution methods are defined by the upgrade tool, and when the component upgrade fails, full upgrade or one-by-one upgrade is selected according to the situation. The OpenStack cross-version upgrade is diversified and more flexible.

[0085] By using the method for cross-version hot upgrade of the OpenStack cloud platform in this embodiment, a one-key hot upgrade tool can be written in actual application, so that the problem of difficult upgrade across OpenStack versions can be effectively solved. For example, the hot upgrade from ICOS554 to ICOS81 can be simply and quickly realized, and the corresponding OpenStack version upgrade is from O version to R version. According to the method in this embodiment, project delivery personnel can operate the upgrade as long as they have a certain basis of kolla-ansible and openstack, which can greatly reduce the difficulty and threshold of upgrade operation, and is convenient for popularization and application. For the upgrade between different versions, multiple upgrade tools can be written, or different versions of upgrade can be simultaneously compatible in the same upgrade tool.

[0086] Embodiment Two

[0087] In Figure 1 the basis of the embodiments shown in Figure 2 , Figure 2 is a structural schematic diagram of a system for cross-version hot upgrade of the OpenStack cloud platform provided by the embodiments of the present application.

[0088] by Figure 2It can be known that the system for cross-version hot upgrade based on the OpenStack cloud platform in the embodiment mainly comprises a backup module, a private library management module, a basic package installation and upgrade module, a deployment code merging module, a configuration parameter modification module, and an upgrade module. The backup module is configured to backup the business operation database of the OpenStack environment to be upgraded and the OpenStack cloud platform configuration parameters. The OpenStack environment to be upgraded corresponds to an OpenStack version to be upgraded. The OpenStack cloud platform configuration parameters include the / etc / kolla / config / directory, the globals.yml file, the multinode file, the passwords.yml file, the deployment directory, and the container image registry private library file. The private library management module is configured to import the container image of the target OpenStack version into the current image warehouse. The current image warehouse includes the container image of the OpenStack version to be upgraded. The basic package installation and upgrade module is configured to install and upgrade the basic package matched with the target OpenStack version according to the identified target OpenStack version. The deployment code merging module is configured to merge the kolla-ansible deployment code by covering the deployment directory of the OpenStack version to be upgraded. The configuration parameter modification module is configured to customize and modify the OpenStack cloud platform configuration parameters according to the component differences between the OpenStack version to be upgraded and the target OpenStack version. The upgrade module is configured to upgrade the target OpenStack version according to the customized and modified OpenStack cloud platform configuration parameters.

[0089] Further, the system further comprises a verification module configured to determine whether there is an upgrade error in the component deployment process. If yes, the upgrade error is modified and the component deployment is performed again. If no, the next step is continued to be executed.

[0090] The verification module comprises a first verification unit, a second verification unit, and a third verification unit. The first verification unit is configured to, for example, when the 443 port is occupied in the deployment process of the haproxy component, query and kill the occupied process, and then redeploy the haproxy component. The second verification unit is configured to, when a branch error occurs in the deployment process of the neutron component, rollback the version number in the business operation database of the OpenStack environment to be upgraded, and then redeploy the neutron component. The third verification unit is configured to, when the upgrade error is a pluto monitoring error, delete the pluto container and then redeploy the pluto component.

[0091] The first, second and third check units in the embodiment can upgrade the plurality of components one by one and individually, or can upgrade the plurality of components in full amount when re-deploying the component.

[0092] Further, the configuration parameter modification module comprises a globals.yml file modification unit, a passwords.yml file modification unit and a multinode file modification unit. The globals.yml file modification unit is configured to modify the globals.yml file of the OpenStack environment to be upgraded, delete components no longer maintained, and add new components matching the target OpenStack version. The passwords.yml file modification unit is configured to add password configurations of new components matching the target OpenStack version in the passwords.yml file. The multinode file modification unit is configured to modify the multinode file according to the multinode file of the target OpenStack version.

[0093] The base package installation and upgrade module comprises a base package installation unit and a base package upgrade unit. The base package installation unit is configured to install the kolla-ansible base dependency package according to the target OpenStack version identified. The base package upgrade unit is configured to upgrade the docker base package according to the target OpenStack version identified.

[0094] The system for cross-version hot upgrade based on the OpenStack cloud platform in the embodiment can be implemented in the form of an upgrade tool. When performing cross-version upgrade of OpenStack, only the one-key upgrade tool needs to be executed to complete the upgrade. The upgrade tool can realize online upgrade of the OpenStack cloud platform across versions, does not affect the normal operation of the virtual machine, and is conducive to improving the upgrade efficiency.

[0095] The parts not described in detail in the embodiment can be referred to in the embodiments shown in Figure 1 The two embodiments can be referred to each other, and will not be described here.

[0096] Embodiment three

[0097] The application also provides a terminal, comprising a processor and a memory connected with the processor in communication, wherein the memory stores instructions executable by the processor, and the instructions are executed by the processor to enable the processor to perform the method for cross-version hot upgrade based on the OpenStack cloud platform.

[0098] The method for cross-version hot upgrade of an OpenStack cloud platform performed by the processor is as follows:

[0099] 1) Backup the service running database of the OpenStack environment to be upgraded and the OpenStack cloud platform configuration parameters, wherein the OpenStack environment to be upgraded corresponds to an OpenStack version to be upgraded, and the OpenStack cloud platform configuration parameters include: a / etc / kolla / config / directory, a globals.yml file, a multinode file, a passwords.yml file, a deployment directory, and a container image registry private library file.

[0100] 2) Import the container image of the target OpenStack version into the current image warehouse, wherein the current image warehouse includes the container image of the OpenStack version to be upgraded.

[0101] 3) According to the identified target OpenStack version, install the base package matched with the target OpenStack version.

[0102] 4) Merge the kolla-ansible deployment code by covering the deployment directory of the OpenStack version to be upgraded.

[0103] 5) According to the component difference between the OpenStack version to be upgraded and the target OpenStack version, customize and modify the OpenStack cloud platform configuration parameters.

[0104] 6) Determine whether there is an upgrade error in the component deployment process.

[0105] 7) If there is an upgrade error in the component deployment process, modify the upgrade error and re-deploy the components, and then continue to the next step.

[0106] Specifically, there are three cases: if the 443 port is occupied during the deployment of the haproxy component, the occupied process is queried and killed, and the haproxy component is re-deployed; if a branch error occurs during the deployment of the neutron component, the version number is rolled back in the service running database of the OpenStack environment to be upgraded, and the neutron component is re-deployed; if the upgrade error is a pluto monitoring error, the pluto container is deleted and the pluto component is re-deployed.

[0107] 8) If there is no upgrade error in the component deployment process, directly execute the next step.

[0108] 9) Perform target OpenStack version upgrade according to customized modified OpenStack cloud platform configuration parameters.

[0109] The parts not described in detail in this embodiment can be referred to the embodiments shown in Figure 1 and Figure 2 The two embodiments can be referred to each other, and will not be described here again.

[0110] The above description is merely that of specific embodiments of the present application, to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other embodiments without departing from the spirit or scope of the application. Accordingly, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for cross-version hot upgrade based on the OpenStack cloud platform, characterized in that, The method includes: Back up the business operation database and OpenStack cloud platform configuration parameters of the OpenStack environment to be upgraded. The OpenStack environment to be upgraded corresponds to the OpenStack version to be upgraded. The OpenStack cloud platform configuration parameters include: the / etc / kolla / config / directory, the globals.yml file, the multinode file, the passwords.yml file, the deployment directory, and the container image registry private repository file. Import the container image of the target OpenStack version into the current image repository, which includes container images of the OpenStack version to be upgraded. Based on the identified target OpenStack version, install and upgrade the base packages that match the target OpenStack version; By overwriting the deployment directory of the OpenStack version to be upgraded, the kolla-ansible deployment code is merged. Based on the component differences between the OpenStack version to be upgraded and the target OpenStack version, the OpenStack cloud platform configuration parameters are customized and modified. Upgrade the target OpenStack version based on the customized OpenStack cloud platform configuration parameters.

2. The method for cross-version hot upgrade based on the OpenStack cloud platform according to claim 1, characterized in that, Based on the component differences between the OpenStack version to be upgraded and the target OpenStack version, after customizing the OpenStack cloud platform configuration parameters, the method further includes: Determine if there are any upgrade errors during component deployment; If so, modify the code to address the upgrade error and redeploy the components; If not, proceed to the next step.

3. The method for cross-version hot upgrade based on the OpenStack cloud platform according to claim 2, characterized in that, The steps to modify and redeploy components in response to upgrade errors include: If port 443 is occupied during the deployment of the HAProxy component, check and kill the process occupying the port, and then redeploy the HAProxy component. If a branch error occurs during the deployment of the neutron component, revert the version number in the business runtime database of the OpenStack environment to be upgraded, and redeploy the neutron component. If the upgrade error is a pluto monitoring error, delete the pluto container and redeploy the pluto components.

4. The method for cross-version hot upgrade based on the OpenStack cloud platform according to claim 2, characterized in that, The methods for redeploying components are either to upgrade each component individually or to perform a full upgrade of all components.

5. The method for cross-version hot upgrade based on the OpenStack cloud platform according to claim 1, characterized in that, The process of customizing OpenStack cloud platform configuration parameters based on component differences between the OpenStack version to be upgraded and the target OpenStack version includes: Modify the globals.yml file of the OpenStack environment to be upgraded, remove components that are no longer maintained, and add new components that match the target OpenStack version; Add password configurations for the new components in the passwords.yml file that match the target OpenStack version; Modify the multinode file according to the target OpenStack version.

6. The method for cross-version hot upgrade based on the OpenStack cloud platform according to claim 1, characterized in that, The step of installing and upgrading the base package that matches the identified target OpenStack version includes: Install the kolla-ansible base dependencies based on the identified target OpenStack version; Upgrade the Docker base package based on the identified target OpenStack version.

7. A system for cross-version hot upgrade based on the OpenStack cloud platform, characterized in that, The system includes: The backup module is used to back up the business operation database and OpenStack cloud platform configuration parameters of the OpenStack environment to be upgraded. The OpenStack environment to be upgraded corresponds to the OpenStack version to be upgraded. The OpenStack cloud platform configuration parameters include: the / etc / kolla / config / directory, the globals.yml file, the multinode file, the passwords.yml file, the deployment directory, and the container image registry private repository file. The private repository management module is used to import container images of the target OpenStack version into the current image repository, which includes container images of the OpenStack version to be upgraded. The base package installation and upgrade module is used to install and upgrade base packages that match the identified target OpenStack version. The deployment code merging module is used to merge kolla-ansible deployment code by overwriting the deployment directory of the OpenStack version to be upgraded; The configuration parameter modification module is used to customize and modify the OpenStack cloud platform configuration parameters based on the component differences between the OpenStack version to be upgraded and the target OpenStack version. The upgrade module is used to upgrade the target OpenStack version based on the customized OpenStack cloud platform configuration parameters.

8. A system for cross-version hot upgrade based on the OpenStack cloud platform according to claim 7, characterized in that, The system also includes: The verification module is used to determine whether there are upgrade errors during component deployment. If so, the upgrade error is corrected and the component is redeployed. If not, proceed to the next step.

9. A system for cross-version hot upgrade based on the OpenStack cloud platform according to claim 8, characterized in that, The verification module includes: The first verification unit is used to query and kill the process occupying port 443 during the deployment of the HAProxy component, and then redeploy the HAProxy component. The second verification unit is used to roll back the version number in the business runtime database of the OpenStack environment to be upgraded and redeploy the neutron component when a branch error occurs during the deployment of the neutron component. The third verification unit is used to delete the pluto container and redeploy the pluto component when the upgrade error is a pluto monitoring error.

10. A terminal, characterized in that, The terminal includes: a processor and a memory communicatively connected to the processor, wherein... The memory stores instructions that can be executed by the processor, which are then executed by the processor to enable the processor to perform the method for cross-version hot upgrade based on the OpenStack cloud platform as described in any one of claims 1 to 6.

Images