vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"href": "https://resource-controller.cloud.ibm.com/v2/resource_groups/60fc731a-1794-4f5d-ba51-ea24b5357207",
"id": "60fc731a-1794-4f5d-ba51-ea24b5357207",
"name": "Default"
},
"resource_type": "share",
"size": 40,
"mount_targets":
{
"href": "https://us-south.iaas.cloud.ibm.com/v1/shares/51bba578-0dce-4f8a-aa6e-f06c899e2c8e/mount_targets/d5fd8173-f519-4ff7-8f63-0ead23ecf1f4",
"id": "d5fd8173-f519-4ff7-8f63-0ead23ecf1f4",
"name": "mount-target-name1",
"resource_type": "share_target",
"vpc": {
"crn": "crn:...]",
"href": "https://us-south.iaas.cloud.ibm.com/v1/vpcs/c2d941de-27f5-432c-b4d0-37a8491c3216",
"id": "c2d941de-27f5-432c-b4d0-37a8491c3216",
"name": "vpc-name1",
"resource_type": "vpc"
}
}
],
"zone": {
"href": "https://us-south.iaas.cloud.ibm.com/v1/regions/us-south/zones/us-south-1",
Management VPC Address prefix for VPC management network <br>VPC management network for virtual server instances 172.10.0.0/16 <br>172.10.1.0/24 
 Workload VPC Address prefix for VPC workload network <br>VPC management network for virtual server instances 172.11.0.0/16 <br>172.11.2.0/24 
 Edge VPC Address prefix for VPC edge network <br>VPC edge network for virtual server instances 172.12.0.0/16 <br>172.11.1.0/24 
 Power VS workspace Power VS management network <br>PowerVS backup network<br><br>Separate network for each SAP system on Power VS and each SAP system or SAP component group on VPC <br>SAP S4/HANA PRD <br>SAP S4/HANA QA1 <br>SAP Web Dispatchers on edge VPC 10.10.10.0/24 <br>10.10.11.0/24<br><br>10.10.20.0/24 <br>10.10.21.0/24 



7. Define hostnames for all the virtual server instances and services that you deploy in the landscape. Map the hostnames to the IP addresses. Also, it's possible to deploy the virtual server instances and assign the IP address dynamically. Make sure that you clear DNS/IP picture before you start. You can use a DNS service of your choice. The only requirement is that this service must be reachable from the Virtual Private Cloud. In the example, IBM Cloud DNS service is used with the following hostname / IP address mappings.



Table 2. Example host name and IP address mappings

 Deployed virtual server instance and services Hostname IP address 

 Access host access.example.com 172.10.1.4 
 Basic management services basic.service.example.com 172.11.1.4 
 Critical management services critical.service.example.com 172.11.1.5 
 Power VS shared file system power.service.mgmt.example.com 10.10.10.4
* a virtual server with floating IP address
* a database
* a file storage



To access information from the global configuration, you can utilize [Terraform remote state](https://www.terraform.io/docs/state/remote.html). It allows the reference of an existing Terraform state in read-only mode. This is a very useful construct to split your Terraform configuration in smaller pieces, leaving the responsibility of individual parts to different teams. [backend.tf](https://github.com/IBM-Cloud/multiple-environments-as-code/blob/master/terraform/per-environment/backend.tf) contains the definition of the global remote state used to find the organization created earlier:

data "terraform_remote_state" "global" {
backend = "local"

config {
path = "${path.module}/../global/terraform.tfstate"
}
}

Setting up a deployment environment begins with creating a resource group. Its name is taken from an environment variable:

 a resource group
resource "ibm_resource_group" "group" {
name = "${var.environment_name}"
}

The VPC is created in that resource group. The VPC is named after the deployment environment.

resource "ibm_is_vpc" "vpc1" {
name = var.environment_name
resource_group = ibm_resource_group.group.id
}

After the VPC and its network, the VSI is created. Most of the properties will be initialized from configuration variables. You can adjust the zone, the machine profile and image type, etc.

resource "ibm_is_instance" "vsi1" {
name = "${var.environment_name}-vsi1"
vpc = ibm_is_vpc.vpc1.id
zone = "${var.region}-1"
profile = "cx2-2x4"
image = data.ibm_is_image.vsi_image.id
* [ibm_is_vpc_routing_table](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpc_routing_table)<br> * [ibm_is_vpc_routing_table_route](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpc_routing_table_route)<br> * [ibm_is_vpc_routing_table_routes](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpc_routing_table_routes)<br> * [ibm_is_vpc_routing_tables](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpc_routing_tables)<br> * [ibm_is_vpcs](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpcs)<br> * [ibm_is_vpn_gateway](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpn_gateway)<br
This applies to VPC subnets using RFC-1918 "and" IANA assigned prefixes. As with all custom route additions, the routing table must include a route for each Availability Zone (AZ) requiring connectivity.

Options include:



* If the VPC default (egress) routing table is attached to all VPC subnets, create a route for each IANA prefix or aggregate per zone in the VPC default table with the Delegate-VPC action. This defers to the VPC system routing table for forwarding action.
* If you use custom routing tables, create a route for each IANA prefix or aggregate per zone in each custom routing table with the Delegate-VPC action.



Using IANA ranges works only with custom routes having the Delegate-VPC action, not Delegate. Both custom route actions of Delegate-VPC and Delegate defer to the VPC system routing table. The only difference is that Delegate uses any floating IP or public gateway when forwarding traffic to IANA destinations; Delegate-VPC does not, and assumes that IANA destinations are in the VPC (not the internet).



 Use case 1: VPC connected to an Enterprise with IBM Cloud Direct Link 

Zoom

![VPC connected to an Enterprise with Direct Link use case](https://cloud.ibm.com/docs-content/v1/content/b698ea8660e1f51664f7479f870bbf8840335d06/dl/includes/vpc/includes/vpc/images/vpc-enterprise.png)

VPC connected to an Enterprise with Direct Link use case

VPC A Networks

VPC B Networks



Table 4. VPC A Networks

 IP Origin 

 10.100.0.0/24 from VPC A subnet 
 13.100.0.0/24 from VPC A subnet 
 10.101.0.0/24 from VPC B through Transit Gateway (local) 
 13.101.0.0/24 from VPC B through Transit Gateway (local) 
 10.0.0.0/8 from an Enterprise through Direct Link 
 172.16.0.0/12 from an Enterprise through Direct Link
If you require one or more address prefixes you should define as part of resource provisioning in the configuration file. To configure multiple address prefix with arguments define the code as stated in the code block. For more information, see [ibm_is_vpc_address_prefix data source](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/data-sources/is_vpc_address_prefixesattribute-reference).

 {: codeblock}
resource "ibm_is_vpc" "testacc_vpc" {
name = "testvpc"
}

resource "ibm_is_vpc_address_prefix" "testacc_vpc_address_prefix" {
name = "test"
zone = "us-south-1"
vpc = ibm_is_vpc.testacc_vpc.id
cidr = "10.240.0.0/24"
}

resource "ibm_is_vpc_address_prefix" "testacc_vpc_address_prefix2" {
name = "test2"
zone = "us-south-1"
vpc = ibm_is_vpc.testacc_vpc.id
cidr = "10.240.0.0/24"
}

* How do I define a policy which has all resource groups?

A access group policy is a way to organize your account having create, modify, or delete an IAM access groups, where user can grant permissions to members with appropriate privileges such as Manager, Viewer and Administrator. For more information, about [ibm_access_group_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_access_group_policy) and [iam_service_policy resource](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_service_policy).

 {: codeblock}
resource "ibm_iam_access_group" "accgrp" {
* UI
* Terraform







 Customizing a three-tier highly available infrastructure VPC in a single availability zone with automation 

Highly available and resilient infrastructures for a single availability zone include multiple components and connections. The individual pieces can be created manually with the IBM Cloud® dashboard, but it is a time-intensive process. To streamline the process, IBM Cloud provides several methods to automate deployment by using Terraform as a base. You can run the Terraform scripts yourself, or use the catalog tile or Schematics user interface to run the scripts. The IBM Cloud VPC infrastructure that is created uses Intel Xeon CPUs and additional Intel technologies.

All infrastructures have a core set of features that are used. You can customize your infrastructure by adding the features that you want.

You can select how you want to deploy the architecture:



* Deploy on IBM Cloud - Use the user interface to enter the information for your infrastructure.
* Run locally - Download script files to your local machine to configure and run.





 Core and Feature modules 

For Terraform and Schematics deployments, the components in a single availability zone 3-tier infrastructure are divided into modules so that you can customize your infrastructure to your needs. You receive all of the core components and can turn features components on or off as needed. Modules are not available for the catalog tile deployment.



 Module Resources 

 Core Resources needed for all single availability zone infrastructures. All resources are configured.<br><br><br><br> * VPC<br> * Region<br> * Subnet<br> * Security Group<br> * App Load balancer (ALB)<br> * web VSI + host placement groups<br> * App VSI + host placement groups<br> * Instance group<br> * Public Gateway<br> * Public or Private (web LBaaS)<br><br><br> 
 Features The optional features for a single availability zone infrastructure. You can select as many as you need.<br><br><br><br> * File<br><br><br> 







 What is created 

A VPC is a private space in IBM Cloud where you can run an isolated environment with custom network policies.
Carefully plan by [designing an addressing plan for a VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-addressing-plan-design) and use non-overlapping CIDR blocks.

It is tempting to divide up the CIDR space first by VPC but this complicates routing. Instead think of an availability zone as a single CIDR block and each VPC as consuming a slice of it.

Zoom

![Zones](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-zones.svg)

Zones

This diagram shows just zone 1 in more detail. The subnet sizes and layout are identical in the other zones:

Zoom

![VPC Layout](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/vpc-transit/vpc-transit-vpc-layout.svg)

VPC Layout

Above the enterprise is on the left and the IBM Cloud on the right. In the IBM Cloud for simplictiy a single zone is depicted for the transit VPC and Spoke 0. Notice the CIDR blocks do not overlap and VPCs all consume a CIDR block in each zone:



* The on-premises CIDR is 192.168.0.0/16.
* The zones in this [multi-zone region](https://cloud.ibm.com/docs/overview?topic=overview-locations) are 10.*.0.0/16. The second digit: 1, 2, 3 is the zone number (shown for Dallas/us-south):



* 10.1.0.0/16, zone 1, Dallas 1, us-south-1.
Repository URL is https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-site2site-vpn
2. Terraform version is terraform_v1.2



3. Under Workspace details,



1. Provide a workspace name : vpnsts.
2. Choose a Resource Group and a Location.
3. Click on Next.



4. Verify the details and then click on Create.
5. Under the Variables section, provide the required values (resource_group_name, ssh_key_name) by clicking the overflow menu and selecting Edit for each row. The value for the variable maintenance must be set to true.
6. Scroll to the top of the page and click Apply plan. Check the logs to see the status of the services created.



Explore the resources that were created by clicking below and selecting the instance with matching prefix. Locate all of the resources in the diagram above.



* [IBM Cloud VPC](https://cloud.ibm.com/vpc-ext/network/vpcs)
* [Virtual Servers for VPC](https://cloud.ibm.com/vpc-ext/compute/vs)
* [IBM® VPN](https://cloud.ibm.com/vpc-ext/network/vpngateways)
* [VPE for VPC](https://cloud.ibm.com/vpc-ext/network/endpointGateways)
* [Databases for PostgreSQL instance in Databases](https://cloud.ibm.com/resources)
* [Object Storage](https://cloud.ibm.com/objectstorage/)







 Step 2: Verify connectivity 

The Schematics workspace output contains variables that can be used to verify the VPN connectivity.



1. Get the list of workspaces, note the ID column, set the shell variable:

ibmcloud schematics workspace list
2. Set the WORKSPACE_ID variable:
The original methods specific to network interfaces are now deprecated:



* GET /security_groups/{security_group_id}/network_interfaces
* DELETE /security_groups/{security_group_id}/network_interfaces/{id}
* GET /security_groups/{security_group_id}/network_interfaces/{id}
* PUT /security_groups/{security_group_id}/network_interfaces/{id}



For more information, see [Integrating an IBM Cloud Application Load Balancer for VPC with security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-alb-integration-with-security-groups).

Bring Your Own IP (BYOIP) support for VPC. VPC address prefixes are no longer restricted to [RFC-1918](https://tools.ietf.org/html/rfc1918) addresses. You must now configure VPCs that use both non-RFC-1918 addresses and have public connectivity (floating IPs or public gateways) using a custom route that contains the new delegate_vpc property. You must specify this property for destination CIDRs that are non-RFC-1918 compliant and outside of the VPC, such as for destinations that are reachable through IBM Cloud® Direct Link, IBM Cloud Transit Gateway, or VPC classic access.

The delegate_vpc property is not required if a VPC uses only RFC-1918 addresses or has no public connectivity.

The following API methods have been updated:



* View the delegate_vpc property in the requests and responses for /vpcs/{vpc_id}/routing_tables/{routing_table_id}/routes.
* View reserved IP ranges in POST /vpcs/{vpc_id}/address_prefixes, which creates an address pool prefix.









 27 January 2021 



 For all version dates 

Checksum (SHA256) for imported images. When you import a custom image to IBM Cloud VPC, you can now view the checksum that was generated for the image during the import operation.
Further summarized to a prefix 192.168.4.0/22 and using NSX-T HA VIP 192.168.0.10 in Zone us-south-2 as the next-hop. For more information about VPC routes, see [VPC routing tables and routes](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routes).



Table 6. VPC routes

 Route description Zone Traffic type CIDR Action Type Next-hop 

 NSX-T overlay networks us-south-2 Egress 192.168.4.0/22 Deliver IP 192.168.0.10 



VPC routes are Zone specific.

Creating a VPC route enables traffic within the Zone or VPC depending on how the VPC route is created. If you use any of the interconnectivity options, such as Direct Link or Transit Gateway, and you need connectivity from another VPC attached to a TGW, in addition to the VPC route, you can create a VPC prefix matching the NSX-T overlay subnet or prefix. This action allows both DL and TGW to advertise your NSX-T overlay subnet or prefix to the attached TGW connections or DL. Using the previous example, you can create a VPC prefix matching the route 192.168.4.0/22, which enables TGW to advertise this prefix to the other attached VPCs, or Classic. For more information about VPC prefixes and about creating prefixes, see [Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).





 Related links 



* [IBM Cloud VPC getting started](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started)
* [IBM Cloud VPC Bare Metal Servers](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-for-bare-metal-servers)
The Transit Gateway will have a connection to each VPC and routes traffic based on the CIDR ranges. So, avoiding overlaps will ensure success.
3. Create the resources:

terraform init
terraform apply
4. List the VPC resources

The VPC resources created is summarized by the output of the subnets command, shown below, edited for brevity. Notice the three VPCs, the non-overlapping CIDR blocks, and the resource groups membership:

ibmcloud target -r $(grep ibm_region terraform.tfvars | sed -e 's/ //g' -e 's/.//' -e 's/.=//' -e 's/"//g')
ibmcloud is subnets --all-resource-groups | grep $basename

The output will look like this:

$ ibmcloud is subnets --all-resource-groups | grep $basename
widget0-shared-z1 available 10.0.0.0/24 widget0-shared us-south-1 widget0-shared
widget0-shared-z2 available 10.0.1.0/24 widget0-shared us-south-2 widget0-shared
widget0-shared-z3 available 10.0.2.0/24 widget0-shared us-south-3 widget0-shared
widget0-application1-z1 available 10.1.0.0/24 widget0-application1 us-south-1 widget0-application1
widget0-application1-z2 available 10.1.1.0/24 widget0-application1 us-south-2 widget0-application1
widget0-application1-z3 available 10.1.2.0/24 widget0-application1 us-south-3 widget0-application1
widget0-application2-z1 available 10.2.0.0/24 widget0-application2 us-south-1 widget0-application2
* If the VPC default (egress) routing table is attached to all VPC subnets, create a route for each IANA prefix or aggregate per zone in the VPC default table with the Delegate-VPC action. This defers to the VPC system routing table for forwarding action.
* If you use custom routing tables, create a route for each IANA prefix or aggregate per zone in each custom routing table with the Delegate-VPC action.



Using IANA ranges works only with custom routes having the Delegate-VPC action, not Delegate. Both custom route actions of Delegate-VPC and Delegate defer to the VPC system routing table. The only difference is that Delegate uses any floating IP or public gateway when forwarding traffic to IANA destinations; Delegate-VPC does not, and assumes that IANA destinations are in the VPC (not the internet).



 Use case 1: VPC connected to an Enterprise with IBM Cloud Direct Link 

Zoom

![VPC connected to an Enterprise with Direct Link use case](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc//images/vpc-enterprise.png)

VPC connected to an Enterprise with Direct Link use case

VPC A Networks

VPC B Networks



Table 4. VPC A Networks

 IP Origin 

 10.100.0.0/24 from VPC A subnet 
 13.100.0.0/24 from VPC A subnet 
 10.101.0.0/24 from VPC B through Transit Gateway (local) 
 13.101.0.0/24 from VPC B through Transit Gateway (local) 
 10.0.0.0/8 from an Enterprise through Direct Link 
 172.16.0.0/12 from an Enterprise through Direct Link 
 13.0.0.0/8 from an Enterprise through Direct Link 



VPC A Default (Egress) Routing Table

VPC B Default (Egress) Routing Table



Table 6. VPC A Default (Egress) Routing Table
[Provision VPC for Rolling button](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-deploy_rolling_button.png)](https://cloud.ibm.com/schematics/workspaces/create?repository=https://github.com/Cloud-Schematics/vpc-bastion-rolling-deploy)[![Provision VPC for Blue-Green button](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-deploy_bg_button.png)](https://cloud.ibm.com/schematics/workspaces/create?repository=https://github.com/Cloud-Schematics/vpc-bastion-bluegreen-deploy)[![Provision VPC for Canary button](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds-vpc-setup-deploy_canary_button.png)](https://cloud.ibm.com/schematics/workspaces/create?repository=https://github.com/Cloud-Schematics/vpc-bastion-canary-deploy)
* An instance of the [Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-getting-started) service.
* Optional. A set of secrets that are stored in a secrets management vault and managed centrally from a single location.
Provide a CIDR address prefix for Primary VPC creation. For more information, see [Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). string 10.10.0.0/24 
 secondary_cidr_block IBM Cloud VPC address prefixes that are needed for VPC creation. Provide a CIDR address prefix for Secondary VPC creation. For more information, see [Bring your own subnet]([https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-add](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-add) 
 secondary_candidate_cidr_block IBM Cloud VPC address prefixes that are needed for VPC creation. Provide a CIDR address prefix for Secondary Candidate VPC creation. For more information, see [Bring your own subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes). string 10.30.0.0/24 
 smc_image_name Name of the custom image that you want to use to create virtual server instances in your IBM Cloud account to deploy the IBM Symphony Multi Cluster. The default may or might not need to be changed, depending on your deployment. By default, the automation uses a base image with more software packages mentioned [here](https://cloud.ibm.com/docs/hpc-spectrum-symphonycreate-custom-image). To include your application-specific binary files, see [Planning for custom images](https://cloud.ibm.com/docs/vpc?topic=vpc-planning-custom-images) to create a custom image and use that image to build the IBM Symphony cluster through this offering. string hpcc-symphony732-rhel86-smc-v1 
 smc_host_instance_type Specify the virtual server instance profile type name to be used to create the Symphony Multi Cluster host.
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) 
 Block Storage Snapshots for VPC ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) 
 Block Storage for VPC ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/adcecdbe4e86955f88aac7f3c1e7ec3ff44992ef/icons/checkmark-icon.svg) !