vania-janet/multiturn-rag-retrieval-data huggingface dataset:
User roles in Knowledge Studio 

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 



* IBM Cloud® roles are different from Knowledge Studio roles.



* IBM Cloud® roles control permissions for managing IBM Cloud services. New service instances of Knowledge Studio are managed with [IBM Cloud Identity and Access Management (IAM)](https://cloud.ibm.com/docs/iam) in all public regions.
* 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?topic=watson-knowledge-studio-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?topic=watson-knowledge-studio-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.
Defining the product details of a virtual server image for Power Systems 

This tutorial walks you through the steps for defining the details of a virtual server image for Power Systems Virtual Server 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 demonstrates how to onboard and publish a [sample virtual server image for Power Systems Virtual Server](https://github.com/IBM-Cloud/isv-power-vsi-product-deploy-sample). 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-vsipower-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.

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. For the purposes of this tutorial, add a new product.



1. From the IBM Cloud Partner Center, click Create.
2.
Do not remove the administrator signature keys from your smart cards. Otherwise, you are not able to perform TKE actions that need to be signed, such as zeroizing crypto units and rotating master keys.

If you want to remove the administrator in a later phase, click Remove Administrator.





 Step 4: Set the signature thresholds to exit imprint mode in the selected crypto units 

When crypto units in service instances are assigned to a user, they begin in a cleared state that is called imprint mode. In imprint mode, most operations on the crypto unit are disabled. To load the master key in a crypto unit, first exit imprint mode by setting the signature thresholds to a value greater than zero.



1. To set the signature thresholds, select the Signature thresholds tab and click Change signature thresholds.
2. When prompted, enter the new signature threshold value and the new revocation signature threshold value. The values must be numbers between one and eight and do not need to be the same. The 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 after you leave imprint mode. Some commands need only one signature, regardless of how the signature threshold is set.
3. If prompted, insert an EP11 smart card with an administrator signature key that is defined to the selected crypto units in smart card reader 1. And then, enter the smart card PIN on the smart card reader PIN pad. Repeat this operation if prompted for more EP11 smart cards with signature keys. When the crypto unit exits imprint mode, the number of signatures that are needed for this command is the new signature threshold value.



After the signature threshold values are set, the new values are displayed on the Signature thresholds page. Setting the signature thresholds to a value greater than one enables [quorum authentication](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-conceptsquorum-authenticaion-concept) from multiple administrators for sensitive operations.

When an EP11 smart card with a valid administrator signature key is inserted in smart card reader 1 and the PIN is entered, the smart card can be used to sign multiple commands.
Defining the product details of your Operator bundle 

This tutorial walks you through the steps for defining the details of an Operator bundle 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 Operator bundle from the Red Hat OpenShift on IBM Cloud Certified registry. 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 Operator bundle](https://cloud.ibm.com/docs/sell?topic=sell-bundle-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. For the purposes of this tutorial, add a new product.



1. From the IBM Cloud Partner Center, click Create.
2.
Other than the IP addresses used for internet access on each customer ESG, you can use any IP address that you want. Typically, you use an IPsec tunnel from the on-premises environment to your virtual data centers, which provides transparent networking with full BYIP capabilities.





 Can I bring a custom image? 

Yes. VMware Cloud Director supports the same set of guest operating systems as VMware vSphere® 6.7. 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.





 Related links 



* [VMware Shared overview](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-shared_overview)
* [User accounts and settings](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-useraccount)
* [Accessing the console](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-loginmethod)
* [Notifications](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-notifications)
![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 submit the IBM Digital Provider Agreement if you plan to offer free plans, 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 services](https://cloud.ibm.com/docs/sell?topic=sell-get-started).





 Defining your service 



Table 2. Tasks for defining service details

 Task Description Environment 

 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Confirm your display and programmatic names Review the programmatic name that was generated for you and make any needed updates. IBM Cloud console 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Verify your partner details Review the Company and Team information and make sure that everything is correct. IBM Cloud console 
 !
Defining the product details of an Operator 

This tutorial walks you through the steps for defining the details of a Node-RED Operator in IBM Cloud® Partner Center. You can onboard an Operator bundle from a TGZ file or an Operator from a CSV file. 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 Node-RED Operator](https://github.com/IBM-Cloud/operator-bundle-sample/releases). 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 Operator](https://cloud.ibm.com/docs/sell?topic=sell-operator-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 have the option to add a new product or import an existing product from a private catalog.
This is particularly important if integrations, data migration or custom reports are part of the implementation.



* Direct Database Access



This is usually required for report developers and those who need to run SQL statements against the database. Which users will need access? What kind of access is needed? Note: read/write access is allowed on non-production environments; read-only allowed on production environments if a database replica is ordered and configured.



* COS (Cloud Object Storage) access



This is typically used for files transfers to/from MAS, file based integrations and Application Server log file access. Who will need it?

IBM recommends first determining who from the implementation team will need each of the above. Create and submit a single case for each access type. Within the case list each user who require that specific type of access.





 3.7 Support Request (Case) Lead Times 

IBM SRE has specific lead times established based on the type of request being submitted. Lead times can vary based on number of cases in the queue and the complexity or level of effort of the specific request. It is important to consider standard lead times when planning your project and delivery commitments. For details please see Request Lead Times





 3.8 Report Customization 

If custom reporting is part of the implementation, please see access section above.





 3.9 SAML and/or LDAP Authentication 

MAS supports Single Sign On (SSO). This can only be configured after environments have been initially provisioned. Further detail on how to initiate this configuration process with the IBM SRE support team can be found under Single Sign On (SSO) and SAML Authentication





 3.10 Roles & Responsibilities 

Roles & Responsibilities for IBM SRE, Customers, Implementors and other parties are described in the Environment Management & Responsibilities section. This includes a RACI that details each level of responsibility (Responsible Accountable, Consulted, Informed) for specific tasks. It is important to review the applicable RACI and make sure all project team members agree to and understand their individual roles.







 Go Live & Steady State Support 

It is important to determine and clearly communicate any critical phases or go live support periods in your project schedule to the IBM SRE team as early as possible.
A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run.



 Determining the type of workloads that you want 

Most Cloud Foundry applications can migrate to Code Engine. However, if your Cloud Foundry application does not wait for an incoming HTTP request, then jobs are probably the better choice. For more discussion and examples, see [Planning for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-codeengine).







 I use manifest files. Are there similar options available with Code Engine? 

If you use manifest files for your Cloud Foundry applications, map your manifest attributes to the corresponding Code Engine features or CLI option.



Table 1. Markdown coding for tables

 Manifest attribute Code Engine equivalent on the ibmcloud ce app create or app update commands 

 command --command option 
 disk_quota Implicitly set by Code Engine. 
 docker Not needed in Code Engine. 
 health-check-http-endpoint Not needed in Code Engine. By default a TCP probe is used to know when the application is healthy and ready. 
 health-check-invocation-timeout Not needed in Code Engine. 
 instances --min-scale and --max-scale options 
 memory --memory option 
 metadata Not currently supported. 
 no-route With the --cluster-local option, the application is still accessible from other workloads within the project, but does not include an internet-facing accessible URL that associated with the application. 
 path Not currently applicable. 
 processes Not needed in Code Engine. The application can create additional processes at run time. 
 random-route Not needed in Code Engine. Each project has a unique subdomain and since the application name is part of the URL, the URL is guaranteed to be unique.
* _security settings aren't backed up by the tools.
* Attachments aren't backed up by the tools.
* Backups aren't precise "point-in-time" snapshots. The reason is that the documents in the database are retrieved in batches, but other applications might be updating documents at the same time. Therefore, data in the database can change between the times when the first and last batches are read.
* Index definitions that are held in design documents are backed up, but the content of indexes isn't backed up. This limitation means that when data is restored, the indexes must be rebuilt. The rebuilding might take a considerable amount of time, depending on how much data is restored.







 Using the tools 

The [NPM page](https://www.npmjs.com/package/@cloudant/couchbackup) details the basics of using the command-line tools for backup and restore of data. The following examples show how to put those details into practice by describing the use of the tools for specific tasks.

The CouchBackup package provides two ways of using its core functions.



* The command-line tools can be embedded into standard UNIX™ command pipelines. For many scenarios, a combination of cron and simple shell scripting of the couchbackup application is sufficient.
* A library usable from Node.js. The library allows more complicated backup processes to be created and deployed, such as determining dynamically which databases must be backed up.



Use either the command-line backup tool, or the library with application code, to enable backup from IBM Cloudant databases as part of more complicated situations. A useful scenario is scheduling backups by using cron, and automatically uploading data to [Cloud Object Storage](https://www.ibm.com/cloud/object-storage/solutions?mhq=object%20storage%20public&mhsrc=ibmsearch_a) for long-term retention.





 Command line scripting examples 

You frequently need to meet the following two requirements:
* The client is responsible for providing in–depth documentation at the time of a failure and responding timely to IBM Support when further clarification is needed.
* Clients are also responsible for following the guidelines in this document to grant consent to proactive support.
* By declining consent or failing to abide by the guidelines provided, the client assumes the responsibility of possible lag in problem resolution that is caused by communication delays between the client and support team.
* The client must be prepared to perform more technical troubleshooting that would otherwise be done by IBM Support. IBM provides appropriate documentation and assistance where necessary.







 Security measures 



* Management of Cloud Service - Client is responsible for managing administration, operation, maintenance, and security of the applications, including underlying middleware.
* Service Integrity and Availability - IBM forwards to the Client all network intrusion notifications detected for this Cloud Service. It is the Client’s responsibility to ascertain the impact of each notification that is reported. Client is notified of hardware failures. Monitoring and responding to OS or software failures is the responsibility of the Client, engaging IBM support as required.
* Activity Logging - Client is responsible for activity logging of OS/System and Database/Applications, as needed.
* Encryption - Client is responsible for configuring and managing all encryption (for both data at rest and in transit), as needed.
* Business Continuity and Disaster Recovery - Client is responsible for configuring and managing all business continuity and disaster recovery processes, as needed.







 Third-party services 



* Third-Party software or code is included or bundled with some of our IBM offerings. This code is included for your convenience but is not considered part of the IBM program.
* These non–IBM programs are licensed directly by their providers. Client agrees to use the non–IBM programs under the provider’s terms and conditions. These terms are provided in the IBM licensing agreement that accompanies the IBM offering at time of purchase.
* IBM does testing to ensure that the third-party products work with IBM programs and that they function correctly.
* IBM Support diagnoses client problems by using the knowledge of how our IBM offerings work with the Third-Party software.