Exosphere

I'll keep working on this. I'll also catch up with @kageurufu when he has some time to get his input.

Problem/Opportunity Statement The resource usage graphs show compute usage for both an instance's CPU and GPU (using nvidia-smi). But for memory (RAM) usage, we only show the system memory. Instances with a GPU will also have GPU memory (VRAM). ... [More] LLM workloads are often VRAM-constrained, so surfacing VRAM usage may make it more intuitive to use Exosphere for these workloads. What would success / a fix look like? Decide on nomenclature. Do we call it "GPU RAM" or "VRAM"? Do we retronym "RAM" into "System RAM"? (The UI is kind of space-constrained here) Collect VRAM usage (probably though the same call to nvidia-smi that we already make) Display it in the graphs. [Less]

Suggestion: expand the scope of this issue a bit, look at resources holistically, support select-multiple (or select-all) and delete of everything across the app. (IPs, volumes, shares, SSH keypairs, images)

Just had a suggestion from @SlicerMorph to use MorphoCloud for people to try out Exosphere. Thank you!

Yes, I think if you create a fork of MorphoCloudWorkflow and assign a small allocation, people can give it a try without having to obtain the allocation first. But they would still need to have github accounts (not a big ask nowadays). There might ... [More] be simpler ways around it, but I think the idea of giving people a chance to "kick the tires" for few hours without having to do all the up front work of obtaining allocation would be good advertisement both for JS2 and Exosphere. At the minimum, I wouldsuggest making a "how to get started with JS2 via Exosphere" video tutorial with sections on: Adding an allocation to exosphere Spinning your first instance Transferring data in/out attaching a volume to the storage. [Less]

Thank you for the suggestions @SlicerMorph!

That isn't trying out Exosphere though. I don't believe MorphoCloud uses any of the Exosphere web app. (Only a subset of our Ansible code for instance and Guacamole interaction setup?).

I think the idea of giving people a chance to "kick the tires" for few hours without having to do all the up front work of obtaining allocation would be good advertisement both for JS2 and Exosphere Jetstream2 does now have the trial allocation which achieves approximately this, though someone still needs to use an ACCESS account.

Per @julianpistorius use of Magnum from CLI on Jetstream2 currently requires creation of an unrestricted application credential that can create other application credentials. That application credential needs load balancer member role.

Steps for creating a cluster Here are the steps to try out Magnum on Jetstream2 with the OpenStack CLI: Create an 'Unrestricted (dangerous)' application credential in the project where you will be creating the cluster, and source it to expose the ... [More] environment variables in your local environment where you'll be running the openstack commands. Ensure you have the Magnum client installed: pip install python-magnumclient Check out the cluster templates available: openstack coe cluster template list List clusters (will probably be empty): openstack coe cluster list Create a cluster: openstack coe cluster create --cluster-template kubernetes-1-30-jammy --master-count 3 $CLUSTER_NAME List clusters again. You should see your cluster now. Once status is CREATE_COMPLETE, get the Kubernetes config file: openstack coe cluster config $CLUSTER_NAME Use the cluster: chmod 600 config && mv config $CLUSTER_NAME.kubeconfig && export KUBECONFIG=$CLUSTER_NAME.kubeconfig && kubectl get nodes List the node groups: openstack coe nodegroup list $CLUSTER_NAME Increase number of worker nodes: openstack coe cluster resize --nodegroup default-worker $CLUSTER_NAME 3 Confirm that there are 3 worker nodes: kubectl get nodes Delete the cluster: openstack coe cluster delete $CLUSTER_NAME [Less]