ec2_vpc_route_table playbook error was: 'dict object' has no attribute subnet

Archives Ansible Project
1

I have a previously working piece of Ansible that I’ve inherited for a previous contractor, and I’m getting an error message that doesn’t lead me in the right direction. I have tried searching for a few days now, with no joy, and my colleagues can’t figure it out either.

The Ansible in question is :-

- name: Routes | Set up NAT-protected route table
  ec2_vpc_route_table:
    vpc_id: "{{ ec2_vpc_net_reg.vpc.id }}"
    region: "{{ vpc_region }}"
    tags:
      Name: "Internal {{ item.subnet_id }}"
    subnets:
      - "{{ az_to_private_sub[public_subnets_to_az[item.subnet_id]] }}"
      - "{{ az_to_private_data_sub[public_subnets_to_az[item.subnet_id]] }}"
    routes:
      - dest: 0.0.0.0/0
        gateway_id: "{{ item.nat_gateway_id }}"
  loop: "{{ existing_nat_gateways.result|flatten(levels=1) }}"
  #with_items: "{{ existing_nat_gateways.result }}"
  register: nat_route_table
  retry: 2
  delay: 10

And the error message is :-

fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute u'subnet-0facefaceface9'\n\n

The error appears to have been in '/cup/core-kubernetes-linux/ansible/roles/aws_vpc/tasks/routes.yml': line 62, column 3, but may\n

be elsewhere in the file depending on the exact syntax problem.\n\n

The offending line appears to be:\n\n\n

- name: Routes | Set up NAT-protected route table\n

  ^ here\n

"}

I have added some carriage returns to make it a bit more readable.

I have tried adding extra debug, for az_to_private_sub and public_subnet_to_az, and these look OK. I’ve tried reading the docs

Can anyone suggest where I should look next?

Thanks!

2

Use debug statements so that you know what is in “existing_nat_gateways.result” and “public_subnets_to_az”.

It looks to me as if there is no element called “subnet-0facefaceface9” in the dictionary “public_subnets_to_az” (that is a very cool subnet ID by the way).

Regards, K.

3

Yes, the actual subnet id was subnet-0f18a0d4a7e9c7719. I was concerned that putting the subnet ID and other IDs into here might (somehow?) be a security issue. I’ve deleted the whole VPC now, so it won’t be a problem.

Here’s the additional debug (which all looks fine to my eyes!!)

TASK [aws_vpc : Routes | Debug public_subnets_to_az] ***************************************************************************************************************************************
task path: /cup/core-kubernetes-linux/ansible/roles/aws_vpc/tasks/routes.yml:59
ok: [localhost] => {
“public_subnets_to_az”: {
“subnet-0d6f53bad96008956”: “eu-west-1c”
}
}

TASK [aws_vpc : Routes | Debug existing_nat_gateways.result] *******************************************************************************************************************************
task path: /cup/core-kubernetes-linux/ansible/roles/aws_vpc/tasks/routes.yml:74
ok: [localhost] => {
“existing_nat_gateways.result”: [
{
“create_time”: “2019-01-21T15:08:50+00:00”,
“nat_gateway_addresses”: [
{
“allocation_id”: “eipalloc-0b86cd580c67ad534”,
“network_interface_id”: “eni-0907d51d9f17e3ff4”,
“private_ip”: “172.17.3.106”,
“public_ip”: “34.246.20.83”
}
],
“nat_gateway_id”: “nat-01e48244fa76ff742”,
“state”: “available”,
“subnet_id”: “subnet-0d6f53bad96008956”,
“tags”: {},
“vpc_id”: “vpc-07fd6abc9b3c96674”
},
{
“create_time”: “2019-01-21T15:08:47+00:00”,
“nat_gateway_addresses”: [
{
“allocation_id”: “eipalloc-0dd6969c7deb9b616”,
“network_interface_id”: “eni-00a24e6de1b45cdee”,
“private_ip”: “172.17.1.252”,
“public_ip”: “63.34.105.22”
}
],
“nat_gateway_id”: “nat-0fd2bad6baffad428”,
“state”: “available”,
“subnet_id”: “subnet-0f18a0d4a7e9c7719”,
“tags”: {},
“vpc_id”: “vpc-07fd6abc9b3c96674”
},
{
“create_time”: “2019-01-21T15:08:49+00:00”,
“nat_gateway_addresses”: [
{
“allocation_id”: “eipalloc-018a80fb6bd4a2efc”,
“network_interface_id”: “eni-0e8507f1ba250dfb9”,
“private_ip”: “172.17.2.18”,
“public_ip”: “63.34.176.76”
}
],
“nat_gateway_id”: “nat-0fb938e1aa8784738”,
“state”: “available”,
“subnet_id”: “subnet-079e51dbe6bcaf502”,
“tags”: {},
“vpc_id”: “vpc-07fd6abc9b3c96674”
}
]
}

4

I have noticed that when I destroy the VPC and re-run the job the existing nat gateways debug shows as “pending”, even when I show the debug, put in a 20 minute delay and then show the debug again. This seems really odd to me. I even went on to the AWS console and the However, when I re-run the job it shows as “available” and it complains about one of the eu-west-1x-public-subnet (with x being a, b or c). The route table DOES seem to have those three subnets in, but when the job fails, they disappear.