Merge pull request #5933 from berkeley-dsep-infra/staging

merging 5929/5930/5931/5932/5934 to prod

.github/labeler.yml

@@ -127,6 +127,8 @@ node-placeholder-scaler:
   - 'deployments/stat159/**'
 'hub: stat20':
   - 'deployments/stat20/**'
+'hub: ugr01':
+  - 'deployments/ugr01/**'
 'hub: workshop':
   - 'deployments/workshop/**'
 'hub: gradebook':

deployments/ugr01/config/common.yaml

@@ -1,7 +1,7 @@
 nfsPVC:
   enabled: true
   nfs:
-    serverIP: 10.49.181.18
+    serverIP: 10.185.238.42
 
 jupyterhub:
   scheduling:

deployments/ugr01/config/prod.yaml

@@ -3,16 +3,29 @@ nfsPVC:
     shareName: shares/ugr01/prod
 
 jupyterhub:
-  ingress:
-    enabled: true
-    hosts:
-      - ugr01.datahub.berkeley.edu
-    tls:
-      - secretName: tls-cert
-        hosts:
-          - ugr01.datahub.berkeley.edu
   hub:
     db:
       pvc:
         # This also holds logs
         storage: 4Gi
+  prePuller:
+    continuous:
+      enabled: false
+  proxy:
+    service:
+      loadBalancerIP: 34.71.179.119
+    traefik:
+      extraInitContainers:
+        # This startup delay can help the k8s container network interface setup
+        # network routing of traffic to the pod, which is essential for the ACME
+        # challenge submitted by Traefik on startup to acquire a TLS certificate.
+        #
+        # Sleeping for 7 seconds has been consistently sufficient to avoid issues
+        # in GKE when this workaround was explored initially for GKE.
+        #
+        - name: startup-delay
+          image: busybox:stable
+          command: ["sh", "-c", "sleep 10"]
+    https:
+      hosts:
+        - ugr01.datahub.berkeley.edu

docs/CNAME

@@ -0,0 +1 @@
+docs.datahub.berkeley.edu

docs/_quarto.yml

@@ -1,5 +1,7 @@
 project:
   type: website
+  resources:
+    - "CNAME"
 
 website:
   navbar:

docs/admins/howto/new-image.qmd

@@ -1,37 +1,31 @@
 ---
-title: Creating a new single user image
+title: Create a New Single User Image
 ---
 
-When deploying a new hub, or moving from a shared single user server
-image, you might need to create a new image for users. We use
-[repo2docker](https://github.com/jupyterhub/repo2docker) to do this.
+You might need to create a new user image when deploying a new hub, or changing
+from a shared single user server image. We use
+[repo2docker](https://github.com/jupyterhub/repo2docker) to generate our images.
 
-There are two approaches to creating a repo2docker image: 1. Use a
-repo2docker-style image
-[template](https://github.com/berkeley-dsep-infra/datahub/tree/staging/deployments/data100/image)
-(environment.yaml, etc) 2. Use a
-[Dockerfile](https://github.com/berkeley-dsep-infra/datahub/tree/staging/deployments/datahub/images/default)
-(useful for larger/more complex images)
+There are two approaches to creating a repo2docker image:
+
+1. Use a repo2docker-style image [template](https://github.com/berkeley-dsep-infra/datahub/tree/staging/deployments/data100/image) (environment.yaml, etc)
+2. Use a [Dockerfile](https://github.com/berkeley-dsep-infra/datahub/tree/staging/deployments/datahub/images/default) (useful for larger/more complex images)
 
 Generally, we prefer to use the former approach, unless we need to
 install specific packages or utilities outside of python/apt as `root`.
 If that is the case, only a `Dockerfile` format will work.
 
-Of course, as always create a feature branch for your changes, and
-submit a PR when done.
+As always, create a feature branch for your changes, and submit a PR when done.
 
-## Find a hub to use as a template
+## Use an existing image as a template
 
 Browse through our `deployments/` directory to find a hub that is similar to
 the one you are trying to create. This will give you a good starting point.
 
-## Create the `image/` directory for your new hub
-
-Create a new directory under `deployments/` with the name of your hub. This
-directory will contain the files that will be used to create the image.
+## Create the image directory
 
-Then, copy the contents (and any subdirectories) of the source
-`image/` directory in to the new directory.
+Create a new `image/` directory in the deployment. Then copy the contents (and
+any subdirectories) of the source `image/` directory in to the new directory.
 
 ## Modify `hubploy.yaml` for the hub
 

docs/admins/howto/remove-users-orm.qmd

@@ -1,16 +1,20 @@
 ---
-title: Remove inactive users from hub ORM
+title: JupyterHub ORM Maintenance
 ---
 
+## Performance
+
 JupyterHub performance sometimes scales with the *total* number of users in its
 ORM database, rather than the number of running users. Reducing the user count
 enables the hub to restart much faster. While this issue should be addressed,
 we can work around it by deleting inactive users from the hub database once in
 a while. Note that this does not delete the user's storage.
+
 The script `scripts/delete-unused-users.py` will delete anyone who hasn't
 registered any activity in a given period of time, double checking to make sure
 they aren't active right now. This will require users to log in again the next
 time they use the hub, but that is probably fine.
+
 This should be done before the start of each semester, particularly on hubs
 with a lot of users.
 
@@ -20,8 +24,8 @@ You can run the script on your own device. The script depends on the
 `jhub_client` python library. This can be installed with
 `pip install jhub_client`.
 
-1.  You will need to acquire a JupyterHub API token with administrative
-    rights. A hub admin can go to `{hub_url}/hub/token` to create a new
-    one.
-2.  Set the environment variable `JUPYTERHUB_API_TOKEN` to the token.
-3.  Run `python scripts/delete-unused-users.py --hub_url {hub_url}`
+1. You will need to acquire a JupyterHub API token with administrative
+   rights. A hub admin can go to `{hub_url}/hub/token` to create a new
+   one.
+2. Set the environment variable `JUPYTERHUB_API_TOKEN` to the token.
+3. Run `python scripts/delete-unused-users.py --hub_url {hub_url}`