vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you add a placement group, the instance is placed according to the placement group policy. For more information, see [About placement groups](https://cloud.ibm.com/docs/vpc?topic=vpc-about-placement-groups-for-vpc). 
 Subnets Select the subnets where you want to create your instance group. To maximize the availability of your applications, select subnets in different zones. For the best performance of an auto scale instance group, ensure that you use a subnet size of 32 or greater. 
 Use a load balancer Select this checkbox if you plan to use a load balancer to balance incoming requests across instances in your instance group. The load balancer must already be configured, attached to the subnets that you select for this instance group, and have at least one back-end pool. 
 Instance template Select the instance template that you want to use for provisioning the virtual server instances in your auto-scale instance group. All virtual server instances in the group are provisioned with the same instance template. 
 Scaling method Select whether you want to use a dynamic or static scaling method. With the dynamic scaling method, instances are added or removed based on the metric targets that you specify. With the static scaling method, you can specify a fixed number of instances that you always want to maintain. 
 Instance group size For a static group, enter the number of instances that you want to constantly have in this instance group. For a dynamic group, enter the minimum and maximum number of instances for your group. The number of instances scale automatically within that range based on the target metrics that you define. 
 Aggregation window (seconds) For a dynamic group, this value determines the time period that the instance group manager monitors each instance and determines the average utilization. 
 Cooldown period (seconds) For a dynamic group, the cooldown period is the time in seconds to pause further scaling actions after scaling takes place. 







 Creating scaling policies 

For the dynamic scaling method, you define certain metrics (like CPU utilization percent) and the target utilization that you want to achieve for that metric. Together, the metric and the average target utilization, determine when your instance group needs to dynamically add or remove virtual server instances from your group.
: Required. The password to log in to your private registry, such as a token value.

--docker-email <docker-email>
: Required. If you have one, enter your Docker email address. If you don't have one, enter a fictional email address, such as a@b.c. This email is required to create a Kubernetes secret, but is not used after creation.

--dry-run=true
: Include this option to create the secret value only, and not create and store the secret object in your cluster.

--output="jsonpath={.data..dockerconfigjson}"
: Get only the .dockerconfigjson value from the data section of the Kubernetes secret.

| base64 --decode > myregistryconfigjson
: Download the decoded secret data to a local myregistryconfigjson file.
2. Retrieve the decoded secret value of the default global pull secret and store the value in a dockerconfigjson file.

oc get secret pull-secret -n openshift-config --output="jsonpath={.data..dockerconfigjson}" | base64 --decode > dockerconfigjson
3. Combine the downloaded private registry pull secret myregistryconfigjson file with the default global pull secret dockerconfigjson file.

jq -s '.[0] * .[1]' dockerconfigjson myregistryconfigjson > dockerconfigjson-merged
4. Update the global pull secret with the combined dockerconfigjson-merged file.

oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=dockerconfigjson-merged
5. Verify that the global pull secret is updated.
Valid values are json, yaml, jsonpath=JSONPATH_EXPRESSION, and jsonpath-as-json=JSONPATH_EXPRESSION. Use jsonpath to specify the path to an element of the JSON output. This value is optional.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.





 Example 

The following command creates a Git access secret called github for host github.com and authenticates with an SSH key located at /<filepath>/.ssh/id_rsa, where <filepath> is the path on your system.

ibmcloud ce repo create -n github --key-path /<filepath>/.ssh/id_rsa --host github.com





 Example output 

Creating Git access secret github...
OK







 ibmcloud ce repo delete 

Delete a Git repository access secret.

ibmcloud ce repo delete --name NAME [--force] [--ignore-not-found] [--quiet]



 Command Options 

--name, -n
: The name of the Git repository access secret. This value is required.

--force, -f
: Force deletion without confirmation. This value is optional. The default value is false.

--ignore-not-found, --inf
: If not found, do not fail. This value is optional. The default value is false.

--quiet, -q
: Specify this option to reduce the output of the command. This value is optional. The default value is false.





 Example 

ibmcloud ce repo delete --name github





 Example output 

Are you sure you want to delete the Git access secret github? [y/N]> y
Deleting Git access secret github...
OK







 ibmcloud ce repo get 

Display the details of a Git repository access secret.
* kustomization.yaml: A YAML file that generates a configmap from the trigger properties, and identifies the secret stores and external secrets that are defined in the directory.
* external-secret.yaml: An external secrets definition of a secret that is defined in the base folder.





 Example 

Complete the following steps in the repo that you use to contain the externalized properties:



1. In the repo that contains the externalized properties, add a folder with a unique name such as trigger[].
2. Add the path of this folder to your pipeline definitions.
3. In the base folder, add the .cdexternalproptrigger, trigger-properties.env, kustomization.yaml, and external-secret.yaml files.
4. Update these files to match the properties that you want to externalize.









 Configuring a root secret 

To use external secrets, you must configure at least one secret store. This secret store requires its own access secret, named root secret.

You must add this root secret as a secure property to the Environment properties page of the pipeline that is being externalized. The root secret name must match the secretRef.key value that is specified in the SecretStore definition, for example, vault_secret_id.
The previous alias for this command, ibmcloud ks ingress alb cert ls, is deprecated.

ibmcloud ks 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 ks ingress secret ls --cluster my_cluster







 ibmcloud ks 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 ks ingress alb cert rm, is deprecated. In CLI version 1.0.157 and later, the ibmcloud ks ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud ks ingress secret subcategory. For more information, see the [CLI change log](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog10).

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
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:
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
IBM-provided TLS certificates are signed by LetsEncrypt and are fully managed by IBM.

The IBM-provided Ingress subdomain wildcard, .<cluster_name>.<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud, is registered by default for your cluster. The IBM-provided TLS certificate is a wildcard certificate and can be used for the wildcard subdomain.

Follow the steps to use the default TLS certificate for the IBM-provided Ingress subdomain.



1. Get the name of the secret where your default TLS certificate is stored. Note that this is the secret name you specify in the spec.tls section of your Ingress resource.

ibmcloud ks cluster get -c <cluster> | grep Ingress

Example output

Ingress Subdomain: mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret: mycluster-<hash>-0000
2. View the secret details and note the CRN value. This is the CRN of the TLS certificate.

ibmcloud ks ingress secret get -c <cluster> --name <secret_name> --namespace default
3. Create a secret for the default TLS certificate in each namespace where your Ingress resources or apps exist. Specify the TLS certificate CRN with the --cert-crn command option.

Alternatively, you can set the secret as the defaultCertificate in the [ibm-ingress-deploy-config ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationscomm-customize-deploy).

ibmcloud ks ingress secret create --cluster <cluster_name_or_ID> --cert-crn <CRN> --name <secret_name> --namespace <namespace>
You can modify the environment variable names by specifying a prefix when referencing the secret. To specify a prefix, use the value PREFIX=SECRET_NAME. Each resulting environment variable has the format <PREFIX><NAME_OF_KEY_IN_SECRET>. For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--env-from-secret-rm, --env-sec-rm
: Remove environment variable references to full secrets by using the secret name. To remove individual key references to secrets, use the --env-rm option. This option can be specified multiple times. This value is optional.

--env-rm
: Remove environment variable references to the key of a key-value pair in a configmap or secret. To remove individual key references and literal values, specify the name of the key. This option can be specified multiple times. This value is optional.

--force, -f
: Do not verify the existence of specified configmap and secret references. Configmap references are specified with the --env-from-configmap or --mount-configmap options. Secret references are specified with the --env-from-secret, --mount-secret or --registry-secret options. This value is optional. The default value is false.

--inline-code
: Specify the path to a file containing the source code for your function.
--env-from-configmap-rm, --env-cm-rm
: Remove environment variable references to full configmaps by using the configmap name. To remove individual key references to configmaps, use the --env-rm option. This option can be specified multiple times. This value is optional.

--env-sec, --env-from-secret
: Set environment variables from the key-value pairs that are stored in a secret by using one of the following ways:



* To add environment variables for all keys in a secret that is named secretName, use the value secretName. You can modify the environment variable names by specifying a prefix when referencing the secret. To specify a prefix, use the value PREFIX=SECRET_NAME. Each resulting environment variable has the format <PREFIX><NAME_OF_KEY_IN_SECRET>. For example, to set the prefix for all variable names of keys in secret secretName to CUSTOM_, use the value CUSTOM_=secretName. If the secret secretName contains KEY_A, the environment variable name is CUSTOM_KEY_A.
* To add environment variables for individual keys, use the format NAME:KEY_A,KEY_B. For example, to add an environment variable for a single key key1 in a secret that is named secretName, use the value secretName:key1. To assign a different name to a referenced key, use the format NAME:NEW_NAME=KEY_A. For example, to add an environment variable named myKey for a single key key1 in a secret that is named secretName, use the value secretName:myKey=key1.



This value is optional.

--env-from-secret-rm, --env-sec-rm
: Remove environment variable references to full secrets by using the secret name. To remove individual key references to secrets, use the --env-rm option. This option can be specified multiple times. This value is optional.

--env-rm
: Remove environment variable references to the key of a key-value pair in a configmap or secret.
When you create your secret, all values are automatically encoded to base64. In the following example, the secret name is cos-write-access.

Example create secret command that uses an API key.

kubectl create secret generic cos-write-access --type=ibm/ibmc-s3fs --from-literal=api-key=<api_key> --from-literal=service-instance-id=<service_instance_guid>

Example create secret command that uses HMAC authentication.

kubectl create secret generic cos-write-access --type=ibm/ibmc-s3fs --from-literal=access-key=<access_key_ID> --from-literal=secret-key=<secret_access_key>
4. If you want to use Key Protect Encryption for buckets created with IBM Cloud Object Storage s3fs plug-in, include the keyprotect root key crn value in the secret that is used to create the PVC.

Key Protect encryption can be used only when you create new buckets. If the Key Protect root key that is used for encryption is deleted, all the files in the associated buckets are inaccessible.



1. Create a YAML file for your IBM Cloud Object Storage secret.

---
apiVersion: v1
data:
access-key: xxx
secret-key: xxx
kp-root-key-crn: <keyprotect-root-key-crn in base64 encoded format>
kind: Secret
metadata:
name: <cos-write-access>
type: ibm/ibmc-s3fs
2. Apply the secret to your cluster.

kubectl apply -f <secret_name>



api-key
: Enter the API key that you retrieved from your IBM Cloud Object Storage service credentials earlier. If you want to use HMAC authentication, specify the access-key and secret-key instead.

access-key
: Enter the access key ID that you retrieved from your IBM Cloud Object Storage service credentials earlier. If you want to use OAuth2 authentication, specify the api-key instead.
_) / /( (_ )( / / ) _)
(____)_)__) ___/(__)_)__)(____)

