Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

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, 2015 at 9:55 PM, Bill Farner  wrote:

> 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 included in object/binary
>> form http://www.apache.org/legal/resolved.html#category-b <
>> http://www.apache.org/legal/resolved.html#category-b>
>>
>> > On Dec 29, 2015, at 10: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 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.
>> >>
>> >> http://logback.qos.ch/reasonsToSwitch.html
>> >>
>> >> I'm not strongly opinionated either way, but it does seem like a better
>> >> log4j.
>> >>
>> >> On Tuesday, December 29, 2015, Bill Farner  wrote:
>> >>
>> >>> I don't have a strong opinion about logback vs log4j.  Can you
>> summarize
>> >>> some of the tradeoffs?
>> >>>
>> >>> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
>> >>> jeffschroe...@computer.org >
>> >>> 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 a fire.
>> 
>>  On Monday, December 28, 2015, Bill Farner > >>> > wrote:
>> 
>> > We're currently using some logging scaffolding carried over from
>> >>> Twitter
>> > commons.  I would like to propose that we dismantle some of this in
>> >>> favor
>> > of more standard java application logging conventions.
>> >
>> > Concretely, i propose we remove the following scheduler command line
>> > arguments:
>> > -logtostderr
>> > -alsologtostderr
>> > -vlog
>> > -vmodule
>> > -use_glog_formatter
>> >
>> > Instead of these, we can allow users to customize logging via
>> >> standard
>> > java.util.logging inputs (e.g. logging.properties).  We could
>> explore
>>  using
>> > an alternative to java.util.logging, but i suggest we retain that
>> >>> backend
>> > for now (since it's what we're currently using).
>> >
>> 
>> 
>>  --
>>  Text by Jeff, typos by iPhone
>> 
>> >>>
>> >>
>> >>
>> >> --
>> >> Text by Jeff, typos by iPhone
>> >>
>>
>>
>

Re: Commits without reviews

[Maxim Khutornenko]

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.

On Tue, Dec 29, 2015 at 8:51 PM, Dave Lester  wrote:
> 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, 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
>>>
>>> On Tue, Dec 29, 2015 at 8:00 PM, John Sirois  wrote:
 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 projects where the right answer should
 generally be one either roll back or fork/patch/custom private release
>>> for
 the emergency.
 My experience is biased by the 1 spat of TBR I personally did as
>>> encouraged
 by the core pants committers on the pants project.  This was a series of
 ~20 TBR reviews of experimental code in an exp/ dir unused by the
>>> mainline
 code, but committed to master.  The hope was that these reviews would be
 looked at and they have not been ~3 months down the road.

 On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell 
>>> wrote:

> +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 below for some
>> rationale, but i would like to propose that we allow committers to
> exercise
>> judgement on skipping code reviews for changes unrelated to build or
>>> test
>> of the main project (e.g. scheduler, executor, client, packaging).
>>> What
> do
>> you all think?
>>
>> As an example, i think the code review process is too much overhead
>>> for
>> commits like the ones below.  With these commits i was playing
> whack-a-mole
>> to get alignment between markdown rendering on
>>> github.com/apache/aurora
>> and
>> aurora.apache.org.  Skipping code review allowed me to fix things in
>>> a
>> much
>> shorter timeframe.
>>
>> commit 0d9fe18
>> Author: Bill Farner 
>> Date:   Wed Dec 23 08:31:27 2015 -0800
>>
>>Fix string interpolation for release email.
>>
>> commit df5200b
>> Author: Bill Farner 
>> Date:   Mon Dec 21 14:19:48 2015 -0800
>>
>>Fix formatting and work around anchor link issues in
>>> installing.md
>>
>> commit 21c605e
>> Author: Bill Farner 
>> Date:   Mon Dec 21 14:11:10 2015 -0800
>>
>>Fix anchor links in installing.md.
>>
>> commit 9326fa6
>> Author: Bill Farner 
>> Date:   Mon Dec 21 12:21:37 2015 -0800
>>
>>Link to install guide from docs/README.md
>>
>> commit f8e59a4
>> Author: Bill Farner 
>> Date:   Mon Dec 21 12:12:56 2015 -0800
>>
>>Fix formatting issues in installing doc.
>>
>



 --
 John Sirois
 303-512-3301
>>>
>

Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

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 included in object/binary
> form http://www.apache.org/legal/resolved.html#category-b <
> http://www.apache.org/legal/resolved.html#category-b>
>
> > On Dec 29, 2015, at 10: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 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.
> >>
> >> http://logback.qos.ch/reasonsToSwitch.html
> >>
> >> I'm not strongly opinionated either way, but it does seem like a better
> >> log4j.
> >>
> >> On Tuesday, December 29, 2015, Bill Farner  wrote:
> >>
> >>> I don't have a strong opinion about logback vs log4j.  Can you
> summarize
> >>> some of the tradeoffs?
> >>>
> >>> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> >>> jeffschroe...@computer.org >
> >>> 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 a fire.
> 
>  On Monday, December 28, 2015, Bill Farner  >>> > wrote:
> 
> > We're currently using some logging scaffolding carried over from
> >>> Twitter
> > commons.  I would like to propose that we dismantle some of this in
> >>> favor
> > of more standard java application logging conventions.
> >
> > Concretely, i propose we remove the following scheduler command line
> > arguments:
> > -logtostderr
> > -alsologtostderr
> > -vlog
> > -vmodule
> > -use_glog_formatter
> >
> > Instead of these, we can allow users to customize logging via
> >> standard
> > java.util.logging inputs (e.g. logging.properties).  We could explore
>  using
> > an alternative to java.util.logging, but i suggest we retain that
> >>> backend
> > for now (since it's what we're currently using).
> >
> 
> 
>  --
>  Text by Jeff, typos by iPhone
> 
> >>>
> >>
> >>
> >> --
> >> Text by Jeff, typos by iPhone
> >>
>
>

Re: [PROPOSAL] Use standard logging practices

[Dave Lester]

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 


> On Dec 29, 2015, at 10: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 
> 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.
>> 
>> http://logback.qos.ch/reasonsToSwitch.html
>> 
>> I'm not strongly opinionated either way, but it does seem like a better
>> log4j.
>> 
>> On Tuesday, December 29, 2015, Bill Farner  wrote:
>> 
>>> I don't have a strong opinion about logback vs log4j.  Can you summarize
>>> some of the tradeoffs?
>>> 
>>> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
>>> jeffschroe...@computer.org >
>>> 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 a fire.
 
 On Monday, December 28, 2015, Bill Farner >> > wrote:
 
> We're currently using some logging scaffolding carried over from
>>> Twitter
> commons.  I would like to propose that we dismantle some of this in
>>> favor
> of more standard java application logging conventions.
> 
> Concretely, i propose we remove the following scheduler command line
> arguments:
> -logtostderr
> -alsologtostderr
> -vlog
> -vmodule
> -use_glog_formatter
> 
> Instead of these, we can allow users to customize logging via
>> standard
> java.util.logging inputs (e.g. logging.properties).  We could explore
 using
> an alternative to java.util.logging, but i suggest we retain that
>>> backend
> for now (since it's what we're currently using).
> 
 
 
 --
 Text by Jeff, typos by iPhone
 
>>> 
>> 
>> 
>> --
>> Text by Jeff, typos by iPhone
>> 

Re: Commits without reviews

[Dave Lester]

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, 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
>> 
>> On Tue, Dec 29, 2015 at 8:00 PM, John Sirois  wrote:
>>> 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 projects where the right answer should
>>> generally be one either roll back or fork/patch/custom private release
>> for
>>> the emergency.
>>> My experience is biased by the 1 spat of TBR I personally did as
>> encouraged
>>> by the core pants committers on the pants project.  This was a series of
>>> ~20 TBR reviews of experimental code in an exp/ dir unused by the
>> mainline
>>> code, but committed to master.  The hope was that these reviews would be
>>> looked at and they have not been ~3 months down the road.
>>> 
>>> On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell 
>> wrote:
>>> 
 +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 below for some
> rationale, but i would like to propose that we allow committers to
 exercise
> judgement on skipping code reviews for changes unrelated to build or
>> test
> of the main project (e.g. scheduler, executor, client, packaging).
>> What
 do
> you all think?
> 
> As an example, i think the code review process is too much overhead
>> for
> commits like the ones below.  With these commits i was playing
 whack-a-mole
> to get alignment between markdown rendering on
>> github.com/apache/aurora
> and
> aurora.apache.org.  Skipping code review allowed me to fix things in
>> a
> much
> shorter timeframe.
> 
> commit 0d9fe18
> Author: Bill Farner 
> Date:   Wed Dec 23 08:31:27 2015 -0800
> 
>Fix string interpolation for release email.
> 
> commit df5200b
> Author: Bill Farner 
> Date:   Mon Dec 21 14:19:48 2015 -0800
> 
>Fix formatting and work around anchor link issues in
>> installing.md
> 
> commit 21c605e
> Author: Bill Farner 
> Date:   Mon Dec 21 14:11:10 2015 -0800
> 
>Fix anchor links in installing.md.
> 
> commit 9326fa6
> Author: Bill Farner 
> Date:   Mon Dec 21 12:21:37 2015 -0800
> 
>Link to install guide from docs/README.md
> 
> commit f8e59a4
> Author: Bill Farner 
> Date:   Mon Dec 21 12:12:56 2015 -0800
> 
>Fix formatting issues in installing doc.
> 
 
>>> 
>>> 
>>> 
>>> --
>>> John Sirois
>>> 303-512-3301
>> 

Re: Commits without reviews

[Bill Farner]

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
>
> On Tue, Dec 29, 2015 at 8:00 PM, John Sirois  wrote:
> > 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 projects where the right answer should
> > generally be one either roll back or fork/patch/custom private release
> for
> > the emergency.
> > My experience is biased by the 1 spat of TBR I personally did as
> encouraged
> > by the core pants committers on the pants project.  This was a series of
> > ~20 TBR reviews of experimental code in an exp/ dir unused by the
> mainline
> > code, but committed to master.  The hope was that these reviews would be
> > looked at and they have not been ~3 months down the road.
> >
> > On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell 
> wrote:
> >
> >> +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 below for some
> >> > rationale, but i would like to propose that we allow committers to
> >> exercise
> >> > judgement on skipping code reviews for changes unrelated to build or
> test
> >> > of the main project (e.g. scheduler, executor, client, packaging).
> What
> >> do
> >> > you all think?
> >> >
> >> > As an example, i think the code review process is too much overhead
> for
> >> > commits like the ones below.  With these commits i was playing
> >> whack-a-mole
> >> > to get alignment between markdown rendering on
> github.com/apache/aurora
> >> > and
> >> > aurora.apache.org.  Skipping code review allowed me to fix things in
> a
> >> > much
> >> > shorter timeframe.
> >> >
> >> > commit 0d9fe18
> >> > Author: Bill Farner 
> >> > Date:   Wed Dec 23 08:31:27 2015 -0800
> >> >
> >> > Fix string interpolation for release email.
> >> >
> >> > commit df5200b
> >> > Author: Bill Farner 
> >> > Date:   Mon Dec 21 14:19:48 2015 -0800
> >> >
> >> > Fix formatting and work around anchor link issues in
> installing.md
> >> >
> >> > commit 21c605e
> >> > Author: Bill Farner 
> >> > Date:   Mon Dec 21 14:11:10 2015 -0800
> >> >
> >> > Fix anchor links in installing.md.
> >> >
> >> > commit 9326fa6
> >> > Author: Bill Farner 
> >> > Date:   Mon Dec 21 12:21:37 2015 -0800
> >> >
> >> > Link to install guide from docs/README.md
> >> >
> >> > commit f8e59a4
> >> > Author: Bill Farner 
> >> > Date:   Mon Dec 21 12:12:56 2015 -0800
> >> >
> >> > Fix formatting issues in installing doc.
> >> >
> >>
> >
> >
> >
> > --
> > John Sirois
> > 303-512-3301
>

Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

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 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.
> >
> > http://logback.qos.ch/reasonsToSwitch.html
> >
> > I'm not strongly opinionated either way, but it does seem like a better
> > log4j.
> >
> > On Tuesday, December 29, 2015, Bill Farner  wrote:
> >
> > > I don't have a strong opinion about logback vs log4j.  Can you
> summarize
> > > some of the tradeoffs?
> > >
> > > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> > > jeffschroe...@computer.org >
> > > 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 a fire.
> > > >
> > > > On Monday, December 28, 2015, Bill Farner  > > > wrote:
> > > >
> > > > > We're currently using some logging scaffolding carried over from
> > > Twitter
> > > > > commons.  I would like to propose that we dismantle some of this in
> > > favor
> > > > > of more standard java application logging conventions.
> > > > >
> > > > > Concretely, i propose we remove the following scheduler command
> line
> > > > > arguments:
> > > > > -logtostderr
> > > > > -alsologtostderr
> > > > > -vlog
> > > > > -vmodule
> > > > > -use_glog_formatter
> > > > >
> > > > > Instead of these, we can allow users to customize logging via
> > standard
> > > > > java.util.logging inputs (e.g. logging.properties).  We could
> explore
> > > > using
> > > > > an alternative to java.util.logging, but i suggest we retain that
> > > backend
> > > > > for now (since it's what we're currently using).
> > > > >
> > > >
> > > >
> > > > --
> > > > Text by Jeff, typos by iPhone
> > > >
> > >
> >
> >
> > --
> > Text by Jeff, typos by iPhone
> >
>

