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
- [x] Changes are OpenShift compatible
- [x] Helm chart can be installed and deployed operator works
- [x] Integration tests passed (for non trivial changes)
- [x] Changes need to be "offline" compatible

# Reviewer
- [ ] Code contains useful comments
- [ ] Code contains useful logging statements
- [ ] (Integration-)Test cases added
- [ ] Documentation added or updated. Follows the [style guide](https://docs.stackable.tech/home/nightly/contributor/docs-style-guide).
- [ ] Changelog updated
- [ ] Cargo.toml only contains references to git tags (not specific commits or branches)

# Acceptance
- [ ] Feature Tracker has been updated
- [ ] Proper release label has been added
- [ ] [Roadmap](https://github.com/orgs/stackabletech/projects/25/views/1) 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