Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/103 submodules #116

Conversation

taylorludwig
Copy link
Contributor

Fixes #103

  • Splits up functionality into vpc, subnets, and routes submodules.
  • Changes routes input to be a map from a list to support for_each resource creation.
  • Updates ci/docker commands to use version 0.6.0 of developer tools image to fix errors when running generate_docs with complex types.

@taylorludwig taylorludwig requested a review from a team November 25, 2019 22:18
@taylorludwig taylorludwig requested a review from a team as a code owner November 25, 2019 22:18
@taylorludwig
Copy link
Contributor Author

taylorludwig commented Nov 25, 2019

Looks like lint test is failing on lint because of

terraform_validate ./modules/fabric-net-firewall

Error: "allow": only one of `allow,deny` can be specified, but `allow,deny` were specified.

on main.tf line 112, in resource "google_compute_firewall" "custom":
112: resource "google_compute_firewall" "custom" {

(something not touched in this PR)

Also a bit strange - I don't get that error locally even when using the same developer-tools:0.6.0 version that cloud build is using.

@morgante
Copy link
Contributor

@taylorludwig This might be an issue with automatically pulling in the latest Terraform provider. Maybe try adding a version constraint on the module? https://www.terraform.io/docs/configuration/providers.html#provider-versions

CHANGELOG.md Outdated Show resolved Hide resolved
README.md Outdated
routes = [
{
name = "egress-internet"
routes = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to change this into a map. We can still maintain the desired behavior by constructing the map (for for_each) internally within the module.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, makes sense.

Ill create a local var map with the original default name as the key.

- Routes within vpc network.
- Optionally deletes the default internet gateway routes.

## Compatibility
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need compatibility warnings on each submodule.

main.tf Show resolved Hide resolved
modules/routes/main.tf Show resolved Hide resolved
description = "The subnet resources"
}

output "subnets_names" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove all these unnecessary outputs since we're not directly outputting the resources directly. We can keep them on the root module though.

*/

variable "project_id" {
description = "The ID of the project where this VPC will be created"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please clean up variable descriptions for submodules. In this case, this module doesn't create a VPC at all.

Shared VPC
*****************************************/
resource "google_compute_shared_vpc_host_project" "shared_vpc_host" {
count = var.shared_vpc_host == "true" ? 1 : 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
count = var.shared_vpc_host == "true" ? 1 : 0
count = var.shared_vpc_host ? 1 : 0

description = "The URI of the VPC being created"
}

output "svpc_host_project_id" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could just be project_id, no? (We can/should make it depend on the shared_vpc_host_project resource though.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah seems logical. Updated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look like it still needs to be updated?

}

variable "shared_vpc_host" {
type = string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's take this opportunity to switch to boolean.

@@ -17,3 +17,7 @@
terraform {
required_version = "~> 0.12.0"
}

provider "google" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be a required version constraint, not a direct module invocation.

@taylorludwig
Copy link
Contributor Author

@morgante yep - the lack of provider version in the modules was the problem. I've added that to the main and submodules and linting is passing.

Working on the other comments now.

@taylorludwig
Copy link
Contributor Author

@morgante I believe I addressed all your comments. Tests are all passing again now as well. Thanks!

description = "The name of the network where routes will be created"
}

variable "network" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this redundant with network_name? Don't think we should need both.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just followed the original, single module, functionality. network and subnet resources were added to the depends_on black of the routes to force the depedency.

But passing in just the network_name from the output of the vpc submodule should force that dependency anyways. Ill remove network

default = null
}

variable "subnets" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't need this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its only passed into the depends_on block, functionality that was there before.

Ill remove it and see what happens. I'm not entirely sure if the subnets really do need to be fully created before the routes are created.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's an issue, we could possibly use an output from the subnets module to pass into the network.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least one of the tests fail if we remove this.

When creating a route with a next_hop_ip with an ip inside a subnet it'll error out with the following when the route tries to get created before the subnet is finished.

Error: Error creating Route: googleapi: Error 400: Invalid value for field 'resource.nextHopIp': '10.10.40.10'. 10.10.40.10 must lie within the address spaces of (). multi-vpc-a1-02 does not own any address space. Please create a subnetwork first., invalid

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. In that case, how about we follow the convention we started with network peering and add an explicit module_depends_on variable?

modules/subnets/README.md Outdated Show resolved Hide resolved
modules/subnets/variables.tf Outdated Show resolved Hide resolved
description = "The URI of the VPC being created"
}

output "svpc_host_project_id" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look like it still needs to be updated?

outputs.tf Outdated
description = "The name of the VPC being created"
}

output "network_self_link" {
value = google_compute_network.network.self_link
value = module.vpc.network_self_link
description = "The URI of the VPC being created"
}

output "svpc_host_project_id" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just call this project_id.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you still want it only outputted if shared_vpc_host == true ?

The original logic was svpc_host_project_id would only be outputted if you enabled shared vpc, otherwise it was "".
But outputting just project_id seems like you'd still expect a value even with shared vpc off

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, let's output it in both cases.

Copy link
Contributor

@aaron-lane aaron-lane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One observation after looking at our current documentation.

modules/subnets/variables.tf Show resolved Hide resolved
@morgante morgante requested a review from aaron-lane December 6, 2019 23:29
@morgante morgante merged commit b60f0ab into terraform-google-modules:release/2.0 Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants