Expected Date: Oct 30,2019

Why are we limiting the number of researchers in this first release?

The environment scales and shrinks automatically and we have imposed a hard cap of 100 active jobs. Why are we allowing only 20 researchers initially?

• We want to be able to give 1:1 help to people getting started in Sid and by doing that to better understand where we need to bulk up documentation and where we missed usability issues in testing.  Jupyter and RStudio are based on stanard release containers but the desktop is custom.  For people who use the desktop in particular we want to be able to catch where they run into usability issues.  
• The workflow for Sid and the RCE is a bit different (and yes - we're biased - we believe it's a bit easier). We expect that Researchers will need some help in getting used to a new workflow.

If the environment auto-scales, then why limit the job size?

• Standardizing the size of the applications in this first release will also help us to work out any kinks that come up related to resource allocations and the scaling algorithms.
• Based on our research we found that although many researchers ask for more resources, it turns out that 70%+ of current RCE users fit into a 1CPU X 4GB profile.

Why just these applications?

• The same research revealed that  53% of researchers on the RCE use Python and R.
• The next most popular application is Stata which we need to work through the mechanics of the licensing for and so didn't have ready for 1.0.

Work was concentrated in these areas:

• Sid Backend Stability.
• Sid Backend Scalability (Auto-scale up and down).
• Sid Backend graceful degredation under resource pressure.
• Sid Desktop App Usability.
• Google Drive OAUTH approval process.
• Analysis of exisiting RCE researchers' resource usage patterns.
• Initial Instrumentation

Limitations:

• Confidential data storage and processing are not supported. 
• End user documentation is limited. 
• There is no global mailing list for Sid users 

Maintenance and Upgrades

Three of the four components of the system have been targeted for continuous deployment.  Updates to these components can be done outside of a maintenance window and will not impact running jobs:

Updates to the BackEnd cannot be implemented in a continuous deployment scenario and impact all running jobs.  The Sid team reserves a weekly maintenance window from Monday at 5PM through Tuesday at 9AM during which BackEnd maintenance will occur.

Not every window will have activity and when possible, users will be given 24 hour notice prior to a maintenance window being utilized.  However, users should expect their applications to be terminated without warning during the maintenance period.   Data stored on their google drive will be preserved. Data stored on local (ephemeral) storage will be lost when the job is shut down by the system at the start of maintenance.