example(vpn): add usecases #20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "example/vpn-example-usecase"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Checklist
db88535b6ftod23be1ca43d23be1ca43toc148e3b716example(vpn): add module to create sna with test machineto example(vpn): WIPc148e3b716to7ed20f586b7ed20f586btobede872194Overall this looks good, but I added a few comments on points that should be clarified or adjusted before merging.
@ -0,0 +44,4 @@| <a name="input_sna_default_nameserver"></a> [sna_default_nameserver](#input_sna_default_nameserver) | A list of STACKIT SNA default nameservers (IP addresses). | `list(string)` | <pre>[<br/> "1.1.1.1"<br/>]</pre> | no || <a name="input_sna_name"></a> [sna_name](#input_sna_name) | The name of the STACKIT Network Area (SNA). | `string` | n/a | yes || <a name="input_sna_network_range_prefix"></a> [sna_network_range_prefix](#input_sna_network_range_prefix) | A list of STACKIT SNA network range prefixes in CIDR notation. | `list(string)` | <pre>[<br/> "10.28.0.0/16"<br/>]</pre> | no || <a name="input_sna_transfer_range"></a> [sna_transfer_range](#input_sna_transfer_range) | The STACKIT SNA transfer range in CIDR notation. | `string` | `"172.3.0.0/16"` | no |172.3.0.0/16 is part of the public IPv4 address space and is not covered by the private ranges defined in RFC1918.
I would suggest using 172.16.0.0/16 instead, as it falls within the private 172.16.0.0/12 range. Using a public IP range internally can lead to routing issues later on. Especially if traffic to a real public endpoint within that range needs to be resolved or routed externally.
https://datatracker.ietf.org/doc/html/rfc1918
nice catch!
@ -0,0 +47,4 @@variable "sna_transfer_range" {description = "The STACKIT SNA transfer range in CIDR notation."type = stringdefault = "172.3.0.0/16"Please adjust here also to the RFC1918
@ -0,0 +16,4 @@required_providers {stackit = {source = "stackitcloud/stackit"version = ">=0.66.0"The STACKIT Terraform provider version should be used consistently across this example.
@ -0,0 +14,4 @@variable "stackit_org_id" {type = stringdefault = "03a34540-3c1a-4794-b2c6-7111ecf824ef"hard coded org id in the vars
@ -0,0 +26,4 @@type = string# TODO removedefault = "/Users/uphoffm/GolandProjects/professional-service/keys/stackit-sa.json"}adjust to generic vars
@ -0,0 +32,4 @@type = string# TODO removedefault = "/Users/uphoffm/GolandProjects/professional-service/keys/gcp-sa.json"}adjust to generic vars
@ -0,0 +16,4 @@required_providers {stackit = {source = "stackitcloud/stackit"version = ">=0.66.0"The STACKIT Terraform provider version should be used consistently across this example.
locked the version in tflock file. Still updated provider.tf
@ -0,0 +15,4 @@variable "stackit_org_id" {type = stringdefault = "03a34540-3c1a-4794-b2c6-7111ecf824ef"}Hard coded org ids
bede872194to720eabd8d3720eabd8d3to8dffccb78a8dffccb78atoaa8265a13caa8265a13cto8f3b77c345example(vpn): WIPto example(vpn): add example usecasesexample(vpn): add example usecasesto example(vpn): add usecases8f3b77c345to7d87aadd12If the README.md is intended to be the source of truth, it might make sense to align the referenced configuration/files accordingly.
@ -0,0 +11,4 @@| Name | Version || ------------------------------------------------------------------ | --------- || <a name="requirement_stackit"></a> [stackit](#requirement_stackit) | >= 0.87.0 |I don’t want to be nitpicky here, but just for the record: should we use v0.87 or v0.95 now?
I’m still of the opinion that we should keep the referenced provider version consistent across the example, even if Terraform will always pick the latest matching version because of the >= constraint.
@ -0,0 +18,4 @@| Name | Version || ------------------------------------------------------------ | --------- || <a name="provider_stackit"></a> [stackit](#provider_stackit) | >= 0.87.0 |don’t want to be nitpicky here, but just for the record: should we use v0.87 or v0.95 now?
I’m still of the opinion that we should keep the referenced provider version consistent across the example, even if Terraform will always pick the latest matching version because of the >= constraint.
@ -0,0 +42,4 @@| --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------- | ---------------------------------------- | :------: || <a name="input_machine_availability_zone"></a> [machine_availability_zone](#input_machine_availability_zone) | The availability zone (e.g. eu01-1) | `string` | n/a | yes || <a name="input_machine_disk_performance_class"></a> [machine_disk_performance_class](#input_machine_disk_performance_class) | Storage performance class | `string` | `"storage_premium_perf4"` | no || <a name="input_machine_disk_size"></a> [machine_disk_size](#input_machine_disk_size) | Boot volume size in GB | `number` | `50` | no |To keep this cost-effective, we should use the minimum required disk size here. 50 GB seems a bit too large for this example.
@ -0,0 +43,4 @@| <a name="input_machine_availability_zone"></a> [machine_availability_zone](#input_machine_availability_zone) | The availability zone (e.g. eu01-1) | `string` | n/a | yes || <a name="input_machine_disk_performance_class"></a> [machine_disk_performance_class](#input_machine_disk_performance_class) | Storage performance class | `string` | `"storage_premium_perf4"` | no || <a name="input_machine_disk_size"></a> [machine_disk_size](#input_machine_disk_size) | Boot volume size in GB | `number` | `50` | no || <a name="input_machine_image_id"></a> [machine_image_id](#input_machine_image_id) | Image UUID (Default: Debian 12) | `string` | `"c751cde7-e648-4f81-9722-ce9c7848bed0"` | no |Image IDs are not the same across projects. For example, in my test project I get the following image ID:
be18b266-372a-4da3-b6b1-61cc6e3f7b13
So maybe we should add an instruction showing users how to retrieve the correct image ID for their own project instead of hardcoding one.
@ -0,0 +47,4 @@| <a name="input_machine_ipv4_prefix"></a> [machine_ipv4_prefix](#input_machine_ipv4_prefix) | The IPv4 prefix for the test machine's network (CIDR notation). This must be a subnet within the defined SNA network ranges. | `string` | n/a | yes || <a name="input_machine_name"></a> [machine_name](#input_machine_name) | name of the stackit test machine | `string` | `"vpn-test-01"` | no || <a name="input_machine_network_name"></a> [machine_network_name](#input_machine_network_name) | The name of the network where the test machine will be connected. | `string` | n/a | yes || <a name="input_machine_type"></a> [machine_type](#input_machine_type) | Flavor of the machine | `string` | `"g1.1"` | no |according to the modules/test-machine/variables.tf its c2.1
have to correct myself its c2i.1 not c2.1
@ -0,0 +51,4 @@| <a name="input_sna_default_nameserver"></a> [sna_default_nameserver](#input_sna_default_nameserver) | A list of STACKIT SNA default nameservers (IP addresses). | `list(string)` | <pre>[<br/> "1.1.1.1"<br/>]</pre> | no || <a name="input_sna_name"></a> [sna_name](#input_sna_name) | The name of the STACKIT Network Area (SNA). | `string` | n/a | yes || <a name="input_sna_network_range_prefix"></a> [sna_network_range_prefix](#input_sna_network_range_prefix) | A list of STACKIT SNA network range prefixes in CIDR notation. | `list(string)` | <pre>[<br/> "10.28.0.0/16"<br/>]</pre> | no || <a name="input_sna_transfer_range"></a> [sna_transfer_range](#input_sna_transfer_range) | The STACKIT SNA transfer range in CIDR notation. | `string` | `"172.3.0.0/16"` | no |pls adjust to the RFC1918
@ -0,0 +123,4 @@variable "machine_disk_size" {description = "Boot volume size in GB"type = numberdefault = 50see comment on README.md
@ -57,3 +57,3 @@description = "Flavor of the machine"type = stringdefault = "g1.1"default = "c2i.1"This needs to be adjusted if the README.md is intended to be the source of truth.
7d87aadd12to8c027e6ef28c027e6ef2tocff1e365fccff1e365fcto1f6abdc72d1f6abdc72dto41762cf7dc