OSC / bc_osc_codeserver

BETA - Batch Connect - OSC Code Server
https://osc.github.io/Open-OnDemand/
GNU General Public License v3.0
18 stars 21 forks source link

Fix env setup to make suitable for production release #4

Closed ericfranz closed 4 years ago

ericfranz commented 4 years ago

Currently, there is extra code in the script to support having a symlink in bin of the app root to point to code server, in addition to an env var pointing to the code server binary. These should be removed.

Instead, a single env var to the code server binary should be set (setting with the default value trick if it isn't already set), and a comment above indicating that this needs to change based on where code server is deployed.

In may OnDemand depoyments the app is deployed on the local disk of the web node, unavailable to the compute nodes.

ericfranz commented 4 years ago

Also removing this will simplify the code a bit further.

johrstrom commented 4 years ago

What about a singularity image?

Nosferican commented 4 years ago

We use it as a singularity image

Screen Shot 2020-08-05 at 1 13 47 PM
msquee commented 4 years ago

@Nosferican

In your opinion do you think most sites would prefer a Singularity image?

Nosferican commented 4 years ago

@rsdmse did we use a published Singularity image or did we make one?

johrstrom commented 4 years ago

I actually started to use my image, and found I needed to install git into it. I'm all about containers, but honestly modules are more composable and I feel like you'd want the freedom in an IDE to modify your environment and not rely on an admin to continually update a global image (or field options in the application).

I just mean, with an IDE we'd want to optimize for user customizations - however that may play out.

rsdmse commented 4 years ago

@rsdmse did we use a published Singularity image or did we make one?

We're using docker://codercom/code-server

Nosferican commented 4 years ago

I guess we inherited from the code-server one.

I'm all about containers, but honestly modules are more composable and I feel like you'd want the freedom in an IDE to modify your environment and not rely on an admin to continually update a global image (or field options in the application).

Agreed I was using an image on AWS and the image had RStudio but missing Git... For adding languages to the VS Code container I didn't need to modify the image. I just passed the path to the Julia executable to the extension and it just works. That's an example of composable design which VS Code extensions usually allow for.

The images we use for R usually require some admin help for updating the images if they require syslib for packages. I mostly use Julia which has more 1,000 libraries (statically compiled and linked) so I usually don't run into those issues and the package manager avoids relying on the user to work with dynamic system libraries... It's 2020 so dynamically linked libraries are not a necessity given storage available.

msquee commented 4 years ago

Closing. See #7.