vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The managed-istio-custom ConfigMap is not removed during uninstallation. If you later re-enable the Istio add-on, any [customized settings that you made to the ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-istiocustomize) are applied during installation. If you don't want to re-use your custom settings in a later installation of Istio, you must delete the ConfigMap.

kubectl delete cm -n ibm-operators managed-istio-custom
3. Delete any custom Istio operator (IOP) resources that you created, such as for a custom ingress gateway. When you run this command, the Istio operator automatically removes any resources that the IOP resource created, such as deployments or services.

kubectl delete IstioOperator <resource_name> -n <namespace>







 Step 2: Uninstalling the Istio add-on 

Uninstall the add-on from the console or CLI.



 Uninstalling the Istio add-on from the console 



1. In your [cluster dashboard](https://cloud.ibm.com/kubernetes/clusters), click the name of the cluster where you want to remove the Istio add-on.
2. Navigate to the Add-ons section.
3. On the Managed Istio card, click the Action menu icon.
4. Click Uninstall. The managed Istio add-on is disabled in this cluster and all Istio resources in this cluster are removed.
5. On the Managed Istio card, verify that the add-on you uninstalled is no longer listed.







 Uninstalling managed Istio add-ons from the CLI 

If you did not install the deprecated istio-sample-bookinfo and istio-extras add-ons, skip steps 1 and 2.



1. Disable the istio-sample-bookinfo add-on.
[Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) 
 Delete a service instance ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) 
 Update a service instance ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) ![Check mark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) 
 Create a service ID !
"plugin":"ibm-file-plugin-5b55b7b77b-55bb7"
: The storage plug-in that the cluster uses.

"region":"us-south"
: The region that your cluster is in.

"cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"
: The cluster ID that is associated with the storage instance.

"type":"Endurance"
: The type of file or block storage, either Endurance or Performance.

"ns":"default"
: The namespace that the storage instance is deployed to.

"pvc":"mypvc"
: The name of the PVC that is associated with the storage instance.

"pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"
: The PV that is associated with the storage instance.

"storageclass":"ibmc-file-gold"
: The type of storage class: bronze, silver, gold, or custom.
11. Remove the physical storage instance.

ibmcloud sl file volume-cancel <classic_file_id>
12. Verify that the physical storage instance is removed.

ibmcloud sl file volume-list



The deletion process might take up to 72 hours to complete.
kubectl delete serviceaccount -n ibm-system olm-operator-serviceaccount
kubectl delete clusterrolebinding olm-operator-binding-ibm-system
kubectl delete operatorgroup -n ibm-operators ibm-operators
kubectl delete operatorgroup -n ibm-system olm-operators
kubectl delete service -n ibm-system catalog-operator-metrics
kubectl delete service -n ibm-system olm-operator-metrics
8. Delete any unused CRs, then delete the custom resource definitions (CRD) that were installed by OLM.

kubectl delete catalogsources.operators.coreos.com NAME -n NAMESPACE

kubectl delete crd catalogsources.operators.coreos.com
9. Repeat the previous steps for each of the following CRDs.



* catalogsources.operators.coreos.com
* clusterserviceversions.operators.coreos.com
* installplans.operators.coreos.com
* operatorgroups.operators.coreos.com
* operators.operators.coreos.com
* subscriptions.operators.coreos.com
https://blockchain-project-ibpconsole-console.xyz.abc.com
5. Paste your URL in your browser and login to the console.



In your browser, you can see the console login screen:



* For the User ID, use the value you provided for the email: field in the console specification in step two.
* For the Password, use the value you encoded for the password: field in the console specification in step two. This password becomes the default password for the console that all new users use to log in to the console. After you log in for the first time, you are asked to provide a new password that you can use to log in to the console.



Ensure that you are not using the ESR version of Firefox. If you are, switch to another browser such as Chrome and log in.

