Multiple users on same Voila page

[echarles]

239 is a prerequisite for multi user dashboarding, but is not enough.

We need to define what the behavior would be:

1. Do we want multiple users use the same kernel and get the other user interations in realtime?
2. Do we want to disallow multiple users to view a same voila page?
3. Do we want to provide different kernels and segregrate user interactions on a same voila page?

[timkpaine]

Segregation of users is essential. For many use cases, you want users to be individually permissioned to whatever is going on in the kernel (e.g. data access)

[timkpaine]

So unless you're going to reauthenticate between interactions, separate kernels makes the most sense.

[echarles]

@timkpaine Agree that segregration with separate kernels should be the default. However, I hear use cases where power/active users would configure the dashboard views and this would become immediately live to read-only/passive users.

I would love to be able to further configure the view with:

1. User roles like read = view only, read+write = view and change the settings (like changing drop-downs to change what is displayed).
2. Kernel mode: segregated or shared.

eg. for segregated kernels, a read-only user could not change the settings - I business env, this could make sense.

[echarles]

BTW Those kind of requirements should even be discussed on the jupyter server it-self, linked to the RTC (Realtime Collaboration) initiatives. Voila would simply inherit them.

[tonywang531]

May I ask what is the current behavior for the current version? Voila seems to create separate kernels for different users, is my understanding correct?

[timkpaine]

@tonywang531 yes

[jtpio]

Voila seems to create separate kernels for different users, is my understanding correct?

Yes, each user gets a dedicated kernel.

[janbucher]

Is it per user or per "opened page"? I want to run Voila in an open environment, it seems that every notebook opened with Voila roughly takes away 300 MB of RAM. So anyone with a browser can DoS the machine in half a minute..

[timkpaine]

@janbucher yep. there are a number of reasons why this is a really good feature to have

[janbucher]

I know, just wanted to clear things a bit up. I can also see that there is no easy way to make things more performant, still being clear about this in the documentation may be beneficial.

[jf---]

So anyone with a browser can DoS the machine in half a minute..

This is a pressing concern, see #95 In my view an important step would be that when the browser refreshes, that the client would reconnect to a running instance, rather than booting another kernel. That seems a reasonable first step?

[timkpaine]

what if the kernel gets into a bad state? How would the user signal they want to restart the kernel?

[jf---]

is it reasonable that a session takes on that responsibility? but the point stand DDoS voila is pretty trivial to achieve due to limitations of the design, its challenging to take it in production because of this. Therefore, I do think its interesting to explore this topic more thoroughly and be explicit about this design choice / current limitation

[timkpaine]

its challenging to take it in production because of this

A very easy way around this is rlimits and nice-ness, which you can do pretty easily. This is what we do in our production deployments

[tonywang531]

At the moment voila seems to create kernels per instance for the same user. I was testing with opening 5 instances of voila before the server crashes. The server has 32GB of ram and still cannot to cope with it (each kernel is takes around 3G probably due to loading a huge dataframe).

[timkpaine]

@tonywang531 so whats the proposition for an alternative? jupyter doesn't have the ability for concurrent users to interact with kernel state and have frontends synchronize these modifications.