search

spotfiresoftware / spotfire-cloud-deployment-kit

Vanilla recipes to build container images and Helm charts for Spotfire®
Apache License 2.0
17 stars 15 forks source link

Default SDN are not installed on Spotfire Server once started #4

Closed alexandrev closed 1 year ago

alexandrev commented 2 years ago

Currently, the default SDN (Spotfire.Dxp.netcore-linux.sdn Spotfire.Dxp.sdn ) are not being properly loaded in the launch of the Spotfire server, and you need to provided it manually. Currently spotfire-config is not loaded those files even that they are provided to the build script.

Spotfire Config needs to change to include those SDN as they are doing for Web Player and Automation Services to be able to deploy it later.

mdiez-tibco commented 2 years ago

Hi @alexandrev,

What you described is how it currently works.

Deployments are not automatically uploaded. When you install a spotfire-server and create a new spotfire-database it will start with an empty deployment area. The services don't need the sdn/spk files because they already are pre-built with all the packages in their respective container images, however they will refuse to start due to a license check that won't pass unless the right packages are deployed to the deployment area. For example, the spotfire-webplayer container won't start without the proper deployment packages in the deployment area. This is noted in the respective READMEs.

You can however deploy several deployment packages automatically with the charts. For that, you need to put the deployment packages in a persistent volume. This is described in the spotfire-server chart

Check the variable volumes.deployments.existingClaim. And this is just an snippet example of what you would use in your values.yaml. Here my PV is called local-pvc-deployment-areas: 

  volumes:
    deployments:
      existingClaim: "local-pvc-deployment-areas"

Let me know if this helps

alexandrev commented 2 years ago

Thanks  @mdiez-tibco !

alexandrev commented 2 years ago

Clarification done.

alexandrev commented 2 years ago

I will reopen again after reviewing the chart. This is forcing now to be PVC claims. This is not the best way to do this kind of "provide data in advance" PVC is not the best way. Opening the option to be a ConfigMap should be much better, especially for the read-only kind of data. Because today there is no way to pre-populate a PVC without being mounted previously.

mjohanss-tibco commented 1 year ago

With the release of version 1.2.0 it adds the ability to automatically deploy Spotfire.Dxp.sdn automatically to a deployment area on helm installation, from the spotfire-server chart. By default it will create the deployment area 'Production' with Spotfire.Dxp.sdn on it.

Even though it does not add Spotfire.Dxp.netcore-linux.sdn we believe this should solve many cases to get a working Spotfire environment bootstrapped. If you want additional deployment areas or packages you can either create them manually using the web interface or configuration command line tool (config.sh) or as previously mentioned using a pre-populated PersistentVolume / PersistentVolumeClaim. Alternatively you can also create your own version of spotfire-deployment container (see containers/spotfire-deployment) with a custom set of sdn / spk packages on it. Note the image for spotfire-server's values.yaml configuration.deployment.defaultDeployment can be overridden to a customly built one.

I think that pre-populating a PersistentVolume seems to be the most straight forward solution to add custom packages.

alexandrev commented 1 year ago

Hi Markus,

I think the approach that we're following for a lot of things focused on "pre-existed persistent volume" is not aligned with best-practices. As is not supporting GitOps approach and require manual intervention. I think the approach should be in a different way. For some options we can rely on ConfigMaps prepoulated, but for big binaries such as this, this is not a valid option.

I don't think this should be close as the solution is quite manual at the moment.

Regards,

Alexandre Vazquez | E @. @.> | W https://alexandre-vazquez.com |*

On Tue, Feb 14, 2023 at 3:40 PM Markus Johansson @.***> wrote:

Closed #4 https://github.com/TIBCOSoftware/spotfire-cloud-deployment-kit/issues/4 as completed.

— Reply to this email directly, view it on GitHub https://github.com/TIBCOSoftware/spotfire-cloud-deployment-kit/issues/4#event-8516237693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHHGYL5UV5VWAMLVYAKPA3WXOKMVANCNFSM6AAAAAAQAKJHAQ . You are receiving this because you modified the open/close state.Message ID: <TIBCOSoftware/spotfire-cloud-deployment-kit/issue/4/issue_event/8516237693 @github.com>

mjohanss-tibco commented 1 year ago

With release 1.2.0 the default sdn, Spotfire.Dxp.sdn, will be installed by default on a brand new installation without any prior spotfire database and that is the reason why the ticket was closed. I would prefer if we could handle additional bugs or improvements in a separate ticket. If there is something else to support can you provide some more information about these best practices you're referring to, what the different way of doing it would be, or exactly what problem that needs to be solved that does not currently have a well working solution.

To summarize, currently supported methods custom/additonal deployment files to be automatically added during helm install. (The standard Spotfire.Dxp.sdn client deployment is deployed by default)

Note: The Spotfire.Dxp.sdn is 387MB and it will not fit into a ConfigMap and it would also have the same requirement as with a volume that it needs to be pre-populated. Because "The data stored in a ConfigMap cannot exceed 1 MiB." it makes it unfit for storing packages.