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

Show warnings when fixing names via StateFunc? #60

Open
radeksimko opened this issue Nov 24, 2015 · 6 comments
Open

Show warnings when fixing names via StateFunc? #60

radeksimko opened this issue Nov 24, 2015 · 6 comments
Labels
enhancement New feature or request ui UI specific change or change which requires significant UI changes upstream-terraform

Comments

@radeksimko
Copy link
Member

This is related to hashicorp/terraform#4020 but also many other PRs which have been mimicking the AWS API behaviour in similar ways.

I understand the convenience for the user having existing resources and I understand that is the motivation for @stack72 and others to solve these issues that way. However I think that Terraform shouldn't be so silent about these fixes.

I think we should be more transparent and at least show warnings if the converted names differ from the original ones.


I'd personally like to use warnings in a way that it would allow us to turn on strict validation in the future (after a few versions, when we're sure enough users have been warned), but I understand the convenience for existing users has probably priority and that others may not like this (correct me if I'm wrong).

@stack72
Copy link
Contributor

stack72 commented Nov 24, 2015

@radeksimko I really like this idea - we should definitely be notifying the user that we are changing their variables so that they work with the APIs we are using

@apparentlymart
Copy link
Contributor

I'm not sure I entirely agree with you. For an API that is case-insensitive, all of the different-cased versions of a value are semantically equivalent, and I don't really see the point in drawing attention to byte-wise diffs that don't represent a difference in meaning.

I would agree that we should never cross the line into making a change that results in a difference of meaning/behavior, but as long as we're just mimicking the same normalization that the underlying API was going to do I see this as a benefit (improved UX) rather than a drawback.

Have you encountered a real-world drawback to having these things silently normalized, from an end-user perspective?

(I know it has a very real developer drawback in that we have to keep adding all of these silly StateFuncs everywhere, but I think we've lowercased enough of these now that we could just have a reusable "make this lowercase" function that just wraps strings.ToLower to make its argument be interface{}, so we can write StateFunc: something.ToLowerCase instead of the same wrapper function each time.)

@stack72
Copy link
Contributor

stack72 commented Dec 11, 2015

@radeksimko / @apparentlymart was any discussion given to this outside of this issue? I feel this has sort of dropped off the face of the planet atm :)

@hashibot hashibot transferred this issue from hashicorp/terraform Sep 26, 2019
@hashibot hashibot added enhancement New feature or request ui UI specific change or change which requires significant UI changes labels Oct 2, 2019
@paultyng
Copy link
Contributor

Easiest to accomplish this when we support diagnostics in protocol 5

@radeksimko
Copy link
Member Author

This may also be related to #19

@paultyng
Copy link
Contributor

paultyng commented Feb 5, 2020

#74 is the tracking issue for diagnostics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request ui UI specific change or change which requires significant UI changes upstream-terraform
Projects
None yet
Development

No branches or pull requests

6 participants