Apology in advance for the novice question. What prevents me from using my own instance of OOD on my local instance of WSL for submitting jobs to our campus cluster (or any other), where WSL in turn is running in a Windows 10 VDI? Thanks.
Best,
CB
Apology in advance for the novice question. What prevents me from using my own instance of OOD on my local instance of WSL for submitting jobs to our campus cluster (or any other), where WSL in turn is running in a Windows 10 VDI? Thanks.
Best,
CB
I think the hurdle would be setting that up correctly to submit and be allowed to submit as your user from the laptop to the cluster. I would think you’d hit some issues with user mapping and permissions, but what exactly I don’t know. It’s a very peculiar way to use the software, but I mean, it could probably be done with enough effort. Why not just request the center to install it
Thanks 10x! for reply and question.
I’d prefer a local test instance in order to become better informed (both as a user and salesman) before I pitch to the center for resources.
Re center installation:
Thanks.
I think the following page in the docs might help with the requirements part:
https://osc.github.io/ood-documentation/latest/requirements.html
There’s also something like the HPC-toolset-tutorial which is a docker-compose
setup that gives you a web front-end for OOD and some clusters to submit to and login to. This may help you wrap your mind around some of the docs and how things work:
And the actual part of the tutorial over OOD once you have it running:
To allow secure logins, OOD will work with various identity providers using Apache modules to handle auth and map the user and groups correctly:
https://osc.github.io/ood-documentation/latest/authentication.html
Thanks always for the information.
Is there any guidance on how many FTE’s are needed just to manage OOD? Thanks.
Not many, but it’s really an organization’s choice. It’s not so much to maintain it, it pretty much just runs once you’ve set it up, so failures don’t happen that much to the actual webserver.
Staff time is more likely going to be spent debugging the applications like Rstudio or Jupyter. Or updating the applications themselves to support different features.
Ultimately OOD is submitting jobs to your compute nodes, so failures originating from the modules that are being loaded or OS upgrades are more common than the webserver itself being broken.
I think there’s a lot of staff time put in to set it up and get it going. But once it’s going, it’s pretty much interrupt driven by customer tickets either wanting features out of your apps or apps themselves not working correctly.
That said - we don’t spend a lot of time on our OSC deployment on OnDemand. We generate maybe 1-3 customer tickets a month (a very liberal estimate) and tweak/update our applications sparingly (you can check our github activity for how often we’re updating our production applications and configs).
Re: Why not just request the center to install it
I appreciate your continued patience in the following for those of us in IT that are research-facing but with limited, if any, HPC privileges.
I’m trying (perhaps naively so - to the extent that every datacenter is different) here to…
In particular in the interest of security, IMHO it would be nice if there were a single place to go in the docs or otherwise to address the datacenter’s anticipated security concerns for introducing the additional attack surface presented by deploying OOD.
Arguably, I would be remiss if I failed to anticipate the above argument.
In just a cursory search at the documentation and support issues, I see the following.
Docs:
2. Authentication
3. Secure Apache httpd
Support: Preventing a JS Attack?
Comments welcome, and thanks again.
Hello, I have a docker-compose project that sets up OnDemand, authorization for an account (hpc.user) and a cluster that works for me with WSL. GitHub - matt257/ondemand-compose: Deploy Open Ondemand locally with Docker Compose
It is not finished and job submission isn’t working yet, but I will be updating it as I am able.
There are security features we’d like to implement in OnDemand, but with thoughtful configuration and controls we’ve found OnDemand to be secure. In 2018 and 2021 the NSF Trusted CI completed engagements and assessments of OnDemand’s security. Trusted CI Blog: 2021 Open OnDemand Engagement Concludes.
If you’d like to discuss specific security concerns for your center please let me know here or email me at mwalton@osc.edu.