Pulumi considers objects different depending on what Platform (Windows/Linux) you use

[NArnott]

Problem description

It looks like Pulumi considers certain objects different depending on what platform you run on.

I used Linux to run a DotNet Pulumi program. I then used Windows, and it wants to make changes that aren't really changes and shouldn't happen.

For example, it considered whitespace different. For example, windows will write a K8s ConfigMap using \r\n, while Linux writes using just \n. Pulumi considers this different. Also, using the K8s ConfigGroup to apply several yaml files, windows using back slash, while Linux uses forward slash in the name/path, causing Pulumi to consider them different as well.

Affected product version(s)

CLI 2.6.1
Pulumi.Kubernetes: 2.4.0

Suggestions for a fix

Assuming a goal for Pulumi should be to be platform agnostic, change detection should ignore certain differences created by using different platforms. For example, \r\n and \n should be considered the same thing. And ConfigGroup should use the same forwardslash or backslash regardless of platform.

[D3-LucaPiombino]

This is still a problem.
It's particularly problematic when you have team members that use different OS.
An alternative is to at least provide something similar to transformations but that is executed BEFORE the resource name is assigned and the file is loaded so either the name or the content can be manipulated.

[D3-LucaPiombino]

For the time being, we created an alternative ConfigGroup implementation that normalize paths before creating the child ConfigFile resources.
I believe a simple solution would be to allow the user to provide a callback/hook that is invoked for each file path resolved from globbing expression/s before the sub ConfigFile resources are instantiated.
This would have to work for all supported languages though (we are using dotnet ATM).

With the current implementation we need to replicate the entire functionality (we didn't, we just support files right now) since there is no way to extend the existing logic.

The issue with config map values is also annoying but it has some solutions that could be solved without duplicating
the built-in implementation:

• Simply by having some utility that "normalize" the values directly on the callsite where the resource
  is created. (we are doing this right now)
• Through resource transformations by post processing values.
  We did not actually tried or implement this ATM.

  NOTE: Ideally it would be nice to have the ability to provide transformations functions globally (for example on the
  parent provider), so this can be solved as an orthogonal concern.
  This would probably provide the most flexible solution, as it avoid the need for the user to remember to specify this
  for every resource but also allow to tune the behavior based on the user requirements.

[EronWright]

I was unable to repro the problem with newlines; I tried changing the line endings on a ConfigMap to no effect. If someone has a repro, please re-open the issue.

The resource naming issue has been resolved in the new v2.ConfigGroup resource, because it doesn't use the manifest file name as a resource name, as some of the v1 implementations did.