Built site for gh-pages

.nojekyll

@@ -1 +1 @@
-2b60b09f
+69080d1e

admins/cluster-config.html

@@ -469,7 +469,7 @@ <h1 class="title">Kubernetes Cluster Configuration</h1>
 <section id="google-kubernetes-engine" class="level2">
 <h2 class="anchored" data-anchor-id="google-kubernetes-engine">Google Kubernetes Engine</h2>
 <p>In our experience, Google Kubernetes Engine (GKE) has been the most stable, performant, and reliable managed kubernetes service. We prefer running on this when possible.</p>
-<p>A <code>gcloud container clusters create</code> command can succintly express the configuration of our kubernetes cluster. The following command represents the currently favored configuration.</p>
+<p>A <code>gcloud container clusters create</code> command can succinctly express the configuration of our kubernetes cluster. The following command represents the currently favored configuration.</p>
 <p>This creates the GKE cluster. It may host one or more node pools:</p>
 <div class="sourceCode" id="cb1"><pre class="sourceCode bash code-with-copy"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">gcloud</span> container clusters create <span class="dt">\</span></span>
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a>     <span class="at">--enable-ip-alias</span> <span class="dt">\</span></span>

admins/howto/calendar-scaler.html

@@ -493,7 +493,7 @@ <h3 class="anchored" data-anchor-id="working-on-testing-and-deploying-the-calend
 <span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="ex">pip</span> install <span class="at">-r</span> requirements.txt</span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
 <p>Any changes to the scaler code will require you to run <code>chartpress</code> to redeploy the scaler to GCP.</p>
 <p>Here is an example of how you can test any changes to <code>scaler/calendar.py</code> locally in the python interpreter:</p>
-<div class="sourceCode" id="cb2"><pre class="sourceCode python code-with-copy"><code class="sourceCode python"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="co"># these tests will use somes dates culled from the calendar with varying numbers of events.</span></span>
+<div class="sourceCode" id="cb2"><pre class="sourceCode python code-with-copy"><code class="sourceCode python"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="co"># these tests will use some dates culled from the calendar with varying numbers of events.</span></span>
 <span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><span class="im">import</span> scaler.calendar</span>
 <span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a><span class="im">import</span> datetime</span>
 <span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a><span class="im">import</span> zoneinfo</span>

admins/howto/course-config.html

@@ -457,12 +457,12 @@ <h1 class="title">Course Configuration</h1>
 
 <section id="allocating-resources" class="level2">
 <h2 class="anchored" data-anchor-id="allocating-resources">Allocating Resources</h2>
-<p>It is possible to alter administrative priviliges or resources allocations (such as memory or extra volumes) of user servers from within the deployment configuration. This is mostly useful for when resources need to be increased based on users' class enrollments. The hub must be configured to use the <a href="https://github.com/berkeley-dsep-infra/canvasauthenticator">CanvasOAuthenticator</a> which is our default. Hubs that use dummy, Google, Generic OAuth, or other authenticators are not configured to allocate additional resources in this way.</p>
+<p>It is possible to alter administrative privileges or resources allocations (such as memory or extra volumes) of user servers from within the deployment configuration. This is mostly useful for when resources need to be increased based on users' class enrollments. The hub must be configured to use the <a href="https://github.com/berkeley-dsep-infra/canvasauthenticator">CanvasOAuthenticator</a> which is our default. Hubs that use dummy, Google, Generic OAuth, or other authenticators are not configured to allocate additional resources in this way.</p>
 <p>Additionally, it is also possible to allocate resources based on the students membership of Canvas groups. This is useful if the instructor wants to dynamically grant additional resources without CI round-trips. Group management can be performed by the course staff directly from bCourses.</p>
 </section>
 <section id="implementation" class="level2">
 <h2 class="anchored" data-anchor-id="implementation">Implementation</h2>