Re: Commits without reviews

[Henry Saputra]

I am sorry, but what is TBR?

- Henry

On Tue, Dec 29, 2015 at 8:00 PM, John Sirois  wrote:
> 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 projects where the right answer should
> generally be one either roll back or fork/patch/custom private release for
> the emergency.
> My experience is biased by the 1 spat of TBR I personally did as encouraged
> by the core pants committers on the pants project.  This was a series of
> ~20 TBR reviews of experimental code in an exp/ dir unused by the mainline
> code, but committed to master.  The hope was that these reviews would be
> looked at and they have not been ~3 months down the road.
>
> On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell  wrote:
>
>> +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 below for some
>> > rationale, but i would like to propose that we allow committers to
>> exercise
>> > judgement on skipping code reviews for changes unrelated to build or test
>> > of the main project (e.g. scheduler, executor, client, packaging).  What
>> do
>> > you all think?
>> >
>> > As an example, i think the code review process is too much overhead for
>> > commits like the ones below.  With these commits i was playing
>> whack-a-mole
>> > to get alignment between markdown rendering on github.com/apache/aurora
>> > and
>> > aurora.apache.org.  Skipping code review allowed me to fix things in a
>> > much
>> > shorter timeframe.
>> >
>> > commit 0d9fe18
>> > Author: Bill Farner 
>> > Date:   Wed Dec 23 08:31:27 2015 -0800
>> >
>> > Fix string interpolation for release email.
>> >
>> > commit df5200b
>> > Author: Bill Farner 
>> > Date:   Mon Dec 21 14:19:48 2015 -0800
>> >
>> > Fix formatting and work around anchor link issues in installing.md
>> >
>> > commit 21c605e
>> > Author: Bill Farner 
>> > Date:   Mon Dec 21 14:11:10 2015 -0800
>> >
>> > Fix anchor links in installing.md.
>> >
>> > commit 9326fa6
>> > Author: Bill Farner 
>> > Date:   Mon Dec 21 12:21:37 2015 -0800
>> >
>> > Link to install guide from docs/README.md
>> >
>> > commit f8e59a4
>> > Author: Bill Farner 
>> > Date:   Mon Dec 21 12:12:56 2015 -0800
>> >
>> > Fix formatting issues in installing doc.
>> >
>>
>
>
>
> --
> John Sirois
> 303-512-3301

Re: Commits without reviews

[John Sirois]

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 projects where the right answer should
generally be one either roll back or fork/patch/custom private release for
the emergency.
My experience is biased by the 1 spat of TBR I personally did as encouraged
by the core pants committers on the pants project.  This was a series of
~20 TBR reviews of experimental code in an exp/ dir unused by the mainline
code, but committed to master.  The hope was that these reviews would be
looked at and they have not been ~3 months down the road.

On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell  wrote:

> +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 below for some
> > rationale, but i would like to propose that we allow committers to
> exercise
> > judgement on skipping code reviews for changes unrelated to build or test
> > of the main project (e.g. scheduler, executor, client, packaging).  What
> do
> > you all think?
> >
> > As an example, i think the code review process is too much overhead for
> > commits like the ones below.  With these commits i was playing
> whack-a-mole
> > to get alignment between markdown rendering on github.com/apache/aurora
> > and
> > aurora.apache.org.  Skipping code review allowed me to fix things in a
> > much
> > shorter timeframe.
> >
> > commit 0d9fe18
> > Author: Bill Farner 
> > Date:   Wed Dec 23 08:31:27 2015 -0800
> >
> > Fix string interpolation for release email.
> >
> > commit df5200b
> > Author: Bill Farner 
> > Date:   Mon Dec 21 14:19:48 2015 -0800
> >
> > Fix formatting and work around anchor link issues in installing.md
> >
> > commit 21c605e
> > Author: Bill Farner 
> > Date:   Mon Dec 21 14:11:10 2015 -0800
> >
> > Fix anchor links in installing.md.
> >
> > commit 9326fa6
> > Author: Bill Farner 
> > Date:   Mon Dec 21 12:21:37 2015 -0800
> >
> > Link to install guide from docs/README.md
> >
> > commit f8e59a4
> > Author: Bill Farner 
> > Date:   Mon Dec 21 12:12:56 2015 -0800
> >
> > Fix formatting issues in installing doc.
> >
>



-- 
John Sirois
303-512-3301

Re: Commits without reviews

[Jake Farrell]

+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 below for some
> rationale, but i would like to propose that we allow committers to exercise
> judgement on skipping code reviews for changes unrelated to build or test
> of the main project (e.g. scheduler, executor, client, packaging).  What do
> you all think?
>
> As an example, i think the code review process is too much overhead for
> commits like the ones below.  With these commits i was playing whack-a-mole
> to get alignment between markdown rendering on github.com/apache/aurora
> and
> aurora.apache.org.  Skipping code review allowed me to fix things in a
> much
> shorter timeframe.
>
> commit 0d9fe18
> Author: Bill Farner 
> Date:   Wed Dec 23 08:31:27 2015 -0800
>
> Fix string interpolation for release email.
>
> commit df5200b
> Author: Bill Farner 
> Date:   Mon Dec 21 14:19:48 2015 -0800
>
> Fix formatting and work around anchor link issues in installing.md
>
> commit 21c605e
> Author: Bill Farner 
> Date:   Mon Dec 21 14:11:10 2015 -0800
>
> Fix anchor links in installing.md.
>
> commit 9326fa6
> Author: Bill Farner 
> Date:   Mon Dec 21 12:21:37 2015 -0800
>
> Link to install guide from docs/README.md
>
> commit f8e59a4
> Author: Bill Farner 
> Date:   Mon Dec 21 12:12:56 2015 -0800
>
> Fix formatting issues in installing doc.
>

Re: [PROPOSAL] Use standard logging practices

[Jake Farrell]

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 operationally.
>
> http://logback.qos.ch/reasonsToSwitch.html
>
> I'm not strongly opinionated either way, but it does seem like a better
> log4j.
>
> On Tuesday, December 29, 2015, Bill Farner  wrote:
>
> > I don't have a strong opinion about logback vs log4j.  Can you summarize
> > some of the tradeoffs?
> >
> > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> > jeffschroe...@computer.org >
> > 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 a fire.
> > >
> > > On Monday, December 28, 2015, Bill Farner  > > wrote:
> > >
> > > > We're currently using some logging scaffolding carried over from
> > Twitter
> > > > commons.  I would like to propose that we dismantle some of this in
> > favor
> > > > of more standard java application logging conventions.
> > > >
> > > > Concretely, i propose we remove the following scheduler command line
> > > > arguments:
> > > > -logtostderr
> > > > -alsologtostderr
> > > > -vlog
> > > > -vmodule
> > > > -use_glog_formatter
> > > >
> > > > Instead of these, we can allow users to customize logging via
> standard
> > > > java.util.logging inputs (e.g. logging.properties).  We could explore
> > > using
> > > > an alternative to java.util.logging, but i suggest we retain that
> > backend
> > > > for now (since it's what we're currently using).
> > > >
> > >
> > >
> > > --
> > > Text by Jeff, typos by iPhone
> > >
> >
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: [PROPOSAL] Use standard logging practices

