vania-janet/multiturn-rag-retrieval-data huggingface dataset:
apiconnect.invitation_acceptSpaceScope.create Accept using the Space Invitation 
 apiconnect.role_updateSpaceScope.update Update the Role object by name or ID 
 apiconnect.member_invitation_createSpaceScope.create Create a Member Invitation object 
 apiconnect.member_invitation_clearSpaceScope.delete Clear the Member Invitation objects 
 apiconnect.member_invitation_updateSpaceScope.update Update the Member Invitation object by name or ID 
 apiconnect.member_invitation_delSpaceScope.delete Delete the Member Invitation object by name or ID 
 apiconnect.member_invitation_regenerateSpaceScope.create Regenerate the Member Invitation 
 apiconnect.member_invitation_registerSpaceScope.create Register using the Member Invitation 
 apiconnect.member_invitation_acceptSpaceScope.create Accept using the Member Invitation 
 apiconnect.member_createSpaceScope.create Create a Member object 
 apiconnect.member_clearSpaceScope.delete Clear the Member objects 
 apiconnect.member_updateSpaceScope.update Update the Member object by name or ID 
 apiconnect.member_delSpaceScope.delete Delete the Member object by name or ID 
 apiconnect.task_updateSpaceScope.update Update the Task object by name or ID 
 apiconnect.consumer_org_setting_singletonUpdate.update Update the Consumer Organization Setting object 
 apiconnect.consumer_org_setting_singletonDel.delete Delete the Consumer Organization Setting object 
 apiconnect.consumer_org_setting_singletonUpdateSpaceInitiated.update Update the Consumer Organization Setting object 
 apiconnect.consumer_org_setting_singletonDelSpaceInitiated.delete Delete the Consumer Organization Setting object 
 apiconnect.activation_clearOrgScope.delete Clear the Activation objects 
 apiconnect.activation_delOrgScope.delete Delete the Activation object by name or ID 
 apiconnect.invitation_createConsumerOrgScope.create Create a Consumer Organization Invitation object 
 apiconnect.invitation_clearConsumerOrgScope.delete Clear the Consumer Organization Invitation objects
Wait for all pods in the Grafana namespace to be in Running state.
4. Log in to the Grafana instance. The default username and password is root/secret. After you are logged in, change the password. You can locate the route by using the following command:

