[Feature]: Rethink how we do ports

[svrnm]

Problem Statement

As of today the way we configure and manage ports for services is complicated and confusing:

• a service provides the HTTP entrypoint on a predefined port (8080 by default), which can be reconfigured, so accomodate docker compose (see

  app-simulator/scripts/generators/docker-compose/createComposeFile.py

  Line 19 in 3919be6

  "services": 80, # this is different from the "default default" on purpose.

  for example), as it needs port 80 to allow easy service to service communication
• k8s provides the capability to have a service port, so it can map 80 to 8080 transparently
• we allow a top level item called exposedPort (previously simply port) to make a service accessible from the outside.

This is farily complicated and also comes with a set of disadvantages:

• If we introduce additional entry points (think grpc, message queues, etc.) the "exposedPort" on top level will no longer work as it is not clear on which entry point it should be mapped
• Contributors and endusers may get confused from the amount of settings and get things configured incorrectly because they misunderstand some of the concepts.

The question is now: how can we do better?

Proposed Solution

to be done

Alternatives Considered

No response

Additional Context

No response

Checklist

• I have read the contributing guidelines
• I have verified this does not duplicate an existing feature request

[noMoreCLI]

Additional Context:
The question is, how configurable this should be.
For K8s I see like 3 port definition we could use:
containerPort: the port the actual service within the container is configured to listen to. e.g. 8080 so that the container could run unprivileged
servicePort: the port other services will connect to. This obviously is dependent on the actual runtime implementation. Not available in docker/docker compose, but available in k8s
exposedPort: used to map the port and make it accessible from the outside. This is seems to be applicable to all containerization environments, as by default the ports will be only exposed within the environment

Proposal:
we remove the servicePort and modify the k8s templates that the servicePort and containerPort are set to the same value. This will reduce the complexity, but might add to more typing in the configuration, as you need to add the corresponding port to the calls etc

I think we should keep the servicePort and exposedPort the give users the flexibility to change this without tampering with the containers directly.

[svrnm]

I would be OK with requiring people to write out the port when they have one service talk to another one, so let's have "servicePort" and "exposedPort" or similar, maybe also "internalPort" and "externalPort" or something descriptive that makes clear what the purpose of these ports is. And their should still be a default for the exposedPort.

We also need to consider if we move it down into the entrypoints.http section, if we ever want to add additional ways to reach a service (Message Queues, gRPC, etc.)