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).
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?
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,
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.
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.
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.
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.
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.