Merge branch 'main' into update-release-guides

Author: viniciusdc

.github/ISSUE_TEMPLATE/documentation.yml

@@ -28,6 +28,7 @@ body:
       options:
         - label: "This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions"
           required: true
+
   - type: textarea
     validations:
       required: true
@@ -37,19 +38,6 @@ body:
         What problem(s) did you run into that caused you to request a fix to the documentation or additional
         documentation? What questions do you think we should answer?
 
-  - type: textarea
-    validations:
-      required: true
-    attributes:
-      label: Steps to Resolve this Issue
-      description: |
-        How can the problem be solved? Are there any additional steps required? Do any other pages need to be updated?
-      value: |
-        1.
-        2.
-        3.
-        ...
-
   - type: markdown
     attributes:
       value: >

.github/workflows/test-website.yml

@@ -19,7 +19,7 @@ jobs:
         run: echo "::set-output name=dir::$(yarn cache dir)"
 
       - name: Cache dependencies 🧪
-        uses: actions/cache@v2
+        uses: actions/cache@v4
         id: yarn-cache
         with:
           path: ${{ steps.yarn-cache-dir-path.outputs.dir }}

.pre-commit-config.yaml

@@ -17,7 +17,7 @@ ci:
 repos:
   # Codespell: Spell checks the code and documentation
   - repo: https://github.com/codespell-project/codespell
-    rev: v2.3.0
+    rev: v2.4.1
     hooks:
       - id: codespell
         entry: codespell

docs/community/nebari-tests.md

