vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Controlling request logging for Watson services 

By default, most IBM Watson® services log requests and their results. Logging is done only to improve the services for future users. The logged data is not shared or made public.

The Language Translator and Tone Analyzer services do not log any request data. You cannot opt in to request logging at the request level or at the account level.

If you are concerned with protecting the privacy of users' personal information or otherwise do not want your requests to be used by IBM, you can choose not to have IBM learn from your data (opt out). Choose to opt out at either the account level or at the API request level.



*  To prevent IBM usage of your data for general service improvements for all services for which you are the owner, select Do not learn from my data on the [Watson Privacy Settings](https://cloud.ibm.com/watson/settings/) page. To access the setting, you must be the account owner.
*  To prevent IBM usage of your data for an API request, set the X-Watson-Learning-Opt-Out header parameter to true.



A choice to opt out from logging data at either level overrides a choice to opt in.

You cannot opt in at the request level if you opt out at the account level. However, you can opt out at the request level if the account is set to opt in. If your intent is to opt out for a subset of your services, select Learn from my data at the account level. Then, set the request header to true to prevent usage of your data on those requests.

For more information about specific use, see the [API reference](https://cloud.ibm.com/developer/watson/documentation) for the Watson service.
On the Delivery pipelines card, click the private workers tool integration for which you want to view a list of all of the registered workers. This worker pool contains one or more private workers that are installed on different clusters, but share a ServiceId. When work is assigned to a private worker pool, any of the private workers that are listed in the pool are eligible to run the workload.

The following information is provided for each worker that is registered in this pool:



* Name: The name of the registered worker.
* Status: The current status of the worker.
* Version: The current version of the worker. If the current version is out of date, a notification is displayed.
* Tekton Version: The Tekton release version.
* Cluster: The name of the cluster that the worker is registered on, if available.
* Last Active: The last time that the agent reported in.



Private workers can have one of the following statuses:



* active: The private worker is operating normally.
* inactive: The private worker is offline. Check your cluster. You might need to register the private worker again.
* unsupported: The private worker version in use is no longer supported. The private worker cannot run and you must update to the latest version.









 Updating a Delivery Pipeline Private Worker 

Complete the following steps to update a private worker to use the latest version:



1. Log in as an authorized user to the cluster that hosts the worker.
2. Run the following command:



kubectl apply --filename "https://private-worker-service.{REGION}.devops.cloud.ibm.com/update"





 Delivery Pipeline Private Worker images 

The private worker installation script pulls required images from the global IBM Cloud® Container Registry. It pulls the most recent images of pipeline private workers and respective Tekton framework images that include fixes for any vulnerability found.

The image URL for the pipeline private worker is icr.io/continuous-delivery/pipeline/pipeline-private-worker:<agent version>.



Table 4. Private Worker images

 Pipeline private worker image version IBM Cloud® Container Registry version Known vulnerabilities
You are next asked to enter your username and password. After you have signed in, you can see an Overview of your RabbitMQ deployment.

Use any user on your deployment to access the UI. Some features are only available to the admin user provisioned with your deployment.

For more information, see the [RabbitMQ Management plug-in](https://www.rabbitmq.com/management.html) page.



 Connecting through private endpoints 

Messages for RabbitMQ also offers both private and public cloud service endpoints. If you want to access the Management UI from a browser that is not on the private network, you must take these additional steps as listed in the [Connecting Through Private Endpoints](https://cloud.ibm.com/docs/messages-for-rabbitmq?topic=cloud-databases-service-endpointsprivate-endpoint-connections) documentation for IBM Cloud® Databases.

After you have configured your environment for private endpoint access, you can navigate to the Messages for RabbitMQ management endpoint URL from your browser. For example, https://bfdb-4263-8ad2-c9a4beaf4591.8f7bfc8f3faa4218afd56e0.databases.appdomain.cloud:323232







 RabbitMQ Management HTTP API 

The Management plug-in also provides an [API](https://www.rabbitmq.com/management.htmlhttp-api) for your RabbitMQ deployment. The base endpoint the same HTTP URL as the browser URL with /api. For example, https://1a619c43-6425-4abb-8df0-0c7b1b3a3001.8f7bfd8f3faa4218aec56e069eb46187.databases.appdomain.cloud:31797/api/

The API uses application/json data and requires basic authentication. You can use any user that you created on your deployment to access the UI. However, some features might be available only to the admin user.
Getting secret 'myliteralsecret'...
OK

Name: myliteralsecret
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: generic
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2023-03-07 21:06:34 +0000 UTC

Data:
---
TARGET: TXkgbGl0ZXJhbCBzZWNyZXQ=

Notice that the value of the key TARGET for this generic secret is encoded. To display the secret data as decoded, use the --decode option with the secret get command.





 Creating a registry secret with the CLI 

A registry secret stores credentials to access a container registry.

The following example creates a registry secret that is named mysecret-registry to access an IBM Cloud Container Registry instance that is on the us.icr.io registry server and specifies credentials for username and password.

ibmcloud ce secret create --name mysecret-registry --format registry --server us.icr.io --username iamapikey --password API_KEY

To display the details of this secret,

ibmcloud ce secret get --name mysecret-registry

Example output

Getting secret 'mysecret-registry'...
OK

Name: mysecret-registry
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: registry
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2023-03-07 20:00:45 +0000 UTC

Data:
---
email: ""
password: REDACTED
server: dXMuaWNyLmlv
username: aWFtYXBpa2V5
"payload": {
"key6": "value6"
}
},
"secret_group_id": "aded5ffd-da17-c923-eb21-600569c5d1c2",
"secret_type": "kv",
"state": 1,
"state_description": "Active",
"versions": [
{
"created_by": "iam-ServiceId-9ca24407-f38d-479e-8b02-ed6b4e1b0d31",
"creation_date": "2022-01-27T17:59:20Z",
"downloaded": false,
"id": "96d5b7dd-d8fb-5afc-9c05-6cfdaff8af9e",
"payload_available": true
}
],
"versions_total": 1
},
"wrap_info": null,
"warnings": null,
"auth": null
}

A request to create user credentials in the default secret group returns the following response:

{
"request_id": "96fc9603-5aff-5daa-f25c-efc3599b374b",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"created_by": "iam-ServiceId-c0c7cfa4-b24e-4917-ad74-278f2fee5ba0",
"creation_date": "2020-12-15T22:43:36Z",
The multiple worker agents are now listed in the private worker integration UI and jobs are scheduled on those agents based on the cluster load at pipeline run request time.
* How do I view the status of private workers on multiple clusters by using the CLI?

You can use the following command within a script that traverses all of the clusters that private workers are installed on.

kubectl get workeragent -ojson | jq '.items[] | .status.versionStatus.state'

Consider upgrading any private workers that return results that are not OK.
* Which attributes can I use for private worker agents?

The following attributes are available for private worker agents:



* NAME: The name that was specified when the agent was registered. This name appears on the Private Worker integration page.
* SERVICEID: The work queue ID from which this agent processes work requests.
* AGENT: A value of OK indicates that the agent can process work requests.
* REGISTERED: A value of Succeeded indicates that the agent successfully registered with the regional private worker service.
* VERSION: A value of OK indicates whether the version of the agent is current.
* AUTH: A value of OK indicates whether the agent apikey is valid.
* CONSTRAINED: A value of false indicates that enough cluster resources are available for the agent to run tasks. A value of True specifies that the cluster is resource-constrained.
* PAUSED: A value of false indicates that the agent is operational and can run tasks. A value of true specifies that the agent is paused and cannot run any tasks. One reason that an agent might be paused is for cluster maintenance.



* How do I set my ClusterImagePolicy so that I can access Tekton images?

Because Delivery Pipeline private workers depend on the Tekton and tekton-pipelines infrastructure, they must pull tekton-releases images from icr.io (icr.io/continuous-delivery/pipeline/). You might need to define a specific Kubernetes ClusterImagePolicy to pull images from these container registries.
Retrieves a secret group and its details.



 Example request 

curl -X GET "https://{instance_id}.{region}.secrets-manager.appdomain.cloud/v1/auth/ibmcloud/manage/groups/{group_id}" -H 'Accept: application/json' -H 'X-Vault-Token: {Vault-Token}'





 Example response 

{
"request_id": "0d127ae6-8359-bc36-af53-3a56be4c3e24",
"lease_id": "",
"renewable": false,
"lease_duration": 0,
"data": {
"creation_date": "2020-12-15T22:08:46Z",
"description": "Updated description for my secret group.",
"id": "2bcaa289-5d38-aa57-910d-970e418ab1b3",
"last_update_date": "2020-12-15T22:18:44Z",
"name": "updated-secret-group-name",
"type": "application/vnd.ibm.secrets-manager.secret.group+json"
},
"wrap_info": null,
"warnings": null,
"auth": null
}







 Delete a secret group 

Deletes a secret group.



 Example request 

curl -X DELETE "https://{instance_id}.{region}.secrets-manager.appdomain.cloud/v1/auth/ibmcloud/manage/groups/{group_id}" -H 'Accept: application/json' -H 'X-Vault-Token: {Vault-Token}'





 Example response 

{
"request_id": "37065859-3238-f671-941f-d43ac340ad99",
"lease_id": "",
"renewable": false,
"iam_id": "$SERVICE_ID",
"status_code": 400,
"trace": "12345678-abcd-1a2b-a1b2-1234567890ab",
"errors":
{
"code": "error_occurred",
"message": "The service id is missing or incorrect"
}
]
}
]
}

