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

Make Taint command use Resource Address #12289

Closed

Conversation

huydinhle
Copy link

@huydinhle huydinhle commented Feb 27, 2017

Issue

Doc Update

  • I don't think we need doc update on the website, but we can clarify it if we really need to
  • I think the release note should be enough for this issue

Relevant Terraform version

  • This is not urgent to be deployed immediately
  • It can wait for the next release of terraform

About Acceptance Test.

  • I'll be running acceptance test in aws
  • I'm still working on writing the acceptance test for this code

Questions

  • Do I need to run acceptance test on Azure and Google also?
  • I ran the acceptance on aws and found no problem, should I save the log and report it here?
    @heraclmene @apparentlymart

@huydinhle huydinhle changed the title make use of resource address inside of taint command Make Taint command use Resource Address Feb 27, 2017
@huydinhle huydinhle force-pushed the taint-resource-addresses branch 5 times, most recently from ada25d4 to 9b68a38 Compare March 1, 2017 18:59
@huydinhle huydinhle force-pushed the taint-resource-addresses branch 2 times, most recently from 67641be to 1ddb236 Compare March 4, 2017 05:40
@josephholsten
Copy link
Contributor

@apparentlymart seems like this is a breaking change, but wanted: #11045 (comment)

@apparentlymart
Copy link
Contributor

Indeed this seems like a good change for consistency, and I think the breaking change shouldn't be too bad since the resource address syntax is pretty similar to what we previously expected, some details notwithstanding.

We don't actually expect acceptance tests for this sort of core functionality, in the same sense as we would for providers, but rather they are usually tested via a mixture of command-line-level tests in the command package and internal-ish tests in the terraform/context_*_test.go tests.

I think this change is definitely a good idea though I think it might be a little close to 0.10 to add it to the scope of that release now. I'll pencil it in to the list and we'll see if we have time to look at it in more detail before the release. If not, we'll look at it for a later release.

Thanks for working on this, @huydinhle!

@huydinhle
Copy link
Author

@apparentlymart no problem at all!

Copy link
Contributor

@apparentlymart apparentlymart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @huydinhle! Thanks again for the great work here and sorry I let it sit here for so long.

I've left some feedback inline. I understand that I've kept you waiting for a while here, so if you're unable to respond to this feedback there's no worries at all; I can plan to work on these remaining asks to get this ready if you no longer have time.

} else {
module = "root." + module
resourceAddressStr = "module.root.module." + module + "." + name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For resource addresses we actually don't expect any prefix for the root module. That is, a resource aws_instance.baz in the root module just has the resource address aws_instance.baz rather than module.root.aws_instance.baz. The module.blah. prefix is only used to traverse through child modules.

I think we could actually drop support for the -module flag here, given that we're considering this a breaking change anyway. Tainting a resource in a child module can be expressed as terraform taint module.foo.aws_instance.baz once we're using the standard resource address syntax.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@apparentlymart Can you help me on this since I haven't worked on this for a while? If I don't put use module.root.aws_instance.bazas resource address then when I call terraform.ParseResourceAddress(resourceAddressStr) always give me rsa.Path = [] in turns make the state.ModuleByPath retun nil ---> making taint can't find resource state

command/taint.go Outdated
return c.allowMissingExit(name, module)
}
// Get resource type from name
resourceType := strings.Split(name, ".")[0]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm understanding correctly, this information is available in rsa.Type, and so we shouldn't need to extract it and pass it around as a separate argument.

