Containerize seashell and enable gradual rollouts with a load balancer.

[kpsuperplane]

I know we talked about this before and the idea seemed too much (especially without sudo), but if UW really wants us to make this thing a long-term, stable platform there must be some provision in UW IT services to enable this.

Also, remove the requirement that people reset their seashell everytime an update is pushed.

[yc2lee]

What were the problems that triggered this? And what exactly is it that you need? i.e. do you just need a container (so something like seashell-dev.student.cs machine but for production) or do you need the ability to create/start/stop containers (if so, where). Currently, www.student.cs is a container, but the linux.student.cs hosts are not.

Also, will doing this on its own allow people to not have to reset their seashell, or is that a separate issue with more work needed

[kpsuperplane]

Its less a problem and more looking into the future of having a stable platform than can be easily deployed, reverted, or even have extra instances added to at any given moment.

As for resetting seashell, that's a separate issue that I felt should probably be addressed at some point - it's a pain and I hear students panicking about their seashell not working every time we deploy haha

[yc2lee]

You can get sudo/root access on machines like seashell-dev.student.cs which don't have other users' accounts mounted on them. AFAIK, there's no need to have the personal .seashell folder in student's cs-teaching accounts. You can, as an example, take the cs136 classlist and create an account for every student on seashell-dev.student.cs, and then use that machine for everything you do (you can create containers there too if you want). The machine can even sit in your office if you want total control over it

EDIT: Actually I just realized that would make authentication a bit more difficult, since you won't have student.cs passwords. But you can probably still use CAS. One advantage would be that course staff can view the .seashell folder of anybody

[e45lee]

There seems to be three threads of discussion here:

1. Notifying students of Seashell updates in a nice way.
2. Load-balancing students to "test" a preproduction version of Seashell.
3. Putting Seashell on a machine for which we have root access, so we can do fancier things (load balancing, etc...)

We don't need 3 to do 1 or 2, and at least with the way Seashell is designed I'm not sure if 3 is even feasible unless we have a cluster of machines (it uses ~3-500M of RAM / student, so one would want ~500GB of RAM split across the cluster).

For 1, we could have the backend install a inotify watch on itself so when seashell-main gets overwritten it could send a push notification to refresh/reset.

For 2, this should be relatively easy to implement once we control the entire auth workflow (get rid of CAS).

[yc2lee]

so how does lxc containers play into any of those 3 things? Do we really need containers then (which is easier with root)