vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You will first need to set up the VPC infrastructure. At a bare minimum, you need to set up a VPC, subnets, and the corresponding instances that you are planning to migrate. The new target virtual server instance profile (vCPU and vMemory) does not need to match the source. However, as for the storage, it needs to be the same or greater in size. This guide does not go through all of the details for setting up the VPC infrastructure. For more information, see [Getting started with Virtual Private Cloud (VPC)](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).



1. Create a VPC.
2. Create subnets.
3. Order the virtual server instance:

a. SSH key (RMM SSH keys need to be added in addition to bastion SSH key)

b. OS name (same major version as the source)

c. Security groups

d. Secondary volume (optional)



Ensure that your VPC, subnet, and other necessary cloud components are set up before adding the cloud user in RMM.





 Step 5: Source and target compute preparation 

Before you start the migration, RMM server needs to SSH into the servers. Thus, the RMM public SSH key needs to be copied on both the source and target servers.

For Windows OS, you need to download the SSH key utility. You can download it from RMM server.

For Windows OS, the user is SYSTEM and you must key in the RMM SSH key here to authenticate for both source and target servers.





 Step 6: Set up RMM waves 

You can migrate the servers one-by-one or opt to perform multiple simultaneous migrations. If you are performing multiple simultaneous migrations, then download the CSV template from the RMM server and complete the appropriate fields.



1. Log in to the RMM server.
2. Create a Wave and define Wave name.
3. If there are multiple hosts, download the template, complete the appropriate fields, and then upload the template.
4.
You can assign more than one IBM Cloud IAM role to each access group. 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.

You can't scope IBM Cloud IAM service access roles to an IAM access group because the roles are not synced to the RBAC roles within the cluster. If you want to scope RBAC roles to a group of users, you must [manually set up groups of users](https://docs.openshift.com/container-platform/4.11/authentication/understanding-authentication.html) in your cluster instead of using IAM access groups. You can still scope IAM platform access roles to IAM access groups to control actions like ordering worker nodes, because platform access roles are never synced to RBAC roles.

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/openshift?topic=openshift-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 (projects in Red Hat OpenShift), 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).
To create a local file with the configuration that is deployed in a cluster, you can also run the command:

kubectl get configmap sysdig-agent -n=ibm-observe -o=yaml > prod-sysdig-agent-configmap.yaml
2. Edit the configuration.
3. Apply the changes by using the following commands:

kubectl apply -f sysdig-agent-configmap.yaml



Running agents will automatically pick the new configuration after Kubernetes pushes the changes across all the nodes in the cluster.





 Adding more tags to data that is collected from a Kubernetes monitoring agent 

Complete the following steps to add more tags to a Kubernetes monitoring agent configuration that you have already deployed:



1. Set up the cluster environment. Run the following commands:

First, get the command to set the environment variable and download the Kubernetes configuration files.

ibmcloud ks cluster config --cluster <cluster_name_or_ID>
2. Edit the sysdig-agent-configmap.yaml file.

Run the following command:

kubectl edit configmap sysdig-agent -n ibm-observe
3. Make changes. Note: Refer to vi editor instructions to learn how to make changes.

apiVersion: v1
data:
dragent.yaml:
k8s_cluster_name: mycluster
collector: ingest.us-south.monitoring.cloud.ibm.com
collector_port: 6443
ssl: true
sysdig_capture_enabled: false
new_k8s: true
tags: department:finance,region:us-south
...
4. Save the changes.



Changes are applied automatically.

For the sample provided, you would get the tags agent.tag.department and agent.tag.region. You could use them to define alerts, customize scopes and more.





 Collecting a set of Kubernetes events 

Monitoring supports event integrations with Kubernetes.
ibmcloud login -r us-south [--sso]

If you have a federated ID, use ibmcloud login -r us-south --sso to log in. Enter your username and use the provided URL in your CLI output to retrieve your one-time passcode. If you have a federated ID, the login fails without the --sso and succeeds with the --sso option.
2. Set us-south as the target region for the IBM Cloud Container Registry commands.

ibmcloud cr region-set us-south
3. Create a namespace by running the following command. Choose a name for your namespace, and replace <my_namespace> with that name.

The namespace must be unique across all IBM Cloud accounts in the same region. Namespaces must have 4 - 30 characters and include lowercase letters, numbers, hyphens (-), and underscores (_) only. Namespaces must start and end with a letter or number.

If you want to create the namespace in a specific resource group, see [Set up a namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-startedgs_registry_namespace_add).

ibmcloud cr namespace-add <my_namespace>

Throughout this tutorial, replace <my_namespace> with your chosen namespace.

