ansible-collections / ansible-collections/google.cloud
Error Handle for not allowing to shrink CIDR for gcp subnet
- Dominant language
- Python
- Stars
- 105
- Forks
- 144
- Avg merge
- 5d 10h
- Merged PRs (30d)
- 4
Description
##### SUMMARY
GCP doesn't allow to shrink of the CIDR of a subnet but the original module doesn't throw an error if the requested new CIDR is not a superset of the original IP range. So I suggest adding a condition check and error out for this scenario.
Many years ago there was a similar issue reported but closed due to the old ansible module getting migrated to Galaxy Collection
https://github.com/ansible/ansible/issues/63348
When there are no changes ansible still shows that the configuration has been changed. Diff on the debug output from 3 consecutive run shows no differences.
##### ISSUE TYPE
- Bug Report
##### COMPONENT NAME
plugins/modules/gcp_compute_subnetwork.py
##### ANSIBLE VERSION
```paste below
ansible [core 2.14.2]
config file = /Users/x/proj/hands-on/ansible/sbn-bug-ansible/playbooks/ansible.cfg
configured module search path = ['/Users/x/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/local/lib/python3.9/site-packages/ansible
ansible collection location = /Users/x/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/local/bin/ansible
python version = 3.9.16 (main, Dec 7 2022, 10:16:11) [Clang 14.0.0 (clang-1400.0.29.202)] (/usr/local/opt/python@3.9/bin/python3.9)
jinja version = 3.0.1
libyaml = True
```
##### COLLECTION VERSION
```paste below
google.cloud 1.1.2
```
##### CONFIGURATION
```paste below
nothing special, just local ansible.cfg
```
##### OS / ENVIRONMENT
MacOS 13.0 (22A380)
##### STEPS TO REPRODUCE
#A1: create a network vpc-a
#A2: create a subnetwork {{ sbn_name }} in vpc-a
#A3: shrink the CIDR for {{ sbn_name }}
#A4: Collect fact about subnet {{ sbn_name }}
#A5: Show subnet info {{ sbn_name }}
```yaml
---
- name: Define variables
set_fact:
project: your-project-name
region: us-east4
gcp_auth_kind: application
sbn_name: subnet-a
- name: "#A1: create a network vpc-a"
google.cloud.gcp_compute_network:
name: "vpc-a"
auto_create_subnetworks: 'false'
project: "{{ project }}"
auth_kind: "{{ gcp_auth_kind }}"
state: present
register: network_a
- name: "#A2: create a subnetwork {{ sbn_name }} in vpc-a"
google.cloud.gcp_compute_subnetwork:
name: "{{ sbn_name }}"
region: "{{ region }}"
network: "{{ network_a }}"
ip_cidr_range: 172.16.0.0/20
project: "{{ project }}"
auth_kind: "{{ gcp_auth_kind }}"
state: present
- name: "#A3: shrink the CIDR for {{ sbn_name }}"
google.cloud.gcp_compute_subnetwork:
name: "{{ sbn_name }}"
region: "{{ region }}"
network: "{{ network_a }}"
ip_cidr_range: 172.16.0.0/21
project: "{{ project }}"
auth_kind: "{{ gcp_auth_kind }}"
state: present
- name: "#A4: Collect fact about subnet {{ sbn_name }}"
gcp_compute_subnetwork_info:
filters:
- network = "{{ network_a.selfLink }}"
- name = {{ sbn_name }}
auth_kind: "{{ gcp_auth_kind }}"
project: "{{ project }}"
region: "{{ region }}"
register: subnet_facts
- name: "#A5: Show subnet info {{ sbn_name }}"
debug:
msg:
- "{{ subnet_facts }}"
```
##### EXPECTED RESULTS
Since GCP API doesn't allow such CIDR shrink, Step #A4 should through such error but actually not, instead, report the status as changed but didn't shrink the CIDR
##### ACTUAL RESULTS
Actually, the original doesn't validate the new CIDR is invalid, doesn't throw any error, instead, reports the status as changed but didn't shrink the CIDR.
```paste below
changed: [localhost] => {
"changed": true,
"creationTimestamp": "2023-03-02T15:24:06.150-08:00",
"fingerprint": "Nz33qz_KLmw=",
"gatewayAddress": "172.16.0.1",
"id": "4466064884805439225",
"invocation": {
"module_args": {
"auth_kind": "application",
"description": null,
"env_type": null,
"ip_cidr_range": "172.16.0.0/21",
"name": "subnet-a",
"network": {
"ansible_facts": {
"discovered_interpreter_python": "/usr/local/bin/python3.11"
},
"autoCreateSubnetworks": false,
"changed": false,
"creationTimestamp": "2023-03-02T15:23:11.142-08:00",
"failed": false,
"id": "2905869197935153456",
"kind": "compute#network",
"name": "vpc-a",
"networkFirewallPolicyEnforcementOrder": "AFTER_CLASSIC_FIREWALL",
"routingConfig": {
"routingMode": "REGIONAL"
},
"selfLink": "https://www.googleapis.com/compute/v1/projects/xx-demo/global/networks/vpc-a",
"selfLinkWithId": "https://www.googleapis.com/compute/v1/projects/xx-demo/global/networks/2905869197935153456",
"subnetworks": [
"https://www.googleapis.com/compute/v1/projects/xx-demo/regions/us-east4/subnetworks/subnet-a"
],
"warnings": [
"Platform darwin on host localhost is using the discovered Python interpreter at /usr/local/bin/python3.11, but future installation of another Python interpreter could change the meaning of that path. See https://docs.ansible.com/ansible-core/2.14/reference_appendices/interpreter_discovery.html for more information."
]
},
"private_ip_google_access": null,
"private_ipv6_google_access": null,
"project": "xx-demo",
"region": "us-east4",
"scopes": [
"https://www.googleapis.com/auth/compute"
],
"secondary_ip_ranges": null,
"service_account_contents": null,
"service_account_email": null,
"service_account_file": null,
"state": "present"
}
},
"ipCidrRange": "172.16.0.0/20",
"kind": "compute#subnetwork",
"name": "subnet-a",
"network": "https://www.googleapis.com/compute/v1/projects/xx-demo/global/networks/vpc-a",
"privateIpGoogleAccess": false,
"privateIpv6GoogleAccess": "DISABLE_GOOGLE_ACCESS",
"purpose": "PRIVATE",
"region": "https://www.googleapis.com/compute/v1/projects/xx-demo/regions/us-east4",
"selfLink": "https://www.googleapis.com/compute/v1/projects/xx-demo/regions/us-east4/subnetworks/subnet-a",
"stackType": "IPV4_ONLY"
}
```
Contributor guide
Research direction
Start in plugins/modules/gcp_compute_subnetwork.py and trace how ip_cidr_range is handled during updates. Reproduce the supplied playbook, especially the change from 172.16.0.0/20 to 172.16.0.0/21, and verify that an invalid CIDR shrink fails instead of reporting a false change. Confirm that valid subnet updates and unchanged runs retain their expected behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ansible, gcp, python
- Domain
- cloud, networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100