[Jeff Schroeder]

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, 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 for debugging user
> >>> issues or operationally.
> >>>
> >>> http://logback.qos.ch/reasonsToSwitch.html
> >>>
> >>> I'm not strongly opinionated either way, but it does seem like a better
> >>> log4j.
> >>>
> >>
> >> Looks like this decision is nicely  limited to a build.gradle edit:
> >> http://logback.qos.ch/reasonsToSwitch.html#slf4j
> >>
> >
> > After a brief skim of the configuration docs [1], I'm in favor of
> > switching in a follow-up RB to https://reviews.apache.org/r/41777/
> > In short - logback supports pointing to a non-root config file via a
> > system-property out of the box, this makes aurora a non-nuisance for
> > operators, they can easily modify init scripts to point to a custom
> config.
> >
> > [1] http://logback.qos.ch/manual/configuration.html
> >
>
> Ah yes, easier said than done since we have /logconfig [1][2].
> Jeff - do you feel strongly enough about this to file an issue to
> investigate / prove out perf wins / send up a change? (doing any part of
> this or all of this would wonderful and I'd be happy to review).


I would if I had the free time to work on it, which I'm unlikely to have
for some time. I'd rather not file more tickets for Bill to clean up in a
year. Just wanted to suggest it as an option if the work is going to be
done regardless.


-- 
Text by Jeff, typos by iPhone

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

[Apache Jenkins Server]

See 

Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

FWIW configuration niceties are enough to sway me.  I can't imagine either
of them would perform poorly enough to make a difference for us.

On Tue, Dec 29, 2015 at 4:35 PM, 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, 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 for debugging user
> >>> issues or operationally.
> >>>
> >>> http://logback.qos.ch/reasonsToSwitch.html
> >>>
> >>> I'm not strongly opinionated either way, but it does seem like a better
> >>> log4j.
> >>>
> >>
> >> Looks like this decision is nicely  limited to a build.gradle edit:
> >> http://logback.qos.ch/reasonsToSwitch.html#slf4j
> >>
> >
> > After a brief skim of the configuration docs [1], I'm in favor of
> > switching in a follow-up RB to https://reviews.apache.org/r/41777/
> > In short - logback supports pointing to a non-root config file via a
> > system-property out of the box, this makes aurora a non-nuisance for
> > operators, they can easily modify init scripts to point to a custom
> config.
> >
> > [1] http://logback.qos.ch/manual/configuration.html
> >
>
> Ah yes, easier said than done since we have /logconfig [1][2].
> Jeff - do you feel strongly enough about this to file an issue to
> investigate / prove out perf wins / send up a change? (doing any part of
> this or all of this would wonderful and I'd be happy to review).
>
> [1]
>
> https://github.com/apache/aurora/blob/master/commons/src/main/java/org/apache/aurora/common/net/http/handlers/LogConfig.java
> [2]
>
> https://github.com/apache/aurora/blob/master/src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java#L221
>
> >
> >
> >>
> >>> On Tuesday, December 29, 2015, Bill Farner  wrote:
> >>>
> >>> > I don't have a strong opinion about logback vs log4j.  Can you
> >>> summarize
> >>> > some of the tradeoffs?
> >>> >
> >>> > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> >>> > jeffschroe...@computer.org >
> >>> > 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 a fire.
> >>> > >
> >>> > > On Monday, December 28, 2015, Bill Farner  >>> > > wrote:
> >>> > >
> >>> > > > We're currently using some logging scaffolding carried over from
> >>> > Twitter
> >>> > > > commons.  I would like to propose that we dismantle some of this
> in
> >>> > favor
> >>> > > > of more standard java application logging conventions.
> >>> > > >
> >>> > > > Concretely, i propose we remove the following scheduler command
> >>> line
> >>> > > > arguments:
> >>> > > > -logtostderr
> >>> > > > -alsologtostderr
> >>> > > > -vlog
> >>> > > > -vmodule
> >>> > > > -use_glog_formatter
> >>> > > >
> >>> > > > Instead of these, we can allow users to customize logging via
> >>> standard
> >>> > > > java.util.logging inputs (e.g. logging.properties).  We could
> >>> explore
> >>> > > using
> >>> > > > an alternative to java.util.logging, but i suggest we retain that
> >>> > backend
> >>> > > > for now (since it's what we're currently using).
> >>> > > >
> >>> > >
> >>> > >
> >>> > > --
> >>> > > Text by Jeff, typos by iPhone
> >>> > >
> >>> >
> >>>
> >>>
> >>> --
> >>> Text by Jeff, typos by iPhone
> >>>
> >>
> >>
> >>
> >> --
> >> John Sirois
> >> 303-512-3301
> >>
> >
> >
> >
> > --
> > John Sirois
> > 303-512-3301
> >
>
>
>
> --
> John Sirois
> 303-512-3301
>

Re: [PROPOSAL] Use standard logging practices

[John Sirois]

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 a fire.
>

The nice thing about glog _format_ is it can be used to make correlating
mesos & aurora events easier.  I'm all for making emulating the mesos log
format easy with whatever logging package we use.
Its true that aurora doesn't ship with tools to view merged logs for
mesos/aurora/thermos, but those sorts of tools are very nice to have.  That
said, it would not be hard to add a temporal translator for each to align
log lines.


>
> On Monday, December 28, 2015, Bill Farner  wrote:
>
> > We're currently using some logging scaffolding carried over from Twitter
> > commons.  I would like to propose that we dismantle some of this in favor
> > of more standard java application logging conventions.
> >
> > Concretely, i propose we remove the following scheduler command line
> > arguments:
> > -logtostderr
> > -alsologtostderr
> > -vlog
> > -vmodule
> > -use_glog_formatter
> >
> > Instead of these, we can allow users to customize logging via standard
> > java.util.logging inputs (e.g. logging.properties).  We could explore
> using
> > an alternative to java.util.logging, but i suggest we retain that backend
> > for now (since it's what we're currently using).
> >
>
>
> --
> Text by Jeff, typos by iPhone
>



-- 
John Sirois
303-512-3301

Re: [PROPOSAL] Use standard logging practices

[John Sirois]

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, 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 for debugging user
>>> issues or operationally.
>>>
>>> http://logback.qos.ch/reasonsToSwitch.html
>>>
>>> I'm not strongly opinionated either way, but it does seem like a better
>>> log4j.
>>>
>>
>> Looks like this decision is nicely  limited to a build.gradle edit:
>> http://logback.qos.ch/reasonsToSwitch.html#slf4j
>>
>
> After a brief skim of the configuration docs [1], I'm in favor of
> switching in a follow-up RB to https://reviews.apache.org/r/41777/
> In short - logback supports pointing to a non-root config file via a
> system-property out of the box, this makes aurora a non-nuisance for
> operators, they can easily modify init scripts to point to a custom config.
>
> [1] http://logback.qos.ch/manual/configuration.html
>

Ah yes, easier said than done since we have /logconfig [1][2].
Jeff - do you feel strongly enough about this to file an issue to
investigate / prove out perf wins / send up a change? (doing any part of
this or all of this would wonderful and I'd be happy to review).

[1]
https://github.com/apache/aurora/blob/master/commons/src/main/java/org/apache/aurora/common/net/http/handlers/LogConfig.java
[2]
https://github.com/apache/aurora/blob/master/src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java#L221

>
>
>>
>>> On Tuesday, December 29, 2015, Bill Farner  wrote:
>>>
>>> > I don't have a strong opinion about logback vs log4j.  Can you
>>> summarize
>>> > some of the tradeoffs?
>>> >
>>> > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
>>> > jeffschroe...@computer.org >
>>> > 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 a fire.
>>> > >
>>> > > On Monday, December 28, 2015, Bill Farner >> > > wrote:
>>> > >
>>> > > > We're currently using some logging scaffolding carried over from
>>> > Twitter
>>> > > > commons.  I would like to propose that we dismantle some of this in
>>> > favor
>>> > > > of more standard java application logging conventions.
>>> > > >
>>> > > > Concretely, i propose we remove the following scheduler command
>>> line
>>> > > > arguments:
>>> > > > -logtostderr
>>> > > > -alsologtostderr
>>> > > > -vlog
>>> > > > -vmodule
>>> > > > -use_glog_formatter
>>> > > >
>>> > > > Instead of these, we can allow users to customize logging via
>>> standard
>>> > > > java.util.logging inputs (e.g. logging.properties).  We could
>>> explore
>>> > > using
>>> > > > an alternative to java.util.logging, but i suggest we retain that
>>> > backend
>>> > > > for now (since it's what we're currently using).
>>> > > >
>>> > >
>>> > >
>>> > > --
>>> > > Text by Jeff, typos by iPhone
>>> > >
>>> >
>>>
>>>
>>> --
>>> Text by Jeff, typos by iPhone
>>>
>>
>>
>>
>> --
>> John Sirois
>> 303-512-3301
>>
>
>
>
> --
> John Sirois
> 303-512-3301
>



-- 
John Sirois
303-512-3301

Re: [PROPOSAL] Use standard logging practices

[John Sirois]

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 for debugging user
>> issues or operationally.
>>
>> http://logback.qos.ch/reasonsToSwitch.html
>>
>> I'm not strongly opinionated either way, but it does seem like a better
>> log4j.
>>
>
> Looks like this decision is nicely  limited to a build.gradle edit:
> http://logback.qos.ch/reasonsToSwitch.html#slf4j
>

After a brief skim of the configuration docs [1], I'm in favor of switching
in a follow-up RB to https://reviews.apache.org/r/41777/
In short - logback supports pointing to a non-root config file via a
system-property out of the box, this makes aurora a non-nuisance for
operators, they can easily modify init scripts to point to a custom config.

[1] http://logback.qos.ch/manual/configuration.html


>
>> On Tuesday, December 29, 2015, Bill Farner  wrote:
>>
>> > I don't have a strong opinion about logback vs log4j.  Can you summarize
>> > some of the tradeoffs?
>> >
>> > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
>> > jeffschroe...@computer.org >
>> > 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 a fire.
>> > >
>> > > On Monday, December 28, 2015, Bill Farner > > > wrote:
>> > >
>> > > > We're currently using some logging scaffolding carried over from
>> > Twitter
>> > > > commons.  I would like to propose that we dismantle some of this in
>> > favor
>> > > > of more standard java application logging conventions.
>> > > >
>> > > > Concretely, i propose we remove the following scheduler command line
>> > > > arguments:
>> > > > -logtostderr
>> > > > -alsologtostderr
>> > > > -vlog
>> > > > -vmodule
>> > > > -use_glog_formatter
>> > > >
>> > > > Instead of these, we can allow users to customize logging via
>> standard
>> > > > java.util.logging inputs (e.g. logging.properties).  We could
>> explore
>> > > using
>> > > > an alternative to java.util.logging, but i suggest we retain that
>> > backend
>> > > > for now (since it's what we're currently using).
>> > > >
>> > >
>> > >
>> > > --
>> > > Text by Jeff, typos by iPhone
>> > >
>> >
>>
>>
>> --
>> Text by Jeff, typos by iPhone
>>
>
>
>
> --
> John Sirois
> 303-512-3301
>



-- 
John Sirois
303-512-3301

Re: [PROPOSAL] Use standard logging practices

[John Sirois]

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.
>
> http://logback.qos.ch/reasonsToSwitch.html
>
> I'm not strongly opinionated either way, but it does seem like a better
> log4j.
>

Looks like this decision is nicely  limited to a build.gradle edit:
http://logback.qos.ch/reasonsToSwitch.html#slf4j


> On Tuesday, December 29, 2015, Bill Farner  wrote:
>
> > I don't have a strong opinion about logback vs log4j.  Can you summarize
> > some of the tradeoffs?
> >
> > On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> > jeffschroe...@computer.org >
> > 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 a fire.
> > >
> > > On Monday, December 28, 2015, Bill Farner  > > wrote:
> > >
> > > > We're currently using some logging scaffolding carried over from
> > Twitter
> > > > commons.  I would like to propose that we dismantle some of this in
> > favor
> > > > of more standard java application logging conventions.
> > > >
> > > > Concretely, i propose we remove the following scheduler command line
> > > > arguments:
> > > > -logtostderr
> > > > -alsologtostderr
> > > > -vlog
> > > > -vmodule
> > > > -use_glog_formatter
> > > >
> > > > Instead of these, we can allow users to customize logging via
> standard
> > > > java.util.logging inputs (e.g. logging.properties).  We could explore
> > > using
> > > > an alternative to java.util.logging, but i suggest we retain that
> > backend
> > > > for now (since it's what we're currently using).
> > > >
> > >
> > >
> > > --
> > > Text by Jeff, typos by iPhone
> > >
> >
>
>
> --
> Text by Jeff, typos by iPhone
>



-- 
John Sirois
303-512-3301

Re: [PROPOSAL] Use standard logging practices

[Jeff Schroeder]

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.

http://logback.qos.ch/reasonsToSwitch.html

I'm not strongly opinionated either way, but it does seem like a better
log4j.

On Tuesday, December 29, 2015, Bill Farner  wrote:

> I don't have a strong opinion about logback vs log4j.  Can you summarize
> some of the tradeoffs?
>
> On Tue, Dec 29, 2015 at 3:52 PM, Jeff Schroeder <
> jeffschroe...@computer.org >
> 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 a fire.
> >
> > On Monday, December 28, 2015, Bill Farner  > wrote:
> >
> > > We're currently using some logging scaffolding carried over from
> Twitter
> > > commons.  I would like to propose that we dismantle some of this in
> favor
> > > of more standard java application logging conventions.
> > >
> > > Concretely, i propose we remove the following scheduler command line
> > > arguments:
> > > -logtostderr
> > > -alsologtostderr
> > > -vlog
> > > -vmodule
> > > -use_glog_formatter
> > >
> > > Instead of these, we can allow users to customize logging via standard
> > > java.util.logging inputs (e.g. logging.properties).  We could explore
> > using
> > > an alternative to java.util.logging, but i suggest we retain that
> backend
> > > for now (since it's what we're currently using).
> > >
> >
> >
> > --
> > Text by Jeff, typos by iPhone
> >
>


-- 
Text by Jeff, typos by iPhone

Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

I don't have a strong opinion about logback vs log4j.  Can you summarize
some of the tradeoffs?

On Tue, Dec 29, 2015 at 3: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 a fire.
>
> On Monday, December 28, 2015, Bill Farner  wrote:
>
> > We're currently using some logging scaffolding carried over from Twitter
> > commons.  I would like to propose that we dismantle some of this in favor
> > of more standard java application logging conventions.
> >
> > Concretely, i propose we remove the following scheduler command line
> > arguments:
> > -logtostderr
> > -alsologtostderr
> > -vlog
> > -vmodule
> > -use_glog_formatter
> >
> > Instead of these, we can allow users to customize logging via standard
> > java.util.logging inputs (e.g. logging.properties).  We could explore
> using
> > an alternative to java.util.logging, but i suggest we retain that backend
> > for now (since it's what we're currently using).
> >
>
>
> --
> Text by Jeff, typos by iPhone
>

Re: [PROPOSAL] Use standard logging practices

[Jeff Schroeder]

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 currently using some logging scaffolding carried over from Twitter
> commons.  I would like to propose that we dismantle some of this in favor
> of more standard java application logging conventions.
>
> Concretely, i propose we remove the following scheduler command line
> arguments:
> -logtostderr
> -alsologtostderr
> -vlog
> -vmodule
> -use_glog_formatter
>
> Instead of these, we can allow users to customize logging via standard
> java.util.logging inputs (e.g. logging.properties).  We could explore using
> an alternative to java.util.logging, but i suggest we retain that backend
> for now (since it's what we're currently using).
>


-- 
Text by Jeff, typos by iPhone

Re: AURORA-1440 Evaluate Fenzo scheduling library

[Maxim Khutornenko]

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 functionality missing that would allow us to
support task preemption within Fenzo. I spoke with Sharma back then
and he had intention to explore adding it. Not sure where it ended up
though.

I still think we should explore Fenzo integration idea as it will
unlock various rich bin packing algorithms we may never get to
implement. I have heard other Mesos frameworks (besides internal
Netflix proprietary schedulers) are actively exploring Fenzo [2]. It's
interesting to see how Fenzo could help us reduce online fragmentation
and support features like soft constraints out of the box.

That said, I don't think Fenzo should be considered as a sole
scheduling algorithm but rather as a supported alternative (at least
in the first iteration). If anything, Fenzo onboarding exercise may
help us make scheduling architecture more modular and pluggable.

I agree with Bill though that adding Fenzo into Aurora should not be a
self-goal but rather a well justified effort that clearly outlines the
benefits. I'd suggest to whoever takes on exploring this route start
with an Aurora list discussion first.

Thanks,
Maxim

[1] - 
https://github.com/maxim111333/incubator-aurora/blob/fenzo_proto/src/main/java/org/apache/aurora/scheduler/filter/SchedulingFilterImpl.java#L210-L249
[2] - https://github.com/twosigma/Cook

On Tue, Dec 29, 2015 at 9:43 AM, Dobromir Montauk
 wrote:
> 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 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, Stephan > >
>> wrote:
>>
>> > 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 power of Fenzo in
>> > Aurora :-)
>> >
>> > Without checking, I would assume that the following areas might need the
>> > most effort to address:
>> > * the preemption mechanism of Aurora to make room for priority/production
>> > jobs
>> > * the work-in-progress feature using oversubscribed resources [2]
>> >
>> > Regards,
>> > Stephan
>> >
>> > [1]
>> >
>> https://docs.google.com/document/d/1vyhTZSlEPeibQm2_7HK6JXOkydO0ZllZNQZ2O3cC4_0/edit?usp=sharing
>> > [2]
>> >
>> https://docs.google.com/document/d/1r1WCHgmPJp5wbrqSZLsgtxPNj3sULfHrSFmxp2GyPTo/edit?pref=2&pli=1#heading=h.af56b6bntcao
>> >
>> > 
>> > From: Mauricio Garavaglia 
>> > Sent: Tuesday, December 29, 2015 6:02 AM
>> > To: dev@aurora.apache.org
>> > Subject: AURORA-1440 Evaluate Fenzo scheduling library
>> >
>> > Hello,
>> >
>> > I found the issue AURORA-1440
>> >  about evaluating
>> fenzo
>> > to replace the scheduling algorithm. Has there been any progress on it?
>> is
>> > the intention just replace the implementation or also expose part of the
>> > configurations that fenzo allows?
>> >
>> > It would be handy to be able to select, for example, between cpu bin
>> > packing and memory bin packing. But also take advantage of the rich
>> > scheduling constraints api that it has. I assume a lot of discussion
>> would
>> > be needed regarding how to expose them though :)
>> > Thanks
>> >
>> >
>> > Mauricio
>> >
>>

Re: [PROPOSAL] Use standard logging practices

[Bill Farner]

>
> Could we still keep the Glog formatter class so folks who want to have the
> same log formatting between the Aurora log lines and the Mesos driver
> (which prints to stderr by default) just have to add a line to their
> logging.properties?


I feel slightly uneasy about pseudo-public APIs like this in the long term,
but it makes sense for now.

FWIW you can almost match the current logging format with vanilla
logging.properties configuration:

java.util.logging.SimpleFormatter.format = %4$1.1s%1$tm%1$td
> %1$tH:%1$tM:%1$tS.%1$tL %2$s %5$s%6$s%n


which results in messages like this:

I1229 10:24:46.099 org.apache.aurora.scheduler.app.local.FakeMaster
> lambda$start$0 All offers consumed, suppressing offer cycle.


This doesn't include the thread ID we currently have in our log lines,
which has been useful in the past for forensics.  If/when we switch to
log4j, we should be able to jettison our formatter class as it appears you
can include the thread name in the log format.


On Mon, Dec 28, 2015 at 3:49 PM, Zameer Manji  wrote:

> +1
>
> Could we still keep the Glog formatter class so folks who want to have the
> same log formatting between the Aurora log lines and the Mesos driver
> (which prints to stderr by default) just have to add a line to their
> logging.properties?
>
> The alternative means users would have to build their own glog formatter
> and add it to the classpath in addition to setting the formatter in
> logging.properties which is not straight forward if you want to have
> reasonably formatted log entries between the driver and the scheduler.
>
> On Mon, Dec 28, 2015 at 2:54 PM, Bill Farner  wrote:
>
> > We're currently using some logging scaffolding carried over from Twitter
> > commons.  I would like to propose that we dismantle some of this in favor
> > of more standard java application logging conventions.
> >
> > Concretely, i propose we remove the following scheduler command line
> > arguments:
> > -logtostderr
> > -alsologtostderr
> > -vlog
> > -vmodule
> > -use_glog_formatter
> >
> > Instead of these, we can allow users to customize logging via standard
> > java.util.logging inputs (e.g. logging.properties).  We could explore
> using
> > an alternative to java.util.logging, but i suggest we retain that backend
> > for now (since it's what we're currently using).
> >
> > --
> > Zameer Manji
> >
> >
>

Re: AURORA-1440 Evaluate Fenzo scheduling library

[Dobromir Montauk]

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 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, Stephan  >
> wrote:
>
> > 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 power of Fenzo in
> > Aurora :-)
> >
> > Without checking, I would assume that the following areas might need the
> > most effort to address:
> > * the preemption mechanism of Aurora to make room for priority/production
> > jobs
> > * the work-in-progress feature using oversubscribed resources [2]
> >
> > Regards,
> > Stephan
> >
> > [1]
> >
> https://docs.google.com/document/d/1vyhTZSlEPeibQm2_7HK6JXOkydO0ZllZNQZ2O3cC4_0/edit?usp=sharing
> > [2]
> >
> https://docs.google.com/document/d/1r1WCHgmPJp5wbrqSZLsgtxPNj3sULfHrSFmxp2GyPTo/edit?pref=2&pli=1#heading=h.af56b6bntcao
> >
> > 
> > From: Mauricio Garavaglia 
> > Sent: Tuesday, December 29, 2015 6:02 AM
> > To: dev@aurora.apache.org
> > Subject: AURORA-1440 Evaluate Fenzo scheduling library
> >
> > Hello,
> >
> > I found the issue AURORA-1440
> >  about evaluating
> fenzo
> > to replace the scheduling algorithm. Has there been any progress on it?
> is
> > the intention just replace the implementation or also expose part of the
> > configurations that fenzo allows?
> >
> > It would be handy to be able to select, for example, between cpu bin
> > packing and memory bin packing. But also take advantage of the rich
> > scheduling constraints api that it has. I assume a lot of discussion
> would
> > be needed regarding how to expose them though :)
> > Thanks
> >
> >
> > Mauricio
> >
>

