Hi T Wang,

The kernel gateway is based on the same code as the notebook server which 
means its fundamentally a single-user service. Multitenancy is gained by 
running multiple gateways, authenticating users with an external service, 
routing all user traffic to the correct gateway instance and the kernels it 
spawns, and isolating users kernels from one another (lest one user execute 
code to discover how to talk to other user kernels).

Cheers,
Pete

On Tuesday, October 11, 2016 at 6:17:36 PM UTC-4, T Wang wrote:
>
> Hi, 
> I would like to have the Jupyter Kernel Gateway sits on my Spark cluster's 
> master / edge node.  It takes the client requests in HTTP or web-socket to 
> create different Jupyter Kernels for clients.  I have a question regarding 
> to how Jupyter Kernel Gateway handles multi-tendency.   For example, I have 
> multiple users who speak Jupyter protocol to access the Jupyter Kernel 
> Gateway remotely in order to launch Spark jobs on the cluster.  The Jupyter 
> Kernel Gateway sites on my cluster's master / edge node.  It takes the 
> requests and creates multiple Kernels, say Kernel A and Kernel B inside of 
> the Spark cluster.
>
> now I have user 1 and user 2 interactively accessing the same Kernel A and 
> user 3 and 4 accessing the kernel B.  How does Jupyter Kernel Gateway makes 
> sure that the correct users are mapped to their own kernels and isolate the 
> wrong users to access others' kernels.  Does Jupyter Kernel Gateway 
> implement impersonation? 
>
> Regards,
> Tanping
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jupyter+unsubscr...@googlegroups.com.
To post to this group, send email to jupyter@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/d3fc08cc-c46c-48f0-89b3-077693e81210%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to