oc get route
5. [Add Grafana users](https://grafana.com/tutorials/create-users-and-teams/).
6. Connect Prometheus to Grafana.



1. Grant the cluster-monitoring-view cluster role to the grafana-serviceaccount service account.

oc adm policy add-cluster-role-to-user cluster-monitoring-view -z grafana-serviceaccount
2. Create a bearer token for the grafana-serviceaccount service account.

oc serviceaccounts get-token grafana-serviceaccount -n grafana
3. Create a [GrafanaDataSource resource](https://github.com/integr8ly/grafana-operator/blob/v3.10.1/documentation/datasources.md). In the following YAML example, substitute <BEARER_TOKEN> with the output of the previous command.

apiVersion: integreatly.org/v1alpha1
kind: GrafanaDataSource
metadata:
name: prometheus-datasource
namespace: grafana
spec:
datasources:
- access: proxy
editable: true
isDefault: true
jsonData:
httpHeaderName1: 'Authorization'
timeInterval: 5s
tlsSkipVerify: true
name: Prometheus
secureJsonData:
httpHeaderValue1: 'Bearer <BEARER_TOKEN>'
type: prometheus
url: 'https://thanos-querier.openshift-monitoring.svc.cluster.local:9091'
The Finance team deploys front end, back end, and database services for the app Srv2 in the finance namespace. Both teams label each service with the app: Srv1 or app: Srv2 label and the tier: frontend, tier: backend, or tier: db label. They also label the namespaces with the usage: accounts or usage: finance label.

Zoom

![Use a network policy to manage cross-namepspace traffic.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/cs_network_policy_multi_ns.png)

Figure 2. Use a network policy to manage cross-namespace traffic

The Finance team's Srv2 needs to call information from the Accounts team's Srv1 back end. So the Accounts team creates a Kubernetes network policy that uses labels to allow all traffic from the finance namespace to the Srv1 back end in the accounts namespace. The team also specifies the port 3111 to isolate access through that port only.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
Namespace: accounts
name: accounts-allow
spec:
podSelector:
matchLabels:
app: Srv1
Tier: backend
ingress:
- from:
- NamespaceSelector:
matchLabels:
usage: finance
ports:
port: 3111
Show more

The spec.podSelector.matchLabels section lists the labels for the Srv1 back-end service so that the policy applies only to those pods. The spec.ingress.from.NamespaceSelector.matchLabels section lists the label for the finance namespace so that ingress is permitted only from services in that namespace.

Traffic can now flow from finance microservices to the accounts Srv1 back end.
location = "us-east"
}

Change the name of the service instance (parameter “name”) and the plan (parameter “plan”) according to your requirements.
2. Create a Terraform execution plan.

terraform plan
3. Remove the namespace and re-create it with a new name. Note that this process might take a few minutes to complete.

terraform apply
4. Verify on the [Instances page](https://cloud.ibm.com/quantum/instances) that your service instance has been created.



Qiskit Runtime service instances are IAM managed resources. Access can be shaped through terraform using IAM user policies. See [ibm_iam_user_policy](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_user_policy) for more details and examples.
Open the manifest.yml file, and change the name from GetStartedTomcat to your app name, app_name.

apps:
- name: GetStartedTomcat
random-route: true
memory: 256M
path: target/GetStartedTomcat.war
buildpack: java_buildpack

In this manifest.yml file, random-route: true generates a random route for your app to prevent your route from colliding with others. If you choose to, you can replace random-route: true with host: myChosenHostName, supplying a host name of your choice.





 Step 4: Deploy the app 

You can use the IBM Cloud® CLI to deploy apps.



1. Log in to your IBM Cloud® account, and select an API endpoint.

ibmcloud login

If you have a federated user ID, instead use the following command to log in with your single sign-on ID. See [Logging in with a federated ID](https://cloud.ibm.com/docs/account?topic=account-federated_id) for more information.

ibmcloud login --sso
2. Next, target a Cloud Foundry org and space:

ibmcloud target --cf

If you don't have an org or a space set up, see [Adding orgs and spaces](https://cloud.ibm.com/docs/account?topic=account-orgsspacesusers).
3. From within the get-started-tomcat directory, push your app to IBM Cloud

ibmcloud cf push

This can take around two minutes. If there is an error in the deployment process you can use the command ibmcloud cf logs <Your-App-Name> --recent to troubleshoot.



When deployment completes you should see a message indicating that your app is running. View your app at the URL listed in the output of the push command. You can also issue the following command to view your apps status and see the URL.

ibmcloud cf apps
You can either download (pull) a chart from another repository to your local computer, or build your own chart by using the [helm create](https://helm.sh/docs/helm/helm_create/) command. To add a chart to your namespace, you must upload (push) the local chart to your namespace in IBM Cloud Container Registry.

Do not put personal information in your charts (for example, in namespace names or description fields) or in any chart or chart configuration data (for example, chart names or chart labels).



 Pulling charts from another registry or Helm repository 

You can pull (download) a chart from any private or public

registrysource or Helm repository, and then tag it for later use in IBM Cloud Container Registry.

Zoom

![Pull a chart from a private or public registry or Helm repository to your computer.](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/images/pulling_images_mul.svg)

Figure 1. Pulling charts from another registry

Before you begin, complete the following tasks.



* [Install the CLI](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespacecli_namespace_registry_cli_install) to work with your namespace.
* [Set up your own namespace in IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup).
* Install the latest release of [Helm CLI](https://github.com/helm/helm/releases) to work with charts.





1. Download the Helm chart to your local computer.



* Download the Helm chart from the OCI registry:

helm pull oci://<registry/<my_namespace>/<chart_name> --version <chart_version>
name Optional Enter a name for your workspace. For more information, see [Designing your workspace structure](https://cloud.ibm.com/docs/schematics?topic=schematics-workspace-setupstructure-workspace). If you update the name of the workspace, the ID of the workspace does not change. 
 type Optional The Terraform version that you want to use to run your Terraform code. Enter Terraform_v1.1 to use Terraform version 1.1, Terraform_v1.0 to use Terraform version 1.0, and similarly, terraform_v0.15, terraform_v0.14, terraform_v0.13, terraform_v0.12. For example, when you specify terraform_v1.1 means users can have template that are of Terraform v1.1.0, v1.1.1, or v1.1.2, so on. Make sure that your Terraform config files are compatible with the Terraform version that you specify. This is a required variable. If the Terraform version is not specified, By default, Schematics selects the version from your template. 
 description Optional Enter tags that you want to associate with your workspace. Tags can help you find your workspace faster. 
 resource_group Optional Enter the resource group where you want to provision your workspace. 
 workspace_status Optional Freeze or unfreeze a workspace. If a workspace is frozen, changes to the workspace are disabled. 
 template_repo.url Optional Enter the URL to the GitHub or GitLab repository where your Terraform configuration files are stored. 
 template_repo.branch Optional Enter the GitHub or GitLab branch where your Terraform configuration files are stored. Now, in template repository, you can also update URL with more parameters as shown in the block. 
 template_repo.datafolder Optional Enter the GitHub or GitLab branch where your Terraform configuration files are stored. 
 template_repo.release Optional Enter the GitHub or GitLab release that points to your Terraform configuration files.
Make sure to create the PVC with the customized storage class that the cluster admin created and use the same name for your PVC that you used for your secret. Using the same name for the secret and the PVC triggers the storage provider to apply the settings of the secret in your PVC.







 Enforcing base64 encoding for the Key Protect root key CRN 



1. As the cluster admin, create a Kubernetes secret that includes the base64 encoded value for your Key Protect root key CRN. To retrieve the root key CRN, see [Setting up encryption for your Block Storage for VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-encryption).

apiVersion: v1
kind: Secret
type: vpc.block.csi.ibm.io
metadata:
name: <secret_name>
namespace: <namespace_name>
stringData:
encrypted: <true_or_false>
resourceGroup: "<resource_group>"
data:
encryptionKey: <encryption_key>

name
: Enter a name for your Kubernetes secret.

namespace
: Enter the namespace where you want to create your secret. To reference the secret in your PVC, the PVC must be created in the same namespace.

encrypted
: In the string data section, enter true to create a secret that sets up encryption for Block Storage for Classic volumes. If you set this option to true, you must provide the root key CRN of your Key Protect service instance that you want to use in parameters.encryptionKey. For more information about encrypting your data, see [Setting up encryption](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-block-encryption) for your Block Storage for VPC.

encryptionKey
: In the data section, if you entered truefor parameters.encrypted, then enter the root key CRN of your Key Protect service instance that you want to use to encrypt your Block Storage for Classic volume.
Create a PVC configuration file that is named pvc.yaml and that references the Kubernetes secret where you stored the Key Protect service credentials. To create this secret, see [Setting up encryption for Block Storage for Classic](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_encryption_setup).

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: <pvc_name> Enter a name for your PVC.
annotations:
volume.beta.kubernetes.io/storage-class: "<storage_class>" Enter a storage class. To see a list of storageclasses run kubectl get storageclasses.
labels:
encrypted: "true"
encryptionKeyNamespace: <namespace> Enter the namespace where your secret was created.
encryptionKeySecret: <secret_name> Enter the name of the secret you created.
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Show more
3. Create the PVC in your cluster.

oc apply -f pvc.yaml
4. Check the status of your PVC.

oc get pvc
5. Wait for your PVC to bind, then [create a deployment that uses your PVC](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageadd_block).
6. [Verify the encryption of your Block Storage for Classic volumes](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storageblock_encrypt).







 Verifying the encryption of your Block Storage for Classic volumes 

You can verify the encryption of your volumes by checking the volume mount path.



1. Log in to your app pod. Replace <pod_name> with the name of the pod that mounts your encrypted Block Storage for Classic volume.
Follow the steps in [Dynamic provisioning: Creating the PVC when you create a stateful set](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_dynamic_statefulset) to create your stateful set. The name of your PVC follows the format <volume_name>-<statefulset_name>-<replica_number>. Make sure to use the following values from your PVC name in the stateful set specification: spec.volumeClaimTemplates.metadata.name : Enter the <volume_name> of your PVC name.

metadata.name
: Enter the <statefulset_name> of your PVC name.

spec.replicas
: Enter the number of replicas that you want to create for your stateful set. The number of replicas must equal the number of PVCs that you created earlier.

If your PVCs are in different zones, don't include a region or zone label in your stateful set.
3. Verify that the PVCs are used in your stateful set replica pods by listing the pods in your cluster. Identify the pods that belong to your stateful set.

kubectl get pods
4. Verify that your existing PVC is mounted to your stateful set replica. Review the ClaimName in the Volumes section of your CLI output.

kubectl describe pod <pod_name>

Example output

Name: nginx-0
Namespace: default
Node: 10.xxx.xx.xxx/10.xxx.xx.xxx
Start Time: Fri, 05 Oct 2022 13:24:59 -0400
...
Volumes:
myvol:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: myvol-nginx-0
...









 Changing the size and IOPS of your existing storage device 

If you want to increase storage capacity or performance, you can modify your existing volume.
List existing stateful sets in your cluster.

oc get statefulset --all-namespaces

Example output

NAME DESIRED CURRENT AGE
mystatefulset 3 3 6s
2. View the Pods Status of each stateful set to ensure that the deployment of the stateful set is finished.

oc describe statefulset <statefulset_name>

Example output

Name: nginx
Namespace: default
CreationTimestamp: Fri, 05 Oct 2022 13:22:41 -0400
Selector: app=nginx,billingType=hourly,region=us-south,zone=dal10
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10
Annotations: oc.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
Replicas: 3 desired | 3 total
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10

A stateful set is fully deployed when the number of replicas that you find in the Replicas section of your CLI output equals the number of Running pods in the Pods Status section. If a stateful set is not fully deployed yet, wait until the deployment is finished before you proceed.
3. Create a configuration file for your stateful set and the service that you use to expose the stateful set.

Example stateful set that specifies a zone. The following example shows how to deploy NGINX as a stateful set with 3 replicas. For each replica, a 20 gigabyte File Storage for Classic device is provisioned based on the specifications in the ibmc-file-retain-bronze storage class.
<SECRET_NAME> is the name of the secret.

<INGESTION_URL> indicates the ingestion endpoint. You must set this value to the ingestion endpoint for the region where the Monitoring instance is available.
2. Apply the changes. Run the following command:

kubectl apply -f prometheus-prometheus.yaml -n <PROMETHEUS_NAMESPACE>



The Prometheus Operator will restart the Prometheus StatefulSets.





 Prometheus with Helm 

For Prometheus v2.25 and previous versions, follow these instructions:



1. Configure the Helm Prometheus values file values.yml and include the remote_write block inside the server section:

... server:
extraSecretMounts:
- name: secret-file
mountPath: /etc/secrets/
secretName: <SECRET_NAME>
remoteWrite:
- url: "https://<INGESTION_URL>/prometheus/remote/write"
bearer_token_file: /tmp/bearer/<SECRET_NAME>
...

Where

<SECRET_NAME> is the name of the secret.

<INGESTION_URL> indicates the ingestion endpoint. You must set this value to the ingestion endpoint for the region where the Monitoring instance is available.
2. Upgrade the Prometheus Helm release.

helm upgrade -f prometheus-values.yml <release name> prometheus-community/prometheus -n <PROMETHEUS_NAMESPACE>



For Prometheus version 2.26 and later versions, follow these instructions:



1. Configure the Helm Prometheus values file values.yml and include the remote_write block inside the server section:

... server:
remoteWrite:
- url: "https://<INGESTION_URL>/prometheus/remote/write"
authorization:
credentials_file: /etc/secrets/<SECRET_NAME>
...

Where
name: iks-ca-configmap
namespace: kube-system
resourceVersion: "2227854"
selfLink: /api/v1/namespaces/kube-system/configmaps/iks-ca-configmap
uid: b45d047b-f406-11e8-b7f0-82ddffc6e65e

If you already deleted the Helm chart and see a message such as iks-ca-configmap not found, [redeploy the cluster autoscaler Helm chart](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-helmcluster-scaling-helm) to your cluster and try to remove it again.
3. Disable the add-on or uninstall the Helm chart.
4. Add-on Disable the add-on.

ibmcloud ks cluster addon disable cluster-autoscaler --cluster <cluster_name>
5. Verify the add-on is disabled.

ibmcloud ks cluster addon ls --cluster <cluster_name>
6. Helm chart List your existing Helm charts and note the name of the cluster autoscaler.

helm list --all-namespaces
7. Remove the existing Helm chart from your cluster.

helm uninstall ibm-iks-cluster-autoscaler -n <namespace>







 Cluster autoscaler Helm chart parameter reference 

This table refers to the cluster autoscaler Helm chart parameters. For add-on values, see [Cluster autoscaler add-on parameter reference](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-install-addonca_addon_ref)

api_route
: Set the IBM Cloud Kubernetes Service API [endpoint](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cli_api) for the region that your cluster is in. No default; uses the targeted region that your cluster is in.
Deploy apps into the labeled namespace, or redeploy apps that are already in the namespace.

kubectl apply <myapp>.yaml --namespace <namespace>
4. Optional To redeploy an app in that namespace, delete the app pod so that it is redeployed with the injected sidecar.

kubectl delete pod -l app=<myapp>
5. If you didn't create a service to expose your app, create a Kubernetes service. Your app must be exposed by a Kubernetes service to be included as a microservice in the Istio service mesh. Ensure that you follow the [Istio requirements for pods and services](https://istio.io/latest/docs/ops/deployment/requirements/).
6. Define a service for the app.

apiVersion: v1
kind: Service
metadata:
name: myappservice
spec:
selector:
<selector_key>: <selector_value> Enter the label key selector_key and value selector_value pair that you want to use to target the pods where your app runs.
ports:
- protocol: TCP
port: 8080 The port that the service listens on
7. Create the service in your cluster. Ensure that the service deploys into the same namespace as the app.

kubectl apply -f myappservice.yaml -n <namespace>



The app pods are now integrated into your Istio service mesh because they have the Istio sidecar container that runs alongside your app container.





 Manually injecting sidecars 

If you don't want to enable automatic sidecar injection for a namespace, you can manually inject the sidecar into a deployment YAML. Inject sidecars manually when apps are running in namespaces alongside other deployments that you don't want sidecars automatically injected into.

Do not enable sidecar injection for the kube-system, ibm-system, or ibm-operators namespaces.



1. Download the istioctl client.
1. Copy the role binding from one namespace to another namespace.

kubectl get rolebinding <role_binding_name> -o yaml | sed 's/<namespace_1>/<namespace_2>/g' | kubectl -n <namespace_2> create -f -

For example, copy the custom-role role binding from the default namespace to the testns namespace.

kubectl get rolebinding custom-role -o yaml | sed 's/default/testns/g' | kubectl -n testns create -f -
2. Verify that the role binding is copied. If you added an IBM Cloud IAM access group to the role binding, each user in that group is added individually, not as an access group ID.

kubectl get rolebinding -n <namespace_2>





Now that you created and bound a custom Kubernetes RBAC role or cluster role, follow up with users. Ask them to test an action that they have permission to complete due to the role, such as deleting a pod.





 Extending existing permissions by aggregating cluster roles 

You can extend your users' existing permissions by aggregating, or combining, cluster roles with other cluster roles. When you assign a user an IBM Cloud service access role, the user is added to a [corresponding Kubernetes RBAC cluster role](https://cloud.ibm.com/docs/containers?topic=containers-iam-service-access-roles). However, you might want to allow certain users to perform additional operations.

For example, a user with the namespace-scoped admin cluster role can't use the kubectl top pods command to view pod metrics for all the pods in the namespace. You might aggregate a cluster role so that users in the admin cluster role are authorized to run the top pods command. For more information, [see the Kubernetes docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/aggregated-clusterroles).