Allow dashes in port names (again)

[nightkr]

Description

Fixes #514

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

Preview Give feedback

1. Changes are OpenShift compatible
2. Helm chart can be installed and deployed operator works
3. Integration tests passed (for non trivial changes)
4. Changes need to be "offline" compatible

Reviewer

Preview Give feedback

1. Code contains useful comments
2. Code contains useful logging statements
3. (Integration-)Test cases added
4. Documentation added or updated. Follows the style guide.
5. Changelog updated
6. Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

Preview Give feedback

1. Feature Tracker has been updated
2. Proper release label has been added
3. Roadmap has been updated

[sbernauer]

Thanks for fixing! All other cases should be handled

As with Kubernetes names in general, names for ports must only contain lowercase alphanumeric characters and -. Port names must also start and end with an alphanumeric character.

Just for the record from #514 (comment)

I'd argue that 123-abc is far less common, and while switching to a PORT_ prefix would fix it, I'm not sure it's worth the compatibility break.

[sbernauer]

Thinking about it, would anything else than rust/operator-binary/src/hdfs_controller.rs be affected by adding a PORT_ prefix?
We set e.g. dfs.datanode.registered.port to ${env.DATA_PORT}, shouldn't his be unnoticed by customers?

[nightkr]

(Merging since digit-prefixed ports are a separate fix anyway, but can continue discussing in here or make a new issue)

We set e.g. dfs.datanode.registered.port to ${env.DATA_PORT}, shouldn't his be unnoticed by customers?

In the default configuration, no. But they can still use ${env.} references in their own config overrides, which would be broken by it.

[nightkr]

It would definitely have been better to do it that way from the start. Now we have the tradeoff to make.

[sbernauer]

I think the likelihood of someone doing that is very very unlikely and I personally would prefer to be safe in the long run

[nightkr]

To be clear, the options here are:

• Break previously-working configurations during routine upgrades, with an unclear cause or path forward
• Break when applying a new configuration that trips over the edge case, which can easily be reverted

[sbernauer]

Honestly I don't care to much, I leave it up to you