vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In RHCOS enabled locations, when you want to add worker pools to your cluster, you can use RHCOS or RHEL hosts. Make sure to attach hosts with the operating system that you want to use to your location before assigning them to a worker pool.
6. In the Worker pools section, configure the details for your default worker pool.



1. Select the Satellite zones that Satellite uses to evenly assign hosts across zones that represent zones in your underlying infrastructure provider. Generally, create your worker pool across 3 zones for high availability.
2. Request the vCPU, Memory (GB), and number of Worker nodes per zone that you want to create the worker pool with. Satellite can automatically assign available hosts to the worker pool to fulfill your request. Generally, select at least 1 worker node per zone for a total of 3 worker nodes in your cluster.



7. In the Satellite Config section, decide whether to enable cluster admin access for Satellite Config. If you don't grant Satellite Config access, you can't later use the Satellite Config functionality to view or deploy Kubernetes resources for your clusters.If you want to enable access later, you can [create custom RBAC roles for Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfigmanual-setup-clusters-satconfig).
8. For the Resource details, enter a Cluster name and any [IBM Cloud tags](https://cloud.ibm.com/docs/account?topic=account-tag) that you want to associate with your cloud resource. The cluster name must start with a letter, can contain letters, numbers, and hyphen (-), and must be 35 characters or fewer.
9. Click Create. When you create the cluster, the cluster master is automatically created in your Satellite location control plane, and your worker pool is automatically assigned available hosts that match your worker node request.
10. Wait for the cluster to reach a Normal state.

If you don't have any available and matching hosts in your Satellite location, the cluster is still created but enters a Warning state.
Target the region of the VPC that your cluster is deployed to.

ibmcloud target -r <region>
2. Check whether you have a public gateway in a zone where you have worker nodes. Within one VPC, you can create only one public gateway per zone, but that public gateway can be attached to multiple subnets within the zone.

ibmcloud is public-gateways

Example output

ID Name VPC Zone Floating IP Created Status Resource group
26426426-6065-4716-a90b-ac7ed7917c63 test-pgw testvpc(36c8f522-.) us-south-1 169.xx.xxx.xxx(26466378-.) 2019-09-20T16:27:32-05:00 available -
2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374 team3(ff537d43-.) us-south-2 169.xx.xxx.xxx(2ba9a280-.) 2019-08-02T10:30:29-05:00 available -



* If you already have a public gateway in a zone where you have workers and in the VPC that your cluster is in, note the gateway's ID.
* If you don't have a public gateway in a zone where you have workers and in the VPC that your cluster is in, create a public gateway. Consider naming the public gateway in the format <cluster>-<zone>-gateway. In the output, note the public gateway's ID.

ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>

Example output

ID 26466378-6065-4716-a90b-ac7ed7917c63
Name mycluster-us-south-1-gateway
* [odf-remote](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-odf-remote): Choose this template if you have a CSI driver installed in your cluster. For example, the azuredisk-csi-driver driver. You can use the CSI driver to dynamically provision storage volumes when deploying ODF.







 Prerequisites for ODF 

To use the ODF storage with the local storage operator and local storage devices, complete the following tasks:



1. Make sure you have the following permissions.



* Editor for the Billing service.
* Manager and Editor for Kubernetes service.
* Satellite Link Administrator and Reader for the Satellite service.



2. [Create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations).
3. [Create a Satellite cluster](https://cloud.ibm.com/docs/satellite?topic=openshift-satellite-clusters).



* Make sure that you select the Enable cluster admin access for Satellite Config option when you create the cluster. If you don't enable Administrator (admin) access for Satellite Config when creating your cluster, you must re-create your cluster and enable admin access before you can deploy storage.
* Your cluster must have a minimum of 3 worker nodes with at least 16CPUs and 64GB RAM per worker node.
* Your hosts must meet the [Satellite host requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs) in addition to having one of the following local storage configurations.



* One extra raw device per worker node in addition to the minimum host requirements. This disk must not be partitioned or have formatted file systems.
* One extra raw partition per worker node in addition to the minimum host requirements. If your host storage devices are partitioned, they must have at least one extra raw/unformatted partition per disk, per worker node.
* Two extra raw devices per worker node in addition to the minimum host requirements. These disks must not be partitioned or formatted file systems.
* [Getting started with toolchains](https://cloud.ibm.com/devops/getting-started)









 Step 1: Create the toolchain 

In this step, you create a Develop and Deploy application to Kubernetes using deployment strategies toolchain. The target Kubernetes cluster is configured during the toolchain setup by using your IBM Cloud API key and your Kubernetes cluster name. You can change these settings later by updating the Delivery Pipeline configuration. Any code that is merged into the target Git repo branch is automatically built, validated, and deployed into the Kubernetes cluster.

To create a Develop and Deploy application to Kubernetes using deployment strategies toolchain, click

[![Create toolchain](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/create_toolchain_button.png)](https://cloud.ibm.com/devops/setup/deploy?repository=https://github.ibm.com/open-toolchain/secure-app-toolchain&env_id=ibm:yp:us-south)

Alternatively, from the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select DevOps. On the Toolchains page, click Create a Toolchain. On the Create a Toolchain page, click Develop and Deploy application to Kubernetes using deployment strategies.



 Configure the toolchain name and region 

Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud.
curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/satellite/createStorageConfigurationByController" -H "accept: application/json" -H "Authorization: TOKEN" -H "Content-Type: application/json" -d "{ "config-name": "string", "controller": "string", "storage-class-parameters": [ { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" } ], "storage-template-name": "ibm-system-storage-block-csi-driver", "storage-template-version": "1.11.1", "update-assignments": true, "user-config-parameters": { "entry.name": "NAMESPACE","user-secret-parameters": }







 Creating a storage assignment in the console 

If you didn't assign your configuration to a cluster or service when you created it, you can create an assignment by completing the following steps.



1. Open the [Satellite console](https://cloud.ibm.com/satellite/locations) in your browser.
2. Select the location where you created your storage configuration.
3. Click the Locations tab, then click Storage.
4. Click the storage configuration that you want to assign to a cluster group.
5. On the Configuration details page, click Create storage assignment.
6. In the Create an assignment pane, enter a name for your assignment.
7. From the Version drop-down list, select the storage configuration version that you want to assign.
8. From the Cluster group drop-down list, select the cluster group that you want to assign to the storage configuration. Note that the clusters in your cluster group where you want to assign storage must all be in the same Satellite location.
9. Click Create to create the assignment.
10. Verify that your storage configuration is deployed to your cluster.



1.
2. Enter a name for your service instance, such as cos-backup, and select the same resource group that your cluster is in. To view the resource group of your cluster, run ibmcloud ks cluster get --cluster <cluster_name_or_ID>.
3. Review the [plan options](https://cloud.ibm.com/objectstorage/create) for pricing information and select a plan.
4. Click Create. The service details page opens.
5. To continue to set up Object Storage to use with your cluster, see [Creating service credentials](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandservice_credentials).







 Creating IBM Cloud Object Storage service credentials 

Before you begin, [Create your object storage service instance](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandcreate_cos_service).



1. In the navigation on the service details page for your Object Storage instance, click Service Credentials.
2. Click New credential. A dialog box opens.
3. Enter a name for your credentials.
4. From the Role drop-down list, select the [Object Storage access role](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iamiam-roles) for the actions that you want storage users in your cluster to have access to. You must select at least Writer service access role to use the auto-create-bucket dynamic provisioning feature. If you select Reader, then you can't use the credentials to create buckets in IBM Cloud Object Storage and write data to it.
5. Optional: In Add Inline Configuration Parameters (Optional), enter {"HMAC":true} to create more HMAC credentials for the IBM Cloud Object Storage service. HMAC authentication adds an extra layer of security to the OAuth2 authentication by preventing the misuse of expired or randomly created OAuth2 tokens.
Keep this in mind and choose the same region for all resources in this tutorial.
2. [Create a resource group for the environment](https://cloud.ibm.com/account/resource-groups).
3. Create an instance of [IBM Cloud Activity Tracker](https://cloud.ibm.com/observe/activitytracker/create) for the region to allow the audit of all API calls for the region.
4. In that resource group create the services [Continuous Delivery](https://cloud.ibm.com/catalog/services/continuous-delivery), [IBM Cloud Object Storage](https://cloud.ibm.com/objectstorage/create), [IBM Log Analysis](https://cloud.ibm.com/catalog/services/logdna?callback=%2Fobserve%2Flogging%2Fcreate), [IBM Cloud Monitoring](https://cloud.ibm.com/catalog/services/ibm-cloud-monitoring?callback=%2Fobserve%2Fmonitoring%2Fcreate) and [IBM Cloudant](https://cloud.ibm.com/catalog/services/cloudant).
5. Create a [Virtual Private Cloud](https://cloud.ibm.com/vpc-ext/network/vpcs) including subnets. Select the resource group you created earlier and the region.
6. [Create a new Kubernetes cluster](https://cloud.ibm.com/kubernetes/catalog/cluster) in Kubernetes Service, under Infrastructure select the new VPC as target, make sure to select the resource group created above.
7. Create a [Virtual Servers for VPC instance](https://cloud.ibm.com/vpc-ext/compute/vs) in the same VPC.
8. From the Kubernetes cluster connect to the IBM Log Analysis and IBM Cloud Monitoring service instances to send logs and to monitor the cluster.



The following diagram shows where the project resources are created under the account:

Zoom

!
From the Access policies tab, confirm that you [have the required permissions to create clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions). Make sure that your account administrator does not assign you the Administrator platform access role at the same time as scoping the access policy to a namespace.



4. If your account uses multiple resource groups, figure out your account's strategy for [managing resource groups](https://cloud.ibm.com/docs/openshift?topic=openshift-access-overviewresource_groups).



* The cluster is created in the resource group that you target when you log in to IBM Cloud. If you don't target a resource group, the default resource group is automatically targeted.
* If you want to create a cluster in a different resource group than the default, you need at least the Viewer role for the resource group. If you don't have any role for the resource group, your cluster is created in the default resource group.
* You can't change a cluster's resource group.
* If you need to use the ibmcloud oc cluster service bind[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_service_bind) to [integrate with an IBM Cloud service](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingbind-services), that service must be in the same resource group as the cluster. Services that don't use resource groups like IBM Cloud Container Registry or that don't need service binding like IBM Log Analysis work even if the cluster is in a different resource group.
* Consider giving clusters unique names across resource groups and regions in your account to avoid naming conflicts. You can't rename a cluster.



5. Classic clusters only: Consider [creating a reservation](https://cloud.ibm.com/docs/openshift?topic=openshift-reservations) to lock in a discount over 1 or 3 year terms for your worker nodes.
For more options, see the [CLI documentation](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_pool_create_vpc_gen2). Note that the new worker nodes run the same major.minor version as the cluster master, but the latest worker node patch of that major.minor version. If you want to create your worker pool on dedicated hosts, make sure to specify the --dedicated-host-pool option.

ibmcloud ks worker-pool create vpc-gen2 --name <name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_worker_nodes_min_1> [--label <key>=<value>] [--vpc-id] [--kms-account-id <KMS_account_ID>] --kms-instance <KMS_instance_ID> --crk <root_key_ID>] [--dedicated-host-pool <dedicated-host-pool>] [--security-group <group-id>]
6. Verify that the worker pool is created.

ibmcloud ks worker-pool ls --cluster <cluster_name_or_ID>
7. By default, adding a worker pool creates a pool with no zones. To deploy worker nodes in a zone, you must add the zones that you previously retrieved to the worker pool. If you want to spread your worker nodes across multiple zones, repeat this command for each zone.

ibmcloud ks zone add vpc-gen2 --zone <zone> --subnet-id <subnet_id> --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name>
8. Verify that worker nodes provision in the zone that you added. Your worker nodes are ready when the State changes from provisioning to normal.

ibmcloud ks worker ls --cluster <cluster_name_or_ID> --worker-pool <pool_name>

Example output

ID Primary IP Flavor State Status Zone Version
You can [create](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_subnet_create) or [add](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_subnet_add) subnets to a cluster later.

--sm-group GROUP
: The secret group ID of the Secrets Manager instance where your secrets are persisted. To get a secret group ID, see the [Secrets Manager CLI reference](https://cloud.ibm.com/docs/secrets-manager-cli-plugin?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-secret-groups-cli).

--sm-instance INSTANCE
: The CRN of the Secrets Manager instance. To get the CRN of an instance, run [ibmcloud oc ingress instance ls --cluster CLUSTER](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_ingress_instance_ls).

--private-vlan PRIVATE_VLAN
: If this standard cluster is the first standard cluster that you create in this zone, don't include this option. A private VLAN is created for you when the cluster is created. If you created a standard cluster before in this zone or created a private VLAN in IBM Cloud infrastructure before, you must specify that private VLAN. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.
: To find out whether you already have a private VLAN for a specific zone or to find the name of an existing private VLAN, run ibmcloud oc vlan ls --zone ZONE.

--public-vlan PUBLIC_VLAN
Deploying apps with the CLI 

After a cluster is created, you can deploy an app into that cluster by using the Kubernetes CLI.

Before you begin



* Install the required [CLIs](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).
* [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
* Make sure that you are assigned a [service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) that grants the appropriate Kubernetes RBAC role so that you can work with Kubernetes resources in the namespace.



To deploy your app,



1. Create a configuration file based on [Kubernetes best practices](https://kubernetes.io/docs/concepts/configuration/overview/). Generally, a configuration file contains configuration details for each of the resources you are creating in Kubernetes. Your script might include one or more of the following sections:



* [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/): Defines the creation of pods and replica sets. A pod includes an individual containerized app and replica sets control multiple instances of pods.
* [Service](https://kubernetes.io/docs/concepts/services-networking/service/): Provides front-end access to pods by using a worker node or load balancer public IP address, or a public Ingress route.
* [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/): Specifies a type of load balancer that provides routes to access your app publicly.



Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with Kubernetes resources.
2.
Make sure that your account administrator does not assign you the Administrator platform access role at the same time as scoping the access policy to a namespace.



4. If your account uses multiple resource groups, figure out your account's strategy for [managing resource groups](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewresource_groups).



* The cluster is created in the resource group that you target when you log in to IBM Cloud. If you don't target a resource group, the default resource group is automatically targeted.
* If you want to create a cluster in a different resource group than the default, you need at least the Viewer role for the resource group. If you don't have any role for the resource group, your cluster is created in the default resource group.
* You can't change a cluster's resource group.
* If you need to use the ibmcloud ks cluster service bind[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_service_bind) to [integrate with an IBM Cloud service](https://cloud.ibm.com/docs/containers?topic=containers-service-bindingbind-services), that service must be in the same resource group as the cluster. Services that don't use resource groups like IBM Cloud Container Registry or that don't need service binding like IBM Log Analysis work even if the cluster is in a different resource group.
* Consider giving clusters unique names across resource groups and regions in your account to avoid naming conflicts. You can't rename a cluster.



5. Classic clusters only: Consider [creating a reservation](https://cloud.ibm.com/docs/containers?topic=containers-reservations) to lock in a discount over 1 or 3 year terms for your worker nodes. After you create the cluster, add worker pools that use the reserved instances. Typical savings range between 30-50% compared to regular worker node costs.
6. Standard clusters: Set up your IBM Cloud infrastructure networking to allow worker-to-master and user-to-master communication.
Then, come back here when you’re ready to plan out your production-ready clusters.

Review the following cluster configurations and take the appropriate action in your account before provisioning your clusters. For more information, see [Preparing to create clusters at the account level](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=ui).



* For VPC Clusters that don't require Classic Infrastructure Access, no account changes are required.
* For VPC Clusters that require Classic Infrastructure Access, you must [enable VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uivrf) & [service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uiservice-endpoint) in your account.
* For Classic clusters with a private service endpoint enabled, you must [enable VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uivrf) & [service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uiservice-endpoint).
If you enter a specific IP range, don't use the following reserved ranges: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16.



6. Select a standard IBM Cloud Object Storage instance where a bucket is automatically created for your cluster's internal registry.
7. Select the cluster version.
8. Optional: For the OCP entitlement section, select an entitlement for a worker pool, if you have one.



* Usually, select Purchase additional licenses for this worker pool.
* If you have an IBM Cloud Pak with a Red Hat OpenShift entitlement that you want to use, you can select Apply my Cloud Pak OCP entitlement to this worker pool.
* Later, when you configure the worker pool, make sure to select only the flavor and number of worker nodes that your entitlement permits.



9. Configure the Location details for your cluster.



1. Select the Resource group that you want to create your cluster in.



* A cluster can be created in only one resource group, and after the cluster is created, you can't change its resource group.
* To create clusters in a resource group other than the default, you must have at least the [Viewer role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the resource group.



2. Select the zones to create your cluster in. For more information about cluster availability, see [Planning your cluster for high availability](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clusters).



* The zones are filtered based on the VPC that you selected, and include the VPC subnets that you previously created.
* To create a single zone cluster, select one zone only. You can [add zones to your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersadd_zone) later.