{
"members": [
{
"iam_id": "$IBM_ID",
"type": "user",
"created_at": "2019-01-01T01:01:00Z",
"created_by_id": "CREATOR_ID",
"status_code": 200
},
{
"iam_id": "$SERVICE_ID",
"status_code": 400,
"trace": "12345678-abcd-1a2b-a1b2-1234567890ab",
"errors":
{
"code": "error_occurred",
"message": "The service id is missing or incorrect"
}
]
}
]
}

{
"members": [
{
"iam_id": "$IBM_ID",
"type": "user",
"created_at": "2019-01-01T01:01:00Z",
"created_by_id": "CREATOR_ID",
"status_code": 200
},
{
"iam_id": "$SERVICE_ID",
"status_code": 400,
"trace": "12345678-abcd-1a2b-a1b2-1234567890ab",
"errors":
{
"code": "error_occurred",
"message": "The service id is missing or incorrect"
}
]
}
ibmcloud sl user create my@email.com --email my@email.com --password generate --api-key --template '{"firstName": "Test", "lastName": "Testerson"}'

Remember to set the permissions and access for this new user.





 ibmcloud sl user delete 

Sets a user's status to CANCEL_PENDING, which immediately disables the account, and is eventually removed from the account by an automated internal process:

ibmcloud sl user delete IDENTIFIER [OPTIONS]

Command options:

-f, --force
: Force operation without confirmation.

Examples:

Delete a user with the ID userId.

ibmcloud sl user delete userId





 ibmcloud sl user detail 

View a user's details:

ibmcloud sl user detail IDENTIFIER [OPTIONS]

Command options:

--keys
: Show the users API key.

--permissions
: Display permissions that are assigned to this user. Master users do not show permissions.

--hardware
: Display hardware this user has access to.

--virtual
: Display virtual guests this user has access to.

--logins
: Show login history of this user for the last 24 hours.

--events
: Show audit log for this user.





 ibmcloud sl user detail-edit 

Edit a user's details:

ibmcloud sl user detail-edit IDENTIFIER [OPTIONS]

Command options:

--template
: A JSON string that describes [https://softlayer.github.io/reference/datatypes/SoftLayer_User_Customer/](https://softlayer.github.io/reference/datatypes/SoftLayer_User_Customer/).

Examples:

This command edit a user's details.

ibmcloud sl user detail-edit USER_ID --template '{"firstName": "Test", "lastName": "Testerson"}'





 ibmcloud sl user list 

To list users:
With trusted profiles, Marla can automatically grant federated users access to the resources they need without having to invite them to an account and assign access one at a time. This tutorial uses fictitious identity provider attributes that might be different from your corporate user directory.



 Before you begin 



* Make sure you're assigned the following access:



* Administrator role in the account to create a trusted profile
* Administrator role on the specific resources to which you are assigning access



* Enable authentication from an external identity provider. For more information, see [Enabling authentication from an external identity provider](https://cloud.ibm.com/docs/account?topic=account-idp-integration).
* Create an instance of the following services and add them to a resource group for this tutorial.



* IBM Cloud Kubernetes Service
* IBM Watson® Tone Analyzer









 Step 1: Create a trusted profile 

First, Marla creates the trusted profile for the test environment:



1. Go to Manage > Access (IAM) in the IBM Cloud console, and select Trusted profiles.
2. Click Create profile.
3. Name the profile Chatbot Dev (test).
4. In the description, list the level of access you want to assign to the profile. The description helps your team quickly identify different profiles from the list of trusted profiles. In this case:



1. Platform: Viewer
2. Services: Reader



5. Click Continue.







 Step 2: Establish trust with federated users 

Now that Marla created a trusted profile, she wants to establish criteria for the federated users that can apply this profile. To do this, she creates conditions based on the attributes in her company's corporate user directory. Marla and half of the team members are based in the Ireland, and the other half are based in the United States.



1. For trusted entity type, select Federated users.
2. For authentication method, select Users federated by IBM Cloud App ID from the list.

If the users that you are creating a trusted profile for use IBM Cloud App ID, you should create the trusted profile as an App ID user, and likewise for IBMid.
"name": "example-private-certificate",
"description": "Extended description for this secret.",
"secret_group_id": "bc656587-8fda-4d05-9ad8-b1de1ec7e712",
"labels":
"dev","us-south"
],
"certificate_template": "example-certificate-template"
"common_name": "cert_common_name",
"rotation": {
"enabled": false,
"rotate_keys":false
},
"custom_metadata" : {
"anyKey" : "anyValue"
},
"version_custom_metadata" : {
"anyKey" : "anyValue"
},
"expiration_date" : "2030-01-01T00:00:00Z",
}
]

