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 more shim layer tests for pf #2231

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

VenelinMartinov
Copy link
Contributor

Follow-up on #2187 with missing PF attribute/block types.

Looks like the shim layer does indeed lose information, unlike in sdkv2. Wondering how much of it is essential:

  • the distinction between block and attribute seems to be lost. Perhaps intentional but it is meaningful in PF (ex. blocks can't be Computed)
  • list-attribute-object-element and list-nested-attribute are the same. As far as I can tell, these are pretty much the same thing on the PF side, so fair.
  • object-attribute, single-nested-attribute and single-nested-block are identical in the shim layer.
  • These are also identical to the nested object in a map-nested-attribute, list-nested-attribute and - these are all roughly "Objects" so probably fair.
  • Interestingly these are all different from the nested object in a list-nested-block - my intuition is that these should be "the same" for the shim layer. Any ideas here?

},
}},
},
// TODO: Why is this different to list-nested-attribute? Should it be?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is this expected? I wonder why the list-nested-attribute has 2 more layers of nesting in the shim layer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, this is probably elemSchemas

func elemSchemas(sch shim.Schema, ps *SchemaInfo) (shim.Schema, *SchemaInfo) {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or not, elemSchemas is called after the shim schema is constructed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Found it in

func (s *attrSchema) Elem() interface{} {

vs blocks:

func (s *blockSchema) Elem() interface{} {

Trying to see what happens if attr shims match the block ones here: #2232

Copy link
Contributor Author

@VenelinMartinov VenelinMartinov Jul 23, 2024

Choose a reason for hiding this comment

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

Explored further in #2232, seems plausible that these should actually match and the attribute one seems wrong here. Wondering how this affects schema.go

Copy link
Member

Choose a reason for hiding this comment

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

Did you reach a conclusion here?

Copy link

codecov bot commented Jul 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.66%. Comparing base (7ccdd03) to head (e46106b).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #2231   +/-   ##
=======================================
  Coverage   60.66%   60.66%           
=======================================
  Files         356      356           
  Lines       46447    46447           
=======================================
  Hits        28176    28176           
  Misses      16711    16711           
  Partials     1560     1560           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

}
},
"optional": true,
"type": 5
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note this is a list type - this means that the CastToTypeObject

func CastToTypeObject(tfs shim.Schema) (shim.SchemaMap, bool) {
is wrong for both PF and SDKv2 - list types CAN have a resource elem in PF, like in SDKv2

This is the root cause of #2180 fixed in #2181

Copy link
Member

Choose a reason for hiding this comment

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

Is this out of date?

@VenelinMartinov VenelinMartinov requested a review from a team July 23, 2024 10:40
VenelinMartinov added a commit that referenced this pull request Jul 23, 2024
Fixes an issue with the SDKv2 and PF input extraction. During import we
wrongly return values for properties which are fully computed which
causes invalid programs to be generated.

~The object check in `CastToTypeObject` was wrong for SDKV2 objects:
https://github.com/pulumi/pulumi-terraform-bridge/blob/48fd41bd16e2f7f933bb9390ab7619d52faabb6d/pkg/tfshim/util/types.go#L36~

The `CastToTypeObject` object check is wrong for both SDKv2 and PF. For
the SDKV2 only sets and lists can have a `Resource` `.Elem`. For PF it
list-nested blocks are represented with a `Resource` `.Elem` in the shim
layer, so the check did not catch these. PF details here:
#2231
This fixes the check and adds regression tests for the broken imports
which resulted from 2180.

Test coverage added in
#2224 for sdkv2
and #2225 for pf.
fixes #2180
depends on pulumi/providertest#91
stacked on #2225
@t0yv0
Copy link
Member

t0yv0 commented Aug 8, 2024

I'm running a bit out of time to review this @VenelinMartinov this week but I think I can take some time next week to work through and get the gory details right here.

Copy link
Member

@iwahbe iwahbe left a comment

Choose a reason for hiding this comment

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

As long as the tests have comments explaining what is "correct" vs just locking in current behavior, I'm happy to merge.

}
},
"optional": true,
"type": 5
Copy link
Member

Choose a reason for hiding this comment

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

Is this out of date?

},
}},
},
// TODO: Why is this different to list-nested-attribute? Should it be?
Copy link
Member

Choose a reason for hiding this comment

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

Did you reach a conclusion here?

@t0yv0
Copy link
Member

t0yv0 commented Aug 9, 2024

As long as the tests have comments explaining what is "correct" vs just locking in current behavior, I'm happy to merge.

That's the rub, we need to do work to understand what's right, not to confuse the codebase any further.

@mjeffryes mjeffryes added this to the 0.108 milestone Aug 16, 2024
@mikhailshilkov mikhailshilkov removed this from the 0.108 milestone Aug 21, 2024
@iwahbe
Copy link
Member

iwahbe commented Sep 10, 2024

@VenelinMartinov Do we have a path towards merging here?

@VenelinMartinov
Copy link
Contributor Author

I believe we should merge this as is.

The shim layer is confusing and ambiguous and it is seems at least some of its behaviour is not intentional.

This PR does not fix that but it provides us with an easy to use reference for some of the shim layer behaviour. We should separately spend more time in cleaning up the shim layer, potentially explore #2232 and other ways of making the shim layer behaviour understandable.

@VenelinMartinov
Copy link
Contributor Author

Moreover, I think anyone who changes the shim layer behaviour should do that very intentionally, so should be fine to re-record some tests which are noted to have questionable conclusions.

@iwahbe
Copy link
Member

iwahbe commented Sep 16, 2024

Moreover, I think anyone who changes the shim layer behaviour should do that very intentionally, so should be fine to re-record some tests which are noted to have questionable conclusions.

I agree. Let's merge.

@t0yv0
Copy link
Member

t0yv0 commented Oct 1, 2024

AS time permits, could we rebase on #2456 and have another peek at the interesting bits with the generated Pulumi Schema side-by-side? Could be a good learning experience. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants