vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To see the IPs registered with each subdomain, run ibmcloud oc nlb-dns ls --cluster <cluster>. Note that you must repeat this command for each IP address that you want to remove.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example nlb-dns rm vpc-gen2 command 

ibmcloud oc nlb-dns rm vpc-gen2 --cluster mycluster --nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud







 Experimental: ibmcloud oc nlb-dns secret regenerate 

Virtual Private Cloud

Classic infrastructure

Regenerate the certificate and secret for an NLB subdomain. Secret regeneration is not disruptive, and traffic continues to flow while the secret regenerates.

If the Let’s Encrypt certificate creation fails during secret regeneration, a 10 minute wait period must pass before the regeneration is automatically attempted again. The regeneration of the secret takes another 5 minutes to complete, making it a total of 15 minutes before the process is completed.

To avoid the Let’s Encrypt rate limit, don't regenerate a secret more than 5 times per day.

ibmcloud oc nlb-dns secret regenerate --cluster CLUSTER --nlb-subdomain SUBDOMAIN [--output json] [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--nlb-subdomain SUBDOMAIN
: The subdomain to regenerate the secret for. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

--output json
: Optional: Prints the command output in JSON format.
To see the IPs registered with each subdomain, run ibmcloud ks nlb-dns ls --cluster <cluster>. Note that you must repeat this command for each IP address that you want to remove.

--output json
: Optional: Prints the command output in JSON format.

-q
: Optional: Do not show the message of the day or update reminders.



 Example nlb-dns rm vpc-gen2 command 

ibmcloud ks nlb-dns rm vpc-gen2 --cluster mycluster --nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud







 Experimental: ibmcloud ks nlb-dns secret regenerate 

Virtual Private Cloud

Classic infrastructure

Regenerate the certificate and secret for an NLB subdomain. Secret regeneration is not disruptive, and traffic continues to flow while the secret regenerates.

If the Let’s Encrypt certificate creation fails during secret regeneration, a 10 minute wait period must pass before the regeneration is automatically attempted again. The regeneration of the secret takes another 5 minutes to complete, making it a total of 15 minutes before the process is completed.

To avoid the Let’s Encrypt rate limit, don't regenerate a secret more than 5 times per day.

ibmcloud ks nlb-dns secret regenerate --cluster CLUSTER --nlb-subdomain SUBDOMAIN [--output json] [-q]

Minimum required permissions
: Editor platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--nlb-subdomain SUBDOMAIN
: The subdomain to regenerate the secret for. To list subdomains, run ibmcloud ks nlb-dns ls --cluster CLUSTER.

--output json
: Optional: Prints the command output in JSON format.

-q
: The path to the Dockerfile. Specify this option only if the name is other than Dockerfile. The build dockerfile option is allowed only if the --build-source option is set. This value is optional. The default value is Dockerfile.

--build-git-repo-secret, --git-repo-secret, --bgrs, --grs, --repo
: The name of the SSH secret, which contains the credentials to access the private repository that contains the source code to build your container image. To create this SSH secret, use the secret create --format SSH command. An SSH secret is also used as a Git repository access secret. This option is allowed only if the --build-source option is set to the URL of a Git repository. This value is optional.

--build-size, --size, --bsz, --sz
: The size for the build, which determines the amount of resources used. Valid values are small, medium, large, xlarge. For details, see [Determining the size of the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-size). The build size option is allowed only if the --build-source option is set. This value is optional. The default value is medium.

--build-source, --source, --bsrc, --src
: The URL of the Git repository or the path to local source that contains your source code; for example https://github.com/IBM/CodeEngine or .. This value is optional.

--build-strategy, --strategy, --bstr, --str
: The strategy to use for building the image. Valid values are dockerfile and buildpacks. The build strategy option is allowed only if the --build-source option is set.
Adding object storage to apps 

Create a persistent volume claim (PVC) to provision IBM Cloud Object Storage for your cluster.

Depending on the settings that you choose in your PVC, you can provision IBM Cloud Object Storage in the following ways:



* [Dynamic provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsdynamic_provisioning): When you create the PVC, the matching persistent volume (PV) and the bucket in your IBM Cloud Object Storage service instance are automatically created.
* [Static provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsstatic_provisioning): You can reference an existing bucket in your IBM Cloud Object Storage service instance in your PVC. When you create the PVC, only the matching PV is automatically created and linked to your existing bucket in IBM Cloud Object Storage.



Before you begin:



* [Create and prepare your IBM Cloud Object Storage service instance](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-cos-understandcreate_cos_service).
* [Create a secret to store your IBM Cloud Object Storage service credentials](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-cos-understandcreate_cos_secret)).
* [Decide on the configuration for your IBM Cloud Object Storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_cos_installconfigure_cos).



