Basically, I agree that we need to keep same behavior even though users restart in any place. I don't have any preference between restarting all processes and starting user's process but currently Zeppelin doesn't have any "admin" feature and no concept like admin by default. Thus we must not assume that "admin" exists. And in my opinion, we need to treat "edit/delete" action as special cases because these are disruptive thus all interpreters should be shutdown.
And as Jeff mentioned - I'm not sure if this issue is related or not -, we need some components to manage lifecycle of interpreters. On Wed, Feb 22, 2017 at 6:18 PM, Jeff Zhang <zjf...@gmail.com> wrote: > > 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 >> > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
