vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Die Nummer ist <say-as interpret-as=‘digits’>AB7234987FFA</say-as>.



Table 3. Using the spell_out_mode parameter for German

 Specification of the spell_out_mode parameter Audio sample 

 spell_out_mode=default <br>The service reads the characters in succession, typically with no pause between them, at the rate at which it synthesizes speech for the request. You can also omit the parameter to get the default behavior. Your browser does not support the audio tag. 
 spell_out_mode=singles <br>The service reads the characters one at a time, with a brief pause between each character. Your browser does not support the audio tag. 
 spell_out_mode=pairs <br>The service reads the characters two at a time, with a brief pause between each pair. Your browser does not support the audio tag. 
 spell_out_mode=triplets <br>The service reads the characters three at a time, with a brief pause between each triplet. Your browser does not support the audio tag. 



Alphanumeric strings that mix letters and digits can yield different groupings of characters. If you do not use the <say-as> element, groups of letters and digits can be pronounced in ways that do not necessarily conform to the requested mode.





 Spell-out mode examples 

The following HTTP POST /v1/synthesize method uses the spell_out_mode query parameter with a value of singles. The example uses the German voice de-DE_ErikaV3Voice. The alphanumeric text to be synthesized is a hexadecimal string that is wrapped in a <say-as> element and interpreted as digits.

IBM Cloud

curl -X POST -u "apikey:{apikey}" --header "Content-Type: application/json" --header "Accept: audio/wav" --output spell-out-mode.wav --data "{"text":"Die Nummer ist <say-as interpret-as=‘digits’>AB7234987FFA</say-as>."
Assigning access by using wildcard policies 

When you're assigning access to certain IAM-enabled services, you can use advanced operators in a

policyto grant access to resources that satisfy specific naming conventions. By using wildcard policies, you can reduce the number of policies that are required for managing access to some resources.

