vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Using the REST API or SDKs 

Incomplete multipart uploads do persist until the object is deleted or the multipart upload is aborted. If an incomplete multipart upload is not aborted, the partial upload continues to use resources. Interfaces should be designed with this point in mind, and clean up incomplete multipart uploads.

There are three phases to uploading an object in multiple parts:



1. The upload is initiated and an UploadId is created.
2. Individual parts are uploaded specifying their sequential part numbers and the UploadId for the object.
3. When all parts are finished uploading, the upload is completed by sending a request with the UploadId and an XML block that lists each part number and it's respective Etag value.



For more information about endpoints, see [Endpoints and storage locations](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-endpointsendpoints)



 Initiate a multipart upload 

A POST issued to an object with the query parameter upload creates a new UploadId value, which is then be referenced by each part of the object being uploaded.

Syntax

POST https://{endpoint}/{bucket-name}/{object-name}?uploads= path style
POST https://{bucket-name}.{endpoint}/{object-name}?uploads= virtual host style

Example request

POST /some-bucket/multipart-object-123?uploads= HTTP/1.1
Authorization: Bearer {token}
Host: s3.us.cloud-object-storage.appdomain.cloud

Example response

HTTP/1.1 200 OK
Date: Fri, 03 Mar 2017 20:34:12 GMT
X-Clv-Request-Id: 258fdd5a-f9be-40f0-990f-5f4225e0c8e5
Accept-Ranges: bytes
Server: Cleversafe/3.9.1.114
X-Clv-S3-Version: 2.5
You can create the cluster or the worker pool within an existing cluster with the Cloud Pak entitlement by using the --entitlement cloud_pak option in the [ibmcloud oc cluster create classic](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_create) or [ibmcloud oc worker-pool create classic](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create) CLI commands. Make sure to specify the correct number and flavor of worker nodes that you are entitled to use.

Do not exceed your entitlement. Keep in mind that your OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what you are entitled to use. For example, you might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and you can't use the same entitlement for other worker pools, cloud providers, or environments.





 What is included in a Cloud Pak? 

Cloud Paks are bundled, licensed, containerized software that is optimized to work together for enterprise use cases, including consistent deployment, access control, and billing. You can flexibly use parts of the Cloud Paks when you need them by choosing the correct mix of virtual processor cores of the software to suit your workloads. You can also change the mix of virtual processor cores as your workloads evolve.

Depending on the Cloud Pak, you get licensed IBM and open source software bundled together in a unified management experience with logging, monitoring, security, and access capabilities.