The command outputs the ID value of the secret, along with other metadata. For more information about the command options, see [ibmcloud secrets-manager secret-create](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-create-command).





 Creating private certificates with the API 

You can generate private certificates programmatically by calling the Secrets Manager API.

The following example shows a query that you can use to create a private certificate. When you call the API, replace the ID variables and IAM token with the values that are specific to your Secrets Manager instance.

You can store metadata that are relevant to the needs of your organization with the custom_metadata and version_custom_metadata request parameters. Values of the version_custom_metadata are returned only for the versions of a secret. The custom metadata of your secret is stored as all other metadata, for up to 50 versions, and you must not include confidential data.

curl -X POST
"hostname": "dd754295-e9e0-4c9d-bf6c-58fbc59e5727.lb.appdomain.cloud",
"is_public": true,
"profile": {
"name": "network-fixed",
"family": "network"
},
"listeners": [
{
"id": "0738-70294e14-4e61-11e8-bcf4-0242ac110004",
"href": "https://us-south.iaas.cloud.ibm.com/v1/load_balancers/dd754295-e9e0-4c9d-bf6c-58fbc59e5727/listeners/70294e14-4e61-11e8-bcf4-0242ac110004"
}
],
"operating_status": "online",
"pools": [
{
"id": "0738-70294e14-4e61-11e8-bcf4-0242ac110004",
"href": "https://us-south.iaas.cloud.ibm.com/v1/load_balancers/dd754295-e9e0-4c9d-bf6c-58fbc59e5727/pools/70294e14-4e61-11e8-bcf4-0242ac110004",
"name": "example-pool"
}
],
"private_ips": [
{
"address": "192.168.10.5"
},
{
"address": "192.168.10.6"
}
],
"provisioning_status": "active",
"public_ips": [
{
"address": "169.11.111.115"
},
{
Getting secret 'mysecret-ssh'...
OK

Name: mysecret-ssh'
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: ssh
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 66s
Created: 2023-03-07 19:19:59 +0000 UTC

Data:
---
known_hosts: fDF8bGh0ekpiSFVXdXRxZWg1NUlrWTk4RjdOdjJZPXxsUmhZd0txVmIwd3dSV2xzcjEySFdoWURUTG89IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQXEyQTdoUkdtZG5tOXRVRGJPOUlEU3dCSzZUYlFhK1BYWVBDUHk2cmJUclR0dzdQSGtjY0tycHAweVZocDVIZEVJY0tyNnBMbFZEQmZPTFg5UVVzeUNPVjB3emZqSUpObEdFWXNkbExKaXpIaGJuMm1VanZTQUhRcVpFVFlQODFlRnpMUU5uUEh0NEVWVlVoN1ZmREVTVTg0S2V6bUQ1UWxXcFhMbXZVMzEveU1mK1NlOHhoSFR2S1NDWklGSW1Xd29HNm1iVW9XZjluenBJb2FTakIrd2VxcVVVbXBhYWFzWFZhbDcySitVWDJCKzJSUFczUmNUMGVPelFncWxKTDNSS3JUSnZkc2pFM0pFQXZHcTNsR0hTWlh5MjhHM3NrdWEyU21WaS93NHlDRTZnYk9EcW5UV2xnNyt3QzYwNHlkR1hBOFZKaVM1YXA0M0pYaVVGRkFhUT09CnwxfEpUSjI4MCt0RkFSMGcxZ3VrZW56U3ZBYm5sQT18RDlSUWppenZlR3UxS0FnNjhNeisrUHM3RmZrPSBlY2RzYS1zaGEyLW5pc3RwMjU2IEFBQUFFMlZqWkhOaExYTm9ZVEl0Ym1semRIQXlOVFlBQUFBSWJtbHpkSEF5TlRZQUFBQkJCRW1LU0VOalFFZXpPbXhrWk15N29wS2d3RkI5bmt0NVlScllNak51RzVOODd1UmdnNkNMcmJvNXdBZFQveTZ2MG1LVjBVMncwV1oyWUIvKytUcG9ja2c9CnwxfDhIOXpNb0VORklZVDNPeVZYWlQrY25wb0srND18dVdhVThFV1FPc0ttSDMzREVVd0xnNUtiUk44PSBzc2gtZWQyNTUxOSBBQUFBQzNOemFDMWxaREkxTlRFNUFBQUFJT01xcW5rVnpybTBTZEc2VU9vcUtMc2FiZ0g1Qzlva1dpMGRoMmw5R0tKbAo=
ssh-privatekey: REDACTED

Notice that the value of the known_hosts key for this SSH secret is encoded, and the value of ssh-privatekey is redacted. To display the secret data as decoded, use the --decode option with the secret get command.





 Creating a TLS secret with the CLI 

A Transport Layer Security (TLS) secret contains a signed TLS certificate, including all its intermediate certificates, and its corresponding private key from a certificate authority (CA). Use TLS secrets when you work with custom domain mappings.

The following example creates a TLS secret that is named mysecret-tls. The certificate chain that corresponds to the custom domain is contained in the file certificate.txt and the matching private key file is contained in the file privatekey.txt. In this example, both of these files are located in the root directory of the local workstation.

ibmcloud ce secret create --name mysecret-tls --format tls --cert-chain-file certificate.txt --private-key-file privatekey.txt

To display the details of this secret,

ibmcloud ce secret get --name mysecret-tls

Example output

Getting secret 'mysecret-tls'...
OK

Name: mysecret-tls'
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Format: tls
Project Name: myproject
After the secret reaches the end of its lease, the credentials are revoked automatically. For more information about the command options, see [ibmcloud secrets-manager secret-create](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-cli-plugin-secrets-manager-clisecrets-manager-cli-secret-create-command).

If reuse_api_key is false for IAM credentials, manual rotation for the secret isn't supported. For more information, see [Manually rotating secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manual-rotation).





 Using an existing service ID in your account 

You might already have a service ID in your account that you want to use to dynamically generate an API key. In this scenario, you can choose to create an IAM credentials secret by bringing your own service ID. For example, the following command creates an IAM credential by using the service_id field.

You can find the ID value of a service ID in the IAM section of the console. Go to Manage > Access (IAM) > Service IDs > name. Click Details to view the ID.

ibmcloud secrets-manager secret-create 
--secret-prototype='{"name": "example-iam-credentials-secret","description": "Description of my IAM credentials secret","secret_type": "iam_credentials","secret_group_id": "<secret_group_id>","labels": ["dev","us-south"],"ttl": "30m","service_id":"<service_id>","reuse_api_key": false, "custom_metadata": {"metadata_custom_key": "metadata_custom_value"},"version_custom_metadata": { "custom_version_key": "custom_version_value"}}'

The command outputs the ID value of the secret, along with other metadata.
-d '{
"size": 20,
"name": "myshare-3",
"profile": {
"name": "dp2"
},
"zone": {
"name": "us-south-1"
},
"mount_targets": [
"virtual_network_interface": {
"subnet": {
"id": "4e95744c-7e64-48c9-b5d2-3b6481b1dfde"
},
"security_groups":
{
"id": "34c09abb-37bf-4ef6-88bb-f63a0ef28915"
}
]
},
"transit_encryption": {
"user_managed"
}
]
}'

