Yes, agreed we need some components to manage lifecycle of interpreters. > "I agree that we need to keep same behavior even though users restart in any place." I too agree we should have same behaviour.
> Thus we must not assume that "admin" exists. In Zeppelin we can do this https://github.com/apache/zeppelin/blob/master/conf/shiro.ini.template#L82 , and when this is enabled, that is the case which concerns me. On 22 February 2017 at 23:03, Jongyoul Lee <jongy...@gmail.com> wrote: > 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 > -- Warm Regards, Prabhjyot Singh
