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

Stop silently converting map Elem from Resource to TypeString #78

Closed
josephholsten opened this issue Jun 16, 2017 · 5 comments
Closed
Labels
enhancement New feature or request technical-debt

Comments

@josephholsten
Copy link
Contributor

Proposed resolution: modify all the schemas which use Type: TypeMap with Elem: Resource; then tighten this validation in getValueType()

Arguably a follow on to hashicorp/terraform#12638

In helper/schema/schema.go:getValueType we see:

if _, ok := schema.Elem.(*Resource); ok {
	// TODO: We don't actually support this (yet)
	// but silently pass the validation, until we decide
	// how to handle nested structures in maps
	return TypeString, nil
}

This has allowed us to write a provider which looks like it's actually validating its elements, but does no such thing.

return &schema.Resource{
	Schema: map[string]*schema.Schema{
		"create_vnic_details": {
			Type:     schema.TypeMap,
			Optional: true,
			Elem: &schema.Resource{
				Schema: map[string]*schema.Schema{
					"assign_public_ip": {
						Type:     schema.TypeBool,
						Optional: true,
					},
				},
			},
		},
	},
}

I do notice this was originally introduced by @radeksimko in hashicorp/terraform@1df1c21

Expected Behavior

getValueType() should have returned an error like "create_vnic_details: unexpected map value type: schema.Resource"

Actual Behavior

Silently allowed using create_vnic_details.assign_public_ip but instead of rendering as "true" or "false", renders as "1" or "0"

Steps to Reproduce

I can do an actual test of this if desired.
Create a provider with the above schema, then use to access create_vnic_details.assign_public_ip

@josephholsten
Copy link
Contributor Author

oh, I'd argue the correct solution is for me to go and fix all the providers which are broken. I'm not saying we should just remove the coercion and call it a day.

@radeksimko
Copy link
Member

I completely agree with you that we should treat such schema as invalid, in fact that's exactly what I did in hashicorp/terraform#12638 and then I realized I broke many acceptance tests across 4 different providers - as mentioned in hashicorp/terraform#12722

It seems that for common use cases these schemas are "kind of working" (based on passing acceptance tests) - which also scares me a bit, but hey 🤷‍♂️

If you are (or anyone else is) willing to modify all those schemas and tighten the validation I'm totally willing to review & merge a PR. 😉

@josephholsten
Copy link
Contributor Author

It's comforting to know I wasn't the only one who's made this mistake!

@hashibot hashibot transferred this issue from hashicorp/terraform Sep 26, 2019
@hashibot hashibot added enhancement New feature or request technical-debt labels Oct 2, 2019
@paultyng
Copy link
Contributor

This is the same as #62 , merging with that one.

@ghost
Copy link

ghost commented Apr 1, 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 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request technical-debt
Projects
None yet
Development

No branches or pull requests

4 participants