// If there are no resources in this module, it is an error
if len(mod.Resources) == 0 {
return nil, fmt.Errorf(
"The module %s has no resources. There is nothing to taint.", module)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this error message was from before you did some refactoring... with the current approach, it's not guaranteed that the caller here is retrieving the resource state in order to taint it.

Given that this function is general and in core, I'd suggest that rather than returning an error we instead return nil in all of these error cases and then produce suitable error messages in the UI code, where we have more context available about what operation is being performed.

@huydinhle
Copy link
Author

huydinhle commented Jun 29, 2017

@apparentlymart I would love to be able to finish the PR unless we are in a rush to have PR in. My bad for getting back to you late.

@apparentlymart
Copy link
Contributor

Hi @huydinhle!

By all means you are welcome to finish this yourself! The only slight time pressure here is that the next 0.10 beta is likely to represent a feature freeze, so I'd ideally like to land this in the next week or so, to make sure there's enough runway to get it in there. However, I don't expect you to rush to meet our schedule! If all else fails, we can include it in a future release.

Thanks again!

@huydinhle huydinhle force-pushed the taint-resource-addresses branch 5 times, most recently from c58d747 to a8f9c09 Compare July 9, 2017 20:35
@huydinhle
Copy link
Author

@apparentlymart I think I addressed all the comments. Can you let me know if I need to do anything else. I would try to be actively working on this PR to get it merged. Thank you !

@apparentlymart
Copy link
Contributor

Hi @huydinhle! Sorry for the long silence.

Unfortunately I didn't see your comment here until today 😖 and so I missed reviewing this for the 0.11 release too.

I've labelled this with breaking-change to remind us to look at it again for merging as part of the forthcoming 0.12 release. Since this changes some behavior of terraform taint we need to wait for a major release to give users a chance to update any automation they may have built around this command that depends on the old usage.

Sorry again for not noticing your updates and comment here before. This is a change I'm excited to merge since indeed the current difference in usage of this command is very confusing.

@mochi99999
Copy link

Any updates on this? Just wanted to follow up as we recently ran into this issue on my team with the terraform taint resource addressing.

@huydinhle
Copy link
Author

@apparentlymart it's no problem at all, I would love to continue to work on this PR to get it merged. Please let me know if anything else need to be done

@huydinhle
Copy link
Author

@sonnyvan let's wait for the next steps from Terraform team 😄

huydinhle and others added 2 commits March 1, 2018 17:41
Previously:
Plan or Apply command UI is "terraform plan -target=aws_instance.kafka[0]" would work. However, that convention does not work with taint command because taint does not make use of resourceAdress. Example:
  $ terraform taint aws_instance.kafka[0]
  The resource aws_instance.kafka[0] couldn't be found in the module root

These changes will make taint to follow the same convention with other commands. Example:
  ./terraform taint aws_instance.web[0]
  The resource aws_instance.web[0] in the module root has been marked as tainted!
@huydinhle
Copy link
Author

@apparentlymart I haven't touched base with terraform in a while, can you give me some help to finish this PR ? thank you

@pietermees
Copy link

@apparentlymart is this making it into 0.12?

@apparentlymart
Copy link
Contributor

Hi all! Sorry for the long silence here.

The work for v0.12 includes some significant changes to how state is modeled internally, and so we will need to change the implementation of the terraform taint command anyway in order to update it for the new internal models. When we make those changes we'll also adapt the work from this PR so that it'll use the standard resource address syntax, and merge all of these changes together.

@apparentlymart
Copy link
Contributor

Hi again @huydinhle! Sorry for the long silence here.

The work for 0.12 in the end included writing a new parser for the resource address syntax that uses the same underlying mechanism as the configuration language itself. That means that resource addresses will always use the same syntax as references within the configuration.

Unfortunately as a result of this the taint command implementation changed a lot. While fixing that, we integrated the new parser and removed the -module option at the same time, which integrated the effect of your PR but written in a different way. This is why the changes in this PR are now conflicting with master.

I'm sorry that the changes here led to an independent implementation of what you implemented, rather than an adaptation of what you wrote as I originally suggested. I'm very grateful for the time you spent on this PR, and the discussions we had about it informed the design of the new implementation.

Since the functionality of this PR is now in master, I'm going to close this out. Thanks again for working on this, and I'm sorry again that the v0.12 work came into conflict with what you'd implemented here.

@ghost
Copy link

ghost commented Mar 31, 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 Mar 31, 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.

6 participants