Review use of normalizeResourceName

[thaJeztah]

Tracking issue for #719 (comment)

I noticed that the normalizeResourceName() utility can lead to ambiguity; https://github.com/docker/compose-cli/blob/ced0eb3912c8ff18d5245775be04098127e93ec5/ecs/cloudformation.go#L442-L444

For example, . hello world, h e l l o world, h$%e^&lloworld, hello-world, Hello___world, and

h
	e
	l
	l
	o
	
	
    world!!!!

Are all considered equal. (see https://play.golang.org/p/Lp3xWkxztpy)

We should check if there's a validation step before we reach that code (and other places where we normalise); I'm always a bit scary with silently "fixing up" user-mistakes (if possible prefer to produce a clear, but "fatal" error to not hide mistakes).

Perhaps if possible, we should produce an error (so that the user can fix the issue) instead of fixing up non-trivial cases (i.e. it may be ok to strip leading/trailing whitespace, but other characters should be looked at more carefully)

[thaJeztah]

/cc @ndeloof

[ndeloof]

CloudFormation resource limitation to require alphanumeric identifiers should be addressed globaly.
I suggest we pre-process the compose model after it has been parsed to "normalize" resource identifiers (services, volumes, network names). This will allow to detect name conflicts and remove the need to process such names everytime we need a reference from code, with risk to forget about this (which resulted into #622 (comment))

[flaviostutz]

There was a small change proposed in PR #871 in "normalize" function in order to avoid this type of conflicts by using a CRC32 checksum as part of the string, so that even if two strings are "cut" to the same contents, the CRC contents will be different. Do you think this strategy could fix this problem? If so, we can extract just this code from the PR and create a new one for this issue to be fixed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.