Update 3d-viewer to dy-sidecar with boot-modes and baked template data

[mrnicegyu11]

What do these changes do?

• Update 3d-viewer to dy-sidecar with boot-modes and baked template data
• Portal Link templates must be updated to use the specific boot-mode to preload their data
• This should be compatible I hope with the registry-syncer (CC @GitHK ?)
• Tested to work on osparc-master.speag.com

[GitHK]

We require a CI step that makes sure that this runs and it can be build. They usually look like so https://github.com/ITISFoundation/jupyter-math/blob/main/.github/workflows/check-image.yml

Without this step working, the automation build process will not work

[sanderegg]

mostly wondering about hard-coding all these vtk file in there? is that really how this should be? are these not under license?

[sanderegg]

did we not say these email addresses shall change to something like support or whatever?

[mrnicegyu11]

didnt hear about this one

[sanderegg]

maybe if you can put my github email address instead...
35365065+sanderegg@users.noreply.github.com

[sanderegg]

not sure I get it here. are we now hard-coding these data inside?
previsously I think the template defined what was going in.

[sanderegg]

is it ok to put all these vip files inside?

[mrnicegyu11]

@sanderegg maybe I am understanding it wrong, but this service's entrypoint.sh relys on the inputs being present to execute the paraview binary. But it seems that the inputs are often only pulled after the start of the sidecar. My trick is to bake the required files into the docker image. Do you have other proposals?

[sanderegg]

@sanderegg maybe I am understanding it wrong, but this service's entrypoint.sh relys on the inputs being present to execute the paraview binary. But it seems that the inputs are often only pulled after the start of the sidecar. My trick is to bake the required files into the docker image. Do you have other proposals?

@mrnicegyu11 the inputs shall be brought in by the dynamic-sidecar (previously done by the integrated one when it was a legacy service). It was not meant to be a hard-coded service.

[GitHK]

@sanderegg maybe I am understanding it wrong, but this service's entrypoint.sh relys on the inputs being present to execute the paraview binary. But it seems that the inputs are often only pulled after the start of the sidecar. My trick is to bake the required files into the docker image. Do you have other proposals?

@mrnicegyu11 the inputs shall be brought in by the dynamic-sidecar (previously done by the integrated one when it was a legacy service). It was not meant to be a hard-coded service.

I confirm, we changed this. When the service starts the inputs are already in place.