OOM NodePort List

NodePorts are used to allow client applications, that run outside of Kubernetes, access to ONAP components deployed by OOM.

A NodePort maps an externally reachable port to an internal port of an ONAP microservice.

It should be noted that the use of NodePorts is temporary. An alternative solution is currently being scoped for the Dublin Release.

But for now, this page is used to track NodePort assignments.

All ONAP project teams that have microservices that need to provide external access for clients, must update this wiki page to reserve NodePorts and prevent ONAP deployment failures due to NodePort conflicts.

If a service is only accessed by other services within the same kubernetes deployment (ie. databases, backend services with no external northbound APIs) then please DO NOT reserve

a NodePort as they are a very limited resource. The service name and its Internal Port (<service name>.port) should be used instead (ie. vid.8443)

To reserve a NodePort search the table below for the text "FREE_PORT".

If it is determined that an existing reservation is no longer required, please add the text "FREE_PORT" to indicate its availability.

Node Port Reservations (shown using default 302 node port prefix range)

Node Port Reservations (304 node port prefix range)

This table is for documenting node ports that are reserved outside of a typical ONAP deployment.

Even though the ports listed below may appear in ONAP Helm Charts, they are not used at runtime unless enabled through configuration.

For example, there may be a need to reserve node ports (even temporarily) for use in POC or for demo code, that currently exists in the ONAP codebase.

This port does not seem to be configurable from a Helm Chart.

Mike Elliott will raise issue to see if it can be made configurable within either the 302 or 304 ranges.