vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The programmatic name is automatically generated from your company name and the display name of your product.

Display name
: A name for your service. This name is publicly displayed in the IBM Cloud catalog. For example, Compose Redis

Service ID
: A service ID is used to identify your service when it communicates with other IBM Cloud services. You're also required to create an API key for your service ID.

Company or product logo
: An SVG file with your product logo.

Short description
: The short description of what your product is, its value, and any other details that you want to be displayed in your IBM Cloud catalog entry. You can add a single sentence or phrase as the description.

Detailed description
: This description is displayed at the beginning of your product page in the catalog. Include relevant keywords and consider at least two sentences for a detailed description.

Documentation URL
: A link to your IBM Cloud documentation.

End User License Agreement (EULA) URL
: A link to the end user license agreement that users must agree with to use your product. Do not include billing, payment, or tax terms in this agreement.

Category
: Selection of available IBM Cloud categories that best describe your product. Only one category can be selected.

Keywords
: Words, phrases, and other key search terms associated with your product.

Features
: Short descriptive unique identifiers about your product's attributes.

Media
: Screen captures and videos that show off your product.

Plan name
: A name for your pricing plan that doesn't include your company or product name. This information is displayed to customers in the IBM Cloud catalog. For example, Gold

Plan description
: The description of the pricing plan. This information is displayed to customers in the IBM Cloud catalog.

Programmatic name of the plan
: The technical name of the pricing plan that is automatically generated. You can't make edits to this name.





 Open Service Broker 

Service brokers manage the lifecycle of services. The IBM Cloud platform interacts with service brokers to create and manage service instances and service bindings.
FAQs for rules and naming conventions 

Have a question about CDN rules and naming conventions? Review these frequently asked questions, which provide answers to common inquiries.



 What are the rules for the CDN hostname? 

The CDN Hostname input string must:



* Consist of alphanumeric characters
* Be fewer than 254 characters
* End with a valid top-level domain name
* Must not contain more than 10 labels
* Must not end in cdn.appdomain.cloud. or cdnedge.bluemix.net. (that ending is used for CNAMES and is reserved)



Refer to RFC 1035, section 2.3.4 for more details.

Furthermore, we highly recommend the use of a fully qualified domain name as your CDN hostname. Choose a name of the form www.example.com rather than a root domain name (also referred as Zone Apex or Naked domain), of the form example.com. You must create a CNAME Record for the CDN hostname you use, and the DNS RFC 1033 requires the root domain record to be an A Record, not a CNAME. Further clarification is provided in RFC 2181, section 10.1





 What are the custom CNAME naming conventions? 

The CNAME input string must adhere to the following rules:



* Must be unique (it cannot be in use by any other IBM Cloud CDN)
* Less than 64 alphanumeric characters
* Special characters ! @ $ % ^ & are not allowed
* Underscores _ are not allowed
* Periods . are not allowed
* Dashes - are allowed, but the CNAME cannot begin or end with a dash







 What are the rules for Bucket names? 

Bucket names:



* Must be at least one character
* Must be fewer than 200 characters
* Can contain letters (both uppercase and lowercase letters are allowed), numbers, and hyphens
* Must not be formatted as an IP address (for example, 127.0.0.1)
* Cannot start with a period (.)
* Can end with a period (.)
Defining the product details of a Terraform template 

This tutorial walks you through the steps to define the details of a Terraform template in IBM Cloud® Partner Center. You can onboard a Terraform template by using a .tgz file. By completing this tutorial, you review and sign the IBM® Digital Provider Agreement, and define your catalog entry, pricing model, and customer support experience.

