[jupyter] Jupyter Enterprise Gateway 2.0 is now available!

[Kevin Bates]

We are thrilled to announce the general availability of Jupyter Enterprise 
Gateway 2.0 
!  Just 
as thrilling is the fact that this release is comprised of numerous 
contributions from over 30 individuals!

While our 1.x release focused on Hadoop YARN and Spark installations, 
release 2.0 focuses on *Kubernetes *(including support for Spark 2.4 in 
Kubernetes).  Included in 2.0 is additional support for Docker and Docker 
Swarm configurations, along with Dask on YARN.

*Jupyter Enterprise Gateway targets larger installations where 
administrators prefer to separate notebook management from the compute 
cluster.  Typically deployed on an edge node, Enterprise Gateway performs 
kernel management in coordination with the underlying resource manager of 
the cluster - distributing kernels across the cluster.  This allows the 
compute driver (i.e., kernel) to reside directly within the compute 
cluster, while notebook file management remains on the user's desktop.  In 
containerized environments, each kernel is its own container/pod, enabling 
finer-grained control of compute resources.*

Join us at: https://github.com/jupyter/enterprise_gateway

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/16dc46e2-975d-4d4c-b92f-3b3b82ece75e%40googlegroups.com.

Re: [jupyter] A modest proposal: jupyter lab should present notebooks in iframes

[Jason Grout]

And also thanks Pete for detailing how an iframe's js execution affects the
rest of the page!

On Wed, Sep 4, 2019 at 12:52 AM Afshin T. Darian  wrote:

> This has turned out to be an interesting conversation. Thanks, everyone!
>
> William, I love your pathological case. You're right, of course. I think I
> am lumping all situations where you need to kill the tab as basically on
> the same tier of user irritation.
>
> On Wed, Sep 4, 2019 at 12:25 AM Pete Blois  wrote:
>
>> As a maintainer of quite of bit of Colab's iframing infrastructure: it
>> does a good job of isolating for security but it's not great at preventing
>> the `while (true) {}` case. The reason is that if the iframe is just a
>> srcdoc iframe then it shares the same thread, so a hang there will still
>> hang your entire page. If the iframe is using a separate origin then with
>> Chrome's OOPIF
>> 
>> feature it will wedge all iframes across all tabs, in even worse ways.
>> OOPIF's are still pretty new. Today, when dealing with while (true), the
>> non-iframed error model is superior.
>>
>> I'm a strong believer in the value of the security model offered by
>> iframes, but they are non-trivial to implement.
>>
>> try opening a notebook with 500 visible cells with output in Colab, and
>>> watch things die badly, due to trying to create 500 nontrivial iframes.
>>
>> Yeah, there are a number of tricks... If the 500 cells were generated by
>> Colab then the resulting height of the output is also written to the
>> notebook file so a placeholder can be rendered instead. Then
>> IntersectionObserver is used to only render the output when it becomes
>> visible. This also helps minimize resize jank when loading a large
>> notebook. 500 cells is still... a whole lot of cells.
>>
>> On Tue, Sep 3, 2019 at 1:12 PM 'Aaron Watters' via Project Jupyter <
>> jupyter@googlegroups.com> wrote:
>>
>>> Thanks Darian,
>>>
>>> I'm concerned that there is precisely one Javascript thread shared by
>>> all notebook interfaces in Jupyter Lab.
>>> I will try to come up with an example involving animation running in
>>> multiple notebooks that causes performance degradation.
>>>
>>> I agree that iframes are difficult to deal with. I think the additional
>>> robustness might be worth it.  Regarding your specific objections:
>>>
>>> 1) dropping "dead zone" -- this may be -- I don't know.  I'm personally
>>> probably willing to sacrifice this use case.  I never "drop" anything into
>>> a notebook myself.
>>> 2) iframes can't communicate with the rest of the application -- I think
>>> you could mediate communication between iframes if necessary on the server
>>> side.
>>>
>>> Thanks for the reply and comments!  -- Aaron Watters
>>>
>>> On Tuesday, September 3, 2019 at 3:19:31 PM UTC-4, Afshin T. Darian
>>> wrote:

 Hi Aaron,

 Thanks for writing. If you have a test case that you can contrive to
 crash JupyterLab, we'd love to try to address the issue head on.

 But in the absence of that, here's what I surmise would happen if you
 did run into a notebook that causes a runaway JS thread to cause JupyterLab
 to become unresponsive:

 1. Let's say you execute a cell and its result is that the web app
 becomes unresponsive.
 2. Like many web apps, you would either refresh the tab or you would
 close it and open a new one.
 3. When the new tab opens, it would restore the state of JupyterLab to
 the last known saved state.
 4. Your broken notebook would be open and you could either close it or
 modify the contents of the offending cell.

 I think you'd basically be in the same situation you were in the
 classic notebook because of JupyterLab's layout/state restoration.

 As far as using iframes, they bring with them a lot of trouble, which
 makes them unsuitable for an application like JupyterLab. They become a
 "dead zone" in terms of drag and drop interoperability with the rest of
 what is on your screen. Also, they don't have programmatic access to the
 rest of the JupyterLab application and it makes interacting with other
 extensions quite difficult.

 Thanks again for reaching out. If you do have a test notebook you'd
 like us to look at, please reach out again or please file an issue
 https://github.com/jupyterlab/jupyterlab/issues/ so we can track it!

 Cheers!

 -Darian

 On Tue, Sep 3, 2019 at 8:17 PM Jason Grout 
 wrote:

