Conjuring is an acronmym for Self-Contained Jupyter Hub for Teaching which doesn't exactly trip off the tongue, so Conjuring it is! The purpose of Conjuring is to make it easy to deploy a local JupyterHub platform for the purposes of teaching or presenting by enabling you to bundle up your libraries, notebooks, data, and user accounts into a single docker container that can be quickly rolled out to a piece of hardware that you can take into a classroom or conference facility (see: ECQTG-19 deployment) and be confident of it performing as required.

Why do we think that this is (potentially) better solution than using AWS or Binder? There are four reasons: control, cost, ease, and flexibility.

In many teaching and presenting contexts you do not have control of the hardware or software in the room and this creates two overlapping problems:

1. From the delivery side you have the issue that many schools and conference venues not only have restricted access and bandwidth, they are also reluctant to make changes to security policies (e.g firewall/filtering rules) ro to install new software (such as Jupyter/Anaconda Python) for the delivery of a one-off workshop, class, or seminar. Moreover, there are substantial security issues that can arise if you're trying to set up user accounts for a JupyterHub deployment in the Cloud: since they're globablly accessible they need to be globally secure.
2. From the client side getting users to install and test software on their own computers before the start of a session has always been... challenging. Assuming that they're even able to install the desired software, when users present a wide range of Operating Systems and Hardware there can be all kinds of unanticipated issues such that some workshops can lose hours to just getting people to the point where the real workshop can start.

So if you can't be sure that the venue host, the Cloud, or the users will be able to support your session, what's left? This is where Conjuring comes in: it seeks to make it easy for you to set up and deploy a local JupyterHub server running on whatever hardware you have to-hand: a laptop, a small form-factor system (see: Installing on a NUC)... whatever. Running it locally, in a containerised environment that is isolated from the actual operating system, also mitigates some of the most serious security issues: your server is only visible to people on the same (sub)network (which could potentially be a Wifi router you've brought with you) and when you rebuild Conjuring for your next session all of the existing user accounts are removed (unless you want to make them persistent such as for a series of classes).

Although Cloud computing services are clearly a cost-effective and flexible way to manage JupyterHub deployments, the fact remains that the overall costs are uncertain: unless you remember to shut down the instance, users could remain connected indefinitely, data storage costs could spiral, and many schools and universities have trouble paying open-ended subscription fees. In contrast, hardware is a fixed cost and all of Conjuring's stack is either Free Open Source Software (FOSS) or just free, meaning that you will continue to benefit from improvements to the tool as they are released with no additional costs.

Meeting Notes