-<p>The authenticator reads users Canvas enrollments when they login, and then assigns them to JupyterHub groups based on those affiliations. Groups are named with the format "course::{canvas_id}::enrollment_type::{canvas_role}", e.g. "course::123456::enrollment_type::teacher" or "course::234567::enrollment_type::student". Our custom kubespawner, which we define in <code>hub/values.yaml</code>, reads users' group memberships prior to spawning. It then overrides various KubeSpawner paramters based on configuration we define, using the canvas ID as the key. (see below)</p>
+<p>The authenticator reads users Canvas enrollments when they login, and then assigns them to JupyterHub groups based on those affiliations. Groups are named with the format "course::{canvas_id}::enrollment_type::{canvas_role}", e.g. "course::123456::enrollment_type::teacher" or "course::234567::enrollment_type::student". Our custom kubespawner, which we define in <code>hub/values.yaml</code>, reads users' group memberships prior to spawning. It then overrides various KubeSpawner parameters based on configuration we define, using the canvas ID as the key. (see below)</p>
 <p>Note that if a user is assigned to a new Canvas group (e.g.&nbsp;by the instructor manually, or by an automated Canvas/SIS system) while their server is already running, they will need to logout and then log back in in order for the authenticator to see the new affiliations. Restarting the user server is not sufficient.</p>
 <p>The canvas ID is somewhat opaque to infrastructure staff -- we cannot look it up ourselves nor predict what it would be based on the name of the course. This is why we must request it from the instructor.</p>
 <p>There are a number of other Canvas course attributes we could have substituted for the ID, but all had various drawbacks. An SIS ID attribute uses a consistent format that is relatively easy to predict, however it is only exposed to instructor accounts on hub login. In testing, when the Canvas admin configured student accounts to be able to read the SIS ID, we discovered that other protected SIS attributes would have been visible to all members of the course in the Canvas UI. Various friendly name attributes (e.g.&nbsp;"Statistics 123, Spring '24") were inconsistent in structure or were modifiable by the instructor. So while the Canvas ID is not predictable or easily discoverable by hub staff, it is immutable and the instructor can find it in the URL for their course.</p>
@@ -487,7 +487,7 @@ <h2 class="anchored" data-anchor-id="assigning-scopes-to-roles">Assigning Scopes
 <span id="cb1-14"><a href="#cb1-14" aria-hidden="true" tabindex="-1"></a><span class="at">        </span><span class="fu">groups</span><span class="kw">:</span></span>
 <span id="cb1-15"><a href="#cb1-15" aria-hidden="true" tabindex="-1"></a><span class="at">          </span><span class="kw">-</span><span class="at"> course::1234567::enrollment_type::teacher</span></span>
 <span id="cb1-16"><a href="#cb1-16" aria-hidden="true" tabindex="-1"></a><span class="at">          </span><span class="kw">-</span><span class="at"> course::1234567::enrollment_type::ta</span></span></code><button title="Copy to Clipboard" class="code-copy-button"><i class="bi"></i></button></pre></div>
-<p>This configuration is headed by a comment which describes the course and term and links to the github issue where the staff made the request. It defines a new role, <code>course-staff-1234567</code>, for a course with bCourse ID <code>1234567</code>. It assigns scopes for accessing and administering the servers for users in group <code>course::1234567</code>. Members of that group include all students and course staff. It also assigns scopes for viewing lists of users at /hub/admin. It assignes these scopes to members of the affiliated course staff groups.</p>
+<p>This configuration is headed by a comment which describes the course and term and links to the github issue where the staff made the request. It defines a new role, <code>course-staff-1234567</code>, for a course with bCourse ID <code>1234567</code>. It assigns scopes for accessing and administering the servers for users in group <code>course::1234567</code>. Members of that group include all students and course staff. It also assigns scopes for viewing lists of users at /hub/admin. It assigns these scopes to members of the affiliated course staff groups.</p>
 <p>This stanza is more verbose than inserting lists of users under <code>admin_users</code>, but it the privileges are more granular. We don't need to know who the individual course staff and they won't have more permissions than they need.</p>
 <p>The configuration causes JupyterHub to update information in its <code>jupyterhub.sqlite</code> database file. When this configuraition is removed, the hub does not automatically flush out the roles and scopes from the database. So after the semester is over, it is advisable to remove this configuration and also to flush out the information in the database. There is no formal process for this, although we should develop one. We can delete the database, or we can manually remove entries from the sqlite file.</p>
 </section>

admins/howto/managing-multiple-user-image-repos.html

@@ -556,7 +556,7 @@ <h4 class="anchored" data-anchor-id="stage"><code>stage</code></h4>
                         List of files to stage in the repositories. Optional, and defaults to all modified files in the repository
   -m MESSAGE, --message MESSAGE
                         Commit message to use for the changes.</code></pre>
-<p><code>stage</code> combines both <code>git add ...</code> and <code>git commit -m</code>, adding and commiting one or more files to the staging area before you push to a remote.</p>
+<p><code>stage</code> combines both <code>git add ...</code> and <code>git commit -m</code>, adding and committing one or more files to the staging area before you push to a remote.</p>
 <p>The commit message must be a text string enclosed in quotes.</p>
 <p>By default, <code>--files</code> is set to <code>.</code>, which will add all modified files to the staging area. You can also specify any number of files, separated by a space.</p>
 </section>

