In order to access a Jetstream2 instance through an external IP address, you need to build a private network in the project where the instance lives. This must be done before the instance is created. You may recall from the Jetstream2 APIs topic that a private network is made up of several connected components:

• A private network to which you will connect your instance(s).
• A subnet within that private network.
• A private router that is connected to the existing public network.
• A router interface that connects the router to the subnet to complete the chain.

That is quite a bit of stuff that has to be defined and connected in just the right way. Fortunately, Terraform is able to sort out the dependencies and do what is needed in the right order. And we can tell Terraform to use information from the components it creates so it makes the right connections. To begin adding a network, download the file network.tf to your configuration directory.

Configuring a Private Network

network.tf contains resource specifications for the four components that were listed above:

resource "openstack_networking_network_v2" "private" {
  name = "terratest_network"
}

resource "openstack_networking_subnet_v2" "private" {
  name       = "terratest_subnet"
  network_id = openstack_networking_network_v2.private.id
  cidr       = var.subnet_cidr
}

resource "openstack_networking_router_v2" "private" {
  name                = "terratest_router"
  external_network_id = var.gateway_id
}

resource "openstack_networking_router_interface_v2" "private" {
  router_id = openstack_networking_router_v2.private.id
  subnet_id = openstack_networking_subnet_v2.private.id
}

Each resource is of a type defined in the OpenStack "networking" API:

• openstack_networking_network_v2
• openstack_networking_subnet_v2
• openstack_networking_router_v2
• openstack_networking_router_interface_v2

Inside these resources, literal strings are assigned to three "name" arguments (these will be the Jetstream2 names for the components). If you want to create multiple networks in one Jetstream2 project, it would be fine to replace these literals with variables that you then declare and set as needed. Note that it is valid and reasonable to give each of these resources the same name ("private"), as each resource is of a different type and together they form the "private" network in your Jetstream project.

Two other assignments are made using variables defined in variables.tf, as seen in the previous page. The "subnet-cidr" variable has a good default value for working with Jetstream2, so you should leave that alone. But you will need to assign a value to the "gateway_id" variable in the file terratest.tfvars. This value must be the ID of the "public" network object in your Jetstream2 project, and it can be found through the Horizon web interface. Three other argument values are taken from properties of other resources defined in this file (the network, the router and the subnet).

Build It Up, Then Tear It Down!

Go ahead and run terraform apply -var-file=terratest.tfvars to deploy this network to Jetstream2. If the deployment is successful, view the network in the Horizon web interface. Now might be good time to test out Terraform's "destroy" command. Issue the command terraform destroy -var-file=terratest.tfvars and you will see that Terraform intends to tear down everything that is defined in your configuration. If you enter "yes" at the prompt, it will go ahead and do that. Then visit the Horizon web page again to see that all of the components are gone. It is that easy!