# Problems getting EC2 VPC information **URL:** \ **Category:** Ansible Developer\ **Created:** [June 23, 2014, 6:18pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528 "2014-06-23T18:18:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Michael\_Peters](https://avatars.discourse-cdn.com/v4/letter/m/c2a13f/32.png) [@Michael\_Peters](https://forum.ansible.com/u/Michael_Peters)\ **Post date:** [June 23, 2014, 6:18pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/1 "2014-06-23T18:18:08Z")
I'm trying to use the ec2\_vpc module to get the information about an existing VPC (specifically get all of the subnets and their IDs to use later). From reading the docs, I'm not completely sure this is possible since all the docs and examples are assuming you are either creating a VPC or deleting one. Now, I know from having used this module that if you are trying to create the same VPC that already exists (providing the vpc\_id) it will try to do an update based on the other information. And if nothing is changed it will just return the info about that VPC. In this case though I just want to pull the information about an existing vpc without updating it. I was hoping to do this by providing basically no information other than the vpc\_id, the region and the state. The first problem is that not specifying any subnets results in a traceback error ([https://github.com/ansible/ansible/issues/7905](https://github.com/ansible/ansible/issues/7905)). That's pretty simple to fix such that if no subnets are specified than ec2\_vpc just doesn't try to create or update any subnets. This seems like the right fix since if you wanted to delete all of the existing subnets you can just provide an empty list. The next issue is that when you don't provide any route\_tables it will try to delete existing route tables. So if we fix subnets to act as I feel they should, then it makes them inconsistent with how route\_tables currently behave. But if subnets are fixed to act like route\_tables then you can never actually just get information about a VPC without either altering that VPC or having to provide all of the information about the VPC used when creating it. And that kind of defeats the purpose of trying to get the information in the first place. I guess basically it seems to me there should be a difference between not having any subnets or route\_tables specified (just don't do anything to them) vs having them specified as empty lists (delete all existing). Thoughts? ---
**Author:** ![Michael\_Peters](https://avatars.discourse-cdn.com/v4/letter/m/c2a13f/32.png) [@Michael\_Peters](https://forum.ansible.com/u/Michael_Peters)\ **Post date:** [June 23, 2014, 9:24pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/2 "2014-06-23T21:24:06Z")
Given some discussion about the traceback bug I’m not sure my underlying problem was made clear. So I thought I’d bring the discussion back here: It was mentioned that pull request #7327 could be applied to ec2\_vpc, but it isn’t quite what’s needed here either. The problem isn’t the ec2\_vpc doesn’t return enough information when a vpc is created (it returns enough for me at least) it’s that there’s no way to get this information without specifying a whole lot of unnecessary information to begin with. My main example is that when I have a vpc\_id I can’t get information about that VPC without also having to know lots of information about it’s subnets and route\_tables (which is the information I’m trying to get) or else it deletes the subnets and route\_tables. Maybe it’s wrong to ask that a non-existent “subnets” (and “route\_tables”) parameter be treated differently than an empty list. I can see how some folks would be confused about the difference between None and . But it also seems strange that the default is to delete subnets/route\_tables since that seems like an uncommon use case. Should just getting information about a non-host resource on AWS have a different state than “present” or “absent”? Should I look to get this information outside of the ec2\_vpc module (like maybe calling out to the AWS command line directly)? Something else? Thanks, ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [June 24, 2014, 1:30pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/3 "2014-06-24T13:30:26Z")
The ansible modules are usually there to assert a certain state is true, not to generate reports on system or cloud configurations. As such, the original premise is not a thing, ergo, it will complain when parameters are not provided that need to be provided to create the VPC should it not exist. ---
**Author:** ![Michael\_Peters](https://avatars.discourse-cdn.com/v4/letter/m/c2a13f/32.png) [@Michael\_Peters](https://forum.ansible.com/u/Michael_Peters)\ **Post date:** [June 24, 2014, 2:54pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/4 "2014-06-24T14:54:46Z")
> The ansible modules are usually there to assert a certain state is true, not > to generate reports on system or cloud configurations. Yes that's true, but there are exceptions. For instance the stat module and ec2\_facts. I'm not looking to generate a report I'm looking to automate provisioning of servers. Basically I need to put some servers into the private subnet of a VPC, and I can't do that without being able to get the subnet\_id of that subnet in the VPC. But the ec2\_vpc module won't let me get that information without knowing almost everything about the existing subnets to begin with. Chicken meet egg... > As such, the original premise is not a thing, ergo, it will complain when > parameters are not provided that need to be provided to create the VPC > should it not exist. After reading my above do you still think "the original premise is not a thing"? Maybe I should be asking about creating a vpc\_facts or a "info" state to the existing ec2\_vpc module. But in my mind I was thinking about it like say the file module. If I provide an "owner" it uses it. If I don't, it doesn't. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [June 24, 2014, 4:10pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/5 "2014-06-24T16:10:41Z")
We are generally trying to reduce the amount of new “facts” modules because they often have a high degree of overlap between the other configuration modules and usually these variables can be returned by the inventory system. So in this case, one way to do it cleaner might be if the variables for the “all” group returned by the inventory script contained a list of the VPCs it found. ---
**Author:** ![Michael\_Peters](https://avatars.discourse-cdn.com/v4/letter/m/c2a13f/32.png) [@Michael\_Peters](https://forum.ansible.com/u/Michael_Peters)\ **Post date:** [June 24, 2014, 5:31pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/6 "2014-06-24T17:31:40Z")
I agree about not wanting a duplicate fact module for every resource already managed by another module, which is why I initially thought of having an "info" state. I can also see wanting to push EC2 environment information into the EC2 dynamic inventory script. But I'm not sure how that would work really. VPCs (and other resources in EC2 like ELBs, EIPs, Security Groups, etc) aren't hosts. The ec2.py script does currently discover which Security Groups the host belongs to and includes that information in it's facts as well as creating a new group for it. I can see that happening with vpc's pretty easily. But it doesn't include detailed information about those groups (like say their ingress and outgress rules) just their names. I don't need th ename (or even id) of the VPC's I need information about it's subelements. That seems weird to include as a top-level thing and also seems weird to include all that nested information in the hostvars section. But maybe that's just me. Maybe it's just a case where I need to use the local\_action + shell + AWS command line interface to get the facts I want and just document the shortcomings and possible work around in the ec2\_vpc module. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [June 24, 2014, 7:18pm UTC](https://forum.ansible.com/t/problems-getting-ec2-vpc-information/15528/7 "2014-06-24T19:18:57Z")
I’m not really ready to introduce an “info” state into all of the modules, and make that consistent. Packages are particularly detailed, do you return all installed packages, etc. The time may come, but I suspect when it does it will be a seperate namespace for some things. “hat seems weird to include as a top-level thing and also seems weird to include all that nested information in the hostvars section” Returning stuff as variables in the “all” group would not neccessarily mean they were set per host.