Details
-
Type: Task
-
Status: Closed (View Workflow)
-
Priority: Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: None
-
Labels:None
-
Story Points:0.5
-
Epic Link:
-
Sprint:Spring 9 : 25 May to 8 Jun
Description
Our appstore playbooks automate creation an ec2 instance to host appstore.
This works pretty great, except for the task in which we create a security group for the ec2.
See task "Create security group for {{ ec2_name }}" in https://bitbucket.org/lorainelab/appstore-playbooks/src/master/roles/ec2/tasks/main.yml).
The task is working in that the security group is created correctly with all the proper permissions. However, whenever it runs, there is a very long pause and then a warning message is printed to the console. Also, the task is always listed as having changed even when the security group already exists and is properly configured.
Please look into why this is happening and figure out a way to make this task properly idempotent and execute faster.
Here is the warning message:
TASK [ec2 : Create security group for testappstore] **********************************
[WARNING]: Ran out of time waiting for sg-0c3690afe2c252497 IpPermissions. Current:
, Desired:
[Rule(port_range=(22, 22), protocol='TCP', target='172.31.19.94/32',
target_type='ipv4', description='ip-172-31-19-94'), Rule(port_range=(80, 80),
protocol='TCP', target='0.0.0.0/0', target_type='ipv4', description='allow all on
port 80'), Rule(port_range=(443, 443), protocol='TCP', target='0.0.0.0/0',
target_type='ipv4', description='allow all on port 443')]
changed: [localhost]
Attachments
Issue Links
- is blocked by
-
IGBF-2384 Reorganize folder hierarchy for appstore playbooks
- Closed
A very funny error.... An error occurred due to capitalization of the protocol text as 'TCP' instead of using 'tcp'
Understanding during Root Cause Analysis
There were solutions proposed online on the link https://github.com/ansible/ansible/issues/42661
but in one place they used numbers instead of actual protocol names which also does not work
My understanding is that possibly the module is not designed to handle uppercases in the protocol names, although this was accepted as valid at aws end.
I think time consumed was during the request packet sent from the module not for the response.