What does it do?

Live Events lets you quickly and easily start many containers at once. It facilitates in-person classroom style events and makes it easy to configure these events. The term “Live Events’ can be misleading. It’s often what we “sell” it for, but it doesn’t have to be a live event with everyone in the same classroom. There are other uses, including trade show booth demos.

How does it fit within our other systems?

Live Events does not rely on Tahoe or Open edX and can be run independently. It has its own event landing page for students (the Learner Dashboard).

How does it help users:

Live Events provides a cleaner experience for the management of sessions (instances of classes). It is an event-centric user experience, which is a very different workflow from the traditional, ad-hoc model. It’s easy to configure and provides a lot of control. It allows users to set go-live and expiration dates, and to cap learner and sessions. The Learner Dashboard landing page reduces barriers to getting to the actual user container. The Learner Deployments tab provides data on actual open class/session containers.

How does it help us?

Live Events reduces the burden on Appsembler during events, while making it easier for customers. These events are a signal that there is going to be increased usage, which gives us time and space to prepare in regard to support and bandwidth.

Who has access to Live Events?

Premium AVL plans include Live Events, but it can also be purchased as an add-on to any AVL plan.

How to enable Live Events for users:

Live Events is behind a feature flag. Only customers a plan that includes Live Events access will see the Events and Learner Deployments tabs. (Engineering controls the flag, at the customer level.) 

The 3 Live Event views: 

• Events tab 
  • Create, configure edit, and delete events, classes, and sessions. (Events effectively replace Projects in the workflow)

• Learner Deployments tab 
  • See which containers have been deployed for which events and sessions, as well as their current status.
  • Includes your learner emails (your users’ unique IDs) and the Deploy ID (a unique alpha-numerical string that represents your set of containers and all their data.)
  • This view will be empty if there are no running containers.
• Learner Dashboard
  • The unique URL accessed by learners to launch a container.
  • Both the URL and the title at the top of the page will reflect the name of the Event.
  • A link to the Leaner Dashboard can be included in all event materials, and people can click simply click the link and start containers right from this page.
  • No matter how many classes or sessions are added, the Learner Dashboard URL will always be the same.
  • Users enter their email address to “Sign in“ (this button really needs another name…)

Optional configurations for setting up Live Events:

Volume Images (aka, paired images)

You can have two images for the same event class. Eventually, you will not be limited to 2 images (this is on the roadmap). The decision to pair images is about a combination of resources, technical architecture, and user experience considerations. Each docker container should have one process/piece of software running. For example, you may have a wep app and a database. They would be in two different images, and would start together in two different containers. 

Learner info template

This field defines what is rendered to the user after they request to start a container. This field accepts HTML; a basic version is pre-populated with content that will work in many cases, but can also be edited. Click Show/hide help to see available variables.
 
[[ AWAITING LINK link from BDant to HS doc on variables ]]

Cloud URLs for Learners
This field allows you to connect one external URL to each container. For example, if you’ve started a VM for each student in another Cloud service, you would attach the URLs here. If a user would like to use this feature, they will need to ask.

(For full details on setting up a Live Event, see Creating your Virtual Labs Live Event)

Live Events FAQs

(This part is a work in progress, but there’s enough good info here to go ahead and publish while it’s still under construction)

Can the limits on an event be altered once an event has started?
Yes, these specifications can be altered in Django admin, but cannot be altered by users.

Are Containers automatically stopped and deleted when the Live Event ends? Or does the admin need to expire them?
Containers are automatically stopped and deleted.

What is the difference between ‘Expire’ and “Cleaned up’?

• Expired = the delete process has started. A container is expired when it hits the expiration date, then it can take a minute to actually stop the container.
• Cleaned up = the delete process worked and the Docker container is truly gone.

When do the items in Expired (Cleaned up) status stop showing on the Learner Deployments view?
Never. We delete the underlying Docker container, but unlike with Projects, we keep the object in the database. This helps with retrospective, in that you can see what containers were running linked to what email, and when they were expired and cleaned up.

Can you test a Live Event ahead of time?
Live Events has a handy feature that allows ” time-spoofing.” This enables you to test your Live Event setup ahead of time, to ensure everything is ready to go for the big day. We have an article all about that called Testing your Virtual Labs Live Event.

A few notes about some wonky UI stuff on the Learner Dashboard (these are documented and hopefully will be improved soon):

• A leaner enters their email and then clicks the  Sign in button.  After you click the Sign in button, the Sign in button goes away. Entering a NEW email will bring back the Sign in button. (There is no actual authentication here, and any new email entered will result in the page behaving as if you are a new user.)
• There is no Exit button from Learner Dashboard page (and clicking back does not necessarily take you to the tab you were previously on, which can be confusing.