Some Env Vars:
--------------
HOME=/root
HOSTNAME=myjobrunresubmit2-2-0
JOB_INDEX=2
KUBERNETES_PORT=tcp://172.21.0.1:443
KUBERNETES_PORT_443_TCP=tcp://172.21.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=172.21.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_HOST=172.21.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
SHLVL=1
TARGET=My new big literal secret



To summarize, you completed basic scenarios to demonstrate how to use secrets with a job by referencing an existing full secret and updating keys within a secret.





 Referencing secrets that are not yet defined with the CLI 

If a secret does not exist before it is referenced, an app will not deploy successfully, and a job will not run successfully until the referenced secret is created.

If you are working with an app or a job and the referenced secret is not yet defined, use the --force option to avoid verification of the existence of the referenced secret.
containers-kubernetes.cluster-ingress-secret.create An Ingress secret for a certificate is created. 
 containers-kubernetes.cluster-ingress-secret.delete An Ingress secret is deleted from the cluster. 
 containers-kubernetes.cluster-ingress-secret.update The certificate for an Ingress secret is updated. 
 containers-kubernetes.cluster-ingress-secret-field.add A field in an Ingress secret is added. 
 containers-kubernetes.cluster-ingress-secret-field.remove A field in an Ingress secret is removed. 







 Observability events for logging and monitoring 

