You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zeppelin.apache.org by Prabhjyot Singh <pr...@apache.org> on 2017/02/22 08:17:10 UTC
[DISCUSS] Behaviour of Interpreter when it is restarted
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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
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 <prabhjyotsingh@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 <jo...@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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
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 <prabhjyotsingh@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 <jo...@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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Prabhjyot Singh <pr...@apache.org>.
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 <jo...@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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Prabhjyot Singh <pr...@apache.org>.
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 <jo...@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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
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 <zj...@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 <pr...@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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jeff Zhang <zj...@gmail.com>.
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 <pr...@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
>
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jeff Zhang <zj...@gmail.com>.
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 <pr...@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
>
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
Hi Jagat,
I'd love to listen how users use Apache Zeppelin in real world. It always
help to figure out what we have to focus on, to find out what the critical
issues are and to set the future roadmap. Can you share us - or me - detail
issues bothering you?
On Wed, Feb 22, 2017 at 5:28 PM, Jagat Singh <ja...@jagatsingh.com> wrote:
> We are implementing the exact same use case today , Trying out central
> shared zeppelin 0.7 instance in our organisation.
>
> As member of admin team we have locked down the interpreter page and
> published set of settings which we have been configured in the backend.
>
> If Interpreter settings are per user basis then only we will give the
> ability to end user to change what he needs , and behaviour you mentioned
> about restart affecting only that user job seems a good idea.
>
> One of the issue we are facing is lifecycle of interpreters , zombie
> Zeppelin processes which are left on the node where Zeppelin is installed
> and on cluster. How does restart of interpreter by end users and people
> from admin team affect those processes ?
>
> Another issue to take care is which of the change will need Zeppelin server
> to be restarted as a whole ?
>
> I can write detailed note on issues we are having with running Zeppelin in
> enterprise if you are ready to take some feedback in future backlog.
>
>
>
>
> On 22 February 2017 at 19:17, Prabhjyot Singh <pr...@apache.org>
> wrote:
>
> > 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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jongyoul Lee <jo...@gmail.com>.
Hi Jagat,
I'd love to listen how users use Apache Zeppelin in real world. It always
help to figure out what we have to focus on, to find out what the critical
issues are and to set the future roadmap. Can you share us - or me - detail
issues bothering you?
On Wed, Feb 22, 2017 at 5:28 PM, Jagat Singh <ja...@jagatsingh.com> wrote:
> We are implementing the exact same use case today , Trying out central
> shared zeppelin 0.7 instance in our organisation.
>
> As member of admin team we have locked down the interpreter page and
> published set of settings which we have been configured in the backend.
>
> If Interpreter settings are per user basis then only we will give the
> ability to end user to change what he needs , and behaviour you mentioned
> about restart affecting only that user job seems a good idea.
>
> One of the issue we are facing is lifecycle of interpreters , zombie
> Zeppelin processes which are left on the node where Zeppelin is installed
> and on cluster. How does restart of interpreter by end users and people
> from admin team affect those processes ?
>
> Another issue to take care is which of the change will need Zeppelin server
> to be restarted as a whole ?
>
> I can write detailed note on issues we are having with running Zeppelin in
> enterprise if you are ready to take some feedback in future backlog.
>
>
>
>
> On 22 February 2017 at 19:17, Prabhjyot Singh <pr...@apache.org>
> wrote:
>
> > 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
Re: [DISCUSS] Behaviour of Interpreter when it is restarted
Posted by Jagat Singh <ja...@jagatsingh.com>.
We are implementing the exact same use case today , Trying out central
shared zeppelin 0.7 instance in our organisation.
As member of admin team we have locked down the interpreter page and
published set of settings which we have been configured in the backend.
If Interpreter settings are per user basis then only we will give the
ability to end user to change what he needs , and behaviour you mentioned
about restart affecting only that user job seems a good idea.
One of the issue we are facing is lifecycle of interpreters , zombie
Zeppelin processes which are left on the node where Zeppelin is installed
and on cluster. How does restart of interpreter by end users and people
from admin team affect those processes ?
Another issue to take care is which of the change will need Zeppelin server
to be restarted as a whole ?
I can write detailed note on issues we are having with running Zeppelin in
enterprise if you are ready to take some feedback in future backlog.
On 22 February 2017 at 19:17, Prabhjyot Singh <pr...@apache.org>
wrote:
> 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
>