### Example install modes output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/olmv1-discovering-bundle-install-modes.adoc

This example output shows the install modes supported by a bundle. In this case, `OwnNamespace` and `SingleNamespace` are supported.

```json
[
  {
    "type": "OwnNamespace",
    "supported": true
  },
  {
    "type": "SingleNamespace",
    "supported": true
  },
  {
    "type": "MultiNamespace",
    "supported": false
  },
  {
    "type": "AllNamespaces",
    "supported": false
  }
]
```

--------------------------------

### Example Install Plan Output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/nw-metalLB-basic-upgrade-operator.adoc

Example output showing a manual install plan that requires approval. Note the `APPROVAL` and `APPROVED` columns.

```terminal
NAME            CSV                                     APPROVAL    APPROVED
install-shpmd   metallb-operator.v{product-version}.0-202502261233   Automatic   true
install-tsz2g   metallb-operator.v{product-version}.0-202503102139   Manual      false
```

--------------------------------

### Example: Install {op-system} on /dev/sda

Source: https://github.com/openshift/openshift-docs/blob/main/modules/machine-user-infra-machines-iso.adoc

An example of using `coreos-installer` to install {op-system} on the `/dev/sda` device. It specifies an HTTP server for the Ignition config file and includes a sample SHA512 digest for validation.

```bash
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/worker.ign /dev/sda --ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
```

--------------------------------

### Installation Output Example

Source: https://github.com/openshift/openshift-docs/blob/main/modules/authentication-kubeadmin.adoc

This output shows example information provided after OpenShift installation, including how to set up KUBECONFIG, log in with the kubeadmin user, and access the web console.

```terminal
INFO Install complete!
INFO Run 'export KUBECONFIG=<your working directory>/auth/kubeconfig' to manage the cluster with 'oc', the OpenShift CLI.
INFO The cluster is ready when 'oc login -u kubeadmin -p <provided>' succeeds (wait a few minutes).
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.demo1.openshift4-beta-abcorp.com
INFO Login to the console with user: kubeadmin, password: <provided>
```

--------------------------------

### Example Output for Installation Status

Source: https://github.com/openshift/openshift-docs/blob/main/modules/serverless-install-eventing-yaml.adoc

This is an example of the expected output when verifying the Knative Eventing installation status, indicating a successful deployment.

```bash
InstallSucceeded=True
Ready=True
```

--------------------------------

### Example Pod output during installation

Source: https://github.com/openshift/openshift-docs/blob/main/modules/ossm-control-plane-deploy-1x.adoc

Example output showing the status of Pods during the {SMProductName} control plane installation. This helps in observing the deployment progress.

```terminal
NAME                                     READY   STATUS             RESTARTS   AGE
grafana-7bf5764d9d-2b2f6                 2/2     Running            0          28h
istio-citadel-576b9c5bbd-z84z4           1/1     Running            0          28h
istio-egressgateway-5476bc4656-r4zdv     1/1     Running            0          28h
istio-galley-7d57b47bb7-lqdxv            1/1     Running            0          28h
istio-ingressgateway-dbb8f7f46-ct6n5     1/1     Running            0          28h
istio-pilot-546bf69578-ccg5x             2/2     Running            0          28h
```

--------------------------------

### Example: Initialize Bootstrap Node Installation (Standard)

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installation-user-infra-machines-iso.adoc

An example command to initialize a bootstrap node installation on the /dev/sda device using a specific Ignition config file from an HTTP server. This is the standard command for this scenario.

```terminal
$ sudo coreos-installer install --ignition-url=http://192.168.1.2:80/installation_directory/bootstrap.ign /dev/sda \
--ignition-hash=sha512-a5a2d43879223273c9b60af66b44202a1d1248fc01cf156c46d4a79f552b6bad47bc8cc78ddf0116e80c59d2ea9e32ba53bc807afbca581aa059311def2c3e3b
```

--------------------------------

### Example output of manifest creation

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installing-private-image-registry-private-azure.adoc

This is an example of the messages displayed after successfully creating installation manifest files.

