-
Notifications
You must be signed in to change notification settings - Fork 342
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
ec2_instance fails if there is no default vpc and no vpc_subnet_id specified #467
Comments
It starts to work if I use the following patch:
although not fully - it creates ec2 instance, but in default availability zone, not the one I specified. |
@nerijus: Greetings! Thanks for taking the time to open this issue. In order for the community to handle your issue effectively, we need a bit more information. Here are the items we could not find in your description:
Please set the description of this issue with this template: |
Hi @nerijus, thank you for raising this issue. I assume you are using a pre 2013 account, could you confirm? Thanks. |
The oldest invoice is from December 3, 2012, so yes, it is pre 2013 account. |
Hi @nerijus. It sounds like your account might have been EC2 Classic originally but your suggestion does not appear to work on my EC2 Classic account. Can you confirm please if you're using VPCs in your account or not? |
I'm trying to reproduce an account setup that would have a default subnet but no default VPC to test with and I'm not seeing how that would work - If I've misunderstood your environment please let me know. |
I would like to use |
And yes, I am using VPCs, as I reported - "when I specify |
We have got emails from aws that EC2 Classic will be deprecated, and it said that we don't have classic resources in our regions. |
* Move ec2_launch_template to standard role-type test * Run elb_application_lb in our standard environment * Move elb_target_info to the standard role structure * add remote_tmp_dir dependency to ec2_launch_template * move test_multiple_actions_fail.yml inside full_test so we don't need to run the prep work twice * Rename the ALBs: "my-alb" isn't helpful and resource prefix is likely to change on us * Ensure ALBs are deleted if "failed" tests created something This commit was initially merged in https://github.com/ansible-collections/community.aws See: ansible-collections/community.aws@887d624
…ns#467) * Move ec2_launch_template to standard role-type test * Run elb_application_lb in our standard environment * Move elb_target_info to the standard role structure * add remote_tmp_dir dependency to ec2_launch_template * move test_multiple_actions_fail.yml inside full_test so we don't need to run the prep work twice * Rename the ALBs: "my-alb" isn't helpful and resource prefix is likely to change on us * Ensure ALBs are deleted if "failed" tests created something This commit was initially merged in https://github.com/ansible-collections/community.aws See: ansible-collections/community.aws@887d624
The order of VPCs when calling describe_vpcs is not guaranteed. Picking what happens to be returned as the first is going to be non-deterministic in accounts with multiple VPCs. If there's no default VPC and no subnet specified I think it's perfectly reasonable for the module to fail. |
But I am talking about situation when "There is only one VPC in the region, but it is not default". So I assume it is safe to return first when there is only one VPC? And yes, if there are multiple VPCs, then it should fail as before. |
Take the simple example that you add a new VPC to your account, suddenly all playbooks relying on that VPC being the only VPC fail. While what you're suggesting would work for your current, specific, use-case (a single VPC, with no VPC marked as default), in my opinion it's not a "good" solution because it adds fragile extra logic while only solving for a very specific edge-case. Managing Security Groups and Instances is already very complex code (due to the massive array of options), adding special cases to try to guess what people want simply makes things unpredictable. The specific case of falling back to the "default subnet" for a specified AZ in the "default VPC" is different because Amazon explicitly ensures it is the only VPC marked as "default" in the region and the only subnet marked as "default" in that availability zone. This in turn means that adding additional VPCs or additional subnets has no unexpected side effects. Additionally, while the AWS Web UI might automatically pick a VPC/subnet for you, it's showing you what it's picked and there's then an explicit confirmation step before you launch the resource. There are already modules which support fetching the information you would need (ec2_vpc_subnet_info), I'd strongly recommend using those so you can be more explicit about the rules you want to follow for picking the subnets. |
I am not sure it is so specific "edge" case, I think there are lots of accounts with one VPC which is not default (because AWS does not allow to mark an existing nondefault VPC as a default VPC). Yes, it will fail if I add another VPC, which I would expect. But I understand that it would add compexity, and if you do not plan to change it, please feel free to close the issue. |
but it should emit a better error message than a backtrace and |
…ns#467) * Move ec2_launch_template to standard role-type test * Run elb_application_lb in our standard environment * Move elb_target_info to the standard role structure * add remote_tmp_dir dependency to ec2_launch_template * move test_multiple_actions_fail.yml inside full_test so we don't need to run the prep work twice * Rename the ALBs: "my-alb" isn't helpful and resource prefix is likely to change on us * Ensure ALBs are deleted if "failed" tests created something
…ns#467) * Move ec2_launch_template to standard role-type test * Run elb_application_lb in our standard environment * Move elb_target_info to the standard role structure * add remote_tmp_dir dependency to ec2_launch_template * move test_multiple_actions_fail.yml inside full_test so we don't need to run the prep work twice * Rename the ALBs: "my-alb" isn't helpful and resource prefix is likely to change on us * Ensure ALBs are deleted if "failed" tests created something This commit was initially merged in https://github.com/ansible-collections/community.aws See: ansible-collections/community.aws@887d624
SUMMARY
There is only one VPC in the region, but it is not default (Default VPC: No). I.e. there is no default VPC at all in this region.
I try to create ec2 instance by using:
It fails with:
The docs at
https://docs.ansible.com/ansible/latest/collections/community/aws/ec2_instance_module.html#parameter-availability_zone
say that availability zone is useful if not specifying the vpc_subnet_id parameter.But it does not work in my case. When I specify
vpc_subnet_id
, it works.ISSUE TYPE
COMPONENT NAME
ec2_instance
ANSIBLE VERSION
The text was updated successfully, but these errors were encountered: