vania-janet/multiturn-rag-retrieval-data huggingface dataset:
3. Click Access > Assign access.
4. Select a service, or group of services.
5. Click Next.
6. Scope the access to all resources, or select specific resources and select the resource groups attribute. Then, click Next.
7. Select the platform, service and resource group access for the resource group.
8. Click Review.
9. Click Add to add your policy configuration to your policy summary.
10. Click Assign.



You can't use access groups with infrastructure service resources or permissions.
* Can I move service instances between resource groups?

You can't move service instances between resource groups. If you assign a service instance incorrectly, you must delete and recreate the instance to assign it to another resource group.
* How do I delete a service from my account?

You can delete a service instance by using the following steps:



1. From your dashboard in the IBM Cloud console, click View resources within the Resources summary widget.
2. Expand the sections to locate the service instance that you want to delete.
3. Click the Actions icon ![Actions icon](https://cloud.ibm.com/icons/action-menu-icon.svg) > Delete for the row.



* Can I view usage per resource group?

Yes, you can. To access your usage dashboard, go to Manage > Billing and usage in the IBM Cloud console. Select Usage to view a summary of the usage by resource group for the account.
* Who can attach tags to a resource?

Any user assigned the correct access for the specific type of resource can attach tags. When a resource is tagged, it is visible to all users who have read access to the resource. However, to attach or detach a tag on a resource, certain access roles or permissions are required depending on the resource type and the tag type. For example, to attach user tags to any of the resources that are managed by using IAM, you must be assigned the Editor or Administrator role on the resource.

You can attach access management tags to IAM-enabled resources only.
You can assign specific access policies to the service ID that restrict permissions for using specific services, or even combine permissions for accessing different services. Since service IDs are not tied to a specific user, if a user happens to leave an organization and is deleted from the account, the service ID remains, ensuring that your application or service stays up and running. For more information, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceids).

Trusted profiles
: A trusted profile is a grouping of federated users, compute resources, IBM Cloud services, service IDs, or a combination of entities, to which the same IAM access can be granted. When applying a trusted profile, temporary security credentials are provided for the duration of a session. All identities that are allowed to apply a single profile inherit the same access. For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).