The administrator who provisions the console can grant access to other users and restrict the actions they can perform. For more information, see [Managing users from the console](https://cloud.ibm.com/docs/blockchain-sw-254?topic=blockchain-sw-254-console-icp-manageconsole-icp-manage-users) in the IBM Blockchain Platform 2.5.4 documentation.





 Removing your deployment 

If you want to delete the IBM Blockchain Platform operator or any instances you have deployed, the simplest way is through the OpenShift UI.

If you want to delete the operator, make sure to delete any instances associated with it first.

To delete an instance, navigate to the Operators tab and then click Installed Operators. From here, click IBM Blockchain and then the All instances tab. Find the instance you that want to delete and click the settings button to the right of the instance. Then, click Delete (the name of your instance).

To delete the operator, navigate back to the Installed Operators page and click the settings button to the right of the IBM Blockchain Platform operator. Then, click Uninstall Operator.

Alternatively, you can use the CLI to switch to the OpenShift project that you created for your blockchain network:
image = data.ibm_is_image.ubuntu.id
 profile = "cc1-2x4"

 primary_network_interface {
 subnet = ibm_is_subnet.subnet1.id
 security_groups = [ibm_is_security_group.sg1.id]
 }
}
3. Commit the change to your Terraform configuration file.
4. From the [workspace dashboard](https://cloud.ibm.com/schematics/workspaces), select the workspace that points to the Terraform template that you just changed.
5. From the navigation, select Settings.
6. In the Summary section, click Pull latest to get the latest version of your Terraform template from the linked GitHub source repository. If you provided your Terraform template by uploading a tape archive file (.tar), you must use the [ibmcloud schematics workspace upload](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-referenceschematics-workspace-upload) command to provide a new version of your template.
7. Click Generate plan to create a Terraform execution plan. The workspace Activity page opens. Note that during this time, you cannot make changes to your workspace.
8. Click View log to review the log files of your execution plan. The log files provide a summary of all the resources that IBM Cloud Schematics is about to remove.
9. Click Apply plan to remove the IBM Cloud resources from your account.

If you want to stop applying your Terraform template, you can use the Stop button. Note that all resources that are already removed are not re-created. If a resource is currently deleting, Schematics waits for the deletion to complete, and then stops the creation, update, or deletion of any other resources in your Terraform template.
10. Review the log files to ensure that no errors occurred during the deletion process.
11. From the navigation, select Resources and verify that your resources are removed.
Get details about the volume. This command returns the worker node ID and attachment ID. Note the worker node ID. In the following command this ID is returned as "Instance name".

ibmcloud is volume <volume_ID>
3. Retrieve a list of your PVs. This command returns a list of your PVs that you can then you use to determine which PVC uses the volume that you want to remove.

kubectl get pv
4. Describe the PV that uses the volume. If you don't know which PV uses the volume that you want to remove, you can run the describe pv command on each PV in your cluster. Note the PVC that uses the PV.

kubectl describe pv <pv_name>
5. Check to see if your storage volume is in use by a pod. The following command shows the pods that mount the volume and the associated PVC. If no pod is returned, the storage is not in use.

kubectl get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
6. If the pod your volume is using is part of a deployment, delete the deployment. If your pod does not belong to a deployment, delete the pod.

kubectl delete deployment <deployment_name>

kubectl delete pod <pod_name>
7. Delete the PVC and PV.

kubectl delete pvc <pvc_name>

kubectl delete pv <pv_name>
8. Retrieve your IAM token.

ibmcloud iam oauth-tokens
9. Detach storage by using a POST request.

Example request
"verification_key": "476754457-428595283",
"cname_suffix": "cdn.cloudflare.net",
"original_name_servers": [
"ns1.softlayer.com",
"ns2.softlayer.com"
],
"original_registrar": "everyones internet, ltd. dba s (id: 925)",
"original_dnshost": null,
"modified_on": "2021-05-07T06:46:19.326826Z",
"created_on": "2021-05-07T01:57:53.163247Z",
"account": {
"id": "b0c53e3f037b8cdc62b5cb373b8c55e6",
"name": "57aea3aa-a38e-4760-ada5-a698bca56171"
}
},
"success": true,
"errors": [],
"messages": []
}
Show more
3. Add the record cloudflare-verify to the parent DNS zone indicated by the verification-key (in this example, ibmnetworkdemo.com).

