Re: AURORA-1440 Evaluate Fenzo scheduling library

For AWS-based Aurora installations having 'tight bin packing' is critical for shutting down unused machines. I believe Fenzo helps with that, right? On Tue, Dec 29, 2015 at 9:31 AM, Bill Farner wrote: > It would also be helpful to capture the goals we hope to achieve with

Re: AURORA-1440 Evaluate Fenzo scheduling library

It would also be helpful to capture the goals we hope to achieve with the integration. We should also assess the risk of bringing it in, specifically that we won't be left maintaining it (currently it's 100% owned by netflix, mostly 1 developer AFAICT). On Tue, Dec 29, 2015 at 4:01 AM, Erb,

Re: [PROPOSAL] Use standard logging practices

On Tue, Dec 29, 2015 at 4:52 PM, Jeff Schroeder wrote: > What about using logback instead of log4j? It has some interesting benefits > over log4j and we wouldn't be the first large mesos framework to switch to > it. > > Personally, I'd love to see glog burn and die in

Re: [PROPOSAL] Use standard logging practices

What about using logback instead of log4j? It has some interesting benefits over log4j and we wouldn't be the first large mesos framework to switch to it. Personally, I'd love to see glog burn and die in a fire. On Monday, December 28, 2015, Bill Farner wrote: > We're

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

See

Re: [PROPOSAL] Use standard logging practices

On Tue, Dec 29, 2015 at 5:05 PM, John Sirois wrote: > > > On Tue, Dec 29, 2015 at 5:02 PM, Jeff Schroeder < > jeffschroe...@computer.org> wrote: > >> Primarily it is faster, uses less memory, and annotates tracebacks with >> package versions. The last one seems like a winner

Re: [PROPOSAL] Use standard logging practices

On Tue, Dec 29, 2015 at 5:02 PM, Jeff Schroeder wrote: > Primarily it is faster, uses less memory, and annotates tracebacks with > package versions. The last one seems like a winner for debugging user > issues or operationally. > >

Re: AURORA-1440 Evaluate Fenzo scheduling library

Some time ago I did a very quick and rough POC integrating scheduler with Fenzo just to evaluate how it may fit into our architecture. Surprisingly, it took just a few lines [1] to plug it in (without constraints support of course, which is a much bigger effort). There was also a big chunk of

Re: [PROPOSAL] Use standard logging practices

Logback can not be used as it is LGPL licensed -Jake On Tue, Dec 29, 2015 at 7:02 PM, Jeff Schroeder wrote: > Primarily it is faster, uses less memory, and annotates tracebacks with > package versions. The last one seems like a winner for debugging user > issues or

Re: Commits without reviews

Sorry for the jargon - "to be reviewed". It's a commit that is reviewed offline, with the expectation that the committer will address any comments in a follow-up patch. On Tue, Dec 29, 2015 at 8:35 PM, Henry Saputra wrote: > I am sorry, but what is TBR? > > - Henry > >

Re: [PROPOSAL] Use standard logging practices

Aha, good catch. Sounds like log4j takes the cake. On Tue, Dec 29, 2015 at 7:34 PM, Jake Farrell wrote: > Logback can not be used as it is LGPL licensed > > -Jake > > On Tue, Dec 29, 2015 at 7:02 PM, Jeff Schroeder < > jeffschroe...@computer.org> > wrote: > > > Primarily

Re: [PROPOSAL] Use standard logging practices

Looks like logback is actually dual-licensed under EPL v1.0 and LGPL. http://logback.qos.ch/license.html So technically, the logbook EPL code could be included in object/binary form http://www.apache.org/legal/resolved.html#category-b

Re: [PROPOSAL] Use standard logging practices

On Tuesday, December 29, 2015, John Sirois wrote: > On Tue, Dec 29, 2015 at 5:18 PM, John Sirois > wrote: > > > > > > > On Tue, Dec 29, 2015 at 5:05 PM, John Sirois > wrote: > > > >> > >> > >> On Tue,

Re: Commits without reviews

+1 -Jake On Wed, Dec 23, 2015 at 4:48 PM, Bill Farner wrote: > All, > > Over the past few days, i have made several commits to the repository > without code review. Our convention has historically been to perform a > code review for any change, however small. Please see

Re: Commits without reviews

The original proposal Bill made was "...for changes unrelated to build or test of the main project (e.g. scheduler, executor, client, packaging)..." +1 on either skipping the RB or TBR for any changes falling into above category. -1 for sidestepping the official review process for anything else.

Re: Commits without reviews

I'm +1 to skipping reviews for those portions of the codebase that are hard to test except via trail and error. I'm -0 to using TBR in an OSS project. In my mind TBR is for emregencies of which there should be none in an OSS infra project; these should only be in the leaves that use the OSS

Re: Commits without reviews

I’m -1 to TBR in most cases. Exceptions may be where there is clear community consensus, and a design document that has been discussed. > On Dec 29, 2015, at 11:48 PM, Bill Farner wrote: > > Sorry for the jargon - "to be reviewed". It's a commit that is reviewed > offline,

Re: [PROPOSAL] Use standard logging practices

Aha, good catch^2! On Tue, Dec 29, 2015 at 9:05 PM, Dave Lester wrote: > Looks like logback is actually dual-licensed under EPL v1.0 and LGPL. > http://logback.qos.ch/license.html > > So technically, the logbook EPL code could be

Re: [PROPOSAL] Use standard logging practices

FYI i have updated my patch to switch us to log4j as a straw man (mostly because i embarked before Dave's clarification) https://reviews.apache.org/r/41785/ I'm interested in general feedback on the patch, but encourage continued discussion on deciding between log4j and logback. On Tue, Dec 29,

Re: AURORA-1440 Evaluate Fenzo scheduling library

Someone also expressed interest in Fenzo by adding it to the community-driven roadmap [1]. AFAIK nobody has looked at in in detail, yet. Or at least nobody has posted about it on the mailinglist. Feel free to be that someone and take a closer look at what would be necessary to leverage the