Re: AURORA-1440 Evaluate Fenzo scheduling library

[Bill Farner]

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, Stephan 
wrote:

> 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 power of Fenzo in
> Aurora :-)
>
> Without checking, I would assume that the following areas might need the
> most effort to address:
> * the preemption mechanism of Aurora to make room for priority/production
> jobs
> * the work-in-progress feature using oversubscribed resources [2]
>
> Regards,
> Stephan
>
> [1]
> https://docs.google.com/document/d/1vyhTZSlEPeibQm2_7HK6JXOkydO0ZllZNQZ2O3cC4_0/edit?usp=sharing
> [2]
> https://docs.google.com/document/d/1r1WCHgmPJp5wbrqSZLsgtxPNj3sULfHrSFmxp2GyPTo/edit?pref=2&pli=1#heading=h.af56b6bntcao
>
> 
> From: Mauricio Garavaglia 
> Sent: Tuesday, December 29, 2015 6:02 AM
> To: dev@aurora.apache.org
> Subject: AURORA-1440 Evaluate Fenzo scheduling library
>
> Hello,
>
> I found the issue AURORA-1440
>  about evaluating fenzo
> to replace the scheduling algorithm. Has there been any progress on it? is
> the intention just replace the implementation or also expose part of the
> configurations that fenzo allows?
>
> It would be handy to be able to select, for example, between cpu bin
> packing and memory bin packing. But also take advantage of the rich
> scheduling constraints api that it has. I assume a lot of discussion would
> be needed regarding how to expose them though :)
> Thanks
>
>
> Mauricio
>