If you have a problem when you try to add a namespace, see [Why can't I add a namespace?](https://cloud.ibm.com/docs/Registry?topic=Registry-troubleshoot-add-namespace) for assistance.







 Build and push an image 

To [build a container image and push it to IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_images_registry_images_creating), you require an application and a

Dockerfile.
The Cloud Connectors are joined to the Active Directory server domain and are configured to communicate with Citrix Cloud. You might have to create users with the necessary privileges. You can also create bulk users in Active Directory. For more information, see this step-by-step guide on how to [Create bulk users in Active Directory](https://activedirectorypro.com/create-bulk-users-active-directory/).





 Extended (Multisite) 



1. With an Extended (Multisite) setup, you must establish network connectivity between IBM Cloud and your on-premises location.

You can set up network connectivity by using any of the gateway appliances available in IBM Cloud. For more information, see the About section in the [Gateway Appliance IBM Cloud catalog page](https://cloud.ibm.com/gen1/infrastructure/provision/gateway).

You must set up another Gateway appliance on-premises too. Configure both the appliances and establish network connectivity between the two sites.

When you order a gateway appliance from IBM Cloud, the data center and backend VLAN must correspond to the same data center and VLAN where your other services are provisioned. See [View network details](https://cloud.ibm.com/docs/citrix-daas?topic=citrix-daas-post-provisioning-citrix-daasview-network-details).
2. Install the domain controller in IBM Cloud

A Windows virtual server instance is provisioned in the same VLAN and network as your other servers. Complete the following steps to install the domain controller and join the secondary controller:

Install the Active Directory Domain Services (AD DS) domain controller on this Windows server and join the secondary controller with your on-premises domain.

Domain join your Cloud Connectors, and then run the Cloud Connector registration scripts to add the connectors to the resource location.

The Cloud Connector PowerShell scripts are available in C:postscript.
3. Run the configuration scripts on each of the three connector virtual server instances:



1. Make sure your Connector and Active Directory can talk to each other. Run the ping command if imp is not blocked.
2.
Supplemental vSRX documentation 

There is a variety of supplemental documentation for IBM Cloud® Juniper vSRX.



 vSRX Documentation Description 

 [Juniper vSRX Overview](https://www.juniper.net/us/en/products-services/security/srx-series/vsrx/) Learn about Juniper vSRX and its extensive features. 
 [Junos OS Routing Protocols Configuration Guide](https://www.juniper.net/documentation/en_US/junos11.4/information-products/topic-collections/config-guide-routing/config-guide-routing.pdf) This guide describes the concepts of various routing protocols and how to configure routing policies on vSRX. 
 [Junos OS Network Address Translation User Guide](https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-nat.pdf) This guide describes information about NAT and how to configure NAT on vSRX. 
 [Junos OS IPsec VPN User Guide for Security Devices](https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/security/security-vpn-ipsec.pdf) This guide describes information on how to configure various type of IPsec VPN on vSRX. 
 [Intrusion Detection and Prevention on IBM Cloud](https://cloud.ibm.com/media/docs/downloads/vSRX/IDP_v5.pdf) IDP is Intrusion Detection and Prevention. Detection is the process of monitoring the events occurring in your network and analyzing them for signs of possible threats to your security policies. Prevention refers to the process stopping the detected incidents. 
 [On-box logging and reporting CSB statistics in J-web](https://public.dhe.ibm.com/cloud/bluemix/network/vsrx/on-box-logging-reporting-11320.pdf) This guide describes how to enable on-box security event reporting using the set security log report CLI command.
[Register your service](https://cloud.ibm.com/docs/sell?topic=sell-svc-register)Register your service

This tutorial walks you through how to register a service in IBM Cloud® Partner Center. By completing this tutorial, you learn how to provide your company details, create a test environment, and grant team members access to help with the onboarding process

Selling on IBM Cloud



* 5 minutes
* 2022-02-07



[Registering your Terraform template](https://cloud.ibm.com/docs/sell?topic=sell-terraform-template-register)Registering your Terraform template

This tutorial walks you through how to register a Terraform template in IBM Cloud® Partner Center. By completing this tutorial, you learn how to provide the company details, create a test environment, and set up the access for your team to help with the onboarding process.

Selling on IBM Cloud



* 5 minutes
* 2022-03-04



[Registering a virtual server image](https://cloud.ibm.com/docs/sell?topic=sell-vsimage-register)Registering a virtual server image

This tutorial walks you through how to register a virtual server image with Terraform in IBM Cloud® Partner Center. By completing this tutorial, you learn how to provide the company details, create a test environment, and set up access for your team to help with the onboarding process.

Selling on IBM Cloud



* 5 minutes
* 2021-12-02



[Registering a virtual server image for Power Systems](https://cloud.ibm.com/docs/sell?topic=sell-vsipower-register)Registering a virtual server image for Power Systems

This tutorial walks you through how to register a public virtual server image for Power Systems in IBM Cloud® Partner Center. By completing this tutorial, you learn how to provide the company details, create a test environment, and set up access for your team to help with the onboarding process.

Selling on IBM Cloud



* 5 minutes
* 2022-03-31
* [Developing Kubernetes-native apps](https://cloud.ibm.com/docs/containers?topic=containers-app)
* [Deploying Kubernetes-native apps in clusters](https://cloud.ibm.com/docs/containers?topic=containers-deploy_app)
* [Managing the app life cycle](https://cloud.ibm.com/docs/openshift?topic=openshift-update_app)



Learning paths
: Curated learning paths for [administrators](https://cloud.ibm.com/docs/openshift?topic=openshift-learning-path-admin) and [developers](https://cloud.ibm.com/docs/openshift?topic=openshift-learning-path-dev) are now available to help guide you through your Red Hat OpenShift on IBM Cloud experience.

Setting up image build pipelines
: You can now find expanded information on how to set up an image registry and build pipelines in the following pages.



* [Setting up an image registry](https://cloud.ibm.com/docs/openshift?topic=openshift-registry)
* [Setting up continuous integration and delivery](https://cloud.ibm.com/docs/openshift?topic=openshift-cicd)



Firewall subnets
: Removed outdated [subnet IP addresses for IBM Cloud Container Registry](https://cloud.ibm.com/docs/openshift?topic=openshift-firewallvyatta_firewall).





 18 February 2020 

Version change logs
: Red Hat OpenShift master fix pack for [3.11.161_1542_openshift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_changelog_311311161_1542_master).





 17 February 2020 

Version change logs
: Master and worker node patch updates.
[Brocade Vyatta Network OS Routing Policies Configuration Guide, 5.2R1](https://public.dhe.ibm.com/cloud/bluemix/network/vra/vyatta-network-os-5.2r1-routing-policies.pdf) This guide describes how to configure routing policies on the Brocade Vyatta Network OS (referred to as a virtual router, vRouter, or router in the guide). 
 [Brocade Vyatta Network OS Scripting Reference Guide, 5.2R1](https://public.dhe.ibm.com/cloud/bluemix/network/vra/vyatta-network-os-5.2r1-scripting.pdf) This guide describes how to use the Brocade 5600 vRouter Scripting API (referred to as the vRouter Scripting API, or configd API, in the guide) to create scripts that programmatically configure and administer the Brocade 5600 vRouter (referred to as a virtual router, vRouter, or router in the guide). This guide also describes how to create vcli scripts to access CLI commands on the vRouter. 
 [Brocade Vyatta Network OS RIPng Configuration Guide, 5.2R1](https://public.dhe.ibm.com/cloud/bluemix/network/vra/vyatta-network-os-5.2r1-ripng.pdf) This guide describes how to configure Routing Information Protocol next generation (RIPng) on the Brocade 5600 vRouter (referred to as a virtual router, vRouter, or router in the guide). 
 [Brocade Vyatta Network OS RIP Configuration Guide, 5.2R1](https://public.dhe.ibm.com/cloud/bluemix/network/vra/vyatta-network-os-5.2r1-rip.pdf) This guide describes how to configure Routing Information Protocol (RIP) on the Brocade 5600 vRouter (referred to as a virtual router, vRouter, or router in the guide).
* Supply the LOA/CFA to your service provider and have them order a third-party cross connect, as well as the circuit between your on-premises and the appropriate Meet Me Room.



IBM Cloud will not order a cross-connect on a customer's behalf.
3. After receiving the completion notice from your carrier, upload it. The completion notice must be in PDF format with the name completion_notice.pdf for the automation to process it properly. The specific connection shows an option in the IBM Cloud console to upload the completion notice. Notice that the connection status changes to Completion notice review in progress.
4. The IBM Cloud team reviews the completion notice and accepts it. The IBM Cloud team then places an order to have the fiber installed between the patch panel/port mentioned in the LOA and the device port. This process can take 1-4 business days, depending on how quickly the site provider finishes the request. This completes the physical-layer portion of the direct link and the connection status changes to Provisioned.
5. You must then configure the BGP parameters on your Edge router for BGP session establishment. After this completes, the BGP status indicates Established and Link status indicates Up. It can take up to 30 minutes for the link status to update.



If you decide to cancel your direct link, remember to disconnect the cross-connect router with the site provider; otherwise, you will continue to be charged for the cross-connect.





 Related link 

[Direct Link Dedicated locations](https://cloud.ibm.com/docs/dl?topic=dl-locationsdedicated-locations)
[RIP Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_rip_configuration_5600.pdf) This guide describes how to configure Routing Information Protocol (RIP) on the AT&T Vyatta vRouter. 
 [RIPng Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_ripng_Configuration_5600.pdf) This guide describes how to configure Routing Information Protocol next generation (RIPng) on the AT&T Vyatta vRouter. 
 [Routing Policies Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_routing_policies_configuration_5600.pdf) This guide describes how to configure routing policies on the AT&T Vyatta Network Operating System. 
 [Scripting Reference Guide, 17.2.0{: external}](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_scripting_reference_5600.pdf) This guide describes how to use the AT&T Vyatta vRouter Scripting API (referred to as the vRouter Scripting API, or configd API in the guide) to create scripts that programmatically configure and administer the AT&T Vyatta vRouter. This guide also describes how to create vcli scripts to access CLI commands on the vRouter. 
 [Services Configuration Guide, 17.2.0](https://public.dhe.ibm.com/cloud/bluemix/network/vra/18_services_configuration_5600.pdf) This guide describes how to configure the DHCP, DHCPv6, DNS, flow monitoring, NHRP, sFlow, TWAMP, and port monitoring services on the AT&T Vyatta Network Operating System.
Setting up Tekton continuous deployment pipelines with DevSecOps 

Complete these steps to set up the Tekton continuous deployment pipelines with compliance. Configuration options guide you through the steps to create your toolchain.



 Before you begin 



* [Create a Kubernetes cluster](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) on IBM Cloud Kubernetes Service to deploy your application.
* [Create toolchain secrets](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-toolchains-secrets) to access different integrations and secure them.
* [Compliance CI toolchain](https://us-south.git.cloud.ibm.com/open-toolchain/compliance-ci-toolchain) configured with DevOps Insight Integrations.
* Optional. [Configure Cloud Object Storage](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-cos-config) as the Compliance Evidence Locker to store pipeline run evidence.
* [Validate recommended IAM permissions](https://cloud.ibm.com/docs/devsecops?topic=devsecops-iam-permissions) are assigned to corresponding integrations.







 Guided setup overview for the CD toolchain 

View the following video tutorial to get an overview of the setup process:

The progress indicator in Figure 1 guides you through the toolchain configuration. If you need to return to a previous step, you can use the progress indicator to navigate to a previous step.

Zoom

![DevSecOps continuous deployment toolchain welcome page](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cd-welcome.png)

Figure 1. DevSecOps continuous deployment toolchain welcome page
oc get pods --all-namespaces
3. Get the details of a pod. Note the limits and request map of the CPU and memory.

oc get pod -n <project> <pod> -o=jsonpath='{range .spec.containers[]} {.name}:{.resources}{"n"}{end}'
4. Repeat the previous step for each pod in your cluster.
5. Add up the resource requests and limits of the apps that you deployed by default.



6. Subtract the sum of your workload resource limits that you estimated in Step 5 from the available compute resources of your worker nodes that you estimated in Step 2. The remaining amount is the extra compute resources that you have to run new workloads or to scale your existing workloads.
7. For workloads that need to scale up and down in response to resource requests, set up the [horizontal pod autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appapp_scaling) and [cluster worker pool autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc).
8. [Set up monitoring tools](https://cloud.ibm.com/docs/containers?topic=containers-health-monitorview_metrics) to continue reviewing CPU and memory usage across worker nodes in your cluster.
9. Run performance tests to continue refining the number of worker nodes you need in your cluster, with representative latency, scalability, data set, and workload requirements.









 Structuring your Red Hat OpenShift environment 

Your Red Hat OpenShift on IBM Cloud is linked to one IBM Cloud infrastructure portfolio only. Within your account, you can create clusters that are composed of a master and various worker nodes. IBM manages the master, and you can create a mix of worker pools that pool together individual machines of the same flavor, or memory and CPU specs. Within the cluster, you can further organize resources by using namespaces and labels.
name: system:serviceaccounts
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:authenticated
Show more
3. Edit the cluster role binding .yaml file. To understand what you can edit, review the [Kubernetes documentation](https://kubernetes.io/docs/concepts/security/pod-security-policy/). Example actions:



* Service accounts: You might want to authorize service accounts so that deployments can occur only in specific namespaces. For example, if you scope the policy to allow actions within the default namespace, the service account can deploy privileged pods in that namespace. However, actions in other namespaces are no longer authorized because you changed the scope from service accounts generally to service accounts specifically in the default namespace.

Do not scope the policy to namespaces that run system components, such as the kube-system, ibm-system, or ibm-operators namespaces. These namespaces already have [their own policies](https://cloud.ibm.com/docs/containers?topic=containers-pspibm_psp). Changing the system component policies might cause unexpected results, such as all service accounts in all namespaces being able to deploy privileged pods.

To scope the policy to allow actions in a specific namespace, change the system:serviceaccounts to system:serviceaccount:<namespace>.

- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:default

To scope the policy to multiple namespaces, copy the subject group and update the namespace.

- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:default
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:serviceaccounts:test
* Users: You might want to remove authorization for all authenticated users to deploy pods with privileged access. Remove the following system:authenticated entry.