This tutorial is one of four in a series that demonstrates how to onboard and publish a [Terraform template](https://github.com/IBM-Cloud/terraform-sample/releases/tag/v1.0.0). It uses a fictitious company that's called Example Corp. As you complete the tutorial, adapt each step to fit your products needs.



 Before you begin 

[Register your Terraform template](https://cloud.ibm.com/docs/sell?topic=sell-terraform-template-register).





 Step 1: Confirm the digital provider agreement 

Third-party providers are required to sign the IBM Digital Provider Agreement, which sets the terms and conditions under which providers can onboard and sell products in IBM Cloud. Or, third-party providers can upload a custom digital provider agreement in .pdf, .doc, or .docx file format.

Custom digital provider agreements must be reviewed and approved by IBM, which increases the time it takes for you to complete the onboarding process. The uploaded files are scanned for viruses, which might take a few minutes to complete. If a virus is detected, it is recommended to run another virus scan on your file, and then try uploading it again.

For the purposes of this tutorial, complete the following steps to sign the IBM Digital Provider Agreement.



1. From the My products page in the IBM Cloud Partner Center, click Provide details in the notification that explains that company details are required.
2. In the Digital provider agreement section, click Standard.
3. Click the IBM Digital Provider Agreement link to review the agreement.
4. Select I understand and agree to the IBM Digital Provider Agreement, and click Save.







 Step 2: Provide your product name and type 

When you add a product, you can add a new product or import an existing product from a private catalog.
Defining the product details of a virtual server image 

This tutorial walks you through the steps for defining the details of a virtual server image with Terraform in IBM Cloud® Partner Center. By completing this tutorial, you review and sign the IBM® Digital Provider Agreement, and define your catalog entry and product page, pricing model, and support experience.

This tutorial is one of four in a series that demonstrates how to onboard and publish a [sample virtual server image with Terraform](https://github.com/IBM-Cloud/isv-vsi-product-deploy-sample/tree/v1.0). It uses a fictitious company that's called Example Corp. As you complete the tutorial, adapt each step to fit your product's needs.



 Before you begin 

[Register your virtual server image](https://cloud.ibm.com/docs/sell?topic=sell-vsimage-register).





 Step 1: Confirm the digital provider agreement 

Third-party providers are required to sign the IBM Digital Provider Agreement, which sets the terms and conditions under which providers can onboard and sell products in IBM Cloud. Or, third-party providers can upload a custom digital provider agreement in .pdf, .doc, or .docx file format.

Custom digital provider agreements must be reviewed and approved by IBM, which increases the time it takes for you to complete the onboarding process. The uploaded files are scanned for viruses, which might take a few minutes to complete. If a virus is detected, it is recommended to run another virus scan on your file, and then try uploading it again.

For the purposes of this tutorial, complete the following steps to sign the IBM Digital Provider Agreement.



1. From the My products page in the IBM Cloud Partner Center, click Provide details in the notification that explains that company details are required.
2. In the Digital provider agreement section, click Standard.
3. Click the IBM Digital Provider Agreement link to review the agreement.
4. Select I understand and agree to the IBM Digital Provider Agreement, and click Save.







 Step 2: Provide your product name and type 

When you add a product, you can add a new product or import an existing product from a private catalog.
The remaining two are actions that were considered because of their confidence score, but weren't used because thee confidence scores were lower.

If no action scores higher than 20% confidence, you see the built-in action No action matches.





 Step locator 

Sometimes you might find an error in the middle of a test conversation, and need to find which step and action is involved. A locator icon next to each assistant response lets you find the associated steps in the editor.

Click the icon, and the editor shows the corresponding step in the background.

Zoom

![Step locator](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/review-step-locator.png)

Step locator





 Follow along 

Follow along connects what you are seeing in Preview with what you built in the action. As you interact with your assistant, the debug mode automatically opens each step in the background. That means you can fix an error as soon as you see it, because the editor is already open to the corresponding step.







 Variable values in Preview 

As you test your conversation in Preview, you can check that each variable is set correctly. Click Variable values to see the values stored in each variable during the conversation. The Variable values pane has two tabs, one for action variables and one for session variables. If you are using dialog, you can see session variables for both actions and dialog on the Session variables tab.

Zoom

![Variable values](https://cloud.ibm.com/docs-content/v1/content/ca9232b3702768f24bb897f48f10778fcda28718/watson-assistant/images/variable-values-preview.png)

Variable values

To learn more about variables, see [Managing information during the conversation](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-manage-info).





 Extension inspector in Preview
User roles in Knowledge Studio for IBM Cloud Pak for Data 

IBM Watson™ Knowledge Studio roles are used to organize a team of people who create machine learning or rule-based models.



 Notes about roles in Knowledge Studio 



* Knowledge Studio roles control access to Knowledge Studio functionality and are managed in the Knowledge Studio application.
* The first user to launch the Knowledge Studio application is assigned the Admin role.
* Once assigned, user roles can't be downgraded from higher to lower levels of permissions. Admins can't be downgraded to project managers or human annotators, and project managers can't be downgraded to human annotators. For information about adding users, upgrading roles, and deactivating user accounts, see [Assembling a team](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-team).
* To manage a workspace, project managers need to be assigned to the workspace by an admin.
* Admins and project managers can perform the role of human annotators. They can also [directly annotate document sets](https://cloud.ibm.com/docs/watson-knowledge-studio-data?topic=watson-knowledge-studio-data-annotating-document-sets-directly) without creating annotation tasks.







 Knowledge Studio role descriptions 

Knowledge Studio roles are described in the following table. Roles are listed in order of highest to lowest level of permissions.



Table 1. Role descriptions

 Role Description 

 Admin Responsible for administrative tasks, which include managing users, resource consumption, and monthly charges. In large team settings, admins rarely participate in the model development process. 
 Project manager Responsible for the overall organization of the workspace that she or he is assigned to. Tasks include creating the type system, managing assets, managing annotation work, evaluating the machine learning model, and deploying models. Users in this role need industry subject-matter expertise because they create the type system, teach the human annotators how to correctly apply the type system, and evaluate the model quality.
The main signature threshold controls how many signatures are needed to run most administrative commands. The revocation signature threshold controls how many signatures are needed to remove an administrator. Some commands need only one signature, regardless of how the signature threshold is set.

Setting the signature thresholds to a value greater than one enables quorum authentication from multiple administrators for sensitive operations. The maximum value that you can set the signature threshold and revocation signature threshold is eight, which is also the maximum number of administrators that can be added to a crypto unit.

When you configure crypto units, you are automatically prompted for the required number of signatures based on the operation type and whether the crypto units are in imprint mode. For reference, the following table includes the required number of signatures of each operation.



Table 1. Required number of signatures for TKE operations

 Operation Commands Required signatures in imprint mode Required signatures after leaving imprint mode 

 Add administrator tke cryptounit-admin-add No signature needed. The current signature threshold value. 
 Remove administrator tke cryptounit-admin-rm No signature needed. The current revocation threshold value. 
 Set signature threshold tke cryptounit-thrhld-set When leaving imprint mode, the new signature threshold value. The current signature threshold value. 
 Clear new master key register tke cryptounit-mk-clrnew Not allowed. One signature. 
 Clear current master key register tke cryptounit-mk-clrcur Not allowed. One signature. 
 Load new master key register tke cryptounit-mk-load Not allowed. One signature per key part. This command generates an importer key, which also requires one signature. The same administrator can be used for all signatures. 
 Commit new master key register tke cryptounit-mk-commit Not allowed. The current signature threshold value. 
 Set immediate (finalize master key register) tke cryptounit-mk-setimm Not allowed. One signature. 
 Set control point tke cryptounit-cp-btctke cryptounit-cp-eddsatke cryptounit-cp-sig-other Not allowed. The current signature threshold value.
![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Invite team members to your account Members of your account are assigned the IAM access that you set up in the previous task. IBM Cloud console 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Confirm your legal agreement with IBM Review and accept the IBM Digital Provider Agreement, or upload your custom digital provider agreement to be reviewed and approved by IBM. IBM Cloud console 



For more information, see [Getting set up to sell software](https://cloud.ibm.com/docs/sell?topic=sell-sw-getting-started).





 Tell us about your product 

The following tasks are typically completed by a team member familiar with the business case, marketing details, and customer support experience for the product.



Table 2. Tasks for defining software details

 Task Description Environment 

 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Review display name Review the display name of the product that was generated for you and make any updates to it if needed. IBM Cloud console 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Create and submit programmatic name Create a programmatic name for your product and submit it for review. IBM Cloud console 
 !
The following flow chart shows how the signature keys are created and assigned to a service instance with two crypto units.

Zoom

![Creating and assigning signature keys](https://cloud.ibm.com/docs-content/v1/content/217f108cc44e2ce15fb692d4b57b4c628464e908/hs-crypto//images/sigkey-flow.svg)

Figure 2. Creating and assigning signature keys

Signature keys are created and assigned by following this procedure:



1. The administrator creates the signature key pairs. The private and public key parts are stored on your local workstation or smart card depending on how you initialize your service instance.
2. The administrator is added by assigning the public signature key part to the crypto unit. The public key part is placed in a certificate that is installed in a target crypto unit to define a crypto unit administrator.







 Understanding imprint mode and signature thresholds 

The crypto units start in a clear state that is known as Imprint Mode. A crypto unit in imprint mode is less secure because actions towards a crypto unit in imprint mode don't need to be signed with any administrator signature keys. After you assign crypto unit administrators, you can set signature thresholds to control how many administrator signatures are needed to run a command. In imprint mode, the signature thresholds are set to zero. To exit imprint mode and secure the crypto unit, set the signature thresholds to a value greater than zero.

There are two types of signature thresholds on a crypto unit. The main signature threshold controls how many signatures are needed to run most administrative commands. The revocation signature threshold controls how many signatures are needed to remove an administrator. Some commands need only one signature, regardless of how the signature threshold is set.

Setting the signature thresholds to a value greater than one enables quorum authentication from multiple administrators for sensitive operations. The maximum value that you can set the signature threshold and revocation signature threshold is eight, which is also the maximum number of administrators that can be added to a crypto unit.
Some sensitive operations require a sufficient number of crypto unit administrators to enter their credentials. Quorum authentication assures that no single person can make a critical change on the crypto unit. Instead, a minimum number of crypto unit administrators (at least two) must cooperate to do these operations. Quorum authentication requires more than one crypto unit administrator to approve an operation, which enables an extra layer of protection on the crypto unit.





 Signature thresholds 

The signature thresholds of a crypto unit control how many administrative signatures are needed to run a command. In imprint mode, the signature thresholds are set to zero. To exit imprint mode, set the signature thresholds to a value greater than zero. When a crypto unit is zeroized, the signature thresholds are reset to zero.

There are two types of signature thresholds on a crypto unit. The main signature threshold controls how many signatures are needed to run most administrative commands. The revocation signature threshold controls how many signatures are needed to remove an administrator. Some commands need only one signature, regardless of how the signature threshold is set.

Setting the signature thresholds to a value greater than one enables quorum authentication from multiple administrators for sensitive operations. The maximum value that you can set the signature threshold and revocation signature threshold is eight, which is also the maximum number of administrators that can be added to a crypto unit.





 Master key 

The master key, also known as HSM master key, is used to encrypt the service instance for key storage. It is a symmetric 256-bit AES key. With the master key, you take the ownership of the cloud HSM and own the root of trust that encrypts the entire hierarchy of encryption keys, including root keys and standard keys in the key management keystore and Enterprise PKCS #11 (EP11) keys in the EP11 keystore. You need to configure the master key first before you can manage encryption keys. One service instance can have only one master key. If you delete the master key of the service instance, you can effectively crypto-shred all data that was encrypted with the keys that are managed in the service.





 Master key part
For more information, see [VMware Guest OS Compatibility Guide](https://www.vmware.com/resources/compatibility/pdf/VMware_GOS_Compatibility_Guide.pdf).

VMware Shared provides Microsoft® Windows® server 2016/2019 templates. You can provide your own image to run other versions.
* What are the Service Level Agreement options with VMware Shared?

VMware Shared uses the IBM Cloud standard Service Level Agreement (SLA). SLAs are not offered for virtual machines and vApps. For more information, see [IBM Cloud (Public Cloud) Service Description (10-2020)](https://www-03.ibm.com/software/sla/sladb.nsf/sla/bm-6605-20).
* Do I get vCenter access?

No.
* Automatic installation of updates from Windows Update

The Microsoft® Active Directory™ (AD) Domain Services server is automatically set up to download the updates only. It does not install these updates or restart automatically. You must install the updates manually and restart at a scheduled time that avoids any interruptions of the ongoing AD server configuration and other backup jobs. To apply Windows® updates, install the updates manually.
* Networking components for vCenter Server instances

To review the networking components that are included in your vCenter Server instance, see [Technical specifications for vCenter Server instances](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverviewvc_vcenterserveroverview-specs).
* Firewall considerations

If you're using firewalls, you must configure rules for all communications from the IBM® CloudDriver virtual server instance (VSI) and the SDDC Manager virtual machines (VMs). These rules must allow all protocols to communicate on the IP addresses 10.0.0.0/8 and 161.26.0.0/16. Examples of such firewalls are NSX Distributed Firewalls (DFW) or vSRX gateway cluster firewalls.
Non-Orchestrated environment Linux based Virtual Machines (VM) on IBM Cloud, on-prem, other clouds Supported Supported 
 Non-Orchestrated environment Linux based Virtual Machines (VM) on VPC Supported Supported 
 Non-Orchestrated environment Linux based Virtual Machines (VM) on VMware Supported Supported 
 Windows environment Windows-based servers Supported by using the Windows exporter 







 Checking the number of time series that are collected per agent 

In IBM Cloud Monitoring, you can monitor your monitoring agent by using the dashboard template monitoring agent Health & Status that is available in Host Infrastructure. In this dashboard, you can see the number of monitoring agents that are deployed and connected to the instance, check the version of the monitoring agents, and find out how many metrics per host the agent is collecting. For more information, see [Checking the number of custom time series that are collected per agent](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_ts_limits).





 Finding out the agent version that runs on a host 

You can use the the Sysdig Agent Health & Status dashboard to determine the Monitoring agent versions that are running in your hosts. For more information, see [Determining the version of an agent](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent_versions).