The following list of the logging and monitoring configuration events are sent to IBM Cloud Activity Tracker by the IBM Cloud Kubernetes Service observability plug-in.



Observability events for logging and monitoring

 Action Description 

 containers-kubernetes.observe-logging.create A Log Analysis configuration is created for the cluster. 
 containers-kubernetes.observe-logging.get The details of a Log Analysis configuration are returned. 
 containers-kubernetes.observe-logging.list Log Analysis configurations for a cluster are listed. 
 containers-kubernetes.observe-logging.modify A Log Analysis configuration is updated. 
 containers-kubernetes.observe-logging.remove A Log Analysis configuration is removed from the cluster. 
 containers-kubernetes.observe-monitoring.create A Monitoring configuration is created for the cluster. 
 containers-kubernetes.observe-monitoring.get The details of a Monitoring configuration are returned. 
 containers-kubernetes.observe-monitoring.list Monitoring configurations for a cluster are listed. 
 containers-kubernetes.observe-monitoring.modify A Monitoring configuration is updated. 
 containers-kubernetes.observe-monitoring.remove A Monitoring configuration is removed from the cluster. 







 NLB DNS events 

The following list of network load balancer (NLB) DNS events are sent to IBM Cloud Activity Tracker.



NLB DNS events

 Action Description 

 containers-kubernetes.cluster-nlb-dns.list Registered NLB subdomains and NLB IP addresses are listed.
