Shulou(Shulou.com)06/03 Report--

How to create and apply patches in patch StarlingX? This article focuses on patch fixes, that is, the creation of patches and application patches, reading the complete article, I believe you have a certain understanding of the creation of patches and application patches.

Create a patch

A StarlingX patch includes one or more rpm packages required for a system upgrade. Before you start creating patches, you need to verify that the RPM package is installed on the deployed StarlingX. The following steps can help us confirm.

There are two ways to determine the software version of a deployed system

Admin-> Platform on the horizon interface

-> System Configuration-> Systems

Use the command line system show

Controller-0:~$. / etc/platform/openrc

[sysadmin@controller-0 ~ (keystone_admin)] $system show

+-+

| | Property | Value |

+-+

| | contact | None |

| | created_at | 2019-10-14T03:10:50.862114+00:00 |

| | description | None |

| | https_enabled | False |

| | location | None |

| | name | 608dfe48-9a05-4b21-afc1-ea122574caa7 |

| | region_name | RegionOne |

| | sdn_enabled | False |

| | security_feature | spectre_meltdown_v1 |

| | service_project_name | services |

| | software_version | 19.09 |

| | system_mode | duplex |

| | system_type | All-in-one |

| | timezone | UTC |

| | updated_at | 2019-10-14T03:12:41.983029+00:00 |

| | uuid | 2639ad15-08a7-4f1b-a372-f927a5e4ab31 |

| | vswitch_type | none |

+-+

Check the latest build, find the rpm package that needs to be upgraded for this version, and select the required rpm to generate patches

Once you have identified the rpm packages that need to be upgraded / installed, the next step is to prepare the patch to build the environment. As StarlingX developers, the easiest way is to use the StarlingX Building container, we only need to make minor changes to the container. The StarlingX Building container can be generated using the build tutorial.

Now assuming that the source code for StarlingX has been downloaded and the rpm package that needs to be upgraded and installed is ready, let's start building a patch build environment. Again, this tutorial is aimed at developers, not products.

Install 2 cgcs-patch dependency packages, crypto and pycrypto

Sudo pip install crypto pycrypto

Use the script $MY_REPO/stx/stx-update/extras/scripts/patch_build.sh to create a patch.

In this script, it takes the PLATFORM_RELEASE parameter from the release-info.inc file and points the PYTHONPATH to the cgcs-patch package in repo, avoiding installing cgcs-patch and manually specifying the PLATFORM_RELEASE parameter. You can use the following command to view instructions for the use of the build script.

$MY_REPO/stx/stx-update/cgcs-patch/bin/patch_build-- helpUsage: patch_build []. Options:-id Patch ID-release Platform release version-status Patch Status Code (ie. O, R V)-unremovable Marks patch as unremovable-- reboot-required Marks patch as reboot-required (default=Y)-- summary Patch Summary-- desc Patch Description-- warn Patch Warnings-- inst Patch Install Instructions-- req Required Patch-- controller New package for controller-- worker New package for worker node-worker-lowlatency New package for worker-lowlatency node-storage New package for storage node-controller-worker New package for combined node-controller-worker-lowlatency New package for lowlatency combined node-all-nodes New package for all node types

Use this script to specify patch id, reboot required, depended patches, rpm list, and so on. If it is not available on the system, the newly installed package needs to specify a node, for example-- controller specifies that the new package is installed on the control node. After the script is executed, you can get a file named ".patch".

Let's take a closer look at this patch file.

First of all, the patch file is a gzip package. We can check it out with the file command.

$file 001.patch

001.patch: gzip compressed data, was "001.patch", last modified:

Fri Aug 16 05:56:59 2019, max compression

After unzipping it, you can see the following files

$tar-xf 001.patch

$tree

├── 001.patch

├── metadata.tar

├── signature

├── signature.v2

└── software.tar

Unpack the software.tar and you can find that it contains all the rpm packages that need to be installed. Note: all rpm packages are signed with the following key when the patch is built.

$MY_REPO/build-tools/signing/ima_signing_key.priv

There is only one file in metadata.tar, metadata.xml, that contains all the information about the patch build. The StarlingX cluster system reads this file information.

The signature file contains a combination of software.tar and metadata.tar 's MD5.

Signature.v2 is the signature file for software.tar and metadata.tar, which is generated by the $MY_REPO/build-tools/signing/dev-private-key.pemkey file in the current environment. Install the patch

After the patch is generated, you can manually install the patch to the specified StarlingX system, supporting both the interface and command line installation operations. The life cycle of a patch consists of four states: Available,Partial-Apply, Applied and Partial-Remove.

Available: indicates that the patch has been uploaded to the patch repository, but it has not yet reached the software upgrade repository, nor has it been installed on any host.

