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

data sources with indexed references to managed resources #26458

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

jbardin
Copy link
Member

@jbardin jbardin commented Oct 1, 2020

If a data source refers to a indexed managed resource instance, we need to
re-target that reference to the containing resource for planning. Since
data sources use the same mechanism as depends_on for managed resource
references, they can only refer to resources as a whole.

If a data source refers to a indexed managed resource, we need to
re-target that reference to the containing resource for planning.  Since
data sources use the same mechanism as depends_on for managed resource
references, they can only refer to resources as a whole.
@jbardin jbardin requested a review from a team October 1, 2020 18:10
@jbardin jbardin force-pushed the jbardin/data-ref-index branch from 74b903e to 78322d5 Compare October 1, 2020 18:10
@codecov
Copy link

codecov bot commented Oct 1, 2020

Codecov Report

Merging #26458 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted Files Coverage Δ
terraform/transform_reference.go 90.09% <100.00%> (+0.22%) ⬆️
dag/marshal.go 54.79% <0.00%> (+1.36%) ⬆️

resAddr = s
case addrs.ResourceInstance:
resAddr = s.Resource
r.Subject = resAddr
Copy link
Contributor

Choose a reason for hiding this comment

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

More a question: reading this movement from the previous block, this appears to be the addition that has changed things (changing the subject). What happened here? Reading the PR summary, I was looking for some change to reading ManagedResourceMode but that behavior hasn't changed (but please correct my reading!): you go from checking == for ManagedResourceMode to != and a continue ... so this behavior is the same as the earlier block.

Copy link
Contributor

@pselle pselle Oct 2, 2020

Choose a reason for hiding this comment

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

I think this is the relevant bit in the PR summary?

we need to re-target that reference to the containing resource for planning

But I'm also interested in this change from == to != ... is it doing anything I'm not seeing? (not saying to revert this part of the change, this continue might make things make more logical sense to future readers)

Copy link
Member Author

@jbardin jbardin Oct 2, 2020

Choose a reason for hiding this comment

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

Yes, the r.Subject = resAddr is the key change here. The problem was that when the reference was to an indexed resource instance, that wouldn't match up with the resource addresses used for depends_on when building the plan graph, since there are no individual instances at that point. This prevented the data source from being connected to the resource during planning, and allowing the data source to be read earlier than expected.

You correct that the resAddr.Mode != addrs.ManagedResourceMode logic didn't change. I believe I had some more code in here that made a difference during the refactor (and made it longer, instigating moving it to another method), but the append logic did end up being the same in the end.

@jbardin jbardin merged commit 3268119 into master Oct 2, 2020
@jbardin jbardin deleted the jbardin/data-ref-index branch October 2, 2020 17:27
@ghost
Copy link

ghost commented Nov 2, 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 as resolved and limited conversation to collaborators Nov 2, 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.

2 participants