Update Blog “open-sourcing-workshops-on-demand-part3-understanding-the-backend”

pattdepanick · pattdepanick · commit a6730bbafe07 · 2023-04-11T09:04:28.000Z
diff --git a/content/blog/open-sourcing-workshops-on-demand-part3-understanding-the-backend.md b/content/blog/open-sourcing-workshops-on-demand-part3-understanding-the-backend.md
@@ -333,7 +333,7 @@ The **PURGE** scenario is therefore triggered on Workshops-on-Demand' deployment
 
 A﻿t the registration time, when the participant hits the register button on the frontend web portal, an entry is automatically created in the database for him. It associates the participant to a student and a workshop. It also r﻿egisters the date and start time of the workshop, sets the participant status  to 'welcome' in the database and a first email is sent to the particpant from the frontend web portal welcoming him to the Workshop-on-Demand and stating to him that within a few minutes a second email will be sent along with the necessary information (credentials and url) to connect to the workshop's environment. If for any reason, the deployment of the workshop fails and as a consequence, no API call is made back to the frontend from the backend, the frontend could remain stuck forever and so would the participant. To overcome this, we implemented a check on the frontend web portal to test this welcome status. In a normal scenario, this welcome status gets updated within less than 3 minutes. If the status is not updated within 10 minutes, we consider that something went wrong during the deployment and as a result, a **PURGE** scenario is initiated to clean up both the backend and the frontend sides of the related registration. Of course, depending of the backend sanity, some actions could also fail. But from our experience, both  frontend and backend are really reliable. 
 
-Considering now the most common case: the backend server and frontend servers can communicate but the JupyterHub server has issues to communicate with appliances. I﻿n terms of tasks associated to the **PURGE** scenario, you can see that we kept the minimal as there should not be much to clean up on the backend server. Simply consider that is a **CLEANUP** scenario without any workshop deployment.
+Considering now the most common case: the backend server and frontend servers can communicate but the JupyterHub server has issues to communicate with appliances. I﻿n terms of tasks associated to the **PURGE** scenario, you can see that we kept the minimal as there should not be much to clean up on the backend server. Simply consider that it is a **CLEANUP** scenario without any workshop deployment.
 
 We call the same tasks to begin with as we still need student ID and workshop ID.
 

-Original file line number
+Diff line change
 At the registration time, when the participant hits the register button on the frontend web portal, an entry is automatically created in the database for him. It associates the participant to a student and a workshop. It also registers the date and start time of the workshop, sets the participant status  to 'welcome' in the database and a first email is sent to the particpant from the frontend web portal welcoming him to the Workshop-on-Demand and stating to him that within a few minutes a second email will be sent along with the necessary information (credentials and url) to connect to the workshop's environment. If for any reason, the deployment of the workshop fails and as a consequence, no API call is made back to the frontend from the backend, the frontend could remain stuck forever and so would the participant. To overcome this, we implemented a check on the frontend web portal to test this welcome status. In a normal scenario, this welcome status gets updated within less than 3 minutes. If the status is not updated within 10 minutes, we consider that something went wrong during the deployment and as a result, a **PURGE** scenario is initiated to clean up both the backend and the frontend sides of the related registration. Of course, depending of the backend sanity, some actions could also fail. But from our experience, both  frontend and backend are really reliable.
 -Considering now the most common case: the backend server and frontend servers can communicate but the JupyterHub server has issues to communicate with appliances. In terms of tasks associated to the **PURGE** scenario, you can see that we kept the minimal as there should not be much to clean up on the backend server. Simply consider that is a **CLEANUP** scenario without any workshop deployment.
 +Considering now the most common case: the backend server and frontend servers can communicate but the JupyterHub server has issues to communicate with appliances. In terms of tasks associated to the **PURGE** scenario, you can see that we kept the minimal as there should not be much to clean up on the backend server. Simply consider that it is a **CLEANUP** scenario without any workshop deployment.
 We call the same tasks to begin with as we still need student ID and workshop ID.