txt cloudflare-verify.ibmnetworkdemo.com 476754457-428595283
4. After CIS verifies the record, the zone will be activated. This process might take several hours.







 Verify the CNAME 

To verify your CNAME setup, take the following steps.



1. Add an A record in CIS and enable proxy:

www.ibmnetworkdemo.com A 169.48.151.44 true 1
2. Add the CNAME record in the authoritative DNS:

www.ibmnetworkdemo.com www.ibmnetworkdemo.com.cdn.cloudflare.net

check::
dig www.ibmnetworkdemo.com a
A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name
* Optional Fields: LOC options (click Configure LOC options to configure)







 CAA Type record 

To add this record type, valid values must exist in the Name and Value fields. The Value field correlates to the value of the Tag list field, which defaults to "Send violation reports to URL". A TTL can also can be specified from the list, with the default value of Automatic.



* Required Fields: Name, Value (associated to tag)
* Optional Fields: TTL (default value is Automatic), Tag (default is to send violation reports to URL)







 SRV Type record 

To add this record type, valid values must exist in the Name, Service Name and Target fields. Use the list menu to select a protocol, which defaults to the UDP protocol. Additionally, you can specify Priority, Weight and Port. These three fields default to a value of 1. A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name, Service Name, Target
* Optional Fields: TTL (default value is Automatic), Protocol (defaulted to UDP), Priority (defaulted to 1), Weight (defaulted to 1), Port (defaulted to 1)







 SPF Type record 

Support for SPF records (deprecated in RFC 7208) is ending in February, 2022. After this date, you can no longer create SPF type records in CIS. Use TXT records instead.

To add this record type, valid values must exist in the Name and Content fields. A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name, Content
* Optional Field: TTL (default value is Automatic)







 TXT Type record 

To add this record type, valid values must exist in the Name and Content fields. A TTL also can be specified from the list menu, with the default value of Automatic.