Partial-Apply: indicates that the patch upgrade has been sw-patch apply and has been installed on some hosts, but not on all the hosts that need to be installed.

Applied: indicates that the installation has been completed on all hosts that need to be installed.

Partial-Remove: indicates that the patch is being removed, triggered by the command (sw-patch remove), is being removed, but not completely removed.

If you need to install the patch from the command line, you need to copy the patch to the control node of active. The StarlingX cluster provides the client command sw-patch. Patch operations are done through this command, which provides a number of features, including upload, apply, query,host-install, delete, remove, and so on.

Controller-0:~$ sw-patch-- helpusage: sw-patch [--debug]... Subcomands: upload: Upload one or more patches to the patching system. Upload-dir: Upload patches from one or more directories to the patching system. Apply: Apply one or more patches. This adds the specified patches to the repository, making the update (s) available to the hosts in the system. Use-- all to apply all available patches. Patches are specified as a space-separated list of patch IDs. Remove: Remove one or more patches. This removes the specified patches from the repository. Patches are specified as a space-separated list of patch IDs. Delete: Delete one or more patches from the patching system. Patches are specified as a space-separated list of patch IDs. Query: Query system patches. Optionally, specify 'query applied' to query only those patches that are applied, or' query available' to query those that are not. Show: Show details for specified patches. What-requires: List patches that require the specified patches. Query-hosts: Query patch states for hosts in the system. Host-install: Trigger patch install/remove on specified host. To force install on unlocked node, use the-- force option. Host-install-async: Trigger patch install/remove on specified host. To force install on unlocked node, use the-- force option. Note: This command returns immediately upon dispatching installation request. Install-local: Trigger patch install/remove on the local host. This command can only be used for patch installation prior to initial configuration. Drop-host: Drop specified host from table. Query-dependencies: List dependencies for specified patch. Use-- recursive for recursive query. Is-applied: Query Applied state for list of patches. Returns True if all are Applied, False otherwise. Report-app-dependencies: Report application patch dependencies, specifying application name with-- app option, plus a list of patches. Reported dependencies can be dropped by specifying app with no patch list. Query-app-dependencies: Display set of reported application patch dependencies. Commit: Commit patches to free disk space. WARNING: This action is irreversible!-- os-region-name: Send the request to a specified region

The following demonstrates how to use this command to install patches. The patch used in the demonstration is the In-Service patch that needs to be installed on all hosts, and the StarlingX environment that needs to be upgraded is the standard environment of 2 / 2 / 2.

Upload patch file

Controller-0:~$ sudo sw-patch upload 001.patch

001 is now available

Check patch status

Controller-0:~$ sudo sw-patch query

Patch ID RR Release Patch State

=

001 N 19.09 Available

Check the upgrade status of all hosts

Controller-0:/$ sudo sw-patch query-hosts

Hostname IP Address Patch Current Reboot Required Release State

= =

Compute-0 192.178.204.7 Yes No 19.09 idle

Compute-1 192.178.204.9 Yes No 19.09 idle

Controller-0 192.178.204.3 Yes No 19.09 idle

Controller-1 192.178.204.4 Yes No 19.09 idle

Storage-0 192.178.204.12 Yes No 19.09 idle

Storage-1 192.178.204.11 Yes No 19.09 idle

Patch Current indicates whether the current host has a patch installed, Yes indicates that no patch is installed, and No indicates that at least one patch is being installed.

When the patch status available, you can trigger the patch installation

Controller-0:/$ sudo sw-patch apply 001

001 is now in the repo

Check patch status

Controller-0:~$ sudo sw-patch query

Patch ID RR Release Patch State

=

001 N 19.09 Partial-Apply

Check node status

Controller-0:~$ sudo sw-patch query-hosts

Hostname IP Address Patch Current Reboot Required Release State

= =

Compute-0 192.178.204.7 No No 19.09 idle

Compute-1 192.178.204.9 No No 19.09 idle

Controller-0 192.178.204.3 No No 19.09 idle

Controller-1 192.178.204.4 No No 19.09 idle

Storage-0 192.178.204.12 No No 19.09 idle

Storage-1 192.178.204.11 No No 19.09 idle

Patches are installed on each node, and since they are in-service patches, there is no need to perform lock operations.

Controller-0:~$ sudo sw-patch host-install controller-0

...

Installation was successful.

Check host upgrade status

Controller-0:~$ sudo sw-patch query-hosts

Hostname IP Address Patch Current Reboot Required Release State

= =

Compute-0 192.178.204.7 No No 19.09 idle

Compute-1 192.178.204.9 No No 19.09 idle

Controller-0 192.178.204.3 Yes No 19.09 idle