Service instances or resources
: Services in IBM Cloud are resource group-based. Service instances that can be added to a resource group and managed by using IBM Cloud Identity and Access Management (IAM) are called resources. For more information, see [Creating resources](https://cloud.ibm.com/docs/account?topic=account-manage_resource).

API keys
: An API key is a unique code that is passed in to an API to identify the calling application or user. You can use platform API keys, which are associated with user identities, and you can create other API keys for service IDs. For more information, see [Understanding API keys](https://cloud.ibm.com/docs/account?topic=account-manapikey).

Access groups
: You can create an access group to organize a set of users, service IDs, and trusted profiles into a single entity and easily assign permissions. You can assign a single policy to the group instead of assigning the same access multiple times per individual user or service ID.
Setting up windows servers for using the instance metadata service 

To access instance metadata from Windows servers, there are extra requirements to locate a default gateway and add a route.



 Overview 

To use the metadata service on Windows, you set up a default route to a link local address for the metadata. To do this, you need to locate the IP address of the default gateway and then add a route to the link local address. After this initial setup, you make calls to access the instance metadata.

The information in this topic is presented as separate steps. More likely, you would set up a cloudbaseinit automation process that does all the steps in a single process. Examples presented are to illustrate what you need, but you can use other methods to get the default gateway and add the route.





 Step 1 - Locate the IP of the default gateway 

Running as administrator, locate the IP of the default gateway. A convenient way is to use Powershell Get-NetRoute command.

Locate the IP of the default gateway by using the PowerShell Get-NetRoute cmdlet. This command gets the next hop for the default route, also known as the default gateway. For more information, see the Windows Powershell documentation for [Get-NetRoute](https://docs.microsoft.com/en-us/powershell/module/nettcpip/get-netroute?view=windowsserver2019-ps).

From the Windows terminal, the following example invokes the Powershell Get-NetRoute command to get the default IP routes and pass the routes to the SelectObject cmdlet, which then displays the NextHop property for each default route.

C:> powershell "Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Select-Object -ExpandProperty "NextHop""

The first IP address that is retrieved is the default route. Place the output into a variable.





 Step 2: Add a route to the default gateway
This documentation is for the classic Watson Assistant experience. To see the documentation for the new Watson Assistant, please go [here](https://cloud.ibm.com/docs/watson-assistant).



 API methods summary 

The following tables list the methods that are available using the Watson Assistant APIs.



 Runtime methods 



 Method Description API ver Reference 

 Create a session Create a new session. A session is used to send user input to a skill and receive responses. It also maintains the state of the conversation. v2 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v2createsession)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=nodecreatesession)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=javacreatesession)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=pythoncreatesession) 
 Delete session Deletes a session explicitly before it times out. v2 [cURL](https://cloud.ibm.com/apidocs/assistant/assistant-v2deletesession)[node](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=nodedeletesession)[java](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=javadeletesession)[python](https://cloud.ibm.com/apidocs/assistant/assistant-v2?code=pythondeletesession) 
 Send user input to assistant (stateful) Send user input to an assistant and receive a response, with conversation state (including context data) stored by Watson Assistant for the duration of the session.
For more information about the methods available for you to use, see [Expression language methods](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-methods).





 Deleting a context variable 

To delete a context variable, set the variable to null.



Nulling a context variable

 Variable Value 

 order_form null 



Alternatively you can delete the context variable in your application logic. For information about how to remove the variable entirely, see [Deleting a context variable in JSON](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-runtime-contextdialog-runtime-context-delete-json).





 Updating a context variable value 

To update a context variable's value, define a context variable with the same name as the previous context variable, but this time, specify a different value for it.

When more than one node sets the value of the same context variable, the value for the context variable can change over the course of a conversation with a user. Which value is applied at any given time depends on which node is being triggered by the user in the course of the conversation. The value specified for the context variable in the last node that is processed overwrites any values that were set for the variable by nodes that were processed previously.

For information about how to update the value of a context variable when the value is a JSON object or JSON array data type, see [Updating a context variable value in JSON](https://cloud.ibm.com/docs/assistant-data?topic=assistant-data-dialog-runtime-contextdialog-runtime-context-update-json)





 How context variables are processed 

Where you define the context variable matters. The context variable is not created and set to the value that you specify for it until your assistant processes the part of the dialog node where you defined the context variable. In most cases, you define the context variable as part of the node response. When you do so, the context variable is created and given the specified value when your assistant returns the node response.
For more information about the methods available for you to use, see [Expression language methods](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-methods).





 Deleting a context variable 

To delete a context variable, set the variable to null.



Nulling a context variable

 Variable Value 

 order_form null 



Alternatively you can delete the context variable in your application logic. For information about how to remove the variable entirely, see [Deleting a context variable in JSON](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-runtime-contextdialog-runtime-context-delete-json).





 Updating a context variable value 

To update a context variable's value, define a context variable with the same name as the previous context variable, but this time, specify a different value for it.

When more than one node sets the value of the same context variable, the value for the context variable can change over the course of a conversation with a user. Which value is applied at any given time depends on which node is being triggered by the user in the course of the conversation. The value specified for the context variable in the last node that is processed overwrites any values that were set for the variable by nodes that were processed previously.

For information about how to update the value of a context variable when the value is a JSON object or JSON array data type, see [Updating a context variable value in JSON](https://cloud.ibm.com/docs/assistant?topic=assistant-dialog-runtime-contextdialog-runtime-context-update-json)





 How context variables are processed 

Where you define the context variable matters. The context variable is not created and set to the value that you specify for it until your assistant processes the part of the dialog node where you defined the context variable. In most cases, you define the context variable as part of the node response. When you do so, the context variable is created and given the specified value when your assistant returns the node response.
Get metadata that describes a specific package.

ibmcloud fn package get PACKAGE_NAME [--summary]



 Command options 

PACKAGE_NAME
: The name of a package. This value is required.

--summary
: Get a summary of the package details. Parameters with the prefix "*" are bound. This flag is optional.





 Example 

ibmcloud fn package get hello







 ibmcloud fn package list 

List all the packages that you created or a specific number of packages.

ibmcloud fn package list [NAMESPACE] [--limit NUMBER_OF_PACKAGES] [--name-sort] [--skip NUMBER_OF_PACKAGES]



 Command options 

/NAMESPACE
: List the packages in a specific namespace ID. This value must begin with a /. This value is optional. If not specified, all packages are listed.

--limit NUMBER_OF_PACKAGES, -l NUMBER_OF_PACKAGES
: List a specified number of packages. The default is 30 packages.

--name-sort, -n
: Sort the list of returned packages by name, otherwise the list is sorted by creation date.

--skip NUMBER_OF_PACKAGES, -s NUMBER_OF_PACKAGES
: Exclude a specified number of the most recently created packages from the result.





 Example 

ibmcloud fn package list

Run ibmcloud fn package list /whisk.system to view a list of preinstalled packages.







 ibmcloud fn package refresh 

Refresh the package bindings for all the packages within a specific namespace.

ibmcloud fn package refresh /NAMESPACE



 Command options 

/NAMESPACE
: A namespace ID, beginning with /. This flag is required. Run ibmcloud fn namespace list to get a list of namespaces to choose from.





 Example 

ibmcloud fn package refresh /user@domain.com_dev







 ibmcloud fn package update 

Update a package designed to contain one or more actions.
RBAC roles and cluster roles define a set of permissions for how users can interact with Kubernetes resources in your cluster.

With IBM Cloud IAM, you can automatically manage RBAC from IBM Cloud, by assigning users [service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users). You might want a deeper understanding of RBAC to customize access for resources within your cluster, like service accounts.



 What are the types of RBAC roles? 



* A Kubernetes role is scoped to resources within a specific namespace, such as a deployment or service.
* A Kubernetes cluster role is scoped to cluster-wide resources, such as worker nodes, or to namespace-scoped resources that can be found in each namespace, like pods.







 What are RBAC role bindings and cluster role bindings? 

Role bindings apply RBAC roles or cluster roles to a specific namespace. When you use a role binding to apply a role, you give a user access to a specific resource in a specific namespace. When you use a role binding to apply a cluster role, you give a user access to namespace-scoped resources that can be found in each namespace, like pods, but only within a specific namespace.

Cluster role bindings apply RBAC cluster roles to all namespaces in the cluster. When you use a cluster role binding to apply a cluster role, you give a user access to cluster-wide resources, like worker nodes, or to namespace-scoped resources in every namespace, like pods.





 What do these roles look like in my cluster? 

If you want users to be able to interact with Kubernetes resources from within a cluster, you must assign user access to one or more namespaces through [IBM Cloud IAM service access roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users). Every user who is assigned a service access role is automatically assigned a corresponding RBAC cluster role. These RBAC cluster roles are predefined and permit users to interact with Kubernetes resources in your cluster.
* [Set permissions for assets](https://www.ibm.com/docs/en/planning-analytics/latest?topic=workspace-set-permissions-assets)



You must have the Full control permission on an asset to set permissions for that asset.



* [Set permissions on the Shared folder and subfolders](https://www.ibm.com/docs/en/planning-analytics/latest?topic=workspace-set-permissions-shared-folder-subfolders)



If you are an administrator in Planning Analytics as a Service, or a user with full control permissions, you can set user permissions on the Shared folder. Additionally, administrators and other users with required privileges can set user permissions on subfolders within the Shared folder.



* [Delete chats from a book](https://www.ibm.com/docs/en/planning-analytics/latest?topic=workspace-delete-chats-from-book)



If you are an administrator, you can delete the entire chat conversation from a book.



* [Limit access to the Set Editor](https://www.ibm.com/docs/en/planning-analytics/latest?topic=workspace-limit-access-set-editor)



If you are an administrator, you can enable or disable access to the Set Editor from a view or from a selector that is created from a dimension tile.
Granting SSH access to a user 

Use the following steps to grant SSH access to one or more users. These steps demonstrate how to configure this file.



1. Locate the following OpenSSH file:

/etc/ssh/sshd_config
2. Make a backup of this file so you can revert if necessary.

cp /etc/ssh/sshd_config{,.'date +%s'}
3. Edit the file by using the OpenSSH keywords.





 OpenSSH keywords 

See the following information about OpenSSH keywords.



 AllowGroups 

After this keyword, include a list of group name patterns. Separate the patterns with spaces. If you specify Login, it is allowed only for users whose primary group or supplementary group list matches one of the patterns. You can use "" and "?" as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, Login is allowed for all groups.





 AllowUsers 

After this keyword, include a list of username patterns. Separate the patterns with spaces. If you specify Login, it is allowed only for usernames that match one of the patterns. You can use "" and "?" as wildcards in the patterns. Only usernames are valid; a numerical user ID is not recognized. By default, Login is allowed for all users. If the pattern takes the form USER@HOST, then USER and HOST are separately checked, restricting logins to particular users from particular hosts.





 DenyGroups 

After this keyword, include a list of group name patterns. Separate the patterns with spaces. If you specify Login, it is disallowed for users whose primary group or supplementary group list matches one of the patterns. You can use "" and "?" can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, Login is allowed for all groups.





 DenyUsers 

After this keyword, include a list of username patterns.
API key A credential that is used for a user or service ID Access Key api-key API key 
 Access groups A way to organize users and service IDs where all members of the group are assigned the same access. Groups, roles Active Directory groups Google Groups 
 Trusted profiles A way to assign access to federated users based on SAML attributes or for all applications running in a compute resource without the need of managing and rotating credentials. Roles Managed identity Workload identity 
 Policy Access assignment made up of a subject, target, and role. Policy Role assignment Policy 
 Policy subject A user, service ID, or access group An IAM user, group, or a role Security principal A resource 
 Roles A role is a collection of actions for a specific resource that are used as a building block to make an access policy. AWS-managed policy Role definition Predefined roles 
 Custom roles Customer-defined and named role, including only the actions chosen by the user. Customer-managed policies Custom roles Custom roles 
 Actions What is allowed to be completed within the context of the platform or service Actions Permissions Permissions 
 Resources Target of an access policy Resources Resources Resources 
 Resource groups Logical organization container for IAM-enabled services Tags Resource groups Projects 
 Public access Public access to specific resources is enabled through a default access group called Public Access. This feature can be disabled on each account. Feature of Amazon S3 that can be enabled for specific resources, and can be disabled at the account or bucket level. Public read access can be enabled for specific account types or resources. It can be disabled at the storage account or container level. Google has an identifier for allAuthenticatedUsers that represents all service accounts and all users who are authenticated with a Google Account, which can also be granted access. 
 Auditing Audit with Activity Tracker Audit with AWS CloudTrail Azure Logging and Auditing Activity logs Audit with Audit logging 







 Federating users to IBM Cloud 

IBM Cloud offers two ways for you to federate your corporate identity provider (IdP), which simplifies login by giving your employees access to IBM Cloud with their company username and password.
The default pinning policy is none.





 What does it mean to set an affinity or anti-affinity rule? 

You can apply affinity and anti-affinity policies to both VMs and volumes.

VM affinity and anti-affinity policy allows you to spread a group of VMs across different hosts or keep them on a specific host.

Volume affinity and anti-affinity policy allow you to control the placement of a new volume based on an existing PVM instance (VM) or volume. When you set an affinity policy for a new storage volume, the volume is created within the same storage provider as an existing PVM instance or volume. With an anti-affinity policy, the new volume is created in a different storage provider other than the storage provider the existing PVM instance or volume is located in.

The use of volume affinity policy (affinity or anti-affinity) requires the availability of multiple storage providers. You might experience the following errors when you use a volume affinity policy:



* If an additional storage provider is not available to fulfill the requested policy, you might receive an error that indicates the inability to locate a storage provider to create a volume by using the requested volume affinity policy.
* If additional storage providers exist but the storage providers do not have sufficient space to fulfill the requested policy, you might receive an error that indicates the inability to locate a storage provider with enough free capacity to satisfy the requested volume size.







 How to set a PVM instance to allow attaching mixed storage? 

You can now attach storage volumes to a PVM instance from different storage tiers and pools, other than the storage pool the PVM instance's root (boot) volume is deployed in. To accomplish this you must modify the PVM instance and set the new PVM instance storagePoolAffinity property to false. The PVM instance storagePoolAffinity property is set to true by default when the PVM instance is deployed and can be changed only by using the modify PVM instance API. For more information about modifying a PVM instance API, see [Modify PVM Instance](https://cloud.ibm.com/apidocs/power-cloudpcloud-pvminstances-put). Attaching mixed storage to a PVM instance has implications on the PVM instance capture, clone, and snapshot features.
This access is read only, by default, which is the level that is required by Code Engine to download the source code. You can select write access, if needed. Consider choosing this option to set an SSH key that is scoped to specific repositories to control access to only the specified repositories.



* [GitHub - Deployment keys](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keysdeploy-keys)
* [GitLab - Deployment keys](https://docs.gitlab.com/ee/user/project/deploy_keys/)



2. An SSH key associated with a user, for example, your own user account or a functional ID that is available in your organization. This SSH key has the repository permissions from the user account. Code Engine requires read access to download the source code.

Because setting an SSH key that is scoped to a user account provides access to the full account, it is important to be aware of security implications when you choose this option.



* [Adding an SSH key to your GitHub account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).
* [Adding an SSH key to your GitLab account](https://docs.gitlab.com/ee/user/ssh).





Do not create your SSH key file with a secure passphrase as this action causes your build command to fail.





 Adding private repository access from the console 

To add private repository access from the console,



1. Go to the [Code Engine dashboard](https://cloud.ibm.com/codeengine/overview).
2. Select a project (or [create one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project)).
3.