Re: AURORA-1440 Evaluate Fenzo scheduling library

[Erb, Stephan]

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 power of Fenzo in Aurora :-)

Without checking, I would assume that the following areas might need the most 
effort to address:
* the preemption mechanism of Aurora to make room for priority/production jobs
* the work-in-progress feature using oversubscribed resources [2]

Regards,
Stephan

[1] 
https://docs.google.com/document/d/1vyhTZSlEPeibQm2_7HK6JXOkydO0ZllZNQZ2O3cC4_0/edit?usp=sharing
 
[2] 
https://docs.google.com/document/d/1r1WCHgmPJp5wbrqSZLsgtxPNj3sULfHrSFmxp2GyPTo/edit?pref=2&pli=1#heading=h.af56b6bntcao


From: Mauricio Garavaglia 
Sent: Tuesday, December 29, 2015 6:02 AM
To: dev@aurora.apache.org
Subject: AURORA-1440 Evaluate Fenzo scheduling library

Hello,

I found the issue AURORA-1440
 about evaluating fenzo
to replace the scheduling algorithm. Has there been any progress on it? is
the intention just replace the implementation or also expose part of the
configurations that fenzo allows?

It would be handy to be able to select, for example, between cpu bin
packing and memory bin packing. But also take advantage of the rich
scheduling constraints api that it has. I assume a lot of discussion would
be needed regarding how to expose them though :)
Thanks


Mauricio