. When we connect to the portal: http://portal.api.simpledemo.onap.org:8989/ONAPPORTAL/login.htm we automatically get redirected to a hardcoded path: http://portal.api.simpledemo.onap.org:8989/ONAPPORTAL/applicationsHome.

Because of this, when browsing to the URL to connect in the OOM setup, which would be http://<KUBERNETES_HOST_IP>:30215/ONAPPORTAL/login.htm, login is successful but then the redirection is failing, because the host on which the browser is running doesn’t know how to resolve portal.api.simpledemo.onap.org

The hostname and the port shouldn’t be hardcoded, they should be configurable.

 

1. Using the apps:

• AAI, the path is hardcoded to aai.api.simpledemo.onap.org:9517

• CLI, the path is hardcoded to cli.api.simpledemo.onap.org:8080

• SDC, the path is hardcoded to sdc.api.simpledemo.onap.org:8181

• VID, the path is hardcoded to vid.api.simpledemo.onap.org:8080

 

A little bit of background regarding OOM networking:

In OOM, each ONAP services that should be exposed to others are mapped using a NodePort, Kubernetes notion that allows to assign statically a port that will be open on each K8S hosts, port that is mapped to the internal port. The benefit of this is, regardless the K8S node to which we send the request to, the port exposed for a given service would be the same. See associated picture attached.

For instance, for SDC BE we have the following, where  {{ .Values.nodePortPrefix }} is configurable, i.e. 302

 

  ports:

  - name: sdc-be-port-8443

    nodePort: {{ .Values.nodePortPrefix }}04

    port: 8443

  - name: sdc-be-port-8080

    nodePort: {{ .Values.nodePortPrefix }}05

    port: 8080

 

So port 8443 is mapped to port 30204. External user can use 30204, internal service can use 8443.

 

 

In the default deployment (HEAT), the user is asked to update the /etc/hosts so it can resolves properly the services. In OOM, because of the NodePort notion explain before, the port 8443 of SDC is not exposed, but 30204 is instead. But as the port is hardcoded in the portal, even if /etc/hosts is updated with the proper mapping hostname/IP, the port would remain incorrect. So we created the vnc-portal hiding this complexity/bug for the user. In OOM, we take care of updating the /etc/hosts of the vnc-portal, and we maintain it up-to-date.

 

To be very concrete, let’s take an example, SDC backend.

 

In HEAT, user has to add to /etc/hosts

IP sdc.api.simpledemo.onap.org

so the portal can resolve sdc.api.simpledemo.onap.org:8181

 

In OOM, if the user adds to /etc/hosts

IP sdc.api.simpledemo.onap.org

the portal will try to resolve sdc.api.simpledemo.onap.org:8181 but as explained above, port 8181 is not exposed, it’s kept internal to the K8S cluster, it's port 30204 that is exposed. Hence that cannot work.

The solution is, using a vnc-portal, the above would work, because the vnc-portal belongs to the K8S cluster internal network, hence is able to resolve port 8181 for SDC.

 

Hope it helps understand why we have done this in OOM, it is basically to hide/fix/overcome the hardcoded hostname/port portal is providing. If that could be configurable, then we wouldn’t need this.

 

This issue becomes serious when we use k8s based deployment. And we have to use vnc to workaround this issue. Please let me know if you have any questions.