vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Deploying Roll Your Own VMware on IBM Cloud Bare Metal Servers for Virtual Private Cloud 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

IBM Cloud™ has a number of [offerings for VMware deployments in Classic](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-getting-startedgetting-started-depl-offerings). These can be classified and described as:



* Automated vSphere Hypervisor Image deployment ([IBM Cloud Bare Metal Servers for Virtual Private Cloud with VMware vSphere](https://cloud.ibm.com/docs/vmware?topic=vmware-vmware-getting-started))
* Automated vSphere Hypervisor Image deployment, installation and configuration ([VMware Solutions Dedicated - VMware vSphere®](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vs_vsphereclusteroverview))
* Automated vCenter and vSphere clusters deployment, installation and configuration ([VMware Solutions Dedicated - vCenter Server](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_vcenterserveroverview))



[IBM Cloud Bare Metal Servers for Virtual Private Cloud](https://cloud.ibm.com/docs/vpc?topic=vpc-about-bare-metal-servers) environment provide a new option to deploy VMware on IBM Cloud. Currently the IBM Cloud VPC environment provides only the automated vSphere Hypervisor (ESXi) Operating System image deployment to Intel Bare Metals on VPC. Therefore, you need to manually install and configure the required VMware components, such as ESXi hosts, vCenter, vSAN or NSX-T components.
* CLI
* API
* Terraform







 Using virtual private endpoints for VPC to privately connect to Direct Link 

IBM Cloud® Virtual Private Endpoints (VPE) for VPC enables you to connect to Direct Link from your VPC network by using the IP addresses of your choosing, allocated from a subnet within your VPC.

VPEs are virtual IP interfaces that are bound to an endpoint gateway created on a per service, or service instance, basis (depending on the service operation model). The endpoint gateway is a virtualized function that scales horizontally, is redundant and highly available, and spans all availability zones of your VPC. Endpoint gateways enable communications from virtual server instances within your VPC and IBM Cloud® service on the private backbone. VPE for VPC gives you the experience of controlling all the private addressing within your cloud. For more information, see [About virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe).



 Before you begin 

Before you target a virtual private endpoint for IBM Cloud®, you must complete the following tasks.



* Ensure that a [Virtual Private Cloud is created](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started).
* Make a plan for your [virtual private endpoints](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-considerations).
* Ensure that [correct access controls](https://cloud.ibm.com/docs/vpc?topic=vpc-configure-acls-sgs-endpoint-gateways) are set for your virtual private endpoint.
* Understand the [limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations-vpe) of having a virtual private endpoint.
* Understand how to [view details](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-viewing-details-of-an-endpoint-gateway) about a virtual private endpoint.







 Setting up a VPE for Direct Link
Validating your resources in VPC 

After you provision your VPC environment, and before you make your VPC live, you will want to validate the components to ensure they are ready for production. You will perform this validation in [IBM Cloud® console](https://cloud.ibm.com/vpc-ext/vpcLayout).

Use the following information as a guideline for validating components. These lists are a starting point. There might be other configurations that you need to validate.

Network



* Validate the number of subnets and the addressing scheme
* Validate that the subnet gateways are configured for the correct subnets
* Validate your firewall rules
* Validate your security groups
* Validate your load balancers. Are the parameters and server pools configured correctly?
* Validate your VPN. Are the parameters are set correctly? Work with your network administrator to ensure that your VPN gateway is configured correctly for peering to be established.



Compute



* Are security groups applied correctly?
* Were the SSH keys moved or created correctly?
* Are virtual servers created and placed in the right subnet?
* Are virtual servers accessible and have access to the correct resources?
* Are virtual servers properly denied access to resources that they should not have access to?
* Can you validate the primary and secondary volumes on virtual servers?



Operating systems

Validate operating system configurations.



* IP addresses
* Route tables
* IP filters
* User access



Applications



* Application configuration files





 Next steps 



1. As a security best practice, when you are finished using VPC+ Cloud Migration, delete the username and API key that you created specifically for VPC+. For more information, see [Deleting an API key](https://cloud.ibm.com/docs/account?topic=account-userapikeydelete_user_key) and [Removing users from an account](https://cloud.ibm.com/docs/account?topic=account-remove).
2. You need a plan for making VPC live. This includes tasks such as:
* CLI
* API
* Terraform







 Integrating with Virtual Private Endpoint for VPC 

IBM Cloud® Virtual Private Endpoint (VPE) for VPC enables you to connect to supported IBM Cloud services from your VPC network by using IP addresses of your choosing, allocated from a subnet within your VPC. A DNS Services VPE allows you to communicate with the control plane of DNS Services.



 Setting up a VPE gateway for the DNS Services service 

Follow instructions in [Getting started](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpevpe-getting-started) for VPE for VPC to create and configure a VPE gateway for the DNS Services service offering.



 Using the CLI 

After creating an endpoint gateway for DNS Services, follow these steps:



1. Update the IBM Cloud CLI to the latest version:

ibmcloud update
2. Update the DNS Services CLI plug-in:

ibmcloud plugin update dns-svcs-cli
3. Log in to the CLI [using a private endpoint](https://cloud.ibm.com/docs/cli?topic=cli-service-connectioncli-private-login).



For more information on VPEs using the CLI, see [Virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencevpe-clis).





 Using the API 

After creating an endpoint gateway for the DNS Services instance, use the service endpoint's FQDN api.private.dns-svcs.cloud.ibm.com in the URL to access the service. For example:

curl https://api.private.dns-svcs.cloud.ibm.com/instance/<instance-id>/dnszones -H "Authorization: Bearer $iam_token"





 Using the SDK
* Classic clusters only, VRF and service endpoint enabled accounts: You must set up your account to use VRF and service endpoints to support scenarios such as running internet-facing workloads and extending your on-premises data center. After you set up the account, your VPC and classic clusters are created with a public and a private cloud service endpoint by default.



1. Enable [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) in your IBM Cloud infrastructure account. To check whether a VRF is already enabled, use the ibmcloud account show command.
2. [Enable your IBM Cloud account to use service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointservice-endpoint).



* Classic clusters only, Non-VRF and non-service endpoint accounts: If you don't set up your account to use VRF and service endpoints, you can create only classic clusters that use VLAN spanning to communicate with each other on the public and private network.



* To use the public cloud service endpoint only (run internet-facing workloads), enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning) for your IBM Cloud infrastructure account so that your worker nodes can communicate with each other on the private network. To perform this action, you need the Network > Manage Network VLAN Spanning[infrastructure permission](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access), or you can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud ks vlan spanning get --region <region>[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get).
For encrypted connections, the Mount Helper uses the instance metadata service protocol option that is set to either http or https. For more information, see the API reference for metadata_service option of [instance provisioning](https://cloud.ibm.com/apidocs/vpc/latestcreate-instance).

For more information, see the [readme file](https://github.com/IBM/vpc-file-storage-mount-helper).



 Requirements and restrictions 



* [Instance metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-about) must be enabled on the virtual server instance.
* The file share must have [security group access mode](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-vpc-about&interface=uifs-mount-access-mode), so the VPC's security access groups can be used to define which virtual server instances can mount the share.
* The mount target must be created with a [virtual network interface](https://cloud.ibm.com/docs/vpc?topic=vpc-vni-about) to create an IP address within the VPC that represents a virtual NFS server.
* Data encryption in transit must be enabled either in the UI or with the API.
* The same certificates cannot be used across multiple regions.
* The Mount Helper is supported for mounting on Linux hosts only.







 Build from source code 



1. Clone the source code repo.

git clone https://github.com/IBM/vpc-file-storage-mount-helper.git
2. Build the artifacts by running the make command.

make prod







 Installation and configuration of the Mount Helper 



1. Download the Mount Helper package:

curl -LO https://github.com/IBM/vpc-file-storage-mount-helper/releases/download/latest/mount.ibmshare-latest.tar.gz
tar -xvf mount.ibmshare-latest.tar.gz
PHP web application on a LAMP Stack in VPC 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

This tutorial walks you through the creation of an Ubuntu Linux virtual server with Apache web server, MySQL database and PHP scripting on IBM Cloud [Virtual Private Cloud (VPC) Infrastructure](https://www.ibm.com/cloud/learn/vpc). This combination of software - more commonly called a LAMP stack - is often used to deliver websites and web applications. Using IBM Cloud VPC you will quickly deploy your LAMP stack and if desired add logging and monitoring. To experience the LAMP server in action, you will also install and configure the free and open source [WordPress](https://wordpress.org/) content management system.



 Objectives 



* Provision a virtual server instance (VSI) in a VPC.
* Install the latest Apache, MySQL and PHP software.
* Host a website or blog by installing and configuring WordPress.
* Configure logging and monitoring to detect outages and monitor for slow performance (optional).
* Resize the VSI (optional).



Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution56-lamp-stack-on-vpc/Architecture.png)

Figure 1. Architecture diagram of the tutorial



1. End user accesses the LAMP server running on a VPC using a web browser.
2. The VSI is configured to use data from an encrypted Block Storage volume (optional).







 Before you begin 

This tutorial requires:



* An IBM Cloud [billable account](https://cloud.ibm.com/docs/account?topic=account-accounts),
* IBM Cloud CLI,
For a list, see [Supported IBM Cloud and third-party integrations](https://cloud.ibm.com/docs/openshift?topic=openshift-supported_integrations). 
 Locations and versions VPC clusters are available worldwide in the [multizone location](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-vpc). 
 Service interface VPC clusters are supported by the [next version (v2) of the IBM Cloud Kubernetes Service API](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_install), and you can manage your VPC clusters through the same CLI and console as classic clusters. 
 Service compliance See the VPC section in [What standards does the service comply to?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsstandards). 
 Service limitations See [Service limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationstech_limits). For VPC-specific limitations in Red Hat OpenShift on IBM Cloud, see [VPC cluster limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationsks_vpc_gen2_limits). For general VPC infrastructure provider limitations, see [Limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations). 







 Satellite 

Satellite



Table 2. Satellite infrastructure overview.

 Component Description 

 Compute and worker node resources Worker nodes can be virtual machines using either shared infrastructure or dedicated hosts, or even bare metal servers. You manage maintenance and billing activity for the worker nodes through your host infrastructure provider whether that is IBM Cloud, your own on-premises hardware, or another cloud provider. You also manage billing through IBM Cloud. For more information about pricing, see [What am I charged for when I use IBM Cloud Satellite?]
From the [IBM Cloud console](https://console.cloud.ibm.com) menu bar, click Manage > Access (IAM), and select Authorizations.
2. On the Manage authorizations page, click Create.
3. Make your selection for the Source account. By default This account is selected.
4. Select a source service for the authorization. Specify VPC Infrastructure Services as the source service.



1. For How do you want to scope the access?, select Resources based on selected attributes.
2. For Add attributes, select Resource type.
3. For Resource type, select Image Service for VPC.



5. For the Target service, select Cloud Object Storage. For How do you want to scope the access?, you can use the default selection All resources.

If you want to scope the access to a specific resource within IBM Cloud Object Storage, you can select Resources based on selected attributes. Then make selections to narrow the access according to your preferences.
6. For the service access roles, select Reader and Writer.
7. Click Authorize.



For more information, see [Using authorizations to grant access between services](https://cloud.ibm.com/docs/account?topic=account-serviceauthserviceauth).





 Granting Reader and Writer access to all buckets from the CLI 

To grant both Reader and Writer access to all buckets in IBM Cloud Object Storage, run the iam authorization-policy-create command. The following command authorizes the Image Service for VPC to both import images from any bucket in an IBM Cloud Object Storage service instance and export images to any bucket in an IBM Cloud Object Storage service instance.

ibmcloud iam authorization-policy-create is cloud-object-storage Reader,Writer --source-resource-type image

For more information, see [ibmcloud iam authorization-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_authorization_policy_create).





 Granting access to a specific bucket from the CLI
ibmcloud is instance-template-create INSTANCE_TEMPLATE_NAME VPC ZONE_NAME PROFILE_NAME SUBNET (--image IMAGE | --catalog-offering CATALOG_OFFERING | --catalog-offering-version CATALOG_OFFERING_VERSION) [--total-volume-bandwidth TOTAL_VOLUME_BANDWIDTH] [--boot-volume BOOT_VOLUME_JSON | @BOOT_VOLUME_JSON_FILE] [--volume-attach VOLUME_ATTACH_JSON | @VOLUME_ATTACH_JSON_FILE] [--keys KEYS] [--dedicated-host DEDICATED_HOST | --dedicated-host-group DEDICATED_HOST_GROUP | --placement-group PLACEMENT_GROUP] [--user-data DATA] [(--sgs SGS] --rip RIP | (--address ADDRESS --auto-delete true | false --ip-name IP_NAME)] --allow-ip-spoofing false | true]) | --primary-network-interface PRIMARY_NETWORK_INTERFACE_JSON | @PRIMARY_NETWORK_INTERFACE_JSON_FILE] [--network-interface NETWORK_INTERFACE_JSON | @NETWORK_INTERFACE_JSON_FILE] [--metadata-service, --ms true | false --metadata-service-protocol, --msp http | https | --metadata-service-response-hop-limit, --msrhl METADATA_SERVICE_RESPONSE_HOP_LIMIT,MSRHL]] [--host-failure-policy restart | stop] [--resource-group-id RESOURCE_GROUP_ID | --resource-group-name RESOURCE_GROUP_NAME] [--output JSON] [-i, --interactive] [-q, --quiet]



 Command examples 



* ibmcloud is instance-template-create my-template-name 72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 us-south-1 bx2-2x8 72b27b5c-f4b0-48bb-b954-5becc7c1dcb8 --image r123-72b27b5c-f4b0-48bb-b954-5becc7c1dcb8
A context variable is a variable that you can use to pass information to your assistant before a conversation starts. It can also collect information during a conversation, and reference it later in the same conversation. For example, you might want to ask for the customer's name and then address the person by name later on.

The following script preserves the context of the conversation. In addition, it adds an $ismember context variable and sets it to true.

The name that is specified for the skill (main skill) is a hardcoded name that is used to refer to any skill that you create from the product user interface. You do not need to edit your skill name.

<script>
function preSendhandler(event) {
event.data.context.skills['main skill'].user_defined.ismember = true;
}
window.watsonAssistantChatOptions = {
integrationID: "YOUR_INTEGRATION_ID",
region: "YOUR_REGION",
serviceInstanceID: "YOUR_SERVICE_INSTANCE_ID",

onLoad: function(instance) {
// Subscribe to the "pre:send" event.
instance.on({ type: "pre:send", handler: preSendhandler });
instance.render();
}
};

setTimeout(function(){
const t=document.createElement('script');
t.src='https://web-chat.global.assistant.dev.watson.appdomain.cloud/versions/' +
(window.watsonAssistantChatOptions.clientVersion || 'latest') +
'/WatsonAssistantChatEntry.js';
document.head.appendChild(t);});

</script>
Show more

You can reference the $ismember context variable from your dialog. For example, the following screen capture shows a dialog node that conditions on #General_Greetings. It has multiple conditioned responses.
[Visit examples intent](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/oe-counter1.png)
2. In the second occurrence of the word, you want to annotate the word visit as an entity value of the @meeting entity. This makes visit equivalent to other @meeting entity values such as appointment, as in I'd like to make an appointment or I'd like to schedule a visit.

![@meeting entity](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/oe-counter2.png)
3. In the first occurrence, the word visit is being used as a verb. It has a different meaning from a meeting. In this case, you can select the word appointment from the intent example, and annotate it as an entity value of the @meeting entity. The model learns from the fact that the word visit in the same example is not annotated.

![Visit unselected](https://cloud.ibm.com/docs-content/v1/content/a2b18c153837bce00a5b4de496e4b4ca64bbf56e/assistant-data/images/oe-counter3.png)









 Adding contextual entities in v1.3 

Annotation-based entites are those for which you annotate occurrences of the entity in sample sentences to teach your assistant about the context in which the entity is typically used.

In order to train a contextual entity model, you can take advantage of your intent examples, which provide readily-available sentences to annotate.

Using an intent's user examples to define contextual entities does not affect the classification of that intent. However, entity mentions that you label are also added to that entity as synonyms.
* <result_variable_name>: The name to use to reference the JSON object that is returned by the external service or program. The result is added to the context section of the /message response. In other words, the result is stored as a context variable so it can be displayed in the node response or accessed by dialog nodes that are triggered later. Any existing value for the context variable is overwritten by the value that is returned by the action. You can specify the result_variable_name by using the following syntax:



* my_result
* $my_result



The name cannot be longer than 64 characters. The variable name cannot contain the following characters: parentheses (), brackets ([]), a single quotation mark ('), a quotation mark ("), or a backslash ().

If you want to save the result to the output or input section of the /message response, then you can add one of the following location keywords as a prefix to the result_variable_name:



* output.: Adds the result to the output section of the /message response. For example, output.my_result.
* input.: Adds the result to the input section of the /message response. For example, input.my_result.



You can specify a context. location keyword prefix also. For example, context.my_result. However, you do not need to because the result is added to the context by default.

You can include periods in the variable name to create a nested JSON object. For example, you can define these variables to capture results from two separate requests to a weather service for forecasts for today and tomorrow:



* context.weather.today
* context.weather.tomorrow



The results (temp and rain parameter values) are stored in the context in this structure:

{
"weather": {
"today": {
"temp": "20",
"rain": "30"
},
"tomorrow": {
"temp": "23",
"rain": "80"
}
}
}
* <result_variable_name>: The name of the context variable you want to use to store the JSON object that is returned by the client action. The client application is expected to use the specified variable to send the return value in the context of the next /message input, and subsequent dialog nodes can then access it. You can specify the result_variable_name by using the following syntax:



* my_result
* $my_result



The name cannot be longer than 64 characters. The variable name cannot contain the following characters: parentheses (), brackets ([]), a single quotation mark ('), a quotation mark ("), or a backslash ().

You can optionally specify a context. location keyword prefix for this variable (for example, context.my_result). However, this is not necessary, because all context variables are stored in this location by default.

You can include periods in the variable name to create a nested JSON object. For example, you can define these variables to capture results from two separate requests to a weather service for forecasts for today and tomorrow:



* context.weather.today
* context.weather.tomorrow



The results (in this example, temp and rain properties) are stored in the context in this structure:

{
"weather": {
"today": {
"temp": "20",
"rain": "30"
},
"tomorrow": {
"temp": "23",
"rain": "80"
}
}
}

If multiple actions in a single JSON action array add the result of their programmatic call to the same context variable, then the order in which the context is updated matters. Per action type, the order in which the actions are defined in the array determines the order in which the context variable's value is set. The context variable value returned by the last action in the array overwrites the values calculated by any other actions.

The result_variable property is required. If the client action does not return any result, specify null as the value.









 Client action example