To assign access, you need the administrator role on the resource. For more information, see [IAM access](https://cloud.ibm.com/docs/account?topic=account-userroles).



 JSON policy document 

Most access policies are stored in IBM Cloud® as JSON documents. When you use the stringEquals operator in a policy, an exact string match is performed between the query and the target string. When you use the stringMatch operator, a case-sensitive string match is performed between the pattern and the target string using either an asterisk (), question mark (?), or both. An asterisk () represents any sequence of zero or more characters in the string, and a question mark (?) represents any single character. See the following examples:



* dev matches any string that contains dev
* dev matches any string that begins with dev
* dev matches any string that ends with dev



Refer to the documentation for the specific service that you are assigning access to for details about the supported operators for specific attributes for that service.



 Using an asterisk () as a wildcard 

The following example shows how you might create a policy that gives a user access to manage all Event Streams topics that start with dev in a particular account.

{
"type": "access",
"subjects": [
{
"attributes":
{
"name": "iam_id",
"value": "IBMid-12345"
}
]
}
],
"roles": [
{
"role_id": "crn:v1:bluemix:public:iam::::serviceRole:Manager"
}
],
"resources": [
{
"attributes":
{
: The port that your service listens to. Use the same port that you defined when you created the Kubernetes service for your app.
2. Create the Ingress resource for your cluster. Ensure that the resource deploys into the same project as the app services that you specified in the resource.

oc apply -f myingressresource.yaml -n <project>
3. Verify that the Ingress resource was created successfully. If messages in the events describe an error in your resource configuration, fix the values in your resource file and reapply the file for the resource.

oc describe ingress myingressresource



Your Ingress resource is created in the same project as your app services, and your apps are registered with the Ingress controller.





 Step 5: Access your app from your private network 



1. Classic clusters: Before you can access your app, make sure that you can access a DNS service. To use the default external DNS provider, you must [configure edge nodes with public access](https://cloud.ibm.com/docs/openshift?topic=openshift-edgeedge) and [configure a Virtual Router Appliance](https://www.ibm.com/blogs/cloud-archive/kubernetes-and-bluemix-container-based-workloads-part4).
2. From within your private network, enter the URL of the app service in a web browser.

https://<domain>/<app1_path>

If you exposed multiple apps, access those apps by changing the path that is appended to the URL.

https://<domain>/<app2_path>

If you use a wildcard domain, access those apps with their own subdomains.

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>



Can't connect to your app through Ingress?
However, if you disable an endpoint that is being used by you or your applications, those connections are dropped.





 Credentials for Private Endpoints 

Use either public or private connection strings with any set of credentials that you make on your deployment. By default, the connection strings for a set of credentials are filled with strings for connecting over a public endpoint. If you are using private endpoints, specify connection strings that contain the private endpoint be generated instead.

When you create credentials in the Service Credentials UI, use either the { "service-endpoints": "public" } or the { "service-endpoints": "private" } parameter to specify which endpoint gets filled into the connection strings.

In the API, use the [/deployments/{id}/users/{userid}/connections/{endpoint_type}](https://cloud.ibm.com/apidocs/cloud-databases-apidiscover-connection-information-for-a-deployment-f-e81026) to retrieve connection strings for both public or private endpoints.

If you have only private endpoints on your deployments, then all new credentials have private endpoints in the connection strings.





 Connecting Through Private Endpoints 

Cloud Databases offers both private and public cloud service endpoints. To run your application or access the end point from a browser that is not on the private network, take these additional steps:



* Ensure your Cloud IaaS or SL account is [enabled for private endpoints](https://cloud.ibm.com/docs/account?topic=account-service-endpoints-overview).
* Create a virtual machine (VSI) that runs Linux.
* Configure a user account with SSH access.
* From your workstation, run ssh -D 2345 user@vsi-host to start an SSH session and open a SOCKS proxy on port 2345 that forwards all traffic through the VSI.
* Configure your browser or application to use a SOCKS5 proxy on localhost:2345.
* Run your application or open the preferred private-endpoint in your browser (for example, a management UI).







 Using Virtual Private Endpoints
* Must have a minimum of minimum of 8 cores and 32 GB RAM, plus any additional cores that you need for your vCPU overhead. For more information, see [CPU overhead](https://docs.openshift.com/container-platform/4.11/virt/install/preparing-cluster-for-virt.htmlCPU-overhead_preparing-cluster-for-virt) in the Red Hat OpenShift docs.
* Must include enough memory for your workload needs. For example: 360 MiB + (1.002 * requested memory) + 146 MiB + 8 MiB * (number of vCPUs) + 16 MiB * (number of graphics devices). For more information, see [Memory overhead](https://docs.openshift.com/container-platform/4.11/virt/install/preparing-cluster-for-virt.htmlmemory-overhead_preparing-cluster-for-virt) in the Red Hat OpenShift docs.
* Must not have an operating system installed. The Red Hat CoreOS operating system is installed later in this process.
* If you want to use OpenShift Data Foundation as your storage solution, add 2 storage disks to each of your Bare Metal Servers when you provision them.



If your servers do not meet these requirements, follow the steps to [create a Bare Metal Server](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ordering-baremetal-server). For a list of bare metal options, see [Available options for a bare metal server](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmoptions-for-bare-metal-servers).





 Step 1: Booting up your Bare Metal Server 

For this specific Bare Metal Server, you must use a browser that supports Java for classic. You can use the Safari browser on your local system or download a Java version that supports javaws.



1.
* If you want more control over access policies, you can choose to [use a custom service ID for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-custom-servid) that is configured in your service instance. In this case, assign access policies to the custom service ID. You'll need to configure your project to use the custom service ID.





 Using the default service binding access policies 

By default, Code Engine automatically creates a service ID for accessing all services in the resource group of the Code Engine project when your account that is used with your project has sufficient permissions. The service ID is created during the first service binding operation.

To use default service binding access policies when your Code Engine project is in the same resource group as the service instance that you want to bind to, [configure access for Code Engine to automatically create and manage the service ID for service bindings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-auto-servid-access).



 Configuring access for Code Engine to automatically create and manage the service ID for service bindings 

If your service instance is in the same resource group as your Code Engine project, and you want Code Engine to automatically create and manage the service ID for service binding for you, then the IBM Cloud account that is used with your Code Engine project must have Writer service access and Operator platform access, at minimum.

With these permissions set for your account, when you create a service binding, Code Engine checks and automatically sets up a service ID with Operator and Manager access for all services in the resource group of the Code Engine project. Code Engine uses this service ID to access IBM Cloud services with service bindings.
Some resources do not require an owner (they can be considered global). In this case, the scope segment is empty (a blank string).

The value of the scope segment must be formatted as {scopePrefix}/{id}. The scopePrefix represents the format that is used to identify the owner or containment. The id represents the identity of the owner or containment in a format that is specific to the scopePrefix.



Table 1. Scope usage

 Scope Type Scope Prefix Usage Example 

 Account a/{account id} The account that the resource was created in. a/292558 
 Organization o/{org guid} The IBM Cloud Organization to which the resource was assigned. o/4716e2d1-35b7-431f-891a-b552bf0b3c66 
 Space s/{space guid} The IBM Cloud Space to which the resource was assigned. s/48b3cdcd-e804-4398-9032-73065863ad7c 







 service-instance 

The service-instance segment identifies the service instance uniquely. The format of the service-instance segment varies by service. Each service must document the format of their service_instance segment as part of their service metadata. Some services do not have instances because the instance is global, and in this case the service-instance field is blank.

The service-instance must be alphanumeric, lowercase, no spaces, or special characters other than '-' and '/'.

For example, a DevOps tool that is used to track and plan work items can have a simple GUID instance ID ("1234-5678-9012-3456"). But, the policy component of an autoscale group service can use a hierarchical naming convention and have a service-id segment of:

c7a27f55-d35e-4153-b044-8ca9155fc467/my-test-asg1/my-scaleout-policy

You can also obtain a CRN from an IBM Cloud resource by using the following CLI command:

ibmcloud resource service-instance





 resource-type, resource
Using groups to control data access 

You can configure, control, and manage data that is available to users in your IBM Cloud® account by configuring groups in the logging instance.

A group is comprised of users with authorization to specific data.



 Before you begin 

Before configuring and using groups, you need to understand the following requirements and limitations.

Users require specific IBM Cloud® Identity and Access Management permissions to work with groups and group members.



Table 1. Roles required for groups

 Role Permissions 

 Account management role Required to invite users, access groups, and define policies 
 Administrator platform role Required to manage the service 
 Manager service role Required to manage groups 
 Platform role viewer, service role reader, or standard member Required to launch the logging instance 



User roles defining permissions and access to manage auditing events are defined in IBM Cloud® Identity and Access Management.

You can map Cloud Identity and Access Management access groups to service groups. Consider the following information:



* You must name your service groups with the same name as your access groups. Users that belong to an access group are granted access to manage data in the service group.
* You must define a policy per service group, where the group that you specify matches the access group name.
* You must define the scope of the data that each service group can manage when you define the service group through the web UI.







 Configuring default access settings 

Complete the following steps to define the default settings for viewing data:



1. Log in to your IBM Cloud account.

Click [Log in to IBM Cloud](https://cloud.ibm.com/login) to sign in to the IBM Cloud.

After you log in with your user ID and password, the IBM Cloud console opens.
2. Select your account.
3. Click the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis//images/icon_hamburger.svg) > Observability.
4.
Not all IBM Cloud services can be managed with IAM. If you use one of these services, you can continue to use Cloud Foundry user roles to control access to those services.

Cloud Foundry roles grant access to organizations and spaces within the account. To see the list of Cloud Foundry-based services in IBM Cloud, run ibmcloud service list.

Example actions that are permitted by Cloud Foundry roles are creating a new Cloud Foundry service instance or binding a Cloud Foundry service instance to a cluster. To learn more, see the available [org and space roles](https://cloud.ibm.com/docs/account?topic=account-mngcf) or the steps for [managing Cloud Foundry access](https://cloud.ibm.com/docs/account?topic=account-mngcf) in the IBM Cloud IAM documentation.







 Assign access roles to individual or groups of users in IBM Cloud IAM 

When you set IBM Cloud IAM policies, you can assign roles to an individual user or to a group of users.

Individual users
: You might have a specific user that needs more or less permissions than the rest of your team. You can customize permissions on an individual basis so that each person has the permissions that they need to complete their tasks. You can assign more than one IBM Cloud IAM role to each user.

Multiple users in an access group
: You can create a group of users and then assign permissions to that group. For example, you can group all team leaders and assign administrator access to the group. Then, you can group all developers and assign only write access to that group. You can assign more than one IBM Cloud IAM role to each access group. When you assign permissions to a group, any user that is added or removed from that group is affected. If you add a user to the group, then they also have the additional access. If they are removed, their access is revoked.

IBM Cloud IAM roles can't be assigned to a service account. Instead, you can directly [assign RBAC roles to service accounts](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac).
Then, it [turns the token into an IAM access token](https://cloud.ibm.com/apidocs/iam-identity-token-apigettoken-crtoken) for the specified trusted profile. Last, it calls the [IBM Cloud resource controller API](https://cloud.ibm.com/apidocs/resource-controller/resource-controller) to retrieve information about service instances. The result depends on the trusted profile's configured privileges. If interested, examine the [app source code](https://github.com/IBM-Cloud/trusted-profile-enterprise-security/blob/main/app.py).
4. Switch to the Activity Tracker logs browser tab and use the search box at the bottom to look for the term profile. It should return at least one line with IAM Identity Service: login.computeresource-token TPwithCR. Expand the record to examine details, look for the initiator section. It lists the trusted profile which was used for the request and information on the compute resource. The authName should match your deployment from the Kubernetes dashboard browser tab.

Zoom

![Activity Tracker showing details of the trusted profile request](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials//images/solution68-trusted-profile-for-enterprise-security/ActivityTracker_TrustedProfile_ComputeResource.png)

Details in the activity log
5. Now, visit the browser tab Kubernetes dashboard and check the container log. The app prints details on the [JWT access token](https://www.ibm.com/cloud/blog/json-web-tokens-as-building-blocks-for-cloud-security) it uses to authenticate for listing the resources. Examine the individual key/value pairs, including sub (subject) twice. They relate to the trusted profile and the compute resource.
6.
Configuring access for service bindings 

Service bindings in Code Engine use a service ID to access IBM Cloud services. A service ID contains the credentials to communicate with a service instance on behalf of your Code Engine project. Before you can bind a service instance to a Code Engine workload, you must configure access for bindings that is based on whether you want Code Engine to automatically create and manage the service ID for you or whether you want to use a service ID that you manage.

Interested in configuring your project such that all users of the project can create and delete service bindings? With sufficient permissions, you can use the Project integrations pages in the console to configure service binding operations from a single page. If you don't have sufficient permissions to perform these actions, you can use this page to help you understand the required permissions. See [Configuring project-wide settings](https://cloud.ibm.com/docs/codeengine?topic=codeengine-project-integrations).

Before you can bind your app, job, or function to a specific IBM Cloud service instance, determine whether you want to [create and manage your own service ID](https://cloud.ibm.com/docs/account?topic=account-serviceids), or if you want Code Engine to automatically create and manage the service ID for you. Based on your choice, assign the proper access policies. Code Engine uses one service ID per project to work with service bindings.



* If you want Code Engine to automatically create and manage the service ID for you, then configure [default service binding access policies](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configure-bindaccessbind-auto-servid). Ensure that proper access policies are assigned to the IBM Cloud account that is used with your Code Engine project.
In addition, the admin functions are not available because they are managed by IBM.



 Using Git Repos and Issue Tracking with toolchains 

You can use a template that contains either a Git Repos and Issue Tracking or GitHub tool integration as a starting point to create a toolchain that you can add Git repositories (repos) to. Alternatively, you can start with an empty toolchain and add either a Git Repos and Issue Tracking or GitHub tool integration to it. By using a toolchain, you can associate Git repos with your resource groups and your Continuous Delivery service instance.

For more information about using toolchains with Git, see [Creating toolchains with Git](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains_git).





 Using Git Repos and Issue Tracking locally 

You can locally access the Git repos that are stored in Git Repos and Issue Tracking. For instructions to set up Git locally, see [Start using Git on the command line](https://us-south.git.cloud.ibm.com/help/gitlab-basics/start-using-git).

Git Repos and Issue Tracking supports HTTPS connections only that use TLS1.2. If you use Eclipse to connect, you might be required to specify this protocol for your Java™ version by adding -Dhttps.protocols=TLSv1.2 to your eclipse.ini file and then restarting Eclipse.





 Authenticating with Git Repos and Issue Tracking 

Your IBM Cloud login and password are only used to authenticate with Git Repos and Issue Tracking in a web browser. You cannot use your IBM Cloud user credentials to authenticate from external Git clients. To complete remote Git operations, such as clone or push, from your local Git repo, you must use a personal access token or SSH key to authenticate with Git Repos and Issue Tracking.

The display name that appears for you throughout Git Repos and Issue Tracking is populated from your IBM Cloud login information.
Istio for service mesh Unlike for community Kubernetes clusters, the Istio managed add-on is not supported. Instead, use the [Red Hat service mesh operator](https://docs.openshift.com/container-platform/4.11/service_mesh/v1x/servicemesh-release-notes.html). Note: The default IBM Cloud configuration of the routers enables host networking, which is not compatible with the service mesh network policy. For the service mesh ingress to work, [apply a network policy](https://gist.githubusercontent.com/kitch/39c504a2ed9e381c2aadea436d5b52e4/raw/d8efa69f41d41425b16bb363a881a98d40d3708c/mesh-policy.yaml). 
 Deprecated: Kubernetes web terminal To use the IBM Cloud CLI to manage your cluster directly from your web browser, try the [IBM Cloud Shell](https://cloud.ibm.com/docs/cloud-shell?topic=cloud-shell-shell-ui). 
 IBM Log Analysis Add log management capabilities to your cluster by deploying a Log Analysis agent to your worker nodes to manage logs from your pod containers. For more information, see the following docs.<br><br><br><br> * [Setting up Log Analysis in a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-healthopenshift_logging).<br> * [Tutorial: Managing Kubernetes cluster logs with IBM Log Analysis](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-tutorial-use-logdna).<br><br><br>