You can update an existing secret and its key-value pairs with the CLI.



1. To change the value of a key-value pair in a defined secret, use the [secret update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-update) command. Let's update the mysecret-registry secret to use a different server.

ibmcloud ce secret update --name mysecret-registry --format registry --server <new_server> --username <new_username> --password <password>
2. Now that your secret is updated, use the secret get command to display details about a specific secret. If needed, use the --decode option to display the secret data as decoded. For example,

ibmcloud ce secret get --name mysecret-registry --decode

Example output

Getting generic secret 'mysecret-registry'...
OK

Name: mysecret-registry
ID: abcdefgh-abcd-abcd-abcd-c88e2775388e
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 21m
Created: 2023-03-07 20:00:45 +0000 UTC

Data:
---
email: ""
password: REDACTED
server: newserver
username: newuser









 Referencing secrets 

Your apps or jobs can consume and use the information that is stored in a secret by using environment variables.



 Referencing secrets from the console 

You can use the console to create environment variables for your apps and jobs that fully reference a secret or reference individual keys in a secret.

Before you can reference a secret, it must exist. See [create a secret](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret-create-ui).
To store an image pull secret in the Kubernetes service account, use the [following steps](https://cloud.ibm.com/docs/containers?topic=containers-registrystore_imagePullSecret).





 Storing the image pull secret in the Kubernetes service account for the selected namespace 

Every Kubernetes namespace has a Kubernetes service account that is named default. Within the namespace, you can add the image pull secret to this service account to grant access for pods to pull images from your registry. Deployments that don't specify a service account automatically use the default service account for this Kubernetes namespace.



1. Check if an image pull secret already exists for your default service account.

kubectl describe serviceaccount default -n <namespace_name>

When <none> is displayed in the Image pull secrets entry, no image pull secret exists.
2. Add the image pull secret to your default service account.



* Example command to add the image pull secret when no image pull secret is defined.

kubectl patch -n <namespace_name> serviceaccount/default -p '{"imagePullSecrets":[{"name": "<image_pull_secret_name>"}]}'
* Example command to add the image pull secret when an image pull secret is already defined.

kubectl patch -n <namespace_name> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"<image_pull_secret_name>"}}]'



3. Verify that your image pull secret was added to your default service account.

kubectl describe serviceaccount default -n <namespace_name>

Example output

Name: default
Namespace: <namespace_name>
Labels: <none>
Annotations: <none>
Image pull secrets: <image_pull_secret_name>