I think we can combine scenario 2 and 3 if user click yes button on the popup window of whether you want to restart interpreter in scenario 3.
Regarding the restarting scenario of 1,2,3, IMHO I think we don't need to differentiate them. Otherwise it might confuse users that restarting in different places have different behavior. Zeppelin as a notebook should not do too much assumption and do too much extra work implicitly for users, let user to control what they want to do. IMHO I think the behavior of restarting should be just restarting the current user's interpreter and don't affect other users. If it's admin perform the restarting operation in interpreter setting page, I also think we should not restart all the users' interpreters by default. Because I think the admin's intention of updating interpreter setting is just to update the interpreter setting so that all the users can use the latest interpreter setting (e.g. update SPARK_HOME in spark interpreter setting. For now everyone share the same interpreter setting, but in the long term I think everyone should has his own setting that extend from admin's setting. But this is another story, not related to this thread ), admin doesn't want to interrupt and close the current other users' active interpreters. Of course, this is just my biased thinking, some customer may indeed want to close all the interpreters when admin perform restarting operation. Then we can provide one configuration in zeppelin-site to allow user to do that, but by default I think we should not allow admin to close all users' active interpreter. Delete is a very special scenario among them, for now I think we can terminate all the interpreter processes when interpreter is deleted. Because after interpreter is deleted, there's no way to shutdown the interpreter in zeppelin for now. If we don't close and shutdown them, then that means resource leakage. Besides these, another thing I want to mention is that there's no dedicated component or concept in zeppelin to control lifecycle of interpreter. E.g. for now if user don't restart interpreter, his interpreter will be alive forever. This is almost unacceptable for enterprise usage. I think we should have some component to do that work to manage the lifecycle of interpreter. Prabhjyot Singh <prabhjyotsi...@apache.org>于2017年2月22日周三 下午4:17写道： > This is WRT the PR that I've created > https://github.com/apache/zeppelin/pull/2034. > > The issue that I want to discuss over here is how should an Interpreter > behave when it is; > - restarted from notebook > - restarted from Interpreter setting page > - edited from Interpreter setting page > - deleted from Interpreter setting page > > > Assuming Zeppelin is being used in Enterprise world, where not all user may > have access to Zeppelin's Interpreter setting page, say only restricted > user say "admin-group" have access to this page. Now when a restart, edit > or delete action is performed from Interpreter setting page; any of this > operation should terminate all the processes of that particular > Interpreter. On the other hand if it is restarted from the notebook page by > any User, then only process of that logged-in User should get affected. > > How do you guys think of it? > > -- > > Warm Regards, > > Prabhjyot Singh >