* Required Fields: Name, Content
* Optional Field: TTL (default value is Automatic)
Internet services 



 Resources Data sources 

 <br><br> * [ibm_cis](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis)<br> * [ibm_cis_alert](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_alert)<br> * [ibm_cis_cache_settings](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_cache_settings)<br> * [ibm_cis_certificate_order](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_certificate_order)<br> * [ibm_cis_certificate_upload](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_certificate_upload)<br> * [ibm_cis_custom_page](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_custom_page)<br> * [ibm_cis_dns_record](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis_dns_record)<br> * [ibm_cis_
Understanding your responsibilities when using IBM Cloud DNS Services 

Learn about the management responsibilities and terms and conditions that you have when you use IBM Cloud® DNS Services. For a high-level view of the service types in IBM Cloud® and the breakdown of responsibilities between the customer and IBM for each type, see [Shared responsibilities for IBM Cloud offerings](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities).

Review the following sections for the specific responsibilities for you and for IBM when you use DNS Services. For the overall terms of use, see [IBM Cloud® Terms and Notices](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms)



  IBM's responsibilities 



*  Fulfill requests for DNS Services configurations, including DNS zones and resource records.
*  Keep your DNS Services configuration, including DNS zones and resource records, secure.
*  Ensure only permitted VPCs have access to the DNS zone information.
*  Provide high availability of DNS zone and resource records configuration data.
*  Ensure redundancy of data, enabling Disaster Recovery.
*  Provide DNS resolvers for DNS resolution.
*  Provide updates of appliance for global load balancer and custom resolvers.







  Customer responsibilities 



*  Ensure that DNS zones and resource records data is correct and accurate.
*  Take periodic [backups](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-writing-dns-svcs-config-to-file) of your DNS zones and resource records.







  Abuse of IBM Cloud DNS Services 

Clients must not misuse IBM Cloud® infrastructure.

Misuse includes:



*  Any illegal activity
*  Distribution or execution of malware
*  Harming IBM Cloud infrastructure or interfering with the use of IBM Cloud infrastructure
*  Harming or interfering with the use of any other service or system
*  Unauthorized access to any service or system
*  Unauthorized modification of any service or system
*  Violation of the personal rights of others



See [Cloud Services terms](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms) for overall terms of use.
Wait a few minutes for the detach command to finish, then check that they have been detached by reviewing the ibm-cloud-provider-vlan-ip-config ConfigMap that stores the subnets and IP addresses.

kubectl get cm -n kube-system ibm-cloud-provider-vlan-ip-config -o yaml

It might take 5-10 minutes for the detach to complete. While you wait, you can ensure that the new portable subnets you created for this cluster also appear in the ConfigMap.
8. Check whether the LoadBalancers in the openshift-ingress namespace re-created, and if so, check whether the IP addresses used are from the new subnets. If they are from the old subnets, then delete them again by using the kubectl delete svc -n openshift-ingress LOADBALANCER_NAME command.
9. After the openshift-ingress LoadBalancers re-create with IP addresses from the new subnets, add the new IP addresses to the DNS record.



1. List the DNS entries.

ibmcloud oc nlb-dns ls -c CLUSTER-ID
2. In the output, find the openshift-ingress entries, and add the new IP address(es) to them by using the following command.

ibmcloud ks nlb-dns add -c CLUSTER-ID --ip NEW-LOADBALANCE-IP --nlb-host INGRESS-DOMAIN-NAME
3. Remove the old IPs.

ibmcloud oc nlb-dns rm classic -c CLUSTER-ID --ip OLD-LOADBALANCER-IP --nlb-host INGRESS-DOMAIN-NAME



10. Re-create any LoadBalancers not in the openshift-ingress namespace that you deleted in step 3 by by using the YAML file that you saved earlier.

kubectl apply -f LB-NAMESPACE.LB-NAME.yaml
ibmcloud oc nlb-dns rm classic -c <cluster_name_or_ID> --ip <old_IP> --nlb-host <hostname>
6. Verify that the hostname for your Ingress controller is now registered with the new IP address. After your Ingress controller hostname is updated with the IP address of the new service, no further changes to your Ingress controller or routes are required.

ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
7. Delete the Ingress controller service on the old VLAN.

oc delete svc <old_router_svc> -n openshift-ingress
8. Optional: If you no longer need the subnets on the old VLANs, you can [remove them](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsremove-subnets).
These CNAME records point to an Akamai Global Traffic Management domain that health checks the subdomains. When a client runs a DNS query for a health checked subdomain, a CNAME record is returned to the client, as opposed to Cloudflare, in which an A record was returned. If your client expects an A record for a subdomain that was health checked in Cloudflare, update your logic to accept a CNAME record.



* 

* During the migration, an Akamai Global Traffic Management (GTM) health check was automatically created for any subdomains that had a Cloudflare health check. If you previously created a Cloudflare health check for a subdomain, and you create an Akamai health check for the subdomain after the migration, the two Akamai health checks might conflict. Note that Akamai GTM configurations don't support nested subdomains. In these cases, you can use the ibmcloud oc nlb-dns monitor disable command to disable the Akamai health check that the migration automatically configured for your subdomain.



* [28 June 2021](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2821)



* Master versions



* [24 June 2021](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2421)



* CLI change log



* [23 June 2021](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2321)



* Cluster autoscaler add-on



* [22 June 2021](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2221)



* IBM Cloud Object Storage plug-in
* Worker node versions
Example DNS configurations 

The following screen captures show some common DNS configurations.

Things to remember:



*  The @ symbol is shorthand for the domain itself.
*  The Arecord points from a hostname (such as domain.com or sub.domain.com) to an IP address (for example, 123.123.231.1).
*  The CNAME record points from a hostname (such as domain.com or sub.domain.com) to another hostname.





  In the IBM Cloud console 

Zoom

![Figure 1: IBM Cloud console DNS zone example](https://cloud.ibm.com/docs-content/v1/content/86dadb3996e7fa2b119c2c09bda56dbc01297416/dns/images/dns1.png)

Figure 1. IBM Cloud console DNS zone example





  In cPanel 

Zoom

![Figure 2: cPanel DNS zone example](https://cloud.ibm.com/docs-content/v1/content/86dadb3996e7fa2b119c2c09bda56dbc01297416/dns/images/cpaneldns.png)

Figure 2. cPanel DNS zone examplee





  In Plesk 

Zoom

![Figure 3: Plesk DNS example](https://cloud.ibm.com/docs-content/v1/content/86dadb3996e7fa2b119c2c09bda56dbc01297416/dns/images/plesk2dns.png)

Figure 3. Plesk DNS example
: Weight of distributing queries among multiple target servers.

--priority
: Priority of the SRV record.

--target
: Hostname of the target server.

--ttl
: Time to live, in seconds. Default value is 900. Valid values: 60, 120, 300, 600, 900, 1800, 3600, 7200, 18000, 43200.

-r, --record-content
: The JSON file or JSON string used to describe a DNS Resource Record. See [Required fields for -r, --record-content](https://cloud.ibm.com/docs/dns-svcs?topic=dns-svcs-dns-services-cli-commandsr-record-details) for more detail.

-i, --instance INSTANCE
: Instance name or ID. If the name is not set, the context instance specified by ibmcloud dns instance-target is used.

--output FORMAT
: Specify output format, only JSON is supported.





 Required fields for -r, --record-content 

The required field in JSON data is name. Resource record name.

PTR records do not need this field.



* For type A, AAAA: Extra required fields are rdata.



* rdata: Content of the resource record.



* ip: IPv4/IPv6 address





* Extra option fields are ttl.



* ttl: Time to live, in seconds. Default value is 900. Valid values: 60, 120, 300, 600, 900, 1800, 3600, 7200, 18000, 43200.





Sample JSON data:

{
     "name": "testA",
     "rdata": {
         "ip": "1.2.3.4"
}
}

{
    "name": "testAAAA",
    "rdata": {
        "ip": "2001:0db8:0012:0001:3c5e:7354:0000:5db1"
    }
}
: Weight of distributing queries among multiple target servers.

--priority
: Priority of the SRV record.

--target
: Hostname of the target server.

--ttl
: Time to live, in seconds. Default value is 900. Valid values: 60, 120, 300, 600, 900, 1800, 3600, 7200, 18000, 43200.

-r, --record-content
: The JSON file or JSON string used to describe a DNS Resource Record. See [Required fields for -r, --record-content](https://cloud.ibm.com/docs/cli?topic=cli-dns-services-cli-commandsr-record-details) for more detail.

-i, --instance INSTANCE
: Instance name or ID. If the name is not set, the context instance specified by ibmcloud dns instance-target is used.

--output FORMAT
: Specify output format, only JSON is supported.





 Required fields for -r, --record-content 

The required field in JSON data is name. Resource record name.

PTR records do not need this field.



* For type A, AAAA: Extra required fields are rdata.



* rdata: Content of the resource record.



* ip: IPv4/IPv6 address





* Extra option fields are ttl.



* ttl: Time to live, in seconds. Default value is 900. Valid values: 60, 120, 300, 600, 900, 1800, 3600, 7200, 18000, 43200.





Sample JSON data:

{
     "name": "testA",
     "rdata": {
         "ip": "1.2.3.4"
}
}

{
    "name": "testAAAA",
    "rdata": {
        "ip": "2001:0db8:0012:0001:3c5e:7354:0000:5db1"
    }
}