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

Document requirements for running test-kitchen tests #25

Closed
adrienthebo opened this issue Oct 30, 2018 · 4 comments
Closed

Document requirements for running test-kitchen tests #25

adrienthebo opened this issue Oct 30, 2018 · 4 comments

Comments

@adrienthebo
Copy link
Contributor

We need to document the requirements/dependencies for running tests with test-kitchen.

For reference, this is my current set of fixtures:

locals {
  project_name = "thebo-gkefixture"
  project_id   = "${local.project_name}-${random_id.project-suffix.hex}"
}

resource "random_id" "project-suffix" {
  byte_length = 2
}

resource "google_project" "main" {
  name            = "${local.project_name}"
  project_id      = "${local.project_id}"
  folder_id       = "${var.folder_id}"
  billing_account = "${var.billing_account}"
}

resource "google_project_services" "main" {
  project  = "${google_project.main.project_id}"
  services = [
    "compute.googleapis.com",
    "bigquery-json.googleapis.com",
    "container.googleapis.com",
    "containerregistry.googleapis.com",
    "oslogin.googleapis.com",
    "pubsub.googleapis.com",
    "storage-api.googleapis.com",
  ]
}

module "network" {
    source = "github.com/terraform-google-modules/terraform-google-network"

    project_id      = "${google_project.main.project_id}"
    network_name    = "vpc-01"
    //shared_vpc_host = "true"

    subnets = [
        {
            subnet_name   = "us-east4-01"
            subnet_ip     = "10.20.16.0/20"
            subnet_region = "us-east4"
        },
    ]

    secondary_ranges = {
        "us-east4-01" = [
            {
                range_name    = "us-east4-01-gke-01-pod"
                ip_cidr_range = "172.18.16.0/20"
            },
            {
                range_name    = "us-east4-01-gke-01-service"
                ip_cidr_range = "172.18.32.0/20"
            },
            {
                range_name    = "us-east4-01-gke-02-pod"
                ip_cidr_range = "172.18.48.0/20"
            },
            {
                range_name    = "us-east4-01-gke-02-service"
                ip_cidr_range = "172.18.64.0/20"
            },
        ]
    }
}
@Jberlinsky
Copy link
Contributor

For posterity, this is related to #20 (comment)

The issue here is that the test case you were running spins up a node pool with 100 machines. From the docs:

The Pod range as determined by the --cluster-ipv4-cidr or --cluster-secondary-range-name flags must be at least large enough to fit (total number of nodes × 256) IP addresses.

So, in this case, 100 * 256 = 25,600 IP addresses required, whereas a /20 CIDR only fits 4,096. You'd need a /14 block.

As to resolution, I'm open to considering this a fixture setup issue (which should be thoroughly documented, to prevent it from happening to others), or to reducing the number of nodes that the test case in question expects to bring up, as 100 nodes is certainly not an average case.

@morgante
Copy link
Contributor

Can we simply document that requirement as the first step?

@Jberlinsky
Copy link
Contributor

Jberlinsky commented Oct 30, 2018

@morgante I'm open to that iterative solution, but I think there's a larger conversation to be had here about repeatable testing. As we were talking about, we should probably focus on making sure that nobody has trouble running tests -- I'm of the belief that providing network fixtures is the least-bad way to handle this.

EDIT: Addressing this here: #20 (comment)

@Jberlinsky
Copy link
Contributor

This was covered in #33. Closing.

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

No branches or pull requests

3 participants