I'm not sure that many people need this, so it is hard to make a decision. I'm reluctant to change the current behavior if the result is a new papercut to 99% of users and a win for 1%. The suggested change will work for 100% of users, so if we don't want a flag then we should go with that. But I would certainly want to turn it off in our environment because it doesn't provide any value for us and would annoy our users.
On Fri, Feb 8, 2019 at 4:18 PM Sean Owen <sro...@gmail.com> wrote: > Is a flag needed? You know me, I think flags are often failures of > design, or disagreement punted to the user. I can understand retaining > old behavior under a flag where the behavior change could be > problematic for some users or facilitate migration, but this is just a > change to some UI links no? the underlying links don't change. > On Fri, Feb 8, 2019 at 5:41 PM Ryan Blue <rb...@netflix.com> wrote: > > > > I suggest using the current behavior as the default and add a flag to > implement the behavior you're suggesting: to link to the logs path in YARN > instead of directly to stderr and stdout. > > > > On Fri, Feb 8, 2019 at 3:33 PM Jungtaek Lim <kabh...@gmail.com> wrote: > >> > >> Ryan, > >> > >> actually I'm not clear about your suggestion. For me three possible > options here: > >> > >> 1. If we want to let users be able to completely rewrite log urls, > that's SPARK-26792. For SHS we already addressed it. > >> 2. We could let users turning on/off flag option to just get one url or > default two stdout/stderr urls. > >> 3. We could let users enumerate file names they want to link, and > create log links for each file. > >> > >> Which one do you suggest? > > > -- Ryan Blue Software Engineer Netflix