* IBM products: Cloud Paks extend licensed IBM software and middleware from [IBM Marketplace](https://www.ibm.com/products), and integrate these products with your cluster to modernize, optimize, and run hybrid cloud workloads.
List parts 

A GET given a path to a multipart object with an active UploadID specified as a query parameter returns a list of all of the object's parts.

Not all operations are supported in Satellite environments. For details, see [supported Satellite APIs](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-apis-cos-satellite)

Syntax

GET https://{endpoint}/{bucket-name}/{object-name}?uploadId={uploadId} path style
GET https://{bucket-name}.{endpoint}/{object-name}?uploadId={uploadId} virtual host style



 Query parameters 



 Parameter Required? Type Description 

 uploadId Required string Upload ID returned when initializing a multipart upload. 
 max-parts Optional string Defaults to 1,000. 
 part-number-marker Optional string Defines where the list of parts begins. 



Example request

GET /farm/spaceship?uploadId=01000162-3f46-6ab8-4b5f-f7060b310f37 HTTP/1.1
Authorization: bearer {token}
Host: s3.us.cloud-object-storage.appdomain.cloud

Example request

GET /farm/spaceship?uploadId=01000162-3f46-6ab8-4b5f-f7060b310f37 HTTP/1.1
Authorization: 'AWS4-HMAC-SHA256 Credential={access-key}/{date}/{region}/s3/aws4_request,SignedHeaders=host;x-amz-date;,Signature={signature}'
x-amz-date: {timestamp}
Host: s3.us.cloud-object-storage.appdomain.cloud

Example response

HTTP/1.1 200 OK
Date: Mon, 19 Mar 2018 17:21:08 GMT
Using this approach, you run a series of commands to generate signature keys and master key parts, add administrators, set the signature thresholds, and load the master key registers. For more information, see [Initializing service instances by using key part files](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm).

You need to be assigned the appropriate role to perform TKE CLI plug-in operations. For more information about the available service access roles, see [Service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-manage-accessuko-service-access-roles).

For a complete list of commands available in the TKE CLI plug-in, see [IBM Cloud Trusted Key Entry CLI plug-in reference](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-cli-plugin-hpcs-cli-plugintke-cli-plugin).





 Understanding operational crypto units 

Operational crypto units are used to manage encryption keys and perform cryptographic operations. Operational crypto units are the crypto units that you send API requests to. When you create a service instance, the number of crypto units that you specify is the number of operational crypto units. Operational crypto units are located in different availability zones of the same region where your instance resides.





 Understanding recovery crypto units 

Two recovery units are automatically assigned to your service instance without extra costs. One recovery unit is allocated in the same region as the operational crypto units, and the other is allocated in a backup region. When you run the ibmcloud tke auto-init or ibmcloud tke auto-mk-rotate command, a random master key value is generated in one of the recovery crypto units and then securely exported to the other crypto units (including failover crypto units if any) for the service instance.

The sole purpose of the recovery crypto units is to save a backup copy of the master key value. The recovery crypto units are not used when running operational workloads.
Which index is used by query? Field type requirement 

 JSON index It's not necessary to specify the type of sort fields in the query. 
 Text index of all fields in all documents Specify the sort field in the query if the database contains documents where the sort field has one type. Also, specify the sort field in the query if it contains documents where the sort field has a different type. 
 Any other text index Specify the type of all sort fields in the query. 



A text index of all fields in all documents is created when you use the syntax: ["index": {}](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-querythe-index-field).

The sorting order is undefined when fields contain different data types. This characteristic is an important difference between text and view indexes. Sorting behavior for fields with different data types might change in future versions.

See the following example of a simple query that uses sorting:

{
"selector": {
"Actor_name": "Robert De Niro"
},
"sort": [
{
"Actor_name": "asc"
},
{
"Movie_runtime": "asc"
}
]
}





 Filtering fields 

It's possible to specify exactly which fields are returned for a document when you select from a database. The two advantages are shown in the following list:



* Your results are limited to only those parts of the document that are needed for your application.
* A reduction in the size of the response.



The fields to be returned are specified as an array.

Only the specified filter fields are included in the response. _id or other metadata fields aren't automatically included.

See the following example of selective retrieval of fields from matching documents:

{
"selector": {
"Actor_name": "Robert De Niro"
},
"fields": [
"Actor_name",
"Movie_year",
"_id",
"_rev"
]
}





 Pagination
Considerations for high availability 

When it comes to

high availabilityin the cloud, it is important to understand the high-level concepts that need to be addressed by anyone who is looking to build or run a highly available cloud system.



 Formula for high availability 

One useful definition of availability is MTBF/(MTBF+MTTR), where MTBF is Mean Time Between Failures and MTTR is Mean Time To Repair. Since MTBF is the time when the system is up, and MTTR is the time that the system is down, this can be summarized as Availability = (The time the system is up)/(The time the system is up + The time the system is down).

The reason the formula is useful is that it allows us to see how to improve availability. One can increase MTBF, decrease MTTR, or both. Put another way, this means that availability can be improved by increasing reliability, fixing things when they break more quickly, or both. Both approaches have been used with computer systems over the years. The mainframe, which uses high reliability parts, redundant parts, and modularity to allow quicker repairs, shows that significant levels of availability are possible with this approach.

Zoom

![Availability formula.](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/overview/images/availability-formula.svg)

Figure 1. Summarized availability formula





 Redundancy in the cloud 

In cloud computing, standard reliability parts are used, along with very high levels of redundancy. And, in some ways it is extremely modular in that the replacement unit is usually an entire server. But there is one major difference between the redundancy that is provided in a mainframe and the redundancy that is provided in the cloud – in the cloud the redundancy must be managed by the user. This means that to design a system to run with high availability on the cloud the system designer needs to be familiar with various high availability issues, as well as the design issues associated with the system that they are trying to build.
Why can't I create access management tags? 

If you can't create an access management tag within an IBM Cloud® account that you're not the owner of, you might need to check the type of access you're assigned.

  What’s happening 

You can't create access management tags in an account of which you are a member.

  Why it’s happening 

This problem can commonly occur by one of the following reasons:



*  You might not be assigned the appropriate access to complete the action. You must have the Administrator role on the Tagging Service that is listed under the Account management services or Administrator role on all Account management services.
*  You reached the limit of 250 access management tags per account.
*  Some services don't have full support for access management tags on their UI, so when you're creating an instance of those services, you can only attach user tags. To learn how you can work with access management tags, see the tutorial about [controlling access to resources by using tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial).



  How to fix it 

Complete the following steps to check your level of access. If you need to request access, contact the account owner.

Go to Manage > Access (IAM) in the IBM Cloud console, and select your name on the Users page.



*  To view IAM access policies that are assigned to you, select Access and view the Access policies table.
*  To determine what access you have through the access groups you are assigned, select Access and view the Access groups table. Check the access policies for each of the access groups.



To view what actions are mapped to each role, click the numbers listed next to each role.
ibmcloud pi network-create-private NETWORK_NAME --cidr-block CIDR --ip-range "startIP-endIP[,startIP-endIP]" [--dns-servers "DNS1 DNS2"] [--gateway GATEWAY] [--json]



 Networking considerations 

Network communication between virtual server instances on the same private network is enabled by using a PER enabled workspace. This works by attaching the subnet to a cloud connection and transit gateway, routing over a Direct Link, or configuring VPNaaS. If you need a private network communication between the two Power Systems Virtual Server instances and are not using one of these methods, you must open a [support ticket](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-getting-help-and-support) against Power Systems Virtual Server to configure such private network communication.

For example, if you add a subnet 172.10.10.0/24 from user interface, and if this use case requires communication between the virtual server instances that are attached to the subnet without the use of the other methods listed above, you must open a support ticket and provide the following subnet information that is displayed in the Power Systems Virtual Server user interface.



Table 1. Example subnet information displayed in UI

 Name Gateway VLAN ID CIDR 

 powerns-net02 172.10.10.1 3001 172.10.10.0/26 







 Using CIDR notation 

You must not use an IP range outside of the ranges that are defined by [RFC 1918](https://tools.ietf.org/html/rfc1918) (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) for a subnet. The instances that are attached to that subnet might not be able to reach parts of the public internet.
And, it can’t be assigned to any other resource group.





 What is an IAM access policy? 

An IAM access policy is how users, services IDs, trusted profiles, and access groups in an account are given permission to work with a specific IAM-enabled service or resource instance, manage a resource group, or complete account management tasks. Each IAM access policy is made of a subject, target, and role. A subject is the who that has the access. The target is what the subject can have access to. And, the role, whether it is a platform or service role depending on the context of the selected target, defines what level of access the subject has on the target.

A subject is a user, service ID, trusted profile, or access group. A target can be a service in the account, a resource group in the account, a specific resource instance or type, or an account management service. And, the roles that are provided as choices depend on your selected target. Some services have service-specific roles that are defined, and some use platform roles only. To understand this concept visually, check out the following graphic with an outline of the options for creating an IAM policy:

Zoom

![Creating IAM policies](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/IAM.svg)

Figure 1. How IAM access policies are created by using a subject, target, and role





 How do I find out what I have access to? 

In the IBM Cloud console, go to Manage > Access (IAM), and select your name on the Users page. Then, depending on the access you're looking for, open the different tabs:



* To determine what access you have through the access groups you are assigned, select Access and view the Access groups table.
* To see IAM access policies that are assigned to you, select Access and view the Access policies table.







 What actions are mapped to each IAM role?
global-search-tagging.tag.delete An event is generated when you delete a tag in your account. 
 global-search-tagging.tags.delete An event is generated when you delete all the tags that are not attached to resources in your account. 
 <service-name>.tag.attach An event is generated when you associate a tag to a resource. 
 <service-name>.tag.detach An event is generated when you remove a tag from a resource. 



When an access tag is created, you get an event with global-search-tagging.tag.create.

When an access tag is attached to a resource you get the event <service-name>.tag.attach.





 Events for managing users 

The following table lists the actions that generate an event:



Table 15. Actions that generate events

 Action Description 

 user-management.user.create An event is generated when you invite a user to the account. 
 billing.user.active An event is generated when a user, that has received an email invitation to join an account, verifies the email address. 
 user-management.user.update An event is generated when log in configurations are modified for a user from the IBM Cloud UI. 
 user-management.user.delete An event is generated when you remove a user from the account. 
 user-management.user-setting.update An event is generated when you update the user's login configuration settings: User one-time passcode authentication ,Require MFA security questions at login, User-managed login or Setting up security questions 







 Where to look for the events 

Events are available in the Frankfurt (eu-de) region.

To view these events, you must [provision an instance](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-provisionprovision) of the IBM Cloud Activity Tracker service in the Frankfurt (eu-de) region. Then, you must [open the IBM Cloud Activity Tracker UI](https://cloud.ibm.com/docs/atracker?topic=atracker-launchlaunch_cloud_ui).





 Analyzing events 



 Catalog events 

You can find the value unavailable in catalog events.
global-search-tagging.tag.delete An event is generated when you delete a tag in your account. 
 global-search-tagging.tags.delete An event is generated when you delete all the tags that are not attached to resources in your account. 
 <service-name>.tag.attach An event is generated when you associate a tag to a resource. 
 <service-name>.tag.detach An event is generated when you remove a tag from a resource. 



When an access tag is created, you get an event with global-search-tagging.tag.create.

When an access tag is attached to a resource you get the event <service-name>.tag.attach.





 Events for managing users 

The following table lists the actions that generate an event:



Table 15. Actions that generate events

 Action Description 

 user-management.user.create An event is generated when you invite a user to the account. 
 user-management.user-invitation.accept An event is generated when a user, that has received an email invitation to join an account, verifies the email address. 
 user-management.user.update An event is generated when log in configurations are modified for a user from the IBM Cloud UI. 
 user-management.user.delete An event is generated when you remove a user from the account. 
 user-management.user-setting.update An event is generated when you update the user's login configuration settings: User one-time passcode authentication ,Require MFA security questions at login, User-managed login or Setting up security questions 







 Where to look for the events 

Events are available in the Frankfurt (eu-de) region.

To view these events, you must [provision an instance](https://cloud.ibm.com/docs/services/activity-tracker?topic=activity-tracker-provisionprovision) of the IBM Cloud Activity Tracker service in the Frankfurt (eu-de) region. Then, you must [open the IBM Cloud Activity Tracker UI](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-launchlaunch_cloud_ui).





 Analyzing events 



 Catalog events 

You can find the value unavailable in catalog events.
The same tag can be attached to several resources by different users in the same billing account. Users don't have the same visibility on all resources on the account. Contact the account owner who can resolve the problem by detaching the tag from the blocking resource.

If you still can't delete it, the tag might be attached to a reclaimed resource. You can use the IBM Cloud CLI to manage the reclamation process of specific resources. For more information, see [Using resource reclamations](https://cloud.ibm.com/docs/account?topic=account-resource-reclamation).

When you delete an access management tag from the account, any associated IAM policies are also deleted with it.
* How do I view my dashboard role?

You can view the role that you are assigned on a dashboard by going to Manage > Account > Dashboards in the IBM Cloud console. All users besides the dashboard owner have the viewer role on the dashboard.
* Can I edit the default dashboard?

You can't edit the default dashboard directly. However, you can create a duplicate version that you can edit and personalize however you want by clicking the Actions icon ![Actions icon](https://cloud.ibm.com/icons/action-menu-icon.svg) > Edit in IBM Cloud console.

By maintaining the original version of the default dashboard, you can discover the latest widgets and functionalities, which get built and added over time. This way, you can always bring out the most of your workflow.

You can also switch between the duplicate and original versions by selecting each one from your list of dashboards that's displayed on your active dashboard.
* Can I move an org to another account?

Currently, you can't move an org to a different account. However, you can re-create the org with the same credentials in a different account to mimic this functionality. For more information, see [Adding orgs and spaces](https://cloud.ibm.com/docs/account?topic=account-orgsspacesuserscreateorg).
* Why can't I create a Lite account?
See [Options for visibility for a Code Engine application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsoptionsvisibility). 
 branch The branch in the repository that contains the buildpacks file or the Dockerfile. The default value is main. 
 build-size The size for the build, which determines the amount of resources used. Valid values are small, medium, large, xlarge. For details, see [Determining the size of the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-size). 
 build-strategy The strategy to use for building the image. Valid values are dockerfile and buildpacks. 
 build-timeout The amount of time, in seconds, that can pass before the build run must succeed or fail. The default is 1200 seconds. 
 build-use-native-docker Optional property to opt-in for using native Docker build capabilities instead of the Code Engine build to containerize the source. You can select this value only if the build-strategy is set to dockerfile. Valid values are true and false. 
 code-engine-project The project that contains this application. 
 cpu The amount of CPU set for the instance of the application. For valid values, see [Supported memory and CPU combinations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-mem-cpu-combo). The default value is 1. 
 deployment-type Specifies the type of deployment. Valid values are application and job. 
 ephemeral-storage The amount of ephemeral storage to set for the instance of the application. Use M for megabytes or G for gigabytes. 
 git-token The access token for the Git repository. 
 image-name The name of the image that is used for this application. The format 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.