> Thanks for commenting on this! Do you want to open an issue on the
> JupyterLab repo about this where we can discuss more in detail the
> implications?
>
> For example, someone could write a notebook opener that would use
> iframes for isolation and would work alongside everything else in jlab.
> That might be a really interesting extension idea to explore.
>
> Thanks,
>
> Jason
>

[jupyter] To access the notebook, open this file in a browser

[Marco Giansoldati]

Dear all, 

Yesterday I logged out from Jupyter notebook and today when I launched it 
from the list of programs (not the prompt) I got the message I attached to 
this post.

I was then able to enter into the Jupyter notebook and continue to work.

Yet, when I close Jupyter notebook and try to launch it again the same 
problem arises and I have to insert again the token.

Is there a way to avoid not enter any time I need to use Jupiter notebook 
the token(s) I am provided and without the need to use a password?

I tried to update jupyter notebook and anaconda, but I am always asked to 
insert a token.

The strange thing is that if I use one of the tokens I may find online, 
like here:

https://jupyter-notebook.readthedocs.io/en/stable/security.html

using this URL:

http://localhost:/?token=c8de56fa4deed24899803e93c227592aef6538f93025fe01

Then it can open a new notebook.

This is making me crazy and I was wondering if any of you is able to provide me 
a suggestion on how to get to the URL, where I was able to get once, where I 
can put the token and decide to use a password.

Many thanks

Marco



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/jupyter/e87f5919-b6bf-4964-b1f9-58374a378be4%40googlegroups.com.

Re: [jupyter] A modest proposal: jupyter lab should present notebooks in iframes

[Afshin T. Darian]

This has turned out to be an interesting conversation. Thanks, everyone!

William, I love your pathological case. You're right, of course. I think I
am lumping all situations where you need to kill the tab as basically on
the same tier of user irritation.

On Wed, Sep 4, 2019 at 12:25 AM Pete Blois  wrote:

> As a maintainer of quite of bit of Colab's iframing infrastructure: it
> does a good job of isolating for security but it's not great at preventing
> the `while (true) {}` case. The reason is that if the iframe is just a
> srcdoc iframe then it shares the same thread, so a hang there will still
> hang your entire page. If the iframe is using a separate origin then with
> Chrome's OOPIF
> 
> feature it will wedge all iframes across all tabs, in even worse ways.
> OOPIF's are still pretty new. Today, when dealing with while (true), the
> non-iframed error model is superior.
>
> I'm a strong believer in the value of the security model offered by
> iframes, but they are non-trivial to implement.
>
> try opening a notebook with 500 visible cells with output in Colab, and
>> watch things die badly, due to trying to create 500 nontrivial iframes.
>
> Yeah, there are a number of tricks... If the 500 cells were generated by
> Colab then the resulting height of the output is also written to the
> notebook file so a placeholder can be rendered instead. Then
> IntersectionObserver is used to only render the output when it becomes
> visible. This also helps minimize resize jank when loading a large
> notebook. 500 cells is still... a whole lot of cells.
>
> On Tue, Sep 3, 2019 at 1:12 PM 'Aaron Watters' via Project Jupyter <
> jupyter@googlegroups.com> wrote:
>
>> Thanks Darian,
>>
>> I'm concerned that there is precisely one Javascript thread shared by all
>> notebook interfaces in Jupyter Lab.
>> I will try to come up with an example involving animation running in
>> multiple notebooks that causes performance degradation.
>>
>> I agree that iframes are difficult to deal with. I think the additional
>> robustness might be worth it.  Regarding your specific objections:
>>
>> 1) dropping "dead zone" -- this may be -- I don't know.  I'm personally
>> probably willing to sacrifice this use case.  I never "drop" anything into
>> a notebook myself.
>> 2) iframes can't communicate with the rest of the application -- I think
>> you could mediate communication between iframes if necessary on the server
>> side.
>>
>> Thanks for the reply and comments!  -- Aaron Watters
>>
>> On Tuesday, September 3, 2019 at 3:19:31 PM UTC-4, Afshin T. Darian wrote:
>>>
>>> Hi Aaron,
>>>
>>> Thanks for writing. If you have a test case that you can contrive to
>>> crash JupyterLab, we'd love to try to address the issue head on.
>>>
>>> But in the absence of that, here's what I surmise would happen if you
>>> did run into a notebook that causes a runaway JS thread to cause JupyterLab
>>> to become unresponsive:
>>>
>>> 1. Let's say you execute a cell and its result is that the web app
>>> becomes unresponsive.
>>> 2. Like many web apps, you would either refresh the tab or you would
>>> close it and open a new one.
>>> 3. When the new tab opens, it would restore the state of JupyterLab to
>>> the last known saved state.
>>> 4. Your broken notebook would be open and you could either close it or
>>> modify the contents of the offending cell.
>>>
>>> I think you'd basically be in the same situation you were in the classic
>>> notebook because of JupyterLab's layout/state restoration.
>>>
>>> As far as using iframes, they bring with them a lot of trouble, which
>>> makes them unsuitable for an application like JupyterLab. They become a
>>> "dead zone" in terms of drag and drop interoperability with the rest of
>>> what is on your screen. Also, they don't have programmatic access to the
>>> rest of the JupyterLab application and it makes interacting with other
>>> extensions quite difficult.
>>>
>>> Thanks again for reaching out. If you do have a test notebook you'd like
>>> us to look at, please reach out again or please file an issue
>>> https://github.com/jupyterlab/jupyterlab/issues/ so we can track it!
>>>
>>> Cheers!
>>>
>>> -Darian
>>>
>>> On Tue, Sep 3, 2019 at 8:17 PM Jason Grout  wrote:
>>>
 Thanks for commenting on this! Do you want to open an issue on the
 JupyterLab repo about this where we can discuss more in detail the
 implications?

 For example, someone could write a notebook opener that would use
 iframes for isolation and would work alongside everything else in jlab.
 That might be a really interesting extension idea to explore.

 Thanks,

 Jason


 On Tue, Sep 3, 2019 at 12:09 PM 'Aaron Watters' via Project Jupyter <
 jup...@googlegroups.com> wrote:

> I have reservations about Jupyter lab and I don't want to see "classic
> notebooks" going away primarily for the following reason:
>