PatchDeployment is the Schema for the PatchDeployments API. Patch deployments are configurations that individual patch jobs use to complete a patch.
Type
CRD
Group
osconfig.gcp.upbound.io
Version
v1beta1
apiVersion: osconfig.gcp.upbound.io/v1beta1
kind: PatchDeployment
PatchDeploymentSpec defines the desired state of PatchDeployment
No description provided.
VM instances to patch. Structure is documented below.
Targets VM instances matching ANY of these GroupLabels. This allows targeting of disparate groups of VM instances. Structure is documented below.
Targets VMs whose name starts with one of these prefixes. Similar to labels, this is another way to group VMs when targeting configs, for example prefix="prod-".
Targets any of the VM instances specified. Instances are specified by their URI in the form zones/{{zone}}/instances/{{instance_name}}, projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}, or https://www.googleapis.com/compute/v1/projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}
Targets VM instances in ANY of these zones. Leave empty to target VM instances in any zone.
Schedule a one-time execution. Structure is documented below.
Patch configuration that is applied. Structure is documented below.
Apt update settings. Use this setting to override the default apt patch rules. Structure is documented below.
List of packages to exclude from update.
An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.
goo update settings. Use this setting to override the default goo patch rules. Structure is documented below.
The ExecStep to run after the patch update. Structure is documented below.
The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStep to run before the patch update. Structure is documented below.
The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
Windows update settings. Use this setting to override the default Windows patch rules. Structure is documented below.
Only apply updates of these windows update classifications. If empty, all updates are applied. Each value may be one of: CRITICAL, SECURITY, DEFINITION, DRIVER, FEATURE_PACK, SERVICE_PACK, TOOL, UPDATE_ROLLUP, UPDATE.
List of packages to exclude from update.
An exclusive list of patches to be updated. These are the only patches that will be installed using 'zypper patch patch:' command. This field must not be used with any other patch configuration fields.
Yum update settings. Use this setting to override the default yum patch rules. Structure is documented below.
List of packages to exclude from update.
An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.
zypper update settings. Use this setting to override the default zypper patch rules. Structure is documented below.
Install only patches with these categories. Common categories include security, recommended, and feature.
List of packages to exclude from update.
An exclusive list of patches to be updated. These are the only patches that will be installed using 'zypper patch patch:' command. This field must not be used with any other patch configuration fields.
Install only patches with these severities. Common severities include critical, important, moderate, and low.
Schedule recurring executions. Structure is documented below.
Schedule with monthly executions. Structure is documented below.
Week day in a month. Structure is documented below.
Rollout strategy of the patch job. Structure is documented below.
The maximum number (or percentage) of VMs per zone to disrupt at any given moment. The number of VMs calculated from multiplying the percentage by the total number of VMs in a zone is rounded up. During patching, a VM is considered disrupted from the time the agent is notified to begin until patching has completed. This disruption time includes the time to complete reboot and any post-patch steps. A VM contributes to the disruption budget if its patching operation fails either when applying the patches, running pre or post patch steps, or if it fails to respond with a success notification before timing out. VMs that are not running or do not have an active agent do not count toward this disruption budget. For zone-by-zone rollouts, if the disruption budget in a zone is exceeded, the patch job stops, because continuing to the next zone requires completion of the patch process in the previous zone. For example, if the disruption budget has a fixed value of 10, and 8 VMs fail to patch in the current zone, the patch job continues to patch 2 VMs at a time until the zone is completed. When that zone is completed successfully, patching begins with 10 VMs at a time in the next zone. If 10 VMs in the next zone fail to patch, the patch job stops. Structure is documented below.
ProviderConfigReference specifies how the provider that will be used to create, observe, update, and delete this managed resource should be configured.
Policies for referencing.
ProviderReference specifies the provider that will be used to create, observe, update, and delete this managed resource. Deprecated: Please use ProviderConfigReference, i.e. providerConfigRef
Policies for referencing.
PublishConnectionDetailsTo specifies the connection secret config which contains a name, metadata and a reference to secret store config to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
WriteConnectionSecretToReference specifies the namespace and name of a Secret to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource. This field is planned to be replaced in a future release in favor of PublishConnectionDetailsTo. Currently, both could be set independently and connection details would be published to both without affecting each other.
PatchDeploymentStatus defines the observed state of PatchDeployment.
No description provided.
VM instances to patch. Structure is documented below.
Targets VM instances matching ANY of these GroupLabels. This allows targeting of disparate groups of VM instances. Structure is documented below.
Targets VMs whose name starts with one of these prefixes. Similar to labels, this is another way to group VMs when targeting configs, for example prefix="prod-".
Targets any of the VM instances specified. Instances are specified by their URI in the form zones/{{zone}}/instances/{{instance_name}}, projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}, or https://www.googleapis.com/compute/v1/projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}
Targets VM instances in ANY of these zones. Leave empty to target VM instances in any zone.
Schedule a one-time execution. Structure is documented below.
Patch configuration that is applied. Structure is documented below.
Apt update settings. Use this setting to override the default apt patch rules. Structure is documented below.
List of packages to exclude from update.
An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.
goo update settings. Use this setting to override the default goo patch rules. Structure is documented below.
The ExecStep to run after the patch update. Structure is documented below.
The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStep to run before the patch update. Structure is documented below.
The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.
Defaults to [0]. A list of possible return values that the execution can return to indicate a success.
A Cloud Storage object containing the executable. Structure is documented below.
Windows update settings. Use this setting to override the default Windows patch rules. Structure is documented below.
Only apply updates of these windows update classifications. If empty, all updates are applied. Each value may be one of: CRITICAL, SECURITY, DEFINITION, DRIVER, FEATURE_PACK, SERVICE_PACK, TOOL, UPDATE_ROLLUP, UPDATE.
List of packages to exclude from update.
An exclusive list of patches to be updated. These are the only patches that will be installed using 'zypper patch patch:' command. This field must not be used with any other patch configuration fields.
Yum update settings. Use this setting to override the default yum patch rules. Structure is documented below.
List of packages to exclude from update.
An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.
zypper update settings. Use this setting to override the default zypper patch rules. Structure is documented below.
Install only patches with these categories. Common categories include security, recommended, and feature.
List of packages to exclude from update.
An exclusive list of patches to be updated. These are the only patches that will be installed using 'zypper patch patch:' command. This field must not be used with any other patch configuration fields.
Install only patches with these severities. Common severities include critical, important, moderate, and low.
Schedule recurring executions. Structure is documented below.
Schedule with monthly executions. Structure is documented below.
Week day in a month. Structure is documented below.
Rollout strategy of the patch job. Structure is documented below.
The maximum number (or percentage) of VMs per zone to disrupt at any given moment. The number of VMs calculated from multiplying the percentage by the total number of VMs in a zone is rounded up. During patching, a VM is considered disrupted from the time the agent is notified to begin until patching has completed. This disruption time includes the time to complete reboot and any post-patch steps. A VM contributes to the disruption budget if its patching operation fails either when applying the patches, running pre or post patch steps, or if it fails to respond with a success notification before timing out. VMs that are not running or do not have an active agent do not count toward this disruption budget. For zone-by-zone rollouts, if the disruption budget in a zone is exceeded, the patch job stops, because continuing to the next zone requires completion of the patch process in the previous zone. For example, if the disruption budget has a fixed value of 10, and 8 VMs fail to patch in the current zone, the patch job continues to patch 2 VMs at a time until the zone is completed. When that zone is completed successfully, patching begins with 10 VMs at a time in the next zone. If 10 VMs in the next zone fail to patch, the patch job stops. Structure is documented below.
Conditions of the resource.
patpatch-deploymentch
apiVersion: osconfig.gcp.upbound.io/v1beta1
kind: PatchDeployment
metadata:
annotations:
meta.upbound.io/example-id: osconfig/v1beta1/patchdeployment
labels:
testing.upbound.io/example-name: patch-deployment
name: patpatch-deploymentch
spec:
forProvider:
instanceFilter:
- all: true
oneTimeSchedule:
- executeTime: 2999-10-10T10:10:10.045123456Z
© 2022 Upbound, Inc.
Discover the building blocksfor your internal cloud platform.