vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You have defined an agent-assignment-policy for the agent running in Dev, with the selector as tags=dev. All workspaces that have tags=dev automatically are bound to the Dev agent. In other words, the Dev agent is used to download Terraform templates (from the Git repository) and run Terraform jobs. Similarly, the agent-assignment-policy can include other attributes of the workspaces, to define the agent for job execution.
* How can I enable debug mode in an agent?

You can follow these steps to enable or disable the debug mode of an agent.



1. Log in to [IBM Cloud](https://cloud.ibm.com/).
2. Click Kubernetes from the left hand navigator pane, then click Clusters
3. On the Kubernetes Clusters page, click your cluster > Kubernetes dashboard.



* Click the default drop down to view the list of Namespaces:



* In the drop down, type the Schematics-job-runtime Namespaces.
* Click Config Map from the Config and Storage.
* From the Config Maps page. Click the three dots against schematics-jobrunner-config.
* Click Edit to view the Edit a resource page with the YAML, and JSON tabs.
* You can now edit the JR_LOGGERLEVEL parameter for job-runner microservice logging. By default the value is -1 that indicated disable debug, to enable you need to edit JR_LOGGERLEVEL as 0.
* Click Update to apply your edits.







* Can I upgrade an agent beta-0 to agent beta-1?

No, you cannot upgrade agent beta-0 setup to agent beta-1.
* Does agent beta-1 support backward compatibility?

Agents beta-1 does not support backward compatibility. You need to create a new agent by using the [agent beta-1](https://cloud.ibm.com/docs/schematics?topic=schematics-agentb1-about-intro) setup.
* Review [known limitations for VPC ALBs](https://cloud.ibm.com/docs/vpc?topic=vpc-lb-limitations) and [known limitations for VPC NLBs](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-limitations).
* Private VPC ALBs don't accept all traffic, only RFC 1918 traffic.
* Private VPC NLBs must be created on a dedicated VPC subnet that must exist in the same VPC and location as your cluster, but the subnet can't be attached to your cluster or any worker nodes.
* Kubernetes 1.23 or later: Although the Kubernetes [SCTP protocol](https://kubernetes.io/docs/concepts/services-networking/service/sctp) is generally available in the Kubernetes community release, creating load balancers that use this protocol is not supported in IBM Cloud Kubernetes Service clusters.
* One VPC load balancer is created for each Kubernetes LoadBalancer service that you create, and it routes requests to that Kubernetes LoadBalancer service only. Across all your VPC clusters in your VPC, a maximum of 50 VPC load balancers can be created. For more information, see the [VPC quotas documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas).
* The VPC load balancer can route requests to a limited number of worker nodes. The maximum number of nodes you can route requests to depends on how you set the externalTrafficPolicy annotation.



* If you set externalTrafficPolicy: Cluster in your load balancer configuration:



Versions 1.25 and later

The VPC load balancer routes to the first 8 worker nodes that are discovered in each zone. For a single-zone cluster, the load balancer routes to 8 worker nodes total. The kube-proxy configures IP tables to route the incoming traffic from the worker node to the application pod on whichever node the application pod resides on.
Versions 1.24 and earlier
When you assign permissions to a group, any user that is added or removed from that group is affected. If you add a user to the group, then they also have the additional access. If they are removed, their access is revoked.

IBM Cloud IAM roles can't be assigned to a service account. Instead, you can directly [assign RBAC roles to service accounts](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac).

You must also specify whether users have access to one cluster in a resource group, all clusters in a resource group, or all clusters in all resource groups in your account.





 Scope user access to cluster instances, namespaces, or resource groups 

In IBM Cloud IAM, you can assign user access roles to resource instances, Kubernetes namespaces, or resource groups.

When you create your IBM Cloud account, the default resource group is created automatically. If you don't specify a resource group when you create the resource, resource instances (clusters) automatically belong to the default resource group. In IBM Cloud IAM, a Kubernetes namespace is a resource type of a resource instance (cluster). If you want to add a resource group in your account, see [Best practices for setting up your account](https://cloud.ibm.com/docs/account?topic=account-account_setup) and [Setting up your resource groups](https://cloud.ibm.com/docs/account?topic=account-rgs).

Resource instance
: Each IBM Cloud service in your account is a resource that has instances. The instance differs by service. For example, in IBM Cloud Kubernetes Service, the instance is a cluster. By default, resources belong to the default resource group in your account. You can assign users an access role to a resource instance to grant permissions as described in the following scenarios.



* All IBM Cloud IAM services in your account, including all clusters in IBM Cloud Kubernetes Service and images in IBM Cloud Container Registry.
* All instances within a service, such as all the clusters in IBM Cloud Kubernetes Service.
* Review [known limitations for VPC ALBs](https://cloud.ibm.com/docs/vpc?topic=vpc-lb-limitations) and [known limitations for VPC NLBs](https://cloud.ibm.com/docs/vpc?topic=vpc-nlb-limitations).
* Private VPC ALBs don't accept all traffic, only RFC 1918 traffic.
* Private VPC NLBs must be created on a dedicated VPC subnet that must exist in the same VPC and location as your cluster, but the subnet can't be attached to your cluster or any worker nodes.
* Red Hat OpenShift 4.10 or later: Although the Kubernetes [SCTP protocol](https://kubernetes.io/docs/concepts/services-networking/service/sctp) is generally available in the Kubernetes community release, creating load balancers that use this protocol is not supported in IBM Cloud Kubernetes Service clusters.
* One VPC load balancer is created for each Kubernetes LoadBalancer service that you create, and it routes requests to that Kubernetes LoadBalancer service only. Across all your VPC clusters in your VPC, a maximum of 50 VPC load balancers can be created. For more information, see the [VPC quotas documentation](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas).
* The VPC load balancer can route requests to a limited number of worker nodes. The maximum number of nodes you can route requests to depends on how you set the externalTrafficPolicy annotation.



* If you set externalTrafficPolicy: Cluster in your load balancer configuration:



Versions 1.25 and later

The VPC load balancer routes to the first 8 worker nodes that are discovered in each zone. For a single-zone cluster, the load balancer routes to 8 worker nodes total. The kube-proxy configures IP tables to route the incoming traffic from the worker node to the application pod on whichever node the application pod resides on.
Versions 1.24 and earlier
(https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingsvc-bind-what)
* [I already have an IBM Cloud service. Can I still use IBM Cloud service binding?](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingsvc-bind-existing)
* [What if I want to use service credentials that use the private cloud service endpoint?](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingsvc-bind-private-cse)
* [Can I use all IBM Cloud services in my cluster?](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingsvc-bind-which)
* [Can I bind multiple IBM Cloud services to multiple clusters at once?](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingsvc-bind-trusted-profile)



* [Adding IBM Cloud services to clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingbind-services)
* [Accessing service credentials from your apps](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingadding_app)



* [Mounting the secret as a volume to your pod](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingmount_secret)
* [Referencing the secret in environment variables](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingreference_secret)



* [Removing a service from a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingunbind-service)







 Understanding high availability and disaster recovery
Customize ALB routing rules with [annotations](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotations).







 Planning private external load balancing 

Privately expose an app in your cluster to the private network only.

When you deploy an app in a Kubernetes cluster in IBM Cloud Kubernetes Service, you might want to make the app accessible to only users and services that are on the same private network as your cluster. Private load balancing is ideal for making your app available to requests from outside the cluster without exposing the app to the general public. You can also use private load balancing to test access, request routing, and other configurations for your app before you later expose your app to the public with public network services.

As an example, say that you create a private load balancer for your app. This private load balancer can be accessed by:



* Any pod in that same cluster.
* Any pod in any cluster in the same IBM Cloud account.
* If you're not in the IBM Cloud account but still behind the company firewall, any system through a VPN connection to the subnet that the load balancer IP is on.
* If you're in a different IBM Cloud account, any system through a VPN connection to the subnet that the load balancer IP is on.
* In classic clusters, if you have [VRF or VLAN spanning](https://cloud.ibm.com/docs/containers?topic=containers-subnetsbasics_segmentation) enabled, any system that is connected to any of the private VLANs in the same IBM Cloud account.
* In VPC clusters:



* If you permit traffic between VPC subnets, any system in the same VPC.
* If you permit traffic between VPCs, any system that has access to the VPC that the cluster is in.







 Choosing a deployment pattern for classic clusters 

To make an app available over a private network only in classic clusters, choose a load balancing deployment pattern based on your cluster's VLAN setup:
* [Microsoft Azure](https://cloud.ibm.com/docs/satellite?topic=satellite-azure).







 Clusters 

See [Satellite cluster limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationssatellite_limits) in the Red Hat OpenShift on IBM Cloud documentation. The limitations include information related to the following components.



* Red Hat OpenShift on IBM Cloud clusters that you create in your Satellite location.
* Storing data in Kubernetes persistent volumes for apps that run in your clusters.
* Cluster networking, such as Kubernetes load balancers.
* Using your hosts as the worker nodes in the cluster.







 Link and endpoints 

Link connector instances
: The Satellite Link connector instances that run in your [Satellite location control plane worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-service-architecture) are limited to three instances, one per host. Even if you attach hosts to the location control plane, network traffic that is routed through the Satellite Link connector is sent only over three hosts.

Cloud and location endpoints
: Review the maximum number of each type of Link endpoint that you can create for one Satellite location.



* cloud endpoints: 1000 total. For example, you might create up to 650 TLS endpoints and 350 HTTP endpoints through which clients in your location can connect to resources outside of the location network.
* location endpoints: 25 total. For example, you might create up to 20 TLS endpoints and 5 HTTP endpoints through which clients outside of your location network can connect to resources inside the location.







 Config 

Review the following application configuration requirements for Satellite Config.

Satellite Config is not supported on locations that are enabled for Red Hat CoreOS.

Satellite Config access to modify Kubernetes resources within a cluster
: By default, Satellite Config is limited to what Kubernetes resources it can read and modify in your clusters. You must grant Satellite Config access in each cluster where you want to use Satellite Config to manage your Kubernetes resources.
: Choose from the following options.
* UI
* API







 Authorizing pods in your cluster to IBM Cloud services with IAM trusted profiles 

Virtual Private Cloud

Classic infrastructure

Satellite

Give application pods that run in your Red Hat® OpenShift® on IBM Cloud® cluster access to IBM Cloud services by creating a trusted profile in IBM Cloud Identity and Access Management (IAM).

You can enable IAM trusted profiles by running the [ibmcloud oc cluster master refresh](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_apiserver_refresh) command.

In IAM
: Start by creating an IAM trusted profile. Then, link the trusted profile with your Red Hat OpenShift on IBM Cloud compute resource by selecting conditions to match with your clusters, including a Kubernetes namespace and service account in the clusters. Finally, assign access policies to the IBM Cloud services that you want your apps to use.

In your cluster
: Through [Kubernetes service account token volume projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/service-account-token-volume-projection), the apps that run in your linked cluster's [Kubernetes namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and use the namespace's service account can exchange the service account public key to get an IBM Cloud IAM access token. Your app can use this access token to authenticate API requests to IBM Cloud services, such as databases, Watson, or VPC infrastructure. Through the access policies of the trusted profile, you control what actions the token lets the app perform.



 Prerequisites 

To use IBM Cloud IAM identities for pods in your cluster, verify that you meet the prerequisites.

Minimum required permissions
You can create new Helm charts or use preexisting Helm charts to define, install, and upgrade complex Kubernetes applications that run in IBM Cloud Kubernetes Service clusters. For example, you can specify all Kubernetes resources that your app requires in a Helm chart. Then, you can use Helm to create the YAML configuration files and deploy these files in your cluster..
: In Red Hat OpenShift clusters that run version 4, use [Operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators) instead of Helm charts. If you have custom Helm charts, you can create a [Helm-based Operator](https://docs.openshift.com/container-platform/4.7/operators/operator_sdk/) instead.

Kustomize
: Use the Kubernetes project [Kustomize](https://github.com/kubernetes-sigs/kustomize) to package your apps by both standardizing and customizing your deployments across multiple environments. Kustomize helps you write, customize, and reuse your Kubernetes resource YAML configurations. To get started, see [Packaging apps for reuse in multiple environments with Kustomize](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_appskustomize).

Operators
: With operators, you can manage the lifecycle of the apps in your cluster, including third-party software and services that you integrate into your cluster from the [OperatorHub](https://operatorhub.io/). You can consistently install, update, and monitor system components by using operators or by making operators available to developers that work in specific projects or across projects. To set up operators, see [Using Operators in version 4 clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-operatorsoperators_4).

Razee
* Record information about the COS resources such as COS instance name, COS bucket name for the later use.



* IAM access permission: At a minimum you must have access permissions for the Kubernetes service, Resource Group, Object Storage, and the Schematics service to [deploy an agent](https://cloud.ibm.com/docs/schematics?topic=schematics-deploy-agent-overview&interface=cli).



* When deploying an agent in another account, or when using a ServiceID or APIKey, you must ensure that the account administrator has granted the required permission for all the services enlisted in [permission to deploy an agent](https://cloud.ibm.com/docs/schematics?topic=schematics-accessagent-permissions).



* IBM Cloud CLI: Use the latest version of IBM Cloud CLI and the [Schematics CLI v1.12.9](https://cloud.ibm.com/docs/schematics?topic=schematics-setup-cliinstall-schematics-plugin) or higher plugin to install an agent. For more information about plugin installation, see [installing Schematics CLI plugin](https://cloud.ibm.com/docs/schematics?topic=schematics-setup-cliinstall-schematics-plugin).



You can deploy only one agent instance in a Kubernetes cluster. To deploy multiple agents in a single IBM Cloud account, they must be on different Kubernetes clusters. Each agent and cluster can cater to different network isolation zones in your Cloud environment.

In this Beta release, an agent can only be associated with and run jobs for one IBM Cloud account. Agents cannot be shared with other accounts or run jobs for multiple accounts. The diagram represents association of agents with a Schematics instance. Here multiple agents for a single account are associated with a single Schematics instance.

Zoom

!
[Create a public LoadBalancer service](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas) in your cluster. A multizonal VPC load balancer is automatically created in your VPC that assigns a hostname to your LoadBalancerservice for your app. 
 Ingress HTTP(S) load balancing that exposes the app with a subdomain and uses custom routing rules. Implement custom routing rules and SSL termination for multiple apps. [Create an Ingress resource](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-public-expose&interface=uiingress-public-se) for the default public Ingress controller in clusters with a public cloud service endpoint, or [create an Ingress resource](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-public-exposeingress-public-expose-vpc-private-se) for a custom public Ingress controller in clusters with a private cloud service endpoint only. 









 Planning private external load balancing 

Privately expose an app in your cluster to the private network only.

When you deploy an app in a Kubernetes cluster in IBM Cloud Kubernetes Service, you might want to make the app accessible to only users and services that are on the same private network as your cluster. Private load balancing is ideal for making your app available to requests from outside the cluster without exposing the app to the general public. You can also use private load balancing to test access, request routing, and other configurations for your app before you later expose your app to the public with public network services.

As an example, say that you create a private load balancer for your app. This private load balancer can be accessed by:



* Any pod in that same cluster.
* Any pod in any cluster in the same IBM Cloud account.
* If you're not in the IBM Cloud account but still behind the company firewall, any system through a VPN connection to the subnet that the load balancer IP is on.
Classic: Setting up DSR load balancing with an NLB 2.0 

Version 2.0 NLBs can be created in classic clusters only, and can't be created in VPC clusters. To load balance in VPC clusters, see [Exposing apps with load balancers for VPC](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas).

Expose a port and use a portable IP address for a Layer 4 network load balancer (NLB) to expose a containerized app. For more information about version 2.0 NLBs, see [Components and architecture of an NLB 2.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-aboutplanning_ipvs).



 Prerequisites 

You can't update an existing version 1.0 NLB to 2.0. You must create a new NLB 2.0. Note that you can run version 1.0 and 2.0 NLBs simultaneously in a cluster.

Before you create an NLB 2.0, you must complete the following prerequisite steps.



1. To allow your NLB 2.0 to forward requests to app pods in multiple zones, open a support case to request capacity aggregation for your VLANs. This configuration setting does not cause any network disruptions or outages.



1. Log in to the [IBM Cloud console](https://cloud.ibm.com/).
2. From the menu bar, click Support, click the Manage cases tab, and click Create new case.
3. In the case fields, enter the following: Topic: Network - Provisioning Subtopic: Classic - VLAN
4. Add the following information to the description: Please set up the network to allow capacity aggregation on the public and private VLANs associated with my account. This is related to https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-v2ipvs_provision, and is needed so I can configure NLB v2.0 LoadBalancers in my Classic Kubernetes Cluster..
(https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/ha-cluster-multizone.svg)

Figure 1. High availability for multizone clusters

In a multizone cluster, the worker nodes in your worker pools are replicated across multiple zones within one region. Multizone clusters are designed to evenly schedule pods across worker nodes and zones to assure availability and failure recovery. If worker nodes are not spread evenly across the zones or capacity is insufficient in one of the zones, the Kubernetes scheduler or Red Hat OpenShift controller might fail to schedule all requested pods. As a result, pods might go into a Pending state until enough capacity is available. If you want to change the default behavior to make Kubernetes scheduler or Red Hat OpenShift controller distribute pods across zones in a best effort distribution, use the preferredDuringSchedulingIgnoredDuringExecution[pod affinity policy](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

You can create a multizone cluster in one of the supported [classic](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz) or [VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-vpc) multizone locations only.



 Why do I need worker nodes in three zones? 

Distributing your workload across three zones ensures high availability for your app in case a zone becomes unavailable. You must have your worker nodes spread evenly across all three availability zones to meet the [IBM Cloud service level agreement (SLA)](https://cloud.ibm.com/docs/overview?topic=overview-slas) for HA configuration. This setup also makes your cluster more cost-efficient. Why is that, you ask? Here is an example.