To add IBM Cloud Object Storage to your cluster:



1. Create a configuration file to define your persistent volume claim (PVC). If you add your [IBM Cloud Object Storage credentials to the default storage classes](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_cos_install), do not list your secret in the PVC.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
For example, the secret reference {vault::my-kms.my-key} expects to find a key that is named my-key in the Key Protect service instance. This service instance is integrated into the toolchain with a Key Protect tool integration that is named my-kms.
* If the secret is stored in Secrets Manager, check that the second, and third segments of the {vault::...} secret reference match the names of the secret group and secret that you want to use in the Secrets Manager service instance. For example, the secret reference {vault::my-sm.my-group.my-key} expects to find a secret that is named my-key in a secret group that is named my-group. This secret and secret group are stored within the Secrets Manager service instance that is integrated into the toolchain by using a Secrets Manager tool integration that is named my-sm.
* If the secret is stored in HashiCorp Vault, check that the second and third segments of the {vault::...} secret reference match the names of the secret and the secret field in the HashiCorp Vault server. For example, the secret reference {vault::my-hcv.my-secret.my-field} expects to find a secret that is named my-secret in the HashiCorp Vault server, and a field named my-field within that secret. This server is integrated into the toolchain by using a HashiCorp Vault tool integration that is named my-hcv.



Complete the following tasks for secrets references by CRN:



* Check that the secret store is integrated as a tool into the toolchain, and that the tool integration is correctly configured to identify by the service instance CRN. If the tool integration is misconfigured, edit the tool integration to correct the error condition, and then save the configuration.
* Check that the CRN of the Secrets Manager service instance that is configured in the tool integration references the same instance as the CRN of the failing secret.







 When I use Terraform or the API to configure a tool integration, why does the configuration fail with the A problem was encountered while attempting to resolve secret reference... error?
After you select the individual key in the secret that you want to reference, notice that the Resulting definition section displays the name of the selected key in the secret, but does not display the actual value of the key that is referenced within the secret.



From the console, you can reference only one individual key of a defined configmap or secret per environment variable. If you need to reference more than one key of a configmap or secret, then repeat the steps to define another environment variable that references a different key.
3. Click Done to save your changes. This action adds your environment variable to the table on the Environment variables tab. To continue adding environment variables, click Add.
4. Complete the create or update for your app or job with the defined environment variable.



* If you are creating an app or job, when you click Create, the app or job is deployed with your environment variables.
* If you are updating an existing app or job to add an environment variable, click Save and deploy to update the app or click Save to update your job with the new environment variables.



5. When your app or job is in Ready state, your app or job is updated with your environment variables.



The following table describes information about your environment variables.



Table of environment variables

 Heading Description 

 Name The name of your environment variable. 
 Defined by Specifies whether the environment variable is of type literal, or whether the environment variable is a fully referenced configmap or secret, or whether specific keys of a secret or configmap are referenced. 
 Value or reference Displays the literal value, the fully referenced configmap or secret, or the referenced keys of a configmap or secret. 



For example, let's create an app and set environment variables for the app.



1. [Create an app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-appdeploy-app-console) that is named myapp, which uses the icr.io/codeengine/codeengine image. This hello-world app includes the TARGET environment variable, and the app prints Hello ${TARGET} from Code Engine and prints a listing of environment variables.
19 May 2022 



