-
Notifications
You must be signed in to change notification settings - Fork 43
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
base: master
Are you sure you want to change the base?
Conversation
}, | ||
}}, | ||
}, | ||
// TODO: Why is this different to list-nested-attribute? Should it be? |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
} | ||
}, | ||
"optional": true, | ||
"type": 5 |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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?
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
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. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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? |
There was a problem hiding this comment.
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?
That's the rub, we need to do work to understand what's right, not to confuse the codebase any further. |
@VenelinMartinov Do we have a path towards merging here? |
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. |
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. |
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! |
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:
Computed
)list-attribute-object-element
andlist-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
andsingle-nested-block
are identical in the shim layer.map-nested-attribute
,list-nested-attribute
and - these are all roughly "Objects" so probably fair.list-nested-block
- my intuition is that these should be "the same" for the shim layer. Any ideas here?