In my opinion, I don't think we drop the default interpreter feature. We are changing that behavior and in current master, we don't have a feature to select default interpreter yet.
On Wed, Oct 3, 2018 at 3:11 AM liuxun <[email protected]> wrote: > I also have some confusion about interpreter binding. I have the > following ideas: > Storage problem with interpreter configuration？ > It is necessary to store the interpreter through the interpreter.json > file. If there are multiple different zeppelin instances, we can unify the > interpreter by copying the interpreter.json file. > Does the note require a default interpreter? > The default interpreter for each note binding, I find it easy to confuse > users, users need to remember which note's default interpreter is what. > The note in the program can be bound to the default interpreter or not, > which makes the code a bit more complicated. > I recommend that each note must specify an interpreter. > It takes only 2 seconds to specify the interpreter, so that the user is > not confused, and it makes things clearer. I think it is more important. > Optimize how the interpreter is specified > The interpreter should be grouped by type(eg. spark, md ...). For example, > the spark interpreter group contains all the interpreters for all spark1.x > or spark2.x created by the system administrator. Different spark.yarn.queue > in the spark interpreter of different user groups in our usage scenario > requires different spark interpreters. > we can use a dynamic form to allow users to easily select different > interpreters and parameters. > For example, select the spark by the drop-down box, select spark1.X, and > then select %pyspark. > > > > > 在 2018年10月3日，上午12:34，[email protected] 写道： > > > > Sorry I see a breaking change here: Or can you explain, how (from 0.9.0 > on) users can change the default interpreter for existing notes, in case > they only use short syntax (e.g. %spark) > > > > In 0.8.0 they are used to see all available intrepreters in the > interpreter binding menu and move the default to the top of the list via > drag and drop. > > > > In current master branch the interpreter binding menu only shows the > interpreters that are currently used. So with current state of > implementation (master branch) end users are facing a breaking change when > upgrading to 0.9.0. > > > > Do you really want to drop support for changing default interpreter in > existing notes (when short syntax is used)? > > > > > > > > On 2018/09/26 22:33:58, Jongyoul Lee <[email protected]> wrote: > >> I think we can use default interpreter which would set when users create > >> a note. It's a bit natural and won't break current behaviours > >> > >> On Sat, Sep 22, 2018 at 8:16 PM, [email protected] < > >> [email protected]> wrote: > >> > >>> I agree with Jongyoul. Changing the default interpreter in an existing > >>> note is vital, especially when a note has plenty of paragraphs. > >>> > >>> E.g. we are using spark interpreter per Org Unit and also for different > >>> sizings. > >>> > >>> Our end users are using the respective Spark Interpreter just by > setting > >>> it to default and then using short syntax: %pyspark, %sql or %spark . > After > >>> some time, they want to change the default interpreter to use a > different > >>> Spark Executor Sizings or hand a note over to another Org Unit. > >>> > >>> In that situation changing full qualified names in ALL paragraphs is > not > >>> really feasible IMHO. > >>> > >>> As changing the default paragraph in existing notes is now still > missing > >>> in master branch, is there already a Jira Issue filed? I couldn't find > it > >>> in the umbrella story: > https://issues.apache.org/jira/browse/ZEPPELIN-3594 > >>> > >>> This issue is currently blocking us from early testing the master > branch > >>> with productive use cases. > >>> > >>> Thanks > >>> Andreas > >>> > >>> On 2018/07/06 07:53:04, Jeff Zhang <[email protected]> wrote: > >>>> We already allow setting default interpreter when creating note. > Another > >>>> way to set default interpreter is to reorder the interpreter setting > >>>> binding in note page. > >>>> > >>>> But personally I don't recommend user to use short interpreter name > >>> because > >>>> of default interpreter. 2 Reaons: > >>>> 1. It introduce in-accurate info. e.g. In our product, we have 2 spark > >>>> interpreters (`spark`: for spark 1.x & `spark2` for spark 2.x). Then > >>> user > >>>> often specify `%spark` for spark interpreter. But it could mean both > >>>> `%spark.spark` and `%spark2.spark`, So usually it is very hard to > tell > >>>> what's wrong when user expect to work spark2 but actually he still use > >>>> spark 1.x. So usually we would recommend user to specify the full > >>> qualified > >>>> interpreter name. Just type several more characters which just cost 2 > >>>> seconds but make it more clear and readable. > >>>> 2. Another issue is that interpreter binding is stored in > >>> interpreter.json, > >>>> that means if they export this note to another zeppelin instance, the > >>>> default interpreter won't work. > >>>> > >>>> So I don't think setting default interpreter via interpreter binding > is > >>>> valuable for users. If user really want to do that, I would suggest to > >>>> store it in note.json instead of interpreter.json > >>>> > >>>> > >>>> Jongyoul Lee <[email protected]>于2018年7月6日周五 下午3:36写道： > >>>> > >>>>> There are two purposes of interpreter binding. One is what you > >>> mentioned > >>>>> and another one is to manage a default interpreter. If we provide a > >>> new way > >>>>> to set default interpreter, I think we can remove them :-) We could > set > >>>>> permissions in other ways. > >>>>> > >>>>> Overall, +1 > >>>>> > >>>>> On Fri, Jul 6, 2018 at 4:24 PM, Jeff Zhang <[email protected]> wrote: > >>>>> > >>>>>> Hi Folks, > >>>>>> > >>>>>> I raise this thread to discuss whether we need the interpreter > >>> binding. > >>>>>> Currently when user create notes, they have to bind interpreters to > >>> their > >>>>>> notes in note page. Otherwise they will hit interpreter not found > >>> issue. > >>>>>> Besides that in zeppelin server side, we maintain the interpreter > >>> binding > >>>>>> info in memory as well as in interpreter.json. > >>>>>> > >>>>>> IMHO, it is not necessary to do interpreter binding. Because it just > >>> add > >>>>>> extra burden to maintain the interpreter binding info in zeppelin > >>> server > >>>>>> side, and doesn't introduce any benefits. The only benefit is that > we > >>> will > >>>>>> check whether user have permission to use this interpreter, but > >>> actually > >>>>>> zeppelin will check the permission when running paragraph, so I > don't > >>> think > >>>>>> we need to introduce interpreter binding just for this kind of > >>> permission > >>>>>> check that we will do later. > >>>>>> > >>>>>> So overall, I would suggest to remove interpreter binding feature. > >>> What > >>>>>> do you think ? > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> 이종열, Jongyoul Lee, 李宗烈 > >>>>> http://madeng.net > >>>>> > >>>> > >>> > >> > >> > >> > >> -- > >> 이종열, Jongyoul Lee, 李宗烈 > >> http://madeng.net > >> > > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
