fix reporting and reporting server

[mayman99]

Signed-off-by: Mohamad mohamad@openrobotics.org

Fixes the front end so it builds, not tested with task-v2 yet.

What's new

[cnboonhan]

good news is that trying this with the example deployment works somewhat, but not all logs are being aggregated.

From what i gather ( i might be mistaken, not 100% sure ) it looks like the logs that are aggregated, are those that still use the legacy data models, like lifts and doors, and the keycloak login / logout logs. Fleet States logs are broken, which probably is due to taskv2 changes.

To reproduce, follow the readme in example-deployment. I encountered a few issues when setting it up,

• minikube is wonky between laptop restarts, but only sometimes. This breaks the verification of minikube ingress during start-minikube.sh. The solution seems to be to delete all running minikube pods. kubectl get all --all-namespaces and making sure to clear it out.
• the rmf-server sometimes gets a connection refused error, but the container does not terminate. So on kubernetes, it looks like the pod is running, but the process essentially does nothing. To fix this in the short term, we can kill the pod, which will cause a ContainerRestart
• the deploy.sh script did not seem to launch the kubenetes pods the first time i run it ( only the services and deployment specs are created ) Not sure why.. but you can run kubectl get pods. If only keycloak is present, the pods are not up. Can try running the script again, which seems to work.

[mayman99]

good news from my side as well, I got the reporting server to work locally, so now I can actually test reporting end-to-end (I'll probably be doing that later today as it works for me only on the other system)

[mayman99]

lgtm, the example worked by following the steps.

[koonpeng]

This is not needed anymore as the api-server no longer uses multiple ports.

[koonpeng]

I recalled that this was added to workaround minikube misconfiguration, iirc the problem was because minikube isolates the networks so other dds wouldn't work if rmf is ran locally and api-server is ran on the cluster. It only works for fastrtps because it supports shared memory.

I think we should remove this as abusing shared memory features to workaround broken network configuration is wrong. iirc it is not possible to create a configuration that works for other dds without also putting rmf inside the cluster, and even if it is in the cluster, it might still not work because dds requires udp broadcast which might not be supported by minikube.

We can also consider writing some deployment instructions for rmf + kubernetes in the rmf meta repo and link to that here since deploying rmf is out of scope of this repo. It might also make sense to move this example deployment to the meta repo as deployment of rmf + rmf-web has become quite coupled together, making it hard to have separate docs without explaining the other.

[koonpeng]

New api-server reverts to using port.

[koonpeng]

DateTimePicker has graduated from material lab and into "material-x". This will cause reporting to fail when we merge #615.

[aaronchongth]

Reporting has been removed via #628. Example deployment has been moved out to https://github.com/open-rmf/rmf_deployment_template