admins/howto/new-hub.html

@@ -511,7 +511,7 @@ <h3 class="anchored" data-anchor-id="determine-deployment-needs">Determine deplo
 <p>Small courses (and some general usage courses) can use either or both of a shared node pool and filestore to save money (Basic HDD filestore instances start at 1T).</p>
 <p>This is also a good time to determine if there are any specific software packages/libraries that need to be installed, as well as what language(s) the course will be using. This will determine which image to use, and if we will need to add additional packages to the image build.</p>
 <p>If you’re going to use an existing node pool and/or filestore instance, you can skip either or both of the following steps and pick back up at the <code>cookiecutter</code>.</p>
-<p>When creating a new hub, we also make sure to label the filestore and GKE/node pool resouces with both <code>hub</code> and <code>&lt;nodepool|filestore&gt;-deployment</code>. 99.999% of the time, the values for all three of these labels will be <code>&lt;hubname&gt;</code>.</p>
+<p>When creating a new hub, we also make sure to label the filestore and GKE/node pool resources with both <code>hub</code> and <code>&lt;nodepool|filestore&gt;-deployment</code>. 99.999% of the time, the values for all three of these labels will be <code>&lt;hubname&gt;</code>.</p>
 </section>
 <section id="creating-a-new-node-pool" class="level3">
 <h3 class="anchored" data-anchor-id="creating-a-new-node-pool">Creating a new node pool</h3>
@@ -645,7 +645,7 @@ <h3 class="anchored" data-anchor-id="create-placeholder-node-pool">Create placeh
 <li><p>Get the node name (it will look something like <code>gke-spring-2024-user-datahub-2023-01-04-fc70ea5b-67zs</code>): <code>kubectl get nodes | grep *hubname* | awk '{print $1}'</code></p></li>
 <li><p>Get the total amount of memory allocatable to pods on this node and convert to bytes: <code>bash     kubectl get node &lt;nodename&gt; -o jsonpath='{.status.allocatable.memory}'</code></p></li>
 <li><p>Get the total memory used by non-user pods/containers on this node. We explicitly ignore <code>notebook</code> and <code>pause</code>. Convert to bytes and get the sum: <code>bash     kubectl get -A pod -l 'component!=user-placeholder' \       --field-selector spec.nodeName=&lt;nodename&gt; \       -o jsonpath='{range .items[*].spec.containers[*]}{.name}{"\t"}{.resources.requests.memory}{"\n"}{end}' \       | egrep -v 'pause|notebook'</code></p></li>
-<li><p>Subract the second number from the first, and then subtract another 277872640 bytes (256Mi) for “wiggle room”.</p></li>
+<li><p>Subtract the second number from the first, and then subtract another 277872640 bytes (256Mi) for “wiggle room”.</p></li>
 <li><p>Add an entry for the new placeholder node config in <code>values.yaml</code>:</p></li>
 </ol>
 <div class="sourceCode" id="cb11"><pre class="sourceCode yaml code-with-copy"><code class="sourceCode yaml"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="fu">data102</span><span class="kw">:</span></span>

admins/howto/new-packages.html

@@ -456,7 +456,7 @@ <h1 class="title">Testing and Upgrading New Packages</h1>
 </header>
 
 
-<p>It is helpful to test package additions and upgrades for yourself before they are installed for all users. You can make sure the change behaves as you think it should, and does not break anything else. Once tested, request that the change by installed for all users by by <a href="https://github.com/berkeley-dsep-infra/datahub/issues">creating a new issue in github</a>,contacting cirriculum support staff, or creating a new pull request. Ultimately, thouroughly testing changes locally and submitting a pull request will result in the software being rolled out to everyone much faster.</p>
+<p>It is helpful to test package additions and upgrades for yourself before they are installed for all users. You can make sure the change behaves as you think it should, and does not break anything else. Once tested, request that the change by installed for all users by by <a href="https://github.com/berkeley-dsep-infra/datahub/issues">creating a new issue in github</a>,contacting cirriculum support staff, or creating a new pull request. Ultimately, thoroughly testing changes locally and submitting a pull request will result in the software being rolled out to everyone much faster.</p>
 <section id="install-a-python-package-in-your-notebook" class="level1">
 <h1>Install a python package in your notebook</h1>
 <p>When testing a notebook with new version of the package, add the following line to a cell at the beginning of your notebook.</p>

