Adam Lewis

It's possible to fix https://github.com/nebari-dev/nebari/issues/2405 with a simpler PR, but I feel that this PR has several advantages: - I like that we've moved the storage account and container info...

This causes a change in the Nebari config of Azure deployments from ```yaml provider: azure namespace: dev nebari_version: 2024.4.2 project_name: ne-bri6 domain: adam.nebari.dev terraform_state: type: remote security: keycloak: initial_root_password: broot...

Just tried to deploy Nebari on Azure with the project name ne-bri and I get the following error just after the terraform state resource group, storage container, and storage account...

The issue is that we mutate the project_name to get the storage account name (e.g. strip dashes), but we create the storage account in a different place from where we...

Brought up in June 4 community meeting, potentially use node types with NVME storage (e.g. i3en on AWS) as swap to accomodate conda store solves with high memory usage in...

> I think these volumes might be more expensive than what we do now. The alternative I'm comparing against is using conda-store-worker nodes (and pods on those nodes) with enough...

This method works as intended when tested on GCP. However, One issue is that certain daemonsets won't run on the tainted nodes. I saw the issue with rook ceph csi-cephfslplugin...

Okay, so things are working for the user node group. I tried adding a taint to the worker node group, but the dask scheduler won't run on the tainted worker...

I managed to get the taints applied to the scheduler pod in [this commit](https://github.com/nebari-dev/nebari/pull/2605/commits/a1370c939823899763b9d9b21fe9a492436d36b9). I would have expected the `c.KubeClusterConfig.scheduler_extra_pod_config` to get merged with the options returned by the function...

Okay things were working as expected for the jupyterlab pod and the dask worker and scheduler pods on GKE. I need to test on: - [x] AWS - [x] Azure....