Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner
> > There is no process to host the observer UI when a task terminates. Aha, i didn't realize that was in reference to Steve's comment "have the executor itself host the observer web UI". I agree, that approach is encumbered for terminal tasks. On Mon, Apr 4, 2016 at 5:10 PM, Maxim Khutornenko

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko
Sorry, I should have tried harder explaining myself. There is no process to host the observer UI when a task terminates. We still want (and arguably more so) to look at terminal task details but since there is no process left to host the http server, there is no way to access that data in the

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko
I think we've discussed this option before. It falls apart for terminal tasks when executor process is not running anymore. One of the possible ways forward could be extending Mesos UI to opportunistically consume task data periodically dumped by an executor into a json file. That could cover the

Re: Are we ready to remove the observer?

2016-04-04 Thread Steve Niemitz
It seems like the easiest path forward would be to have the executor itself host the observer web UI, if the HTTP port for the UI were configured as just another port on the task, the aurora UI could just link to /mname for that instance. I think the overall "what is running on this machine" view

Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner
> > why don't we revisit the problem from the other direction and see if we > can remove checkpoints? Simplicity, again :-) If it turns out we don't need the observer anyhow, it saves a lot of time. I'm just poking at different parts to make sure we can still justify their weight. On Mon, Apr

Re: Are we ready to remove the observer?

2016-04-04 Thread Maxim Khutornenko
I am with Josh on this one. Thermos Observer UI (and especially its process graph) is one of the features universally appreciated by our customers. I am all for deprecating the Observer but only in way that retains parity with the existing functionality and hopefully enhances it. What are we

Re: Are we ready to remove the observer?

2016-04-04 Thread Joshua Cohen
If you're suggesting just going to the task directory and pulling them out of the executor logs. Yes, I could ssh into the host the task is running on and grep the task directory out of the mesos agent logs and then trawl the logs (or cat task.json), but that's much more effort than going to the

Re: Are we ready to remove the observer?

2016-04-04 Thread Bill Farner
> > 2) Providing an easy view of a process's command-line > 3) Providing a holistic view of the task config Just to check my understanding - these could be trivially handled in text/log format, right? On Mon, Apr 4, 2016 at 9:30 AM, Joshua Cohen wrote: > I'm -1 on this

Re: Are we ready to remove the observer?

2016-04-01 Thread Erb, Stephan
>From an operator and Aurora developer perspective, it would be really great to >get rid of the thermos observer quickly. However, from a user perspective the usability gap between observer and plain Mesos sandbox browsing is quite large right now. I agree with Benjamin here that it would

Re: Are we ready to remove the observer?

2016-03-31 Thread ben...@gmail.com
Is there any chance we can keep the per-process cpu and ram utilization stats? That's one of the coolest things about aurora, imo. The executor is already writing those checkpoints inside the mesos sandbox (I think?), so perhaps it could also produce the html pages that the observer currently

Re: Are we ready to remove the observer?

2016-03-31 Thread Zhitao Li
+1. On Thu, Mar 31, 2016 at 4:11 PM, Bill Farner wrote: > Assuming that the vast majority of utility provided by the observer is > sandbox/log browsing - can we remove it and link to sandbox browsing that > mesos provides? > > The rest of the information could be (or already