Jenkins build is back to normal : aurora-packaging-nightly #253

See

Build failed in Jenkins: aurora-packaging-nightly #252

See -- Started by timer [EnvInject] - Loading node environment variables. Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace

Build failed in Jenkins: aurora-packaging-nightly #251

See -- Started by timer [EnvInject] - Loading node environment variables. Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace

Build failed in Jenkins: aurora-packaging-nightly #250

See -- Started by timer [EnvInject] - Loading node environment variables. Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace

Re: Build failed in Jenkins: aurora-packaging-nightly #248

On Mon, Apr 4, 2016 at 7:08 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [john.sirois] Upgrade build tools. > This was a transient deb fetch error. Trying a rebuild to make sure https://r

Build failed in Jenkins: aurora-packaging-nightly #249

See -- Started by timer [EnvInject] - Loading node environment variables. Building remotely on H11 (docker Ubuntu ubuntu yahoo-not-h2) in workspace

Build failed in Jenkins: aurora-packaging-nightly #248

See Changes: [john.sirois] Upgrade build tools. -- [...truncated 28890 lines...] Get:66 http://httpredir.debian.org/debian/ jessie/main libunistring0 amd64 0.9.3-5.2+b1 [288 kB] Get:67 h

Re: Are we ready to remove the observer?

> > 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?

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 curre

Re: Are we ready to remove the observer?

> > It falls apart for terminal tasks when executor process is not running > anymore. This sounds important...can you recall what would not work in that scenario? I figured it would work ~identically because the observer follows the lifecycle of the task sandbox directory. On Mon, Apr 4, 2016 a

Re: Are we ready to remove the observer?

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?

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?

> > 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: [DISCUSS]: 0.13.0 release candidate

+1 On Mon, Apr 4, 2016 at 2:10 PM, Zameer Manji wrote: > +1 > > On Mon, Apr 4, 2016 at 12:27 PM, Bill Farner wrote: > >> +1, fire away >> >> On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell wrote: >> >> > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it >> > looks like we a

Re: [DISCUSS]: 0.13.0 release candidate

+1 On Mon, Apr 4, 2016 at 12:27 PM, Bill Farner wrote: > +1, fire away > > On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell wrote: > > > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it > > looks like we are about ready to cut the 0.13.0 release candidate and > start > > a

Re: Are we ready to remove the observer?

On Mon, Apr 4, 2016 at 1:47 PM, Bill Farner wrote: > We clearly have different experiences - i've never really benefited from > viewing the process graph, as most jobs have very simple sequences that > could be easily explained by a text file in the sandbox. On the contrary, > i've encountered p

Re: Are we ready to remove the observer?

But the executor would still stay around thereby distributing healthchecks, correct? On Monday, April 4, 2016, Bill Farner wrote: > We clearly have different experiences - i've never really benefited from > viewing the process graph, as most jobs have very simple sequences that > could be easily

Re: Are we ready to remove the observer?

We clearly have different experiences - i've never really benefited from viewing the process graph, as most jobs have very simple sequences that could be easily explained by a text file in the sandbox. On the contrary, i've encountered people confused by the process graph, the observer, and sandbo

Re: Are we ready to remove the observer?

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 trying

Re: Are we ready to remove the observer?

Have you recently looked at the Mesos UI, Joshua? It offers sandbox browsing similar to the chroot link of Thermos. So at least you don't have to do SSH into any box. We could link to that Mesos UI instead of the Thermos one, and Mesos could then serve a nice index.html that contains the content

Re: [DISCUSS]: 0.13.0 release candidate

+1, fire away On Mon, Apr 4, 2016 at 12:26 PM, Jake Farrell wrote: > Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it > looks like we are about ready to cut the 0.13.0 release candidate and start > a vote. I wanted to open the floor up for any last minute requests or > pa

[DISCUSS]: 0.13.0 release candidate

Other than a couple deprecation clean up tickets, in AURORA-1584 [1], it looks like we are about ready to cut the 0.13.0 release candidate and start a vote. I wanted to open the floor up for any last minute requests or patches people would like to see make it in before we finalize and cut the relea

Jenkins build is back to normal : Aurora #1447

See

Re: Are we ready to remove the observer?

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 ob

Re: Are we ready to remove the observer?

> > 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 until we have an actual

Re: Are we ready to remove the observer?

I'm -1 on this until we have an actual replacement for the Observer. I think that the observer provides significant value outside of just sandbox browsing: 1) Exporting task-level statistics. 2) Providing an easy view of a process's command-line 3) Providing a holistic view of the task config 4) R