```terminal
INFO Consuming Install Config from target directory
INFO Manifests created in: <installation_directory>/manifests and <installation_directory>/openshift
```

--------------------------------

### Example installation completion output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/install-sno-installing-with-agent-based-installer.adoc

Example output indicating that the cluster installation is complete. It provides instructions for accessing the cluster using `oc` and the web console.

```terminal
...................................................................
INFO Cluster is installed
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=~/<install_directory>/auth/kubeconfig
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.<cluster_name>.<domain>
```

--------------------------------

### Kubernetes RawExtension Example

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/objects/index.adoc

Demonstrates how to use RawExtension for handling external versions and plugins in Kubernetes API objects. It shows the structure for both internal and external packages, and an example of the resulting JSON.

```go
// Internal package:

type MyAPIObject struct {
	runtime.TypeMeta `json:",inline"
	MyPlugin runtime.Object `json:"myPlugin"
}

type PluginA struct {
	AOption string `json:"aOption"
}

// External package:

type MyAPIObject struct {
	runtime.TypeMeta `json:",inline"
	MyPlugin runtime.RawExtension `json:"myPlugin"
}

type PluginA struct {
	AOption string `json:"aOption"
}

// On the wire, the JSON will look something like this:

/*
	{
		"kind":"MyAPIObject",
		"apiVersion":"v1",
		"myPlugin": {
			"kind":"PluginA",
			"aOption":"foo",
		},
	}
*/

// So what happens? Decode first uses json or yaml to unmarshal the serialized data into your external MyAPIObject. That causes the raw JSON to be stored, but not unpacked. The next step is to copy (using pkg/conversion) into the internal struct. The runtime package's DefaultScheme has conversion functions installed which will unpack the JSON stored in RawExtension, turning it into the correct object type, and storing it in the Object. (TODO: In the case where the object is of an unknown type, a runtime.Unknown object will be created and stored.)
```

--------------------------------

### Example Output of 'oc get csv -A'

Source: https://github.com/openshift/openshift-docs/blob/main/modules/update-ensuring-that-layered-products-are-compatible.adoc

This is an example of the output you might see when running the 'oc get csv -A' command, showing installed Operators, their versions, and status.

```terminal
NAMESPACE                              NAME            DISPLAY          VERSION   REPLACES                             PHASE
gitlab-operator-kubernetes.v0.17.2     GitLab                           0.17.2    gitlab-operator-kubernetes.v0.17.1   Succeeded
openshift-operator-lifecycle-manager   packageserver   Package Server   0.19.0                                         Succeeded
```

--------------------------------

### Example Output of oc get nodes

Source: https://github.com/openshift/openshift-docs/blob/main/modules/install-sno-monitoring-the-installation-manually.adoc

This is an example of the expected output when running `oc get nodes` after a successful installation, showing the status, roles, age, and version of the control plane node.

```terminal
NAME                         STATUS   ROLES           AGE     VERSION
control-plane.example.com    Ready    master,worker   10m     v1.35.4
```

```terminal
NAME                         STATUS   ROLES           AGE     VERSION
control-plane.example.com    Ready    master,worker   10m     v1.27.9+e36e183
```

--------------------------------

### Example DNS record for bare metal installation

Source: https://github.com/openshift/openshift-docs/blob/main/installing/installing_bare_metal/upi/installing-bare-metal.adoc

This example shows a typical DNS A record configuration for a bare metal installation. Ensure that the IP address and hostname match your environment's setup.

```text
api-int.your-cluster.your-domain.com. IN A 192.168.1.100
```

--------------------------------

### View Quick Start API Documentation

Source: https://github.com/openshift/openshift-docs/blob/main/modules/contributing-quick-starts.adoc

Access the API documentation for ConsoleQuickStart resources using the `oc explain` command. This helps in understanding the structure and available fields for the custom resource.

```terminal
$ oc explain consolequickstarts
```

--------------------------------

### Agent Status After Node Start

Source: https://github.com/openshift/openshift-docs/blob/main/modules/hcp-bm-hosts.adoc

Example output showing agents in the namespace after nodes have started. These agents represent nodes available for installation.

```terminal
NAMESPACE         NAME                                   CLUSTER   APPROVED   ROLE          STAGE
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412             true       auto-assign
clusters-hosted   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413             true       auto-assign
```

--------------------------------

### Readiness Probe HTTP GET Configuration

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.adoc

Defines the HTTP GET probe configuration for readiness checks within ephemeral containers.

```APIDOC
## .spec.install.spec.deployments[].spec.template.spec.ephemeralContainers[].readinessProbe.httpGet

### Description
HTTPGet specifies an HTTP GET request to perform.

### Type
`object`

### Properties
#### host (string)
- Required: No
- Description: Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead.

#### httpHeaders (array)
- Required: No
- Description: Custom headers to set in the request. HTTP allows repeated headers.

#### path (string)
- Required: No
- Description: Path to access on the HTTP server.

#### port (integer-or-string)
- Required: Yes
- Description: Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME.

#### scheme (string)
- Required: No
- Description: Scheme to use for connecting to the host. Defaults to HTTP.
```

--------------------------------

### Example Output for oc get csv

Source: https://github.com/openshift/openshift-docs/blob/main/modules/eco-self-node-remediation-operator-installation-cli.adoc

This is an example of the expected output when verifying the CSV resource for the Self Node Remediation Operator, indicating a successful installation.

```terminal
NAME                               DISPLAY                          VERSION   REPLACES   PHASE
self-node-remediation.v.0.4.0      Self Node Remediation Operator   v.0.4.0              Succeeded
```

--------------------------------

### Create install.ks kickstart file

Source: https://github.com/openshift/openshift-docs/blob/main/modules/virt-creating-bootable-encrypted-ibm-secure-execution-vm-image-ibm-z.adoc

Create the install.ks kickstart file on a trusted instance. This file configures the installation process, including disk partitioning and encryption.

```bash
[trusted instance ~]
text
lang en_US.UTF-8
keyboard us 
network --bootproto=dhcp 
rootpw --plaintext <password>
timezone <>
firewall --enabled
selinux --enforcing
bootloader --location=mbr
reboot   

# Wipe and partition the disk
clearpart --all --initlabel 
zerombr  

# /boot gets encrypted on post reboot
part /boot --fstype ext4 --size=512 --label=boot  
# Root (/) is LUKS-encrypted 
part / --fstype xfs --size=3000 --pbkdf=pbkdf2 --encrypted --passphrase <passphrase>
```

--------------------------------

### HTTPGet Configuration

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc

Specifies an HTTP GET request to perform for readiness or liveness probes.

```APIDOC
## HTTPGet Configuration

### Description
HTTPGet specifies an HTTP GET request to perform.

### Properties

| Property | Type | Description |
|---|---|---|
| `host` | `string` | Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. |
| `httpHeaders` | `array` | Custom headers to set in the request. HTTP allows repeated headers. |
| `path` | `string` | Path to access on the HTTP server. |
| `port` | `integer-or-string` | Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. |
| `scheme` | `string` | Scheme to use for connecting to the host. Defaults to HTTP. |

### HTTPHeader Object

| Property | Type | Description |
|---|---|---|
| `name` | `string` | The header field name. This will be canonicalized upon output, so case-variant names will be understood as the same header. |
| `value` | `string` | The header field value |

```

--------------------------------

### Example CSV Output Showing Succeeded Phase

Source: https://github.com/openshift/openshift-docs/blob/main/modules/serverless-install-cli.adoc

This is an example output of the `oc get csv` command, illustrating a successfully installed Serverless Operator with its version and status.

```yaml
NAME                          DISPLAY                       VERSION   REPLACES                      PHASE
serverless-operator.v1.25.0   Red Hat OpenShift Serverless   1.25.0    serverless-operator.v1.24.0   Succeeded
```

--------------------------------

### Create a new project

Source: https://github.com/openshift/openshift-docs/blob/main/modules/albo-validate-install.adoc

Initiates a new project named 'hello-world' to host the sample application and its resources.

```terminal
$ oc new-project hello-world
```

--------------------------------

### ClusterServiceVersion Spec InstallModes

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.adoc

InstallModes specify supported installation types.

```APIDOC
## spec.installModes

### Description
InstallModes specify supported installation types.

### Type
`array`

### Items
#### spec.installModes[]

### Description
InstallMode associates an InstallModeType with a flag representing if the CSV supports it.

### Type
`object`

### Required
- `supported`
- `type`

### Properties
#### `supported`
- **Type**: `boolean`
- **Description**: 

#### `type`
- **Type**: `string`
- **Description**: InstallModeType is a supported type of install mode for CSV installation
```

--------------------------------

### Example Node Status Output (Standard)

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installation-approve-csrs.adoc

This is an example of the expected output when running 'oc get nodes' on a standard OpenShift installation. All listed nodes should display 'Ready' status.

```terminal
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.35.4
master-1  Ready     master  73m  v1.35.4
master-2  Ready     master  74m  v1.35.4
worker-0  Ready     worker  11m  v1.35.4
worker-1  Ready     worker  11m  v1.35.4
```

--------------------------------

### spec.initContainers[].lifecycle.preStop.httpGet

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/monitoring_apis/prometheus-monitoring-coreos-com-v1.adoc

HTTPGet specifies an HTTP GET request to perform.

```APIDOC
## spec.initContainers[].lifecycle.preStop.httpGet

### Description
HTTPGet specifies an HTTP GET request to perform.

### Type
`object`

### Required
- `port`

### Properties
#### `host` (string)
Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead.

#### `httpHeaders` (array of objects)
Custom headers to set in the request. HTTP allows repeated headers.

##### `httpHeaders[]` (object)
HTTPHeader describes a custom header to be used in HTTP probes

- **name** (string) - The header field name.
This will be canonicalized upon output, so case-variant names will be understood as the same header.
- **value** (string) - The header field value

#### `path` (string)
Path to access on the HTTP server.

#### `port` (integer-or-string)
Name or number of the port to access on the container.
Number must be in the range 1 to 65535.
Name must be an IANA_SVC_NAME.

#### `scheme` (string)
Scheme to use for connecting to the host.
Defaults to HTTP.
```

--------------------------------

### ClusterServiceVersion Spec Install Spec Permissions

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.adoc

Permissions describe the rbac rules and service account needed by the install strategy.

```APIDOC
## spec.install.spec.permissions

### Description
StrategyDeploymentPermissions describe the rbac rules and service account needed by the install strategy.

### Type
`array`

### Items
#### spec.install.spec.permissions[]

### Description
StrategyDeploymentPermissions describe the rbac rules and service account needed by the install strategy.

### Type
`object`

### Required
- `rules`
- `serviceAccountName`

### Properties
#### `rules`
- **Type**: `array`
- **Description**: 

#### `rules[]`
- **Type**: `object`
- **Description**: PolicyRule holds information that describes a policy rule, but does not contain information about who the rule applies to or which namespace the rule applies to.

#### `serviceAccountName`
- **Type**: `string`
- **Description**: 

### spec.install.spec.permissions[].rules

#### Description

#### Type
`array`

### spec.install.spec.permissions[].rules[]

#### Description
PolicyRule holds information that describes a policy rule, but does not contain information about who the rule applies to or which namespace the rule applies to.

#### Type
`object`

#### Required
- `verbs`

#### Properties
##### `apiGroups`
- **Type**: `array (string)`
- **Description**: APIGroups is the name of the APIGroup that contains the resources. If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed. "" represents the core API group and "*" represents all API groups.

##### `nonResourceURLs`
- **Type**: `array (string)`
- **Description**: NonResourceURLs is a set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path. Since non-resource URLs are not namespaced, this field is only applicable for ClusterRoles referenced from a ClusterRoleBinding. Rules can either apply to API resources (such as "pods" or "secrets") or non-resource URL paths (such as "/api"), but not both.

##### `resourceNames`
- **Type**: `array (string)`
- **Description**: ResourceNames is an optional white list of names that the rule applies to. An empty set means that everything is allowed.

##### `resources`
- **Type**: `array (string)`
- **Description**: Resources is a list of resources this rule applies to. '*' represents all resources.

##### `verbs`
- **Type**: `array (string)`
- **Description**: Verbs is a list of Verbs that apply to ALL the ResourceKinds contained in this rule. '*' represents all verbs.
```

--------------------------------

### Preserve Partitions from Index Onwards (PXE Installation)

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installation-user-infra-machines-advanced-retain-disk.adoc

For PXE installations, use the `coreos.inst.save_partindex` kernel parameter with a range to preserve partitions starting from a specific index. This example preserves partitions 5 and higher.

```bash
coreos.inst.save_partindex=5-
```

--------------------------------

### Get network configuration

Source: https://github.com/openshift/openshift-docs/blob/main/modules/ipi-install-troubleshooting-misc-issues.adoc

Retrieve the cluster network configuration to verify if the installation program created it. This is useful when diagnosing issues with network setup.

```terminal
$ kubectl get network.config.openshift.io cluster -oyaml
```

```yaml
apiVersion: config.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  serviceNetwork:
  - 172.30.0.0/16
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  networkType: OVNKubernetes
```

--------------------------------

### Start Host Installation

Source: https://github.com/openshift/openshift-docs/blob/main/modules/ai-adding-worker-nodes-to-cluster.adoc

Initiate the installation process for a specific host using the assisted-service API. This command sends a POST request to the install action endpoint.

```bash
$ curl -X POST -s "$API_URL/api/assisted-install/v2/infra-envs/$INFRA_ENV_ID/hosts/$HOST_ID/actions/install"  -H "Authorization: Bearer ${JWT_TOKEN}"
```

--------------------------------

### livenessProbe.httpGet

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.adoc

HTTPGet specifies an HTTP GET request to perform.

```APIDOC
## livenessProbe.httpGet

### Description
HTTPGet specifies an HTTP GET request to perform.

### Type
`object`

### Required
- `port`

### Properties

#### `host` (string)
Host name to connect to, defaults to the pod IP. You probably want to set
"Host" in httpHeaders instead.

#### `httpHeaders` (array)
Custom headers to set in the request. HTTP allows repeated headers.
```

--------------------------------

### Preserve Partitions from Index Onwards (ISO Installation)

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installation-user-infra-machines-advanced-retain-disk.adoc

Use the `--save-partindex` option with a range to preserve partitions starting from a specific index. This example preserves partitions 5 and higher.

```bash
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- /dev/disk/by-id/scsi-<serial_number>
```

```bash
# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \
--save-partindex 5- \
--offline \
/dev/disk/by-id/scsi-<serial_number>
```

--------------------------------

### Install the KVC framework instance

Source: https://github.com/openshift/openshift-docs/blob/main/modules/building-testing-kernel-module-container.adoc

Install the KVC framework by running the make install command. This action also sets up the kmod-via-container systemd service.

```bash
$ sudo make install
```

--------------------------------

### Successful Decryption Output Example

Source: https://github.com/openshift/openshift-docs/blob/main/modules/ibm-z-secure-execution.adoc

This output indicates that the decryption of the Ignition configuration was successful during the first boot. Key services related to Secure Execution and Ignition setup have started and completed.

```terminal
[    2.801433] systemd[1]: Starting coreos-ignition-setup-user.service - CoreOS Ignition User Config Setup...

[    2.803959] coreos-secex-ignition-decrypt[731]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.808874] coreos-secex-ignition-decrypt[740]: gpg: encrypted with rsa4096 key, ID <key_name>, created <yyyy-mm-dd>
[  OK  ] Finished coreos-secex-igni…S Secex Ignition Config Decryptor.
```

--------------------------------

### Example of getting a single node

Source: https://github.com/openshift/openshift-docs/blob/main/modules/nodes-nodes-viewing-listing.adoc

This example shows how to get information for a specific node named `node1.example.com`.

```terminal
$ oc get node node1.example.com
```

--------------------------------

### Create initial application component (v1)

Source: https://github.com/openshift/openshift-docs/blob/main/modules/deployments-blue-green.adoc

Creates the first instance of the example application using the 'v1' image and names it 'example-blue'. This is the initial production version.

```bash
$ oc new-app openshift/deployment-example:v1 --name=example-blue
```

--------------------------------

### Ephemeral Container Readiness Probe

Source: https://github.com/openshift/openshift-docs/blob/main/rest_api/operatorhub_apis/clusterserviceversion-operators-coreos-com-v1alpha1.adoc

Configures readiness probes for ephemeral containers, including execution commands, HTTP GET requests, TCP sockets, and gRPC health checks. It also defines thresholds and timing for probe failures and successes.

```APIDOC
## .spec.install.spec.deployments[].spec.template.spec.ephemeralContainers[].readinessProbe

Description::
+
--
Probes are not allowed for ephemeral containers.
--

Type::
  `object`

[cols="1,1,1",options="header"]
|===
| Property | Type | Description

| `exec`
| `object`
| Exec specifies a command to execute in the container.

| `failureThreshold`
| `integer`
| Minimum consecutive failures for the probe to be considered failed after having succeeded.
Defaults to 3. Minimum value is 1.

| `grpc`
| `object`
| GRPC specifies a GRPC HealthCheckRequest.

| `httpGet`
| `object`
| HTTPGet specifies an HTTP GET request to perform.

| `initialDelaySeconds`
| `integer`
| Number of seconds after the container has started before liveness probes are initiated.
More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

| `periodSeconds`
| `integer`
| How often (in seconds) to perform the probe.
Default to 10 seconds. Minimum value is 1.

| `successThreshold`
| `integer`
| Minimum consecutive successes for the probe to be considered successful after having failed.
Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1.

| `tcpSocket`
| `object`
| TCPSocket specifies a connection to a TCP port.

| `terminationGracePeriodSeconds`
| `integer`
| Optional duration in seconds the pod needs to terminate gracefully upon probe failure.
The grace period is the duration in seconds after the processes running in the pod are sent
a termination signal and the time when the processes are forcibly halted with a kill signal.
Set this value longer than the expected cleanup time for your process.
If this value is nil, the pod's terminationGracePeriodSeconds will be used. Otherwise, this
value overrides the value provided by the pod spec.
Value must be non-negative integer. The value zero indicates stop immediately via
the kill signal (no opportunity to shut down).
This is a beta field and requires enabling ProbeTerminationGracePeriod feature gate.
Minimum value is 1. spec.terminationGracePeriodSeconds is used if unset.

| `timeoutSeconds`
| `integer`
| Number of seconds after which the probe times out.
Defaults to 1 second. Minimum value is 1.
More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes

|===

```

--------------------------------

### Deploy a hello world application

Source: https://github.com/openshift/openshift-docs/blob/main/modules/cloud-experts-dynamic-certificate-custom-domain-config-deploy-sample-app.adoc

Deploy a sample hello world application to the specified project.

```terminal
$ oc -n hello-world new-app --image=docker.io/openshift/hello-openshift
```

--------------------------------

### Get all pending workloads in ClusterQueue

Source: https://github.com/openshift/openshift-docs/blob/main/modules/kueue-viewing-pending-workloads-clusterqueue.adoc

Use this command to retrieve a list of all workloads currently waiting for admission by a specific ClusterQueue resource. No setup is required beyond having access to the Kubernetes cluster and Kueue installed.

```terminal
$ oc get --raw "/apis/visibility.kueue.x-k8s.io/v1beta2/clusterqueues/cluster-queue/pendingworkloads"
```

--------------------------------

### Create Kickstart File for MicroShift Bootc Installation

Source: https://github.com/openshift/openshift-docs/blob/main/modules/microshift-kickstart-bootc-install.adoc

Create the kickstart.ks file for installation using the provided template and environment variables. This command processes the template and outputs the final kickstart file.

```bash
envsubst <     /usr/share/microshift/kickstart/kickstart-bootc.ks.template >     "${HOME}/kickstart.ks"

```

--------------------------------

### Example WMCO Installation Verification Output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installing-wmco-using-cli.adoc

Example output showing a successful WMCO installation with a 'Succeeded' phase.

```terminal
NAME                                    DISPLAY                           VERSION   REPLACES   PHASE
windows-machine-config-operator.2.0.0   Windows Machine Config Operator   2.0.0                Succeeded
```

--------------------------------

### Create Test Project and Application

Source: https://github.com/openshift/openshift-docs/blob/main/modules/nw-customize-ingress-error-pages.adoc

Set up a test environment by creating a new project and deploying a sample application. This is necessary for verifying the custom error pages.

```bash
$ oc new-project test-ingress
```

```bash
$ oc new-app django-psql-example
```

--------------------------------

### Create kickstart.ks file

Source: https://github.com/openshift/openshift-docs/blob/main/modules/microshift-install-bootc-prepare-kickstart.adoc

Create the kickstart.ks file which configures disk partitioning, network settings, and includes pre-install and post-install scripts for registry authentication and image pulling.

```terminal
$ cat > kickstart.ks <<EOFKS
lang en_US.UTF-8
keyboard us
timezone UTC
text
reboot

# Partition the disk with hardware-specific boot and swap partitions, adding an
# LVM volume that contains a 10GB+ system root. The remainder of the volume will
# be used by the CSI driver for storing data.
zerombr
clearpart --all --initlabel
# Create boot and swap partitions as required by the current hardware platform
reqpart --add-boot
# Add an LVM volume group and allocate a system root logical volume
part pv.01 --grow
volgroup rhel pv.01
logvol / --vgname=rhel --fstype=xfs --size=10240 --name=root

# Lock root user account
rootpw --lock

# Configure network to use DHCP and activate on boot
network --bootproto=dhcp --device=link --activate --onboot=on

%pre-install --log=/dev/console --erroronfail

# Create a 'bootc' image registry authentication file
mkdir -p /etc/ostree
cat > /etc/ostree/auth.json <<'EOF'
$(cat "${AUTH_CONFIG}")
EOF

%end

# Pull a 'bootc' image from a remote registry
ostreecontainer --url "${IMAGE_REF}"

%post --log=/dev/console --erroronfail

# Create an OpenShift pull secret file
cat > /etc/crio/openshift-pull-secret <<'EOF'
$(cat "${PULL_SECRET}")
EOF
chmod 600 /etc/crio/openshift-pull-secret

%end
EOFKS
```

--------------------------------

### Example Kernel Parameters for FCP Boot

Source: https://github.com/openshift/openshift-docs/blob/main/modules/install-sno-ibm-z.adoc

An example demonstrating how to set kernel parameters for booting an FCP device, including disk configuration and network settings.

```bash
$ cp set loaddev scpdata 'rd.zfcp=0.0.8001,0x500507630a0350a4,0x4000409D00000000
ip=encbdd0:dhcp::02:00:00:02:34:02 rd.neednet=1'
```

--------------------------------

### Example FCP Disk Configuration with Multipath

Source: https://github.com/openshift/openshift-docs/blob/main/modules/adding-ibm-z-lpar-agent.adoc

This example shows how to specify FCP disks for installation, including multipath configuration. It is used when installing on FCP-type disks and requires enabling multipath during installation.

```terminal
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2> \
rd.multipath=default
```

--------------------------------

### Example output for installation completion

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installing-ocp-agent-verify.adoc

This example output indicates that the OpenShift cluster installation has finished successfully and provides information on accessing the cluster.

```terminal
...................................................................
...................................................................
INFO Cluster is installed
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/home/core/installer/auth/kubeconfig
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno-cluster.test.example.com
```

--------------------------------

### Create a component using a starter project

Source: https://github.com/openshift/openshift-docs/blob/main/modules/developer-cli-odo-ref-create.adoc

When you do not have existing source code and want to quickly experiment, use the `--starter` flag with `odo create` to utilize a starter project. Specify the desired starter project name.

```bash
odo create nodejs --starter nodejs-starter
```

--------------------------------

### Example output for bootupctl adopt-and-update

Source: https://github.com/openshift/openshift-docs/blob/main/modules/updating-bootloader-manual.adoc

This is an example of the output after successfully running the `bootupctl adopt-and-update` command, indicating the updated components.

```bash
Updated: grub2-efi-x64-1:2.04-31.el8_4.1.x86_64,shim-x64-15-8.el8_1.x86_64
```

--------------------------------

### Example Output of oc get dasoperator

Source: https://github.com/openshift/openshift-docs/blob/main/modules/das-operator-installing-web-console.adoc

This is an example of the expected output when checking the DASOperator CR status using the 'oc get' command.

```terminal
NAME     	STATUS    	AGE
cluster  	Available	3m
```

--------------------------------

### Deploy a hello world application

Source: https://github.com/openshift/openshift-docs/blob/main/modules/cloud-experts-aws-load-balancer-operator-validating.adoc

Deploys a sample 'hello-openshift' application to the specified project.

```terminal
$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
```

--------------------------------

### Example Cluster Extension Output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/olmv1-installing-an-operator-in-a-specific-namespace.adoc

Example output showing a successfully installed cluster extension with the `Installed` condition set to `True` and the reason `Succeeded`.

```yaml
apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <extension_name>
spec:
  namespace: <installation_namespace>
  config:
    configType: Inline
    inline:
      watchNamespace: <installation_namespace>
status:
  conditions:
  - type: Installed
    status: "True"
    reason: Succeeded
```

--------------------------------

### Create kickstart.ks file

Source: https://github.com/openshift/openshift-docs/blob/main/modules/microshift-kickstart-rpm-install.adoc

Create the kickstart.ks file by substituting environment variables into the MicroShift Kickstart template. This file will be used during the virtual machine installation.

```bash
envsubst < \
    /usr/share/microshift/kickstart/kickstart-rpm.ks.template > \
    "${HOME}/kickstart.ks"
```

--------------------------------

### Example Installation Output

Source: https://github.com/openshift/openshift-docs/blob/main/modules/installation-launching-installer.adoc

This is an example of the terminal output after a successful cluster deployment, showing access instructions and console links.

```terminal
...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/myuser/install_dir/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.mycluster.example.com
INFO Login to the console with user: "kubeadmin", and password: "password"
INFO Time elapsed: 36m22s
----
```

--------------------------------

### Example output of `oc get pods`

Source: https://github.com/openshift/openshift-docs/blob/main/modules/ztp-configuring-pgt-compliance-eval-timeouts.adoc

This is an example output of the `oc get pods -n open-cluster-management-agent-addon` command, showing the status and age of pods.

```terminal
NAME                                         READY   STATUS    RESTARTS        AGE
config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d
```

--------------------------------

### Example Output of `oc get nodes`

Source: https://github.com/openshift/openshift-docs/blob/main/modules/images-configuration-file.adoc

This is an example output of the `oc get nodes` command, showing node status, roles, age, and version.

```terminal
NAME                                         STATUS                     ROLES                  AGE   VERSION
ip-10-0-137-182.us-east-2.compute.internal   Ready,SchedulingDisabled   worker                 65m   v1.35.4
ip-10-0-139-120.us-east-2.compute.internal   Ready,SchedulingDisabled   control-plane          74m   v1.35.4
ip-10-0-176-102.us-east-2.compute.internal   Ready                      control-plane          75m   v1.35.4
ip-10-0-188-96.us-east-2.compute.internal    Ready                      worker                 65m   v1.35.4
ip-10-0-200-59.us-east-2.compute.internal    Ready                      worker                 63m   v1.35.4
ip-10-0-223-123.us-east-2.compute.internal   Ready                      control-plane          73m   v1.35.4
```

--------------------------------

### Example Output of Operator Installation Verification

Source: https://github.com/openshift/openshift-docs/blob/main/modules/logging-es-deploy-cli.adoc

This is an example output showing the status of ClusterServiceVersions (CSVs) across namespaces, indicating whether operators are installed and in what phase.

```terminal
NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
```