Skip to content
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

provider/aws: New resource: aws_security_group_attachment #15167

Closed

Conversation

vancluever
Copy link
Contributor

This adds the aws_security_group_attachment resource, allowing one to attach security groups to ENIs outside of an aws_instance or aws_network_interface resource.

Use cases:

  • More granular management of security groups
  • Attachment of security groups to instances not managed by Terraform (the use case that prompted me to write this)

Docs and tests included!

Chris Marchesi added 5 commits June 7, 2017 10:55
... by removing instance_id. It just dawned on me that one can simply
reference the primary_network_interface_id from the aws_instance
resource to get the same effect. This removes a bunch of unnecessary
logic from the resource, and makes things explicit in what you are
supposed to do.
And added into provider.go. Just docs remaining now.
This will probably be one of the more used use cases, as it allows TF to
hook a security group into an instance or ENI not necessarily managed by
Terraform, where you don't necessarily want to manage instance
lifecycle.
Two examples: one with a full-managed instance, and one that works
through the data source.
vancluever pushed a commit to paybyphone/terraform-provider-aws that referenced this pull request Jun 14, 2017
This is a transfer of work from hashicorp/terraform#15167.

This adds the aws_security_group_attachment resource, allowing one to
attach security groups to ENIs outside of an aws_instance or
aws_network_interface resource.

Use cases for this would include more granular management of security
groups, or attachment of security groups to instances that are managed
out-of-band from Terraform.
@vancluever
Copy link
Contributor Author

Closing this in favour of hashicorp/terraform-provider-aws#860.

@vancluever vancluever closed this Jun 14, 2017
radeksimko pushed a commit to hashicorp/terraform-provider-aws that referenced this pull request Jun 29, 2017
* New resource: aws_security_group_attachment

This is a transfer of work from hashicorp/terraform#15167.

This adds the aws_security_group_attachment resource, allowing one to
attach security groups to ENIs outside of an aws_instance or
aws_network_interface resource.

Use cases for this would include more granular management of security
groups, or attachment of security groups to instances that are managed
out-of-band from Terraform.

* aws_security_group_attachment -> aws_network_interface_sg_attachment

Renamed as pre review comments in #860. This should help differentiate
it between the other kinds of security groups available in the AWS
provider.

* resource: network_interface_sg_attachment: Require network_interface_id

This attribute was set to optional back when this resource allowed
either an instance or network interface specified. Now that this is no
longer the case, there's no reason to keep it this way.

* resource/aws_network_interface_sg_attachment: refactor tests

Make the test configs a bit easier to understand. Each case (via
resource or data source) now has its own config, but we still
parameterize on enabling/disabling the security group resource for the
removal check.

* resource/aws_network_interface_sg_attachment: Add locks, fix races

The resource was actually racing when there was multiple attachments
trying to work with the same network interface. This is fixed now with
locks added in create and delete.

The added test checks the race in a couple of steps, switching up the
resource names on the second run for the security groups and security
group attachments to get a good mix of creation and deletion events to
really test the effectiveness of the serialization.

Also a small cosmetic re-refactoring of test names and configuration
generation functions.

* resource/aws_network_interface_sg_attachment: Simplify interface check

Simplified the interface check function so that the test case directly
takes the attribute that we are deriving the interface ID from, rather
than taking a bool. This actually uncovered the fact my attribute logic
was reversed (the bool logic was giving primary_network_interface_id for
a false value passed to checkPrimaryInterfaceAttr instead of a true
value, and this error was propagated to the test cases). So this is
fixed now as well.

* resource/aws_network_interface_sg_attachment: Simplify race check

Race check needed simplifying as well, in addition to being reduced from
two steps to one.

Reason for the latter is once security groups were modified so that the
were operating off the same set of groups in both steps (so step1 ->
step2), it was discovered that there was no way we could reasonably
expect the deletion/creation order would never favour a situation where
the new SG attachment would be ordered after the old SG attachment was
removed (as both step1 destroys and step2 creations would be happening
at the same level in the graph and without any dependencies).

* resource/aws_network_interface_sg_attachment: Flatten some code

Removed a bunch of the single-use functions, which has moved most logic
to the main CRUD functions. The old functions served a purpose when this
resource was designed to support both instance IDs and network interface
IDs, but just adds more cruft now that only network interface IDs are
supported.

Also moved all the messages to the DEBUG level as TF_LOG=info does not
mean anything at a provider level, currently.
@ghost
Copy link

ghost commented Apr 8, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants