Dandihub requirements: meta issue

[asmacdo]

Context

The DANDI project is using Nebari to deploy and maintain our Jupyterhub deployment. This issue is intended to collect the variety of issues that we need in order to move from our fork to a vanilla release of Nebari.

Open PRs

• Nodes should not have a public subnet Moves nodes to private subnets.  #3004
  • This fix introduces an availability zone issue [BUG] - General node on AWS EKS spawns in wrong AZ and fails to mount volumes #3008
• fix: handle unauthorized kms keys in the account fix: handle unauthorized kms keys in the account #3071
• Add Multiple AWS instance types enh: allow multiple instance types for aws #3070
• Add more subnets nebari/commit/cfcb06d58
  • This one doesn't have a PR, it was left as a review comment

Needed Features

• conda-store backup in some form. Recreation of envs from lockfiles would be sufficient [ENH] - Archiving/recreation of old builds conda-incubator/conda-store#889 (though ideally we would be able to backup without deleting)
• Ability to destroy a deployment without deleting EFS [ENH] - Support skipping some resources in nebari destroy #3061
  • current backup of the user home dirs (EFS) is simply to tarball and push to s3. This would be very expensive to run on an ongoing basis, a better path forward for us would be to leave the EFS in place, spin up a new nebari deployment and connect to previous one.

Value and/or benefit

This will benefit others who deploy with AWS, and projects that intend to have long-running/large jupyterhub deployments.

[viniciusdc]

Hey @asmacdo, regarding the node shutdown issues, were the changes made to storage and conda-store resources restrictions helpful?

[asmacdo]

@viniciusdc so far no problems on staging but I haven't had a chance to try to break it yet (I want to see how the cluster recovers before we put into production).