* Notify users about incident issues that have approaching due dates and overdue due dates by using Slack after the Slack tool integration is enabled.
* Support for [cyclonedx](https://cloud.ibm.com/docs/devsecops?topic=devsecops-generate-cyclonedx-sbom) format when generating Software Bill of Material by using Code Risk Analyzer in compliance pipelines.







 13 May 2022 

Added support to the Continuous Integration and Continuous Compliance pipelines for [incident issues](https://cloud.ibm.com/docs/devsecops?topic=devsecops-incident-issues), such as vulnerabilities and CVEs that are related to creating, storing, updating, and closing those issues. With this feature, you can set due dates for issues, add default assignees, and filter issues by using labels.





 24 March 2022 



 Introducing IBM Cloud DevSecOps 

DevSecOps is a methodology that integrates security practices with the software development and operations lifecycle. The goal of the merge is to prioritize the balance of development speed and security.



* New Continuous Compliance template that periodically scans your deployed application code.
* Support for Zap Dynamic scans that use async pipelines.
* Support for tracing the origin of default scripts that are running in the compliance pipelines.
* Incident issues support a "Due Date" field based on the issue severity.
* Format issues created by Continuous Compliance pipeline for better readability.
* Support for disabling static and dynamic scans that use optional environment properties.
* Updated IBM Cloud Object Storage tool integration UI for easy setup.
* Support for querying environment tags from inventory repository while setting up CC and CD toolchain.
* New wizard support for customizing the welcome page.



IBM Cloud® DevOps Insights is not supported in the Continuous Compliance pipeline. Also, there is limited support for triggering dynamic scans for multiple apps out of the box.







 16 March 2022 



* Enhanced DevSecOps pipeline code to publish CRA results to DevOps Insights including BOM, vulnerability, and deployment records.
* Added support for the optional CRA plug-in parameter --dockerfilepattern.
Mounting ISCSI VMware ESXi 

Mounting iSCSI into VMware® ESXi can be accomplished with a few steps and only the details of the server and storage node.

In most VMware® environments, NFS File Storage is the better choice. File Storage is designed to support high I/O applications that require predictable levels of performance. In a VMware® deployment, a single File Storage volume can be mounted to up to 64 ESXi hosts as shared storage, that is much better than Block Storage which supports 8 hosts by default. You can also mount multiple {site.data.keyword.filestorage_short}} volumes to create a storage cluster to use vSphere Storage Distributed Resource Scheduler (DRS). For more information, see [Provisioning File Storage for use as VMware datastore](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-architectureguide&interface=ui).



1. Log in to the vSphere by using the primary private IP and user root and root's password.
2. From the Welcome page, click the Configuration tab.
3. Click Storage adapters > Add.
4. Click OK to add the Software iSCSI adapter.
5. Confirm by clicking OK.
6. After the refresh, the new iSCSI adapter is listed.
7. Click Properties.
8. From the Properties Window, click Configure and set the Name to the IQN for the server (found on the storage device page under authorized hosts).
9. Click the Dynamic discovery tab then click Add....
10. The iSCSI server is the target IP of the storage device, then click CHAP.
11. Select Use CHAP and clear Inherit from parent. Input the username (found on the storage device page under authorized hosts) and the password.
12. Select Do not use CHAP under the Mutual CHAP section then click OK.
13. You now see the device in the Dynamic discovery window and click Close.
14.
Adding object storage to apps 

Create a persistent volume claim (PVC) to provision IBM Cloud Object Storage for your cluster.

Depending on the settings that you choose in your PVC, you can provision IBM Cloud Object Storage in the following ways:



* [Dynamic provisioning](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsdynamic_provisioning): When you create the PVC, the matching persistent volume (PV) and the bucket in your IBM Cloud Object Storage service instance are automatically created.
* [Static provisioning](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptsstatic_provisioning): You can reference an existing bucket in your IBM Cloud Object Storage service instance in your PVC. When you create the PVC, only the matching PV is automatically created and linked to your existing bucket in IBM Cloud Object Storage.



Before you begin:



* [Create and prepare your IBM Cloud Object Storage service instance](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandcreate_cos_service).
* [Create a secret to store your IBM Cloud Object Storage service credentials](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandcreate_cos_secret)).
* [Decide on the configuration for your IBM Cloud Object Storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_cos_installconfigure_cos).



To add IBM Cloud Object Storage to your cluster:



1. Create a configuration file to define your persistent volume claim (PVC). If you add your [IBM Cloud Object Storage credentials to the default storage classes](https://cloud.ibm.com/docs/containers?topic=containers-storage_cos_install), do not list your secret in the PVC.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: <name> Enter the name of the PVC.
This error indicates that the toolchain cannot find the identified secret, or that the secret store is not integrated into the toolchain. The error can occur for secrets references by name if one or more of the segments in the secrets reference {vault:...} string are incorrect, or if a key of the specified group, name, or field does not exist in the secret store. The error can occur for secrets references by CRN if the secret CRN references a secret that was deleted.

 How to fix it 

The error message includes the secret reference string that cannot be resolved.

Complete the following tasks for secrets references by name:



* Check that the secret store is integrated as a tool into the toolchain, and that the tool integration is correctly configured to identify by the service instance name. If the tool integration is misconfigured, edit the tool integration to correct the error condition, and then save the configuration.
* Check that the first segment of the {vault::...} secret reference matches the name of the secret store tool integration. For example, the secret reference {vault::my-secret-store.my-secret} expects the toolchain to have a secret store tool integration that is named my-secret-store. This value is the name of tool integration, not the name of the secret store service instance.
* If the secret is stored in Key Protect, check that the second segment of the {vault::...} secret reference matches the name of the key that you want to use in the Key Protect service instance. For example, the secret reference {vault::my-kms.my-key} expects to find a key that is named my-key in the Key Protect service instance. This service instance is integrated into the toolchain with a Key Protect tool integration that is named my-kms.
* If the secret is stored in Secrets Manager, check that the second, and third segments of the {vault::...} secret reference match the names of the secret group and secret that you want to use in the Secrets Manager service instance.
-n, --name
: The name of the application. Use a name that is unique within the project.



* The name must begin with a lowercase letter.
* The name must end with a lowercase alphanumeric character.
* The name must be 63 characters or fewer and can contain lowercase letters, numbers, and hyphens (-).



This value is required.

--argument, --arg, -a
: Set arguments for the application. Specify one argument per --argument option; for example, -a argA -a argB. This value overrides the default values that are specified within the container image. This value is optional.

--build-commit, --commit, --bcm, --cm, --revision
: The commit, tag, or branch in the source repository to pull. The build commit option is allowed only if the --build-source option is set. This value is optional.

--build-context-dir, --context-dir, --bcdr, --cdr
: The directory in the repository that contains the buildpacks file or the Dockerfile. The build context directory option is allowed only if the --build-source option is set. This value is optional.

--build-dockerfile, --dockerfile, --bdf, --df
: The path to the Dockerfile. Specify this option only if the name is other than Dockerfile. The build dockerfile option is allowed only if the --build-source option is set. This value is optional. The default value is Dockerfile.

--build-git-repo-secret, --git-repo-secret, --bgrs, --grs, --repo
: The name of the SSH secret, which contains the credentials to access the private repository that contains the source code to build your container image. To create this SSH secret, use the secret create --format SSH command. An SSH secret is also used as a Git repository access secret.
Mounting ISCSI VMware ESXi 

Mounting iSCSI into VMware® ESXi can be accomplished with a few steps and only the details of the server and storage node.

In most VMware® environments, NFS File Storage for Classic is the better choice. File Storage for Classic is designed to support high I/O applications that require predictable levels of performance. In a VMware® deployment, a single File Storage for Classic volume can be mounted to up to 64 ESXi hosts as shared storage, that is much better than Block Storage for Classic which supports 8 hosts by default. You can also mount multiple {site.data.keyword.filestorage_short}} volumes to create a storage cluster to use vSphere Storage Distributed Resource Scheduler (DRS). For more information, see [Provisioning File Storage for use as VMware datastore](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-architectureguide&interface=ui).



1. Log in to the vSphere by using the primary private IP and user root and root's password.
2. From the Welcome page, click the Configuration tab.
3. Click Storage adapters > Add.
4. Click OK to add the Software iSCSI adapter.
5. Confirm by clicking OK.
6. After the refresh, the new iSCSI adapter is listed.
7. Click Properties.
8. From the Properties Window, click Configure and set the Name to the IQN for the server (found on the storage device page under authorized hosts).
9. Click the Dynamic discovery tab then click Add....
10. The iSCSI server is the target IP of the storage device, then click CHAP.
11. Select Use CHAP and clear Inherit from parent. Input the username (found on the storage device page under authorized hosts) and the password.
12. Select Do not use CHAP under the Mutual CHAP section then click OK.
13. You now see the device in the Dynamic discovery window and click Close.
14.
To create a secret, you can run the [ibmcloud ks ingress secret create](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_ingress_secret_create) command. If a secret for a different TLS certificate is specified in the spec.tls section of an Ingress resource, and that secret exists in the same namespace as the Ingress resource, then that secret is applied instead of this default secret.

defaultConfig
: Specify a default configmap for your ALBs. Enter the location of the configmap you want to use in the format namespace/configmap-name. For example, kube-system/ibm-k8s-controller-config.

enableSslPassthrough
: Enable SSL passthrough for the ALB. The TLS connection is not terminated and passes through untouched.

httpPort, httpsPort
: Expose non-default ports for the Ingress ALB by adding the HTTP or HTTPS ports that you want to open.

ingressClass
: If you specified a class other than public-iks-k8s-nginx or private-iks-k8s-nginx in your Ingress resource, specify the class.

logLevel
: Specify the log level that you want to use. Choose from the following values.
: 2: Shows the details by using the diff command to show changes in the configuration in NGINX.
: 3: Shows the details about the service, Ingress rule, endpoint changes in JSON format.
: 5: Configures NGINX in debug mode.
: For more information about logging, see [Debug Logging](https://kubernetes.github.io/ingress-nginx/troubleshooting/debug-logging).

replicas
: By default, each ALB has 2 replicas. Scale up your ALB processing capabilities by increasing the number of ALB pods.