Controller-1 192.178.204.4 No No 19.09 idle

Storage-0 192.178.204.12 No No 19.09 idle

Storage-1 192.178.204.11 No No 19.09 idle

To install patches on all nodes, you need to execute commands for each node

Controller-0:~$ sudo sw-patch host-install controller-1

....

Installation was successful.

Controller-0:~$ sudo sw-patch host-install compute-0

....

Installation was successful.

Controller-0:~$ sudo sw-patch host-install compute-1

....

Installation was successful.

Controller-0:~$ sudo sw-patch host-install storage-0

...

Installation was successful.

Controller-0:~$ sudo sw-patch host-install storage-1

...

Installation was successful.

After all the nodes are finished, you can see the following status

Controller-0:~$ sudo sw-patch query

Patch ID RR Release Patch State

=

001 N 19.09 Applied

Controller-0:~$ sudo sw-patch query-hosts

Hostname IP Address Patch Current Reboot Required Release State

= =

Compute-0 192.178.204.7 Yes No 19.09 idle

Compute-1 192.178.204.9 Yes No 19.09 idle

Controller-0 192.178.204.3 Yes No 19.09 idle

Controller-1 192.178.204.4 Yes No 19.09 idle

Storage-0 192.178.204.12 Yes No 19.09 idle

Storage-1 192.178.204.11 Yes No 19.09 idle

At this point, the patch upgrade program is complete

In addition to patch upgrades, StarlingX also supports patch fallback and deletion, and sw-patch remove and sw-patch host-install are implemented through the following two commands, similar to patch installation.

Patch arrangement

In the above example, the ability to update patches in a cluster is demonstrated. But in large clusters, the whole upgrade process takes a long time. Reboot-required patches, in particular, can be bad, inefficient and bring a lot of work to administrators. So StarlingX provides another advanced feature, patch choreography. It supports the cluster to upgrade through some simple operations, greatly reducing the workload of administrators and fewer errors. This feature can be used in three ways: client CLI, interface Horizon, and VIM Restful API.

Client CLI. StarlingX provides a client tool, sw-manager, that can be used for patch orchestration. As shown below, you can upgrade the entire cluster by creating and applying patch policies

Controller-0:~$ sw-manager patch-strategy-h

Usage: sw-manager patch-strategy [- h]...

Optional arguments:

-h,-- help show this help message and exit

Software Patch Commands:

Create Create a strategy

Delete Delete a strategy

Apply Apply a strategy

Abort Abort a strategy

Show Show a strategy

Controller-0:~$ sw-manager patch-strategy create-h

Usage: sw-manager patch-strategy create [- h]

[--controller-apply-type {serial,ignore}]

[--storage-apply-type {serial,parallel,ignore}]

[--worker-apply-type {serial,parallel,ignore}]

[--max-parallel-worker-hosts {2, 3, 4, 5, 6, 7, 8, 9, 10

11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27

28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44

45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61

62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78

79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95

96,97,98,99100}]

[--instance-action {migrate,stop-start}]

[--alarm-restrictions {strict,relaxed}]

Optional arguments:

-h,-- help show this help message and exit

-- controller-apply-type {serial,ignore}

Defaults to serial

-- storage-apply-type {serial,parallel,ignore}

Defaults to serial

-- worker-apply-type {serial,parallel,ignore}

Defaults to serial

-- max-parallel-worker-hosts {2, 3, 4, 5, 6, 7, 8, 9, 11, 11, 12, 13, 14, 15, 16

17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36

37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56

57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76

77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96

97,98,99100}

Maximum worker hosts to patch in parallel

-- instance-action {migrate,stop-start}

Defaults to stop-start

-- alarm-restrictions {strict,relaxed}

Defaults to strict

Interface Horizon. Open Admin-> Platform

-> Software Management-> Patch Orchestration tag

VIM API .

+-+

| | Method | URI | Description | |

+ = +

| | Post | / api/orchestration/sw-update/strategy | Create a patch strategy | |

+-+

| | Delete | / api/orchestration/sw-update/strategy | Delete current patch | |

| | strategy |

+-+

| | Get | / api/orchestration/sw-update/strategy | Get detailed information of | |

| | current patch strategy |

+-+

| | Post | / api/orchestration/sw-update/strategy/ | Apply or abort a patch | |

| | actions | strategy |

+-+

When the patch is installed, the patch orchestration requires the cluster to be in a good state.

All hosts must be in the unlocked-enabled-available state

There is no alarm in the system

Enough space for VM migration

Current development status

All the source code is open source in the StarlingX repository, including "update" and "nfv"

The generation and installation of in-service and reboot-required patches have been verified

The patch choreography has not been verified

After reading this article, have you learned to create patches and apply patches? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.