vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Dynamic provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsdynamic_provisioning)
* [Static provisioning](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsstatic_provisioning)







 Dynamic provisioning 

Use dynamic provisioning if you want to give developers the freedom to provision storage when they need it.

Dynamic provisioning is a feature that is native to Kubernetes and that allows a cluster developer to order storage with a pre-defined type and configuration without knowing all the details about how to provision the physical storage device. To abstract the details for the specific storage type, the cluster admin must create [storage classes](https://cloud.ibm.com/docs/openshift?topic=openshift-kube_conceptsstorageclasses) that the developer can use, or use the storage classes that are provided with the IBM Cloud® storage plug-ins.

To order the storage, you must create a PVC. The PVC determines the specification for the storage that you want to provision. After the PVC is created, the storage device and the PV are automatically created for you.

The following image shows how file storage is dynamically provisioned in a cluster. This sample flow works similarly with other storage types, such as block storage.

Zoom

![Sample flow to dynamically provision file storage in a cluster, as described in the following list.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_storage_dynamic-01-01.svg)

Figure 1. Sample flow to dynamically provision file storage in a cluster



1. The user creates a persistent volume claim (PVC) that specifies the storage type, storage class, size in gigabytes, number of IOPS, and billing type. The storage class determines the type of storage that is provisioned and the allowed ranges for size and IOPS.
curl -X PATCH "$vpc_api_endpoint/v1/images/$image_id?version=2022-11-21&generation=2" -H "Authorization: Bearer $iam_token" -d '{ "deprecation_at": null, “obsolescence_at": null }'







 Performance considerations 

Several factors can impact how quickly your image from volume is queued and created, such as size of the image and number of jobs in the queue. If an image is taking longer than you want to wait, you can cancel the job.



 Performance during image creation 

When you create the image, the API status_reasons parameter indicates image_request_queued, with a message The image request is accepted and waiting for system resources to become available. When you see this message, it might take a while for the job to start. The following table provides some guidelines that are based on image size. Check for an in_progress status to see whether the image is being created. Again, depending on the size of the image, it might take a while before the image is available.



Table 1. Estimated wait time for image creation

 Image size Estimated time until image is available 

 5 GB 5 min 
 10 GB 10 min 
 25 GB 25 min 
 50 GB 50 min 
 75 GB 1 hr 15 min 
 100 GB 1 hr 40 min 



The time for the job to start is about 30 seconds. This time does not reflect traffic in the queue, which can increase the estimate. Most jobs start within 5 - 10 minutes. If it takes longer, [cancel the image creation](https://cloud.ibm.com/docs/vpc?topic=vpc-image-from-volume-vpc-manageifv-delete-queued).





 Cancelling an image that is queued for creation 

You can cancel the image creation by deleting the image if the underlying job didn't start yet. For images in a pending state, the GET/images API call returns an image_request_queued reason code. You can delete the pending image with DELETE/image{image_id}.
* If the path is identical to the name of an existing (nonempty) object, it matches only that single object.
* If the path is a prefix of multiple objects at a slash / character, it matches all those objects that are not empty. For example, the path mydir/test1 (or mydir/test1/) matches objects mydir/test1/object1, mydir/test1/nested/object2, but not mydir/test100.
* The usage of a * wildcard depends on how the object structure was created: - If the object structure was created as Hive-partitioned structure, for example as Data Engine result output, and the result objects are starting with the prefix part-, wildcards are not supported. Using SQL constructs based on the Hive structure is always the preferred method to restrict the number of objects to be read during query processing.



* If the object structure was created as Hive-partitioned structure, but by using arbitrary file names, the usage of wildcards is supported. The wildcard matches all objects with the indicated path prefix. For example, mydir/test1, matches objects mydir/test100, and mydir/test101/nested/object.





* For an output URI, it is the prefix under which the [result objects](https://cloud.ibm.com/docs/sql-query?topic=sql-query-readingresult) are to be written.







 Composite input tables 

As noted previously, the URI for an input table on Cloud Object Storage can match multiple objects, forming a "composite" input table. When you run a query over composite input, ensure that the schema of each matching object is appropriate within the context of the SELECT statement. The schemas of the objects do not need to be identical; depending on the input format, the schemas of multiple objects can be merged:



* For CSV format, columns are matched based on their order. Some input objects can contain more columns than others, but common columns must always use the same order across objects. The number of columns in the composite input is the maximum number of columns from all matched objects.
* For JSON and Parquet format, columns are matched based on their name.
Adding a Destination 

A destination is a definition of how to connect to a specific on-premises or cloud resource. Once the destination has been created, the Secure Gateway servers will provide it with a unique public endpoint where it will listen for connections while the gateway is connected.

![Dashboard with no destinations](https://cloud.ibm.com/docs-content/v1/content/690bf9a59650e0582967be8899e39840589532f7/SecureGateway/images/emptyDestinations.png?raw=true)

From within your new gateway and on the Destinations tab, click the Add Destination button to open the Add Destination panel. There are two methods for creating your destination: a guided setup that shows how each piece fits into the overall architecture and an advanced setup that provides all fields and options on a single panel.

The guided setup does not allow for the configuration of proxy information, server name indicators, reject unauthorized or the upload of a destination-specific cert/key pair. After creation, all fields are available via the Edit Destination panel.



 Guided Setup Panel 

![Guided Setup](https://cloud.ibm.com/docs-content/v1/content/690bf9a59650e0582967be8899e39840589532f7/SecureGateway/images/guidedLanding.png?raw=true)





 Advanced Setup Panel 

![Advanced Setup](https://cloud.ibm.com/docs-content/v1/content/690bf9a59650e0582967be8899e39840589532f7/SecureGateway/images/advancedLanding.png?raw=true)





 On-premises vs Cloud Destinations 

The first question to answer when creating your destination is where the resource resides that you need to connect to.



 On-premises Destination 

The on-premises destination is for the use case where an application in the public space needs access to a restricted resource located on-premises. !
* /opt/IBM/node-v0.10.40-linux-x64/npm
* /opt/IBM/node-v0.12.7-linux-x64/npm
* /opt/IBM/node-v4.2.2-linux-x64/npm
* /usr/bin/Xvfb
* /usr/bin/pip



After a job runs, the container that was created for it is discarded. The results of a job run can persist, but the environment in which it ran does not.

Jobs can run for up to 60 minutes. When jobs exceed that limit, they fail. If a job is exceeding the limit, break it into multiple jobs. For example, if a job performs three tasks, you might break it into three jobs: one for each task.

To learn how to add a job to a stage, see [Adding a job to a stage](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline_build_deploydeliverypipeline_add_job).



 Build jobs 

Build jobs compile your project in preparation for deployment. They generate artifacts that can be sent to a build archive directory, although by default, the artifacts are placed in the project's root directory.

Jobs that take input from build jobs must reference build artifacts in the same structure that they were created in. For example, if a build job archives build artifacts to an output directory, a deploy script would refer to the output directory rather than the project root directory to deploy the compiled project. You can specify the directory to archive by entering the directory name in the Build Archive Directory field. Leaving the field blank archives the root directory.

If you use the Simple builder type, your code is not compiled or built; it is packaged and made available for future stages.





 Deploy jobs 

Deploy jobs upload your project to IBM Cloud as an app and are accessible from a URL. After a project is deployed, you can find the deployed app on your IBM Cloud dashboard.

Deploy jobs can deploy new apps or update existing apps.
Once a Dockerfile is created, next you would need to build the container image and push it to IBM Cloud Container Registry. You can build a container using a command like:

docker build . -t <image_name>
docker push <image_name>







 Deploy your app to a Kubernetes cluster 

After a container image is built and pushed to the cloud, next you need to deploy to your Kubernetes cluster. To do that you would need to create a deployment.yaml file.



 Learn how to create a Kubernetes deployment yaml file 

To create Kubernetes deployment.yaml files, you would need to do something like this:



1. Create a deployment.yaml file, here is an example of a [deployment YAML](https://github.com/IBM-Cloud/jpetstore-kubernetes/blob/master/jpetstore/jpetstore.yaml) file.
2. In your deployment.yaml file, you can define [resource quotas](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) for your containers to specify how much CPU and memory each container needs to properly start. If containers have resource quotas specified, the Kubernetes scheduler can make better decisions about the worker node where to place your pods on.
3. Next, you can use below commands to create and view the deployment and services created:

kubectl create -f <filepath/deployment.yaml>
kubectl get deployments
kubectl get services
kubectl get pods









 Summary 

In this tutorial, you learned the following:



* The differences between VMs, containers, and Kubernetes.
* How to define clusters for different environment types (dev, test, and production).
* How to handle data storage and the importance of persistent data storage.
* Apply the 12-factor principles to your app and use secrets for credentials in Kubernetes.
* Build container images and push them to IBM Cloud Container Registry.
A load balancer service that exposes the ALB is created and assigned a hostname.
4. The load balancer hostname is used to register the Ingress subdomain in Akamai. Akamai might have latency during the registration process.



Creating a cluster after deleting a cluster the same or similar name? See [Why does no Ingress subdomain exist after I create clusters of the same or similar name?](https://cloud.ibm.com/docs/containers?topic=containers-cs_rate_limit) instead.

 How to fix it 

Typically, after the cluster is ready, the Ingress subdomain and secret are created after 15 minutes.

If the Ingress subdomain and secret are still unavailable after your cluster is in a normal state for more than 15 minutes, you can check the progress of the creation process by following these steps:



1. Verify that the worker nodes have a State of normal and a Status of Ready. After you create the cluster, it can take up to 20 minutes for the worker nodes to be ready.

ibmcloud ks worker ls -c <cluster_name_or_ID>

Example output

ID Public IP Private IP Flavor State Status Zone Version
kube-blrs3b1d0p0p2f7haq0g-mycluster-default-000001f7 169.xx.xxx.xxx 10.xxx.xx.xxx u3c.2x4.encrypted deployed Ready dal10 1.26
2. Verify that the prerequisite steps for your ALB creation are completed.



* Classic clusters: Get the details of the ibm-cloud-provider-vlan-ip-config config map.

kubectl describe cm ibm-cloud-provider-vlan-ip-config -n kube-system
* If the config map shows IP addresses, continue to the next step.
This solution supports two approaches to initializing service instances: [by using recovery crypto units](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm-recovery-crypto-unit) and [by using key part files](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm). When you use recovery crypto units, the master key is automatically generated within crypto units, and you don't need to create multiple master key parts. When you use key part files, file contents are decrypted and appear temporarily in the clear in workstation memory.



For more information, see [Introducing service instance initialization approaches](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-instance-mode).
* Can I initialize my service instance through the TKE CLI plug-in by using a proxy?

Yes, if the proxy is configured for HTTPS port 443. You can add an entry to the local hostname mapping of your workstation with the TKE CLI, for example, in /etc/hosts. In this host mapping entry, map the TKE API endpoint tke.<region>.hs-crypto.cloud.ibm.com to your proxy. For example, for an instance in Frankfurt the URL is tke.eu-de.hs-crypto.cloud.ibm.com.
* Are there any recommendations on how to set up smart cards?

It is suggested that each master key part is created on a separate EP11 smart card and is assigned to a different person. Backup copies of all smart cards need to be created and stored in a safe place. It is suggested that you order 10 or 12 smart cards and initialize them this way:



* Create a certificate authority (CA) smart card and a backup certificate authority smart card.
* Create two EP11 smart cards and two backup EP11 smart cards to store two administrator signature keys. Generate administrator signature keys separately on two EP11 smart cards and copy them to other two backup smart cards.
Click the Export icon to download the MSP to a JSON file on your local system.

Zoom

![How to export MSP](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/export-msp.png)

Figure 13. How to export MSP

Share the JSON file with all of the members of the network who must import it into their console. It is important for them to import the updated MSP, so that when they create a new channel, they are using the MSP definition with the latest admin certificate.





 Import an MSP 

When another organization member shares their MSP with you, importing it into your console is important to ensure you are using the latest version of their organization MSP.



1. Navigate to the Organizations tab and click Import MSP definition.
2. Browse to the MSP JSON file that was shared with you and click Import MSP definition.



If you previously imported the MSP into your console, you need to update the definition.



1. On the Organizations tab and click the MSP tile.
2. Click the Settings icon and then Add file to browse to the new JSON file.
3. Click Update MSP. If you created any nodes in your console that use this MSP, they are updated with the new MSP and restarted.



--------------------



1. If a certificate expires in more than five years, the expiration date is not visible from the console.[↩](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtfootnote-how-to-view1-ref)
2. If a certificate expires in more than five years, the expiration date is not visible from the console.
If you have more than one read-only replica that is attached to a leader, a user that is created on any one of the read-only replicas is also created on all of the other read-only replicas.

Read-only replica users who are created on a read-only replica are able connect to the replicas and run reads. Read-only replica users are not able to connect and run operations on the leader. They also do not persist when a read-only replica is promoted to a stand-alone deployment.

Read-only replica created users are assigned privileges by the leader, and are assigned the ibm-cloud-base-user-ro role, and are members of the ibm-cloud-base-user group. They have access to all of the objects that are created by other members of this group, including any users on the leader that were created through Service Credentials, the CLI, or the API. Consistent with privileges of the ibm-cloud-base-user, a read-only replica-created user does not have access to objects created by the admin user, or other users created through psql. For more information, see the [PostgreSQL Roles and Privileges](https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-user-management) page.







 Resyncing a Read-only Replica 

If you need to resync a read-only replica, click the Resync Read-Only Replica button. Resyncing is a disruptive operation and performing a resync tears down and rebuilds the data in the read-only replica. The read-only replica is not able to perform any other operations or run any queries while a resync is running. Queries are not rerouted to the leader, so any connections to the read-only replica fail until it is finished resyncing.

The amount of time it takes to resync a read-only replica varies, but the process can be long running.
The format of the name of the image for this job is REGISTRY/NAMESPACE/REPOSITORY:TAG where REGISTRY and TAG are optional. If REGISTRY is not specified, the default is docker.io. If TAG is not specified, the default is latest.







 Next steps 



* After you create your job, submit the job to run it. See [Run a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job). You can run your job multiple times.
* After you [run your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job), to view details of your job and job runs, see [access job details](https://cloud.ibm.com/docs/codeengine?topic=codeengine-access-job-details).
* Now that your job is created, consider making your jobs event-driven. By using event subscriptions, you can trigger your jobs by [periodic schedules](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-croneventing-cron-job) or set your job to react to events like [file uploads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producerobstorage_ev_job).
* You can [update your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-job) and its referenced code in any of the following ways, independent of how you created or previously updated your job.



* If you have a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/), then you need to provide only a reference to the image, which points to the location of your container registry when you create (or update) your job.
Why can't I create vaults? 

You are not able to create a vault through either the Hyper Protect Crypto Services user interface or the Unified Key Orchestrator API.

  What’s happening 

You might receive an error message similar to one of the following messages when you create a vault:

> The service was not able to create vault "vault-name" or the vault "vault-name" is not created.

  Why it’s happening 

It might be caused by one of the following reasons:



*  You do not have the correct authorization to perform Hyper Protect Crypto Services actions.
*  The master key rotation is in progress.



  How to fix it 

Try the following solutions:



*  Verify with your administrator that you're assigned the Vault Administrator role in the applicable resource group or service instance. For more information about roles, see [Roles and permissions](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-manage-accessuko-service-access-roles).
*  Try to create the vault again after the master key rotation is complete. For more information, see [Master key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-master-key-rotation-intro).
offering_version_crn="crn:v1:staging:public:globalcatalog-collection:global:a/efe5afc483594adaa8325e2b4d1290df:0b322820-dafd-4b5e-b694-6465da6f008a:version:136559f6-4588-4af2-8585-f3c625eee09d/8ae92879-e253-4a7c-b09f-8d30af12e518"









 Create an instance 

Create an instance in the newly created subnet. Pass in your public SSH key so that you can log in after the instance is provisioned.

Run one of the following CLI commands based on the image you plan to use.



* Create an instance using a stock image or custom image from your account for your instance.

ibmcloud is instance-create my-instance $vpc us-south-3 bx2-2x8 $subnet --image-id $image --key-ids $key
* Create an instance using a private catalog managed image from the latest image version.

ibmcloud is instance-create my-instance $vpc us-south-3 bx2-2x8 $subnet --catalog-offering $offering_crn --keys $key
* Create an instance using a private catalog managed image from a specific version of the image.

ibmcloud is instance-create my-instance $vpc us-south-3 bx2-2x8 $subnet --catalog-offering-version $offering_version_crn --keys $key



Information about the network interface that is created for the new instance is not returned after the instance is created.

From the output that's returned, save the ID of the instance in a variable so you can use it later, for example:

instance="0738-21179496-964e-4c00-8210-cf23d75750b3"

The status of the instance is pending when it's first created.
Also, to isolate this traffic in logical segments in the underlying network infrastructure and dedicate a Distributed Port Group in the Distributed Virtual Switch.

In IBM Cloud VPC, each IBM Cloud bare metal server is connected to a VPC subnet by using its primary PCI interface. This interface is used by the default management VMkernel adapter vmk0. For the other System Traffic Types in VMware, VLAN interfaces are used and one VLAN interface is created for each VMkernel adapter type.

The following table lists the VMK key that is required in this architecture for each ESXi host. Depending on your design and planned capabilities, you might not need all VMKs listed here. However, when you plan the deployment and VPC infrastructure automation with, for example Terraform, it is recommended to take a note of these requirements.



Table 2. Host management networks and VMkernel adapters

 Interface name Interface type VLAN ID Subnet Allow float VMkernel adapter Distributed Port Group name 

 pci-nic-vmnic0-vmk0 pci 0 vpc-host-subnet false vmk0 dpg-hosts 
 vlan-nic-vmotion-vmk2 vlan 200 vpc-vmot-subnet false vmk2 dpg-vmotion 
 vlan-nic-vsan-vmk3 vlan 300 vpc-vsan-subnet false vmk3 dpg-vsan 
 vlan-nic-tep-vmk10 vlan 400 vpc-tep-subnet false vmk10 dpg-tep 



If you are not using NSX-T, you do not need vlan-nic-tep-vmk10 interface.

If you are not using vSAN, you do not need vlan-nic-vsan-vmk3 interface.

The following diagram presents how PCI and VLAN interfaces, Distributed Virtual Switch and Distributed Port Groups are created and used with basic deployment architecture without NSX-T.

Zoom

!