The following response shows that access control mode is security_group, which is the default value.

{
"access_control_mode": "security_group",
"created_at": "2023-06-11T12:55:40Z",
"crn": "crn:[...]",
"encryption": "provider_managed",
"href": "$vpc_api_endpoint/v1/shares/r134-56f91d4a-2801-470a-b368-176bde64e954",
"id": "r134-56f91d4a-2801-470a-b368-176bde64e954",
"initial_owner": {
"gid": 0,
"uid": 0
},
"iops": 100,
"lifecycle_state": "pending",
"name": "myshare-3",
"profile": {
"severity": "normal",
"requestData": {
"generation": "2"
},
"responseData": {
"responseURI": "/v1/snapshots/09ca2bab-c5c4-4c06-b034-dda9bbeb859c"
},
"dataEvent": false,
"logSourceCRN": "crn:v1::public:is::a/cf27ad23-60e6-47d8-a4c1-b63ac14488f1::snapshot:09ca2bab-c5c4-4c06-b034-dda9bbeb859c",
"saveServiceCopy": true
}

The following example shows an event that was generated when you list snapshot details by ID:

{
"eventTime": "2022-01-16T17:55:25.60+0000",
"action": "is.snapshot.read",
"outcome": "success",
"message": "Block Storage Snapshots for VPC: read my-snapshot-2",
"initiator": {
"id": "IBMid-50A7R6DVH5",
"typeURI": "service/security/account/user",
"name": "myuser@mycompany.com",
"host": {
"address": "192.0.2.0"
},
"credential": {
"type": "token"
}
},
"target": {
"id": "crn:v1::public:is::a/ef0574dd126031eba03e554728ab939::snapshot:4e3252d7-cf32-4586-93e9-f7d9a497bed4",