-
Notifications
You must be signed in to change notification settings - Fork 398
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
ACM module has no "check" mode #451
Comments
Files identified in the description: If these files are inaccurate, please update the |
Files identified in the description:
If these files are inaccurate, please update the |
Ah, woops. I never use check mode myself, so I forgot to put this in. What's check mode supposed to do? Just check the input parameters match the module spec? Or should it check that it can find IAM credentials? Some boto calls allow you to do a "dry_run" to check that you've got sufficient IAM permissions, but I expect that this particular call does not. |
@matt-telstra See https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html Yes, check mode and dry run are the same thing. If the boto call doesn't support dry run directly, the module would probably need simulate it in some other way. Having a module that affects changes when it's not supposed to will result in a never-ending litany of bug reports. |
For testing in my own projects (outside of Ansible), I use moto. I suppose I could just turn on moto and do the checks that way? I'm not sure whether other Ansible AWS modules use moto. That would add a dependency to the module. Is that worth it? |
It looks like some modules only check the input. Others say @jillr what do AWS modules normally do in check mode? Just validate the input? Or is there a helper function I can call to check IAM credentials? Would we expect an AWS task to fail in check mode if no IAM credentials can be found? |
Is this the kind of thing we need? (I haven't created a PR yet, because I haven't written the tests for this, or tested it manually, yet) |
The idea of "check_mode" is generally to tell you if changes would be made.
The most common way to do this is just to exit with changed=True or return
True from a function (depending on the structure of the module) just before
you'd apply a change. Generally read-only (get, list or describe) calls
should still happen.
Please note, the Boto/AWS check mode only tests permissions, not if a
change would occur, and is especially useless on read-only operations.
|
Can someone confirm that these integration tests cover the functionality that needs to be added? |
@mdavis-xyz Those tests look right at first glance. Normally we write the tests using a separate assert statement rather than "failed_when", this makes the logic a little simpler to flow since you can write it in the positive rather than the negative
|
… default value for instance_type (ansible-collections#587) ec2_instance: Fix launch template condition, handle launch template - default value for instance_type SUMMARY The launch_template option in ec2_instance has a broken condition. Also the launch_template option defaults the instance_type to t2.micro if not specified and ignores the instance_type specified in the launch_template as said in the issue ansible-collections#451. Fixes ansible-collections#451 ansible-collections#462 ISSUE TYPE Bugfix Pull Request COMPONENT NAME ec2_instance ADDITIONAL INFORMATION The change does not break existing functionality as tested by the integration test run locally. Related to the condition fix in community.aws: ansible-collections#111 Ran the following playbook to verify the change. # create a launch template called "test-launch-template" - name: create test launch template community.aws.ec2_launch_template: template_name: test-launch-template image_id: ami-002068ed284xxxxxx instance_type: t3a.small network_interfaces: - associate_public_ip_address: no delete_on_termination: yes device_index: 0 groups: - sg-xxxxxxxxxxxxxxxxxx subnet_id: subnet-xxxxxxxxxxxxxxxxxx region: us-east-2 block_device_mappings: - device_name: /dev/sdb ebs: volume_size: 5 volume_type: gp3 delete_on_termination: true encrypted: yes - device_name: /dev/sdc ebs: volume_size: 2 volume_type: gp2 delete_on_termination: true encrypted: no tags: ssome: tags # launch a ec2 instance using launch template created earlier - launches t3a.small instance as expected - name: test launch template usage ec2_instance: wait: yes name: "test-instance-mk-t3a.small" launch_template: name: test-launch-template vpc_subnet_id: subnet-xxxxxxxxxxxxxxxxxx # launch ec2 instance using launch template created earlier - override instance type to be launch to t3.xlarge - name: test launch template usage - override instance type ec2_instance: wait: yes name: "test-instance-mk-t3.xlarge" instance_type: t3.xlarge launch_template: name: test-launch-template vpc_subnet_id: subnet-xxxxxxxxxxxxxxxxxx Reviewed-by: Jill R <None> Reviewed-by: Markus Bergholz <[email protected]> Reviewed-by: Emanuele Leopardi <None> Reviewed-by: Alina Buzachis <None> Reviewed-by: None <None>
SUMMARY
When running a playbook in check mode, changes are affected.
ISSUE TYPE
COMPONENT NAME
aws_acm
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
STEPS TO REPRODUCE
Full playbook is at https://gist.github.com/dale-c-anderson/31c6212e8a9e86f4a829e2bdee40a6f8
The relevant portion is reproduced here:
Ran the above with
EXPECTED RESULTS
Certificate import should only be simulated.
ACTUAL RESULTS
Certificate was actually imported.
The text was updated successfully, but these errors were encountered: