vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you created a secret for a certificate from Secrets Manager, only the secret in the cluster is deleted and the certificate remains in your Secrets Manager instance.

The previous alias for this command, ibmcloud oc ingress alb cert rm, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory. For more information, see the [CLI change log](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_cli_changelog10).

ibmcloud oc ingress secret rm --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [-q]

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

Command options:

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

--name SECRET_NAME
: Required: The name of the secret.

--namespace NAMESPACE
: Required: The project that the secret is deployed to.

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



 Example ingress secret rm command 

ibmcloud oc ingress secret rm --cluster my_cluster --name my_alb_secret --namespace demo_ns







 ibmcloud oc ingress secret update 

Virtual Private Cloud

Classic infrastructure

Update an Ingress secret for a certificate that is not hosted in the default Secrets Manager instance that was created for your cluster.

Any changes that you make to a certificate in the default Secrets Manager instance in your cluster are automatically reflected in the secret in your cluster. If you make changes to a certificate that is not hosted in your cluster Secrets Manager instance, you must use this command to update the secret in your cluster the pick up the certificate changes.

ibmcloud oc ingress secret update --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--cert-crn CRN] [-q]

Minimum required permissions
namespace: default
resourceVersion: "111111"
uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

You can also list the fields in a secret with the ibmcloud oc ingress secret field ls and ibmcloud oc ingress secret get commands, but the outputs include only the field name and not the value associated with it.





 Adding a secret field 

Add a secret field to a non-TLS secret by running the [ibmcloud oc ingress secret field add](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_secret_field_add) command with the --field option. You can also use this option to add fields when you create a secret with the [ibmcloud oc ingress secret create](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_secret_create) command. This option is not supported for TLS secrets.

There are three ways to specify the --field option. The one you choose depends on the secret type and how you want to name the field in the secret.



Options for adding fields to non-TLS secrets

 Option Format Description Supported secret types 

 Default --field <crn> The field name applied is the default field name for the secret type. All non-TLS secret types 
 Named --field <name>=<crn> The field name applied is the value specified for <name>. This option allows you to specify a custom name. <br><br> * Arbitrary /n - IAM credentials<br><br><br> 
 Prefixed --field <prefix>=<crn> The field name applied is the secret name in Secrets Manager, followed by an underscore and the default field name for the secret type. <br><br> * IAM credentials /n - username/password /n - key/value<br><br><br>
For more information and additional command options, see the [CLI reference](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_secret_create).

The following example command creates a non-TLS secret with the Opaque type specified. Non-TLS secrets require at least one secret [field](https://cloud.ibm.com/docs/openshift?topic=openshift-secretsnon-tls-field-add). Note that how you specify the --field option varies [based on the type of secret you create](https://cloud.ibm.com/docs/openshift?topic=openshift-secretsnon-tls-field-add).

ibmcloud oc ingress secret create -c cluster-test --name example-secret --namespace default --field crn:v1:bluemix:public:secrets-manager:us-south:a/1aa111aa1a11111aaa1a1111aa1aa111:111a1111-11a1 --type Opaque

To verify that the secret is created, list all secrets in the namespace.

kubectl get secret -n default

The following example shows the output.

NAME TYPE DATA AGE
all-icr-io kubernetes.io/dockerconfigjson 1 41h
default-token-8t6xw kubernetes.io/service-account-token 3 41h
example-secret Opaque 3m





 Managing non-TLS secret fields 

A secret field is a key-value pair that is stored in a non-TLS secret. Refer to the following examples to view, add, update, or remove non-TLS secret fields.



 Viewing field values 

You can view the values of a secret's fields by getting the details of the secret.

kubectl get secret -n default example-secret -o yaml

The following example output shows the secret fields and their values in the data section.

apiVersion: v1
data:
Any other error message Dockerfile, Buildpacks <br><br> * There's a problem with the Docker build.<br> * There's a problem with the source code.<br><br><br> 



 How to fix it 

Try using the following information to resolve your problem.

Whether you are running your build in the console or in the CLI, use the CLI for troubleshooting problems with your build.



1. Run the ibmcloud ce buildrun get --name BUILDRUN_NAME command to display the details of your build run.
2. Review the Reason in the command output.



After you check the logs and identify potential root causes, use the following resolution actions to help you resolve the problem.



 Resolution for memory limit during build 

See [Build fails when the memory limit is exceeded](https://cloud.ibm.com/docs/codeengine?topic=codeengine-ts-build-memory-limit) for resolution information.





 Resolution for a container registry problem during build 

In this scenario, a registry secret to access your container registry does not exist or the secret is not correct.



1. Determine which secret is used. Use the [ibmcloud ce build get](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-get) command to display the registry secret that is used.
2. Determine whether a .dockerconfigjson key exists. Use the [ibmcloud ce secret get](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-registry-get) command for the registry secret. Note that the secret data is encoded with base64 and not directly visible; however, the secret contains credentials. In the command output, check the Data section. It must contain a key that is called .dockerconfigjson. If the .dockerconfigjson key is not displayed, then this secret is not suitable to authenticate with a container registry and you need to create a correct secret and reference it in the build.
Create an environment variable that fully references the mycolorconfigmap configmap, including all its key-value pairs. Notice that the Resulting definition section displays the name of the keys in the configmap, but does not display the actual values of the keys that are referenced within the configmap. Click Done to save your changes.
* Click Add to open the Add environment variable page and create another environment variable that references an individual key of a defined secret. Before you can reference a secret, it must exist. For this example, a secret with the name mynewsecret exists and contains the following key-value pairs: newsec1=mynewsecret1, newsec2=mynewsecret2, and newsec3=mynewsecret3. Create an environment variable that references the newsec2 key of the mynewsecret secret. Notice 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. Click Done to save your changes.



6. Click Save and create to update the app with the new environment variables.
7. When the app is in Ready state, your app is updated with your environment variables.
8. To test your app, click Test application and then click Send request in the Test application pane. To open the application in a web page, click Application URL. With this app revision, this app outputs Hello World from Code Engine and the output includes the names of the environment variables, which were added in the previous steps.



When you set environment variables in your app or job, this action adds a new environment variable or overrides an existing environment variable. If you have an environment variable with the same Name, and specify a different value than the previously defined environment variable, then the updated environment variable overrides the existing value.
To create a secret to access a service with an SSH key, such as to authenticate to a Git repository like GitHub or GitLab, use the [ibmcloud ce secret create --format ssh](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. An SSH secret is also used as a Git repository access secret. To learn more about working with secrets in Code Engine, see [Working with secrets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret).

An SSH secret contains the credentials to access the private repository that contains the source code to build your container image. An SSH secret is also used as a Git repository access secret.

To create an SSH secret with the CLI, use the secret create --format ssh command. This command requires a name and a key path, and also allows other optional arguments such as the path to the known hosts file. For a complete listing of options, see the [ibmcloud ce secret create --format ssh](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command.

For example, the following command creates an SSH secret that is called myrepossh to a repository at github.com that uses your personal SSH private key that is found at the default location on your system.

Mac OS or Linux®

ibmcloud ce secret create --format ssh --name myrepossh --key-path $HOME/.ssh/id_rsa --known-hosts-path $HOME/.ssh/known_hosts

Windows

ibmcloud ce secret create --format ssh --name myrepossh --key-path "%HOMEPATH%.sshid_rsa" --known-hosts-path "%HOMEPATH%.sshknown_hosts"

The following table summarizes the options that are used with the repo create command in this example.
--namespace NAMESPACE
: Required: The project that the secret is deployed to.

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

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



 Example ingress secret get command 

ibmcloud oc ingress secret get --cluster my_cluster --name my_alb_secret --namespace demo_ns







 ibmcloud oc ingress secret ls 

Virtual Private Cloud

Classic infrastructure

List Ingress secrets in your cluster, including secrets stored in IBM Cloud® Secrets Manager.

The previous alias for this command, ibmcloud oc ingress alb cert ls, is deprecated.

ibmcloud oc ingress secret ls --cluster CLUSTER [--show-deleted] [--output json] [-q]

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

Command options:

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

--show-deleted
: Optional: View secrets that were deleted from the cluster.

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

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



 Example ingress secret ls command 

ibmcloud oc ingress secret ls --cluster my_cluster







 ibmcloud oc ingress secret rm 

Virtual Private Cloud

Classic infrastructure

Delete an Ingress secret from your cluster. If you created a secret for a certificate from Secrets Manager, only the secret in the cluster is deleted and the certificate remains in your Secrets Manager instance.

The previous alias for this command, ibmcloud oc ingress alb cert rm, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory.
A secret field is a key-value pair that is stored in a non-TLS secret. Refer to the following examples to view, add, update, or remove non-TLS secret fields.



 Viewing field values 

You can view the values of a secret's fields by getting the details of the secret.

kubectl get secret -n default example-secret -o yaml

The following example output shows the secret fields and their values in the data section.

apiVersion: v1
data:
arbitraryFVT: AAAaaAAaAAA1AAAaaAAa
userCredsFVT_password: aAAaa1aaaA=
userCredsFVT_username: aAAaaa==
kind: Secret
metadata:
annotations:
ingress.cloud.ibm.com/cert-source: ibm
razee.io/build-url: https://travis.ibm.com/alchemy-containers/armada-ingress-secret-mgr/builds/78876583
razee.io/source-url: https://github.ibm.com/alchemy-containers/armada-ingress-secret-mgr/commit/651fa822632128163cf638c47f0a14b1e0e2915a
creationTimestamp: "2022-11-08T19:45:05Z"
name: example-secret
namespace: default
resourceVersion: "111111"
uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

You can also list the fields in a secret with the ibmcloud oc ingress secret field ls and ibmcloud oc ingress secret get commands, but the outputs include only the field name and not the value associated with it.





 Adding a secret field
ibmcloud ks ingress secret rm --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [-q]

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

Command options:

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

--name SECRET_NAME
: Required: The name of the secret.

--namespace NAMESPACE
: Required: The namespace that the secret is deployed to.

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



 Example ingress secret rm command 

ibmcloud ks ingress secret rm --cluster my_cluster --name my_alb_secret --namespace demo_ns







 ibmcloud ks ingress secret update 

Virtual Private Cloud

Classic infrastructure

Update an Ingress secret for a certificate that is not hosted in the default Secrets Manager instance that was created for your cluster.

Any changes that you make to a certificate in the default Secrets Manager instance in your cluster are automatically reflected in the secret in your cluster. If you make changes to a certificate that is not hosted in your cluster Secrets Manager instance, you must use this command to update the secret in your cluster the pick up the certificate changes.

ibmcloud ks ingress secret update --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--cert-crn CRN] [-q]

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

Command options:

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

--name SECRET_NAME
: Required: The name of the secret. To see available secrets, run ibmcloud ks ingress secret ls.

--namespace NAMESPACE
: Required: The namespace that the secret is deployed to. To see the secret namespace, run ibmcloud ks ingress secret get --cluster cluster_name_or_ID <--name secret_name> --namespace <namespace>.

--cert-crn CERTIFICATE_CRN
razee.io/source-url: https://github.ibm.com/alchemy-containers/armada-ingress-secret-mgr/commit/651fa822632128163cf638c47f0a14b1e0e2915a
creationTimestamp: "2022-11-08T19:45:05Z"
name: example-secret
namespace: default
resourceVersion: "111111"
uid: 1aaa1111-1a11-111a-a1a1-11111a1a1a1a
type: Opaque

You can also list the fields in a secret with the ibmcloud ks ingress secret field ls and ibmcloud ks ingress secret get commands, but the outputs include only the field name and not the value associated with it.





 Adding a secret field 

Add a secret field to a non-TLS secret by running the [ibmcloud ks ingress secret field add](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_ingress_secret_field_add) command with the --field option. You can also use this option to add fields when you create a secret with the [ibmcloud ks ingress secret create](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_ingress_secret_create) command. This option is not supported for TLS secrets.

There are three ways to specify the --field option. The one you choose depends on the secret type and how you want to name the field in the secret.



Options for adding fields to non-TLS secrets

 Option Format Description Supported secret types 

 Default --field <crn> The field name applied is the default field name for the secret type. All non-TLS secret types 
 Named --field <name>=<crn> The field name applied is the value specified for <name>. This option allows you to specify a custom name. <br><br> * Arbitrary /n - IAM credentials<br><br><br>
"custom_version_key": "custom_version_value"
}
}

The downloaded property indicates whether the data for each secret version was already read or accessed. If the payload_available field has a value of true, it means that you're able to access or [restore the secret data of that version](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-historyrestore-secret-api).

You can store metadata that is relevant to the needs of your organization with the version_custom_metadata request parameter. The custom metadata of your secret is stored as all other metadata, for up to 50 versions, and you must not include confidential data. For more information about the required and optional request parameters, check out the [API reference](https://cloud.ibm.com/apidocs/secrets-manager/secrets-manager-v2)





 Restoring secrets to a previous version 

Accidentally replace or overwrite an existing secret? You can use IBM Cloud® Secrets Manager to immediately roll back to the previous version.

When you restore a secret to its previous version, a new version of the secret is created. For example, if the current version of your secret is 3, and you roll back to version 2, the data that was restored from version 2 becomes version 4.

You can restore one version back on [supported secret types](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-automatic-rotation&interface=uibefore-auto-rotate-supported-secret-types). For auditing purposes, the service retains the metadata of up to 50 versions for each secret, which you can review as part of a secret's [version history](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-version-history).



 Supported secret types 

Restoring to a previous version is supported for [IAM credentials](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-iam-credentials) and [public certificates](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-public-certificates).
Similarly, to reference a secret from a job with the CLI, specify the --env-from-secret option on the [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create), [job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update), [jobrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-submit), or [jobrun resubmit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-jobrun-resubmit) commands.

The following example describes how to reference an existing generic secret with a job by using the CLI.



1. Use the secret create command to create the following two generic secrets for this scenario. By default, a generic secret is created when the --format option is not specified.

ibmcloud ce secret create --name myliteralsecret --from-literal "TARGET=My big literal secret"

ibmcloud ce secret create --name myliteralsecret2 --from-literal "TARGET=My little literal secret"
2. [Create a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan) and reference the myliteralsecret secret. For this example, create a Code Engine job that uses the icr.io/codeengine/codeengine image and then run the job. When a request is sent to this sample job, the job reads the TARGET environment variable, and the job prints Hello ${TARGET} from Code Engine and prints a listing of environment variables. If the TARGETenvironment variable is empty, Hello World from Code Engine is returned.

ibmcloud ce job create --name myjob --image icr.io/codeengine/codeengine --array-indices 2-3 --env-from-secret myliteralsecret
3.
The default value is false.





 Example 

ibmcloud ce revision logs -n myapp-00001





 Example output 

Code Engine retains only the latest inactive revision of your application in addition to your active app revision. Older revisions are not retained.

Getting logs for all instances of application revision 'newapp-mytest-00002'...
Getting application revision 'newapp-mytest-00002'...
OK

newapp-mytest-00002-deployment-7c87cfbf66-xnwkp/user-container:
2021-07-15 20:40:56 Listening on port 8080









 Secret commands 

A secret provides a method to include sensitive configuration information, such as passwords or SSH keys, to your deployment. By referencing values from your secret, you can decouple sensitive information from your deployment to keep your app or job portable. Anyone who is authorized to your project can also view your secrets; be sure that you know that the secret information can be shared with those users. Secrets contain information in key-value pairs.

You must be within the context of a [project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-project) before you use secret commands.

For more information about working with secrets, see [Working with secrets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret).

To see CLI help for the secret commands, run ibmcloud ce secret -h.

Beginning with CLI version 1.42.0, defining and working with secrets in the CLI is unified under the secret command group. Use the --format option to specify the category of secret, such as basic_auth, generic, ssh, tls, or registry. The default value for the --format option is generic.



 ibmcloud ce secret create 

Create a secret.