@@ -91,7 +91,7 @@ To test on cloud Kubernetes, deploy Nebari in the normal way on the cloud, but m
 - [Use a development branch](#use-a-development-branch) to specify the Docker images based on the latest development code in `nebari-config.yaml`.
 
 :::warning
-Testing your contribution by deploying Nebari on the cloud (AWS, GCP, Azure, and Digital Ocean) can consume a lot of time and resources.
+Testing your contribution by deploying Nebari on the cloud (AWS, GCP, and Azure) can consume a lot of time and resources.
 Always prefer local testing when possible.
 It will be easier to debug, may be quicker to deploy, and is likely to be less expensive.
 :::

docs/docs/explanations/advanced-configuration.md

@@ -265,7 +265,6 @@ domain: demo.nebari.dev
 
 `provider`: Determines the cloud provider used to deploy infrastructure related resources on Nebari. Possible values are:
 
-- `do` for DigitalOcean
 - `aws` for Amazon Web Services
 - `gcp` for Google Could Provider
 - `azure` for Microsoft Azure
@@ -316,7 +315,7 @@ The CI/CD workflow that is best for you will depend on your organization, but th
 - Advanced Nebari users may also want to add a step in their deployment flow that includes a `nebari render` so that the administrator may preview the resulting diffs to IaC and/or CI/CD files before `nebari deploy` is executed.
 
 :::note
-In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment. See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication), or [Digital Ocean](https://www.nebari.dev/docs/how-tos/nebari-do/#authentication) for Nebari's required variables. Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
+In order for your CI/CD pipeline to be able to deploy changes into your Nebari cloud hosting provider, you must set the appropriate authentication environment variables for your GitLab or GitHub CI/CD execution environment. See the Authentication section for deploing to [AWS](https://www.nebari.dev/docs/how-tos/nebari-aws/#authentication), [Azure](https://www.nebari.dev/docs/how-tos/nebari-azure#authentication), or [GCP](https://www.nebari.dev/docs/how-tos/nebari-gcp/#authentication) for Nebari's required variables. Guidance on how to set these for your repository/project can be found in the documentation for [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/variables) and [GitLab CI/CD](https://docs.gitlab.com/ee/ci/variables/).
 :::
 
 ### Certificates

docs/docs/explanations/advanced-profiles-settings.md

@@ -15,14 +15,27 @@ Profiles are used to control the JupyterLab user instances and Dask workers prov
 profiles:
   jupyterlab:
     - display_name: Small Instance
-      description: Stable environment with 1 cpu / 1 GB ram
+      description: Stable environment with 2 cpu / 8 GB ram
       access: all
       default: true
+      profile_options:  # optional
+        image:
+          display_name: Image
+          choices:
+            default:
+              display_name: nebari-jupyterlab:latest
+              default: true
+              kubespawner_override:
+                image: quay.io/nebari/nebari-jupyterlab:latest
+            custom:
+              display_name: my-custom-image:mytag
+              kubespawner_override:
+                image: <my-container-registry>/myOrg/my-custom-image:mytag
       kubespawner_override:
-        cpu_limit: 1
-        cpu_guarantee: 1
-        mem_limit: 1G
-        mem_guarantee: 1G
+        cpu_limit: 2
+        cpu_guarantee: 1.5
+        mem_limit: 8G
+        mem_guarantee: 6G
     - display_name: Medium Instance
     ...
 ```
@@ -35,6 +48,8 @@ Each profile under `jupyterlab` is a named JupyterLab profile.
 
 `description` is a description of the profile that will be displayed to users.
 
+`profile_options` makes it possible to set various sub-options per profile. See the [Kubespawner docs](https://jupyterhub-kubespawner.readthedocs.io/en/latest/spawner.html#kubespawner.KubeSpawner.profile_list) for more info.
+
 `kubespawner_override` field to define behavior as per the [KubeSpawner](https://jupyterhub-kubespawner.readthedocs.io/en/latest/spawner.html) API.
 
 It is possible to control which users have access to which JupyterLab profiles. Each profile has a field named `access` which can be set to `all` (default if omitted), `yaml`, or

docs/docs/explanations/advanced-provider-configuration.md

@@ -226,37 +226,6 @@ azure:
 
 </TabItem>
 
-<TabItem value="do" label="DigitalOcean">
-
-DigitalOcean has a restriction with autoscaling in that the minimum nodes allowed (`min_nodes` = 1) is one but is by far the least expensive provider even accounting for `spot/pre-emptible` instances.
-In addition, Digital Ocean doesn't have accelerator/gpu support.
-
-Digital Ocean is a good choice for trying out Nebari, but we recommend selecting a different provider for your production Nebari deployment.
-
-To see available instance types refer to [Digital Ocean Instance Types](https://www.digitalocean.com/docs/droplets/).
-Additionally the Digital Ocean cli `doctl` has [support for listing droplets](https://www.digitalocean.com/docs/apis-clis/doctl/reference/compute/droplet/list/).
-
-```yaml
-digital_ocean:
-  region: nyc3
-  kubernetes_version: "1.21.10-do.0"
-  node_groups:
-    general:
-      instance: "g-4vcpu-16gb"
-      min_nodes: 1
-      max_nodes: 1
-    user:
-      instance: "g-2vcpu-8gb"
-      min_nodes: 1
-      max_nodes: 5
-    worker:
-      instance: "g-2vcpu-8gb"
-      min_nodes: 1
-      max_nodes: 5
-```
-
-</TabItem>
-
 <TabItem value="existing" label="Existing Kubernetes clusters">
 
 Originally designed for Nebari deployments on a "local" minikube cluster, this feature has now expanded to allow users to deploy Nebari to any existing kubernetes cluster.
@@ -318,7 +287,6 @@ local:
 :::note
 Many of the cloud providers regularly update their internal **Kubernetes versions** so if you wish to specify a particular version, please check the following resources.
 This is _completely optional_ as Nebari will, by default, select the most recent version available for your preferred cloud provider:
-[Digital Ocean](https://docs.digitalocean.com/products/kubernetes/changelog/);
 [Google Cloud Platform](https://cloud.google.com/kubernetes-engine/docs/release-notes-stable);
 [Amazon Web Services](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html);
 [Microsoft Azure](https://docs.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli).

docs/docs/explanations/architecture.mdx

@@ -52,11 +52,7 @@ import TabItem from '@theme/TabItem';
 ![GCP Architecture Diagram](/img/explanations/architecture-diagram-gcp.png)
 
 </TabItem>
-<TabItem value="do" label="Digital Ocean">
 
-![DO Architecture Diagram](/img/explanations/architecture-diagram-do.png)
-
-</TabItem>
 <TabItem value="aws" label="Amazon AWS">
 
 ![AWS Architecture Diagram](/img/explanations/architecture-diagram-aws.png)

docs/docs/faq.md

@@ -48,8 +48,8 @@ If you'd like to retain the latest version of an environment and only remove spe
 ## How do I use preemptible and spot instances on Nebari?
 
 A preemptible or spot VM is an instance that you can create and run at a much lower price than normal instances. Azure
-and Google Cloud platform use the term preemptible, while AWS uses the term spot, and Digital Ocean doesn't support
-these types of instances. However, the cloud provider might stop these instances if it requires access to those
+and Google Cloud platform use the term preemptible, while AWS uses the term spot.
+However, the cloud provider might stop these instances if it requires access to those
 resources for other tasks. Preemptible instances are excess Cloud Provider's capacity, so their availability varies with
 usage.
 
@@ -84,10 +84,6 @@ Spot instances aren't supported at this moment.
 
 Preemptible instances aren't supported at this moment.
 
-##### Digital Ocean
-
-Digital Ocean doesn't support these type of instances.
-
 ## Why doesn't my code recognize the GPU(s) on Nebari?
 
 First be sure you chose a [GPU-enabled server when you selected a profile][selecting a profile]. Next, if you're using PyTorch, see [Using GPUs on Nebari][using gpus]. If it's still not working for you, be sure your environment includes a GPU-specific version of either PyTorch or TensorFlow, i.e. `pytorch-gpu` or `tensorflow-gpu`. Also note that `tensorflow>=2` includes both CPU and GPU capabilities, but if the GPU is still not recognized by the library, try removing `tensorflow` from your environment and adding `tensorflow-gpu` instead.

docs/docs/get-started/cloud-providers.mdx

@@ -36,17 +36,8 @@ import TabItem from '@theme/TabItem';
 For detailed instructions on how to deploy Nebari on **GCP** visit the [How to deploy Nebari on GCP][nebari-gcp] section.
 
 </TabItem>
-<TabItem value="do" label="Digital Ocean">
 
-<div class="text--center">
-  <img src="/img/get-started/started-digital-ocean-logo.png" width={420} />
-</div>
-
-[DigitalOcean](https://docs.digitalocean.com/products/kubernetes/) is a cloud hosting provider that offers cloud computing services and Infrastructure as a Service (IaaS) known for its pricing and scalability.
 
-For detailed instructions on how to deploy Nebari on **Digital Ocean** visit the [How to deploy Nebari on Digital Ocean][nebari-do] section.
-
-</TabItem>
 <TabItem value="aws" label="Amazon AWS">
 
 <div class="text--center">
@@ -75,7 +66,6 @@ For detailed instructions on how to deploy Nebari on **Azure** visit the [How to
 
 [nebari-aws]: /how-tos/nebari-aws.md
 [nebari-azure]: /how-tos/nebari-azure.md
-[nebari-do]: /how-tos/nebari-do.md
 [nebari-gcp]: /how-tos/nebari-gcp.md
 [nebari-local]: /how-tos/nebari-local.md
 [nebari-how-tos]: /how-tos/index.mdx