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

Add iam_instance_profile to resource_aws_launch_configuration #371

Merged
merged 1 commit into from
Oct 8, 2014

Conversation

xuwang
Copy link
Contributor

@xuwang xuwang commented Oct 7, 2014

Add optional param iam_instance_profile to resource_aws_launch_configura...tion to support role based AC.
This code change depends on a patch to goamz, see mitchellh/goamz#117

@mitchellh
Copy link
Contributor

LGTM.

mitchellh added a commit that referenced this pull request Oct 8, 2014
providers/aws: Add iam_instance_profile to resource_aws_launch_configuration
@mitchellh mitchellh merged commit 9912ca7 into hashicorp:master Oct 8, 2014
mitchellh added a commit that referenced this pull request Oct 8, 2014
@packplusplus
Copy link

I realize this merge is over a year old, but I need some direction.

  • aws_instance's iam_instance_profile wants aws_iam_instance_profile.name
  • aws_launch_configuration's iam_instance_profile wants aws_iam_instance_profile.arn.

There may be other cases where arguments with the same name require values to have different attribute types, but it seems pretty counter-intuitive to use the same attribute name in different resource types that take different

What would be preferable

  • A new issue to have discussion on how to make this consistent? May extend to a discussion on how to implement breaking changes (or maybe you already have a procedure)
  • A PR for updating the docs explaining how to use iam_instance_profile in either context for the webpage?
  • A PR to make the two resources consistent? This will break existing tf files.
  • A PR to extend both resources to have iam_instance_profile_arn, and you deprecate the existing arguments?

The first two are quick / easy, the next two may need significant code review, go isn't a primary language.

@clstokes
Copy link
Contributor

Hey @packplusplus, I think your 4th option (A PR to extend both resources...) is likely the best option at this point. I'd start with creating an issue to track the inconsistency and then link here for context. Thanks for reporting!

@ghost
Copy link

ghost commented Apr 30, 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 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants