Yes, we can set some roles by Shiro but what I mean is we didn't implement role-based functions like hiding or showing some menu.
On Thu, Feb 23, 2017 at 12:17 PM, Prabhjyot Singh <prabhjyotsi...@apache.org > wrote: > 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 > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