admins/howto/rebuild-hub-image.html

@@ -416,7 +416,7 @@ <h1 class="title">Customize the Hub Docker Image</h1>
 <li>Run <code>gcloud auth configure-docker us-central1-docker.pkg.dev</code> <em>once per machine</em> to setup docker for authentication with the <a href="https://cloud.google.com/artifact-registry/docs/docker/authentication">gcloud credential helper</a>.</li>
 <li>Modify the image in <code>images/hub</code> and make a git commit.</li>
 <li>Run <code>chartpress --push</code>. This will build and push the hub image, and modify <code>hub/values.yaml</code> appropriately.</li>
-<li>Make a commit with the <code>hub/values.yaml</code> file, so the new hub image name and tag are comitted.</li>
+<li>Make a commit with the <code>hub/values.yaml</code> file, so the new hub image name and tag are committed.</li>
 <li>Proceed to deployment as normal.</li>
 </ol>
 <p>Some of the following commands may be required to configure your environment to run the above chartpress workflow successfully:</p>

admins/howto/rebuild-postgres-image.html

@@ -410,11 +410,11 @@ <h1 class="title">Customize the Per-User Postgres Docker Image</h1>
 </header>
 
 
-<p>We provide each student on <code>data100</code> witha postgresql server. We want the <a href="https://www.postgresql.org/docs/current/plpython.html">python extension</a> installed. So we inherit from the <a href="https://hub.docker.com/_/postgres">upstream postgresql docker image</a>, and add the appropriate package.</p>
+<p>We provide each student on <code>data100</code> with a postgresql server. We want the <a href="https://www.postgresql.org/docs/current/plpython.html">python extension</a> installed. So we inherit from the <a href="https://hub.docker.com/_/postgres">upstream postgresql docker image</a>, and add the appropriate package.</p>
 <p>This image is in <code>images/postgres</code>. If you update it, you need to rebuild and push it.</p>
 <ol type="1">
 <li>Modify the image in <code>images/postgres</code> and make a git commit.</li>
-<li>Run <code>chartpress --push</code>. This will build and push the image, <em>but not put anything in YAML</em>. There is no place we can put thi in <code>values.yaml</code>, since this is only used for data100.</li>
+<li>Run <code>chartpress --push</code>. This will build and push the image, <em>but not put anything in YAML</em>. There is no place we can put this in <code>values.yaml</code>, since this is only used for data100.</li>
 <li>Notice the image name + tag from the <code>chartpress --push</code> command, and put it in the appropriate place (under <code>extraContainers</code>) in <code>data100/config/common.yaml</code>.</li>
 <li>Make a commit with the new tag in <code>data100/config/common.yaml</code>.</li>
 <li>Proceed to deploy as normal.</li>

incidents/2017-03-20-too-many-volumes.html

@@ -446,7 +446,7 @@ <h2 class="anchored" data-anchor-id="summary">Summary</h2>
 <h2 class="anchored" data-anchor-id="timeline">Timeline</h2>
 <section id="march-18-1630" class="level3">
 <h3 class="anchored" data-anchor-id="march-18-1630">March 18, 16:30</h3>
-<p>RAM per student is <a href="https://github.com/data-8/infrastructure/issues/16">reduced</a> from 2G to 1G, as a resource optimization measure. The size of our nodes remains the same (26G RAM), and many are cordonned off and slowly decomissioned over the coming few days.</p>
+<p>RAM per student is <a href="https://github.com/data-8/infrastructure/issues/16">reduced</a> from 2G to 1G, as a resource optimization measure. The size of our nodes remains the same (26G RAM), and many are cordonned off and slowly decommissioned over the coming few days.</p>
 <p>Life seems fine, given the circumstances.</p>
 </section>
 <section id="march-20-1244" class="level3">
@@ -467,7 +467,7 @@ <h3 class="anchored" data-anchor-id="section-1">13:03</h3>
 </section>
 <section id="section-2" class="level3">
 <h3 class="anchored" data-anchor-id="section-2">13:04</h3>
-<p>The simple autoscaler is stopped, on fear that it’ll be confused by the unusal mixed state of the nodes and do something wonky.</p>
+<p>The simple autoscaler is stopped, on fear that it’ll be confused by the unusual mixed state of the nodes and do something wonky.</p>
 </section>
 <section id="section-3" class="level3">
 <h3 class="anchored" data-anchor-id="section-3">13:11</h3>