Graduation checklist

[Jake Farrell]

All steps on the graduation checklist from the incubator are now completed

-Jake

[VOTE] Release Apache Aurora 0.8.0 RC0

[Jake Farrell]

All,
I propose that we accept the following release candidate as the official
Apache Aurora 0.8.0 release.

Aurora 0.8.0-rc0 includes the following:
---
The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.gitf=CHANGELOGhb=0.8.0-rc0

The branch used to create the release candidate is:
https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/0.8.0-rc0

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/aurora/0.8.0-rc0/apache-aurora-0.8.0-rc0.tar.gz

The MD5 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.8.0-rc0/apache-aurora-0.8.0-rc0.tar.gz.md5

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.8.0-rc0/apache-aurora-0.8.0-rc0.tar.gz.asc

The GPG key used to sign the release are available at:
https://dist.apache.org/repos/dist/dev/aurora/KEYS

Please download, verify, and test.

The vote will close on Thu May  7 22:35:17 EDT 2015

[ ] +1 Release this as Apache Aurora 0.8.0
[ ] +0
[ ] -1 Do not release this as Apache Aurora 0.8.0 because...

I would like to get the voting started with my own +1

-Jake

Re: Review Request 33854: Fix RC verification script.

[Jake Farrell]

there should not be any drift, this is just some cleanup based on us
learning from our first couple releases. Jenkins can not cut release as it
requires committing and signing, but jenkins does currently use the same
build script as this uses to test.

-Jake



On Tue, May 5, 2015 at 2:25 PM, Zameer Manji zma...@apache.org wrote:

 To prevent this drift of our release and verification infrastructure,
 should we have CI cut a release tarball and try to verify it with this
 script?

 On Tue, May 5, 2015 at 11:14 AM, Bill Farner wfar...@apache.org wrote:

 
  ---
  This is an automatically generated e-mail. To reply, visit:
  https://reviews.apache.org/r/33854/
  ---
 
  Review request for Aurora and Jake Farrell.
 
 
  Repository: aurora
 
 
  Description
  ---
 
  Script has drifted over time, this makes it functional again.
 
 
  Diffs
  -
 
build-support/release/verify-release-candidate
  0d4d6e0c01ebe006056198d25b165b9658156653
 
  Diff: https://reviews.apache.org/r/33854/diff/
 
 
  Testing
  ---
 
  Ran it and verified 0.8.0.
 
 
  Thanks,
 
  Bill Farner
 
  --
  Zameer Manji
 
 

Re: ASF Board Report - Initial Reminder for June 2015

[Jake Farrell]

I'll take care of it

-Jake

On Sun, Jun 7, 2015 at 2:38 PM, Bill Farner wfar...@twopensource.com
wrote:

 Is anyone else willing/able to pick up the board report for this month?  I
 am out of the country, returning the day it is due.

 -- Forwarded message --
 From: *Marvin* no-re...@apache.org
 Date: Sunday, June 7, 2015
 Subject: ASF Board Report - Initial Reminder for June 2015
 To: Bill Farner wfar...@twopensource.com


 Subject: ASF Board Report - Initial Reminder for June 2015

 This email was sent by an automated system on behalf of the ASF Board.
 It is an initial reminder to give you plenty of time to prepare the report.

 The meeting is scheduled for Wed, 17 Jun 2015 10:30 PDT and the deadline
 for
 submitting your report is 1 full week prior to that (Wed Jun 10th)!

 According to board records, you are listed as the chair of at least one
 committee that is due to submit a report this month. [1] [2]

 Details on which project reports are due and how to submit a report
 are enclosed below.

 Please submit your report with sufficient time to allow the board members
 to review and digest. Again, the very latest you should submit your report
 is 1 full week (7days) prior to the board meeting (Wed Jun 10th).

 If you feel that an error has been made, please consult [1] and if there
 is still an issue then contact the board directly.

 As always, PMC chairs are welcome to attend the board meeting.

 Thanks,
 The ASF Board

 [1] -
 https://svn.apache.org/repos/private/committers/board/committee-info.txt
 [2] - https://svn.apache.org/repos/private/committers/board/calendar.txt
 [3] - https://svn.apache.org/repos/private/committers/board/templates
 [4] - https://reporter.apache.org/


 Submitting your Report
 --

 Full details about the process and schedule are in [1].

 The report should be committed to the meeting agenda in the board directory
 in the foundation repository, trying to keep a similar format to the
 others.
 This can be found at:

   https://svn.apache.org/repos/private/foundation/board

 Reports can also be posted using the online agenda tool:

   https://whimsy.apache.org/board/agenda/2015-06-17/Aurora

 Your report should also be sent in plain-text format to bo...@apache.org
 javascript:;
 with a Subject line that follows the below format:

 Subject: [REPORT] Project Name

 Cutting and pasting directly from a Wiki is not acceptable due to
 formatting
 issues. Line lengths should be limited to 77 characters.

 Chairs may use the Apache Reporter Service [4] to help them compile and
 submit a board report.


 Resolutions
 ---

 There are several templates for use for various Board resolutions.
 They can be found in [3] and you are encouraged to use them. It is
 strongly recommended that if you have a resolution before the board,
 you are encouraged to attend that board meeting.


 ASF Board Reports
 -

 Reports are due from you for the following committees:

   Aurora

[DRAFT] Apache Aurora board report June 2015

[Jake Farrell]

Please review the following draft board report, if no comments or changes
are noted in the next day or so I will submit this report

-Jake



June 2015

Apache Aurora is a service scheduler used to schedule jobs onto Apache
Mesos.

Project Status
-
Since our last 0.8.0 release Apache Aurora has been working on bug fixes
and
packaging (deb, rpm) to help users with the install process. Design
discussions
for health checks have been occurring on the mailing list and progress has
started
towards our next release candidate (0.9.0) and we hope to make it available
in
the next two weeks.

Community
---
Latest Additions:

* PMC addition: Zameer Manji, 2014-01-14
* Contributor addition: Joshua Cohen, 2015-02-02

Issue backlog status since last report:

* Created:   37 [1]
* Resolved:  30 [2]

Mailing list activity since last report:

* @dev  96  messages
* @reviews  447 messages

Releases
---
Last release: 0.8.0 was released on 2015-05-15


[1]: http://s.apache.org/EhX
[2]: http://s.apache.org/dfe

Re: [VOTE] Release Apache Aurora 0.8.0 API Artifacts

[Jake Farrell]

With four +1's and no negatives the vote to release the Apache Aurora 0.8.0
API Artifacts passes. Thanks everyone for reviewing and voting, will
publish the staged artifacts shortly

-Jake

On Thu, Jun 11, 2015 at 4:31 PM, Jake Farrell jfarr...@apache.org wrote:

 All,
 I have packaged up and staged the API jar/source artifacts from Apache
 Aurora 0.8.0
 and deployed them to the Apache staging repo [1]. I propose that we accept
 this
 staging repo as part of the official Apache Aurora 0.8.0 release artifacts.

 Aurora 0.8.0 API artifacts staging repo details include:
 ---
 The branch used to create the staged release candidate artifacts:

 https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/0.8.0

 The staged release candidate artifacts are available at:
 https://repository.apache.org/content/repositories/orgapacheaurora-1002

 The GPG key used to sign the release artifacts are available at:
 https://dist.apache.org/repos/dist/dev/aurora/KEYS

 Please download, verify, and test.

 The vote will close on Sun Jun 14 17:00:00 EDT 2015

 [ ] +1 Release this as Apache Aurora 0.8.0 API Artifacts
 [ ] +0
 [ ] -1 Do not release this as Apache Aurora 0.8.0 API Artifacts because...

 I would like to get the voting started with my own +1


 [1]:
 https://repository.apache.org/content/repositories/orgapacheaurora-1002

Re: [VOTE] Release Apache Aurora 0.8.0 API Artifacts

[Jake Farrell]

Nexus upload automatically does that

-Jake

On Thu, Jun 11, 2015 at 4:33 PM, Kevin Sweeney kevi...@apache.org wrote:

 It looks like there are checksums of the signatures, is that intentional?

 On Thu, Jun 11, 2015 at 1:31 PM, Jake Farrell jfarr...@apache.org wrote:

 All,
 I have packaged up and staged the API jar/source artifacts from Apache
 Aurora 0.8.0
 and deployed them to the Apache staging repo [1]. I propose that we accept
 this
 staging repo as part of the official Apache Aurora 0.8.0 release
 artifacts.

 Aurora 0.8.0 API artifacts staging repo details include:
 ---
 The branch used to create the staged release candidate artifacts:

 https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/0.8.0

 The staged release candidate artifacts are available at:
 https://repository.apache.org/content/repositories/orgapacheaurora-1002

 The GPG key used to sign the release artifacts are available at:
 https://dist.apache.org/repos/dist/dev/aurora/KEYS

 Please download, verify, and test.

 The vote will close on Sun Jun 14 17:00:00 EDT 2015

 [ ] +1 Release this as Apache Aurora 0.8.0 API Artifacts
 [ ] +0
 [ ] -1 Do not release this as Apache Aurora 0.8.0 API Artifacts because...

 I would like to get the voting started with my own +1


 [1]:
 https://repository.apache.org/content/repositories/orgapacheaurora-1002

Re: Forking twitter-commons into our tree

[Jake Farrell]

no objections, but we would have to get an IP clearance doc from Twitter
for this code in order to bring this code into the ASF

-Jake

On Thu, Jul 2, 2015 at 3:20 PM, Zameer Manji zma...@apache.org wrote:

 Hey,

 Aurora depends heavily on twitter-commons for lots of functionality.
 However upstream is not very active and I suspect that it will be less
 active in the future. Currently we depend on artifacts published from this
 project which causes us to depend on older versions of guava and guice.

 As a result, it seems that will be difficult to address tickets like
 AURORA-1380 https://issues.apache.org/jira/browse/AURORA-1380 without
 changing something. I propose we fork all of the java portions of
 twitter-commons into our tree, remove the parts we don't use and update
 guava and guice so we can move forward on this front.

 What are people's thoughts on this?

 --
 Zameer Manji

Re: Forking twitter-commons into our tree

[Jake Farrell]

yes, makes it easier to donate when its Apache License 2.0, but still
requires the IP clearance [1], which is handled through the IPMC. This is
required so there is an audit trail of that software being donated to the
ASF

-Jake

[1]: http://incubator.apache.org/ip-clearance/index.html



On Thu, Jul 2, 2015 at 10:41 PM, Bill Farner wfar...@apache.org wrote:

 Jake - i'm not fully versed on licenses, but is that true even though it's
 all Apache License 2.0?

 -=Bill

 On Thu, Jul 2, 2015 at 5:28 PM, Jake Farrell jfarr...@apache.org wrote:

  no objections, but we would have to get an IP clearance doc from Twitter
  for this code in order to bring this code into the ASF
 
  -Jake
 
  On Thu, Jul 2, 2015 at 3:20 PM, Zameer Manji zma...@apache.org wrote:
 
   Hey,
  
   Aurora depends heavily on twitter-commons for lots of functionality.
   However upstream is not very active and I suspect that it will be less
   active in the future. Currently we depend on artifacts published from
  this
   project which causes us to depend on older versions of guava and guice.
  
   As a result, it seems that will be difficult to address tickets like
   AURORA-1380 https://issues.apache.org/jira/browse/AURORA-1380
 without
   changing something. I propose we fork all of the java portions of
   twitter-commons into our tree, remove the parts we don't use and update
   guava and guice so we can move forward on this front.
  
   What are people's thoughts on this?
  
   --
   Zameer Manji
  
 

Re: [PROPOSAL] Changes to the Python BUILD layout

[Jake Farrell]

+1

-Jake

On Thu, Jul 30, 2015 at 7:24 PM, Kevin Sweeney kswee...@twitter.com.invalid
 wrote:

 Somewhat complementary work - this change would make the generated packages
 equivalent to the ultimate goal of replacing these top-level BUILD files
 directly with setup.py files. Users could begin testing deployment with the
 pants-generated sdists and seamlessly drop in setup.py-generated
 replacements. Users wishing to deploy via PEX could use the pex tool on the
 generated sdists rather than the pants pex plugin.

 On Thu, Jul 30, 2015 at 4:13 PM, Bill Farner wfar...@apache.org wrote:

  We've talked in the past about switching build tools.  Just to keep that
 in
  context - how would you weigh this effort against a tool change?
 
  -=Bill
 
  On Thu, Jul 30, 2015 at 4:00 PM, Kevin Sweeney kevi...@apache.org
 wrote:
 
   I propose a simplification of the Python BUILD layout as follows and a
  set
   of new conventions, as follows:
  
   1) 1 BUILD per 3rd level directory. These are currently
  
   ```
   % find src/main/python -maxdepth 3 -mindepth 3 -type d |while read
  dirname;
   do echo $dirname | sed 's@src
  /main/python/\(.*\)/\(.*\)/\(.*\).*@\1.\2.\3@
   ';
   done
   apache.aurora.client
   apache.aurora.common
   apache.aurora.tools
   apache.aurora.admin
   apache.aurora.executor
   apache.aurora.config
   apache.thermos.monitoring
   apache.thermos.common
   apache.thermos.cli
   apache.thermos.testing
   apache.thermos.core
   apache.thermos.runner
   apache.thermos.observer
   apache.thermos.config
   ```
  
   2) Each BUILD file exports 1 python_library that provides a setup_py
   containing each python_binary in the BUILD file, named the same as the
   directory it's in so that it can be referenced without a ':' character.
  The
   sources field in the python_binary will always be rglobs('*.py').
  
   3) Other BUILD files may only depend on this single public
 python_library
   target. Any other target is considered a private implementation detail
  and
   should be prefixed with an _.
  
   4) python_binary targets are always named the same as the exported
  console
   script.
  
   5) python_binary targets must have identical dependencies to the
   python_library exported by the package and must use entry_point.
  
   The advantage of this change is that a PEX file generated by pants will
   contain exactly the same files that will be available on the PYTHONPATH
  in
   the case of pip-installation of the corresponding library target. This
  will
   help our migration off pants in the future.
  
   Annotated example: apache.thermos.runner (renamed thermos/bin -
   thermos/runner)
  
   ```
   % find src/main/python/apache/thermos/runner
   src/main/python/apache/thermos/runner
   src/main/python/apache/thermos/runner/__init__.py
   src/main/python/apache/thermos/runner/thermos_runner.py
   src/main/python/apache/thermos/runner/BUILD
   % cat src/main/python/apache/thermos/runner/BUILD
   # License boilerplate omitted
   import os
  
  
   # Private target so that a setup_py can exist without a circular
   dependency. Only targets within this file should depend on
   # this.
   python_library(
 name = '_runner',
 # The target covers every python file under this directory and
   subdirectories.
 sources = rglobs('*.py'),
 dependencies = [
   '3rdparty/python:twitter.common.app',
   '3rdparty/python:twitter.common.log',
   # Source dependencies are always referenced without a ':'.
   'src/main/python/apache/thermos/common',
   'src/main/python/apache/thermos/config',
   'src/main/python/apache/thermos/core',
 ],
   )
  
   # Binary target for thermos_runner.pex. Nothing should depend on this -
   it's only used as an argument to ./pants binary.
   python_binary(
 name = 'thermos_runner',
 # Use entry_point, not source so the files used here are the same
 ones
   tests see.
 entry_point = 'apache.thermos.bin.thermos_runner',
 dependencies = [
   # Notice that we depend only on the single private target from this
   BUILD file here.
   ':_runner',
 ],
   )
  
   # The public library that everyone importing the runner symbols uses.
   # The test targets and any other dependent source code should depend on
   this.
   python_library(
 name = 'runner',
 dependencies = [
   # Again, notice that we depend only on the single private target
 from
   this BUILD file here.
   ':_runner',
 ],
 # We always provide a setup_py. This will cause any dependee
 libraries
  to
   automatically reference this library
 # in their requirements.txt rather than copy the source files into
  their
   sdist.
 provides = setup_py(
   # Conventionally named and versioned.
   name = 'apache.thermos.runner',
   version = open(os.path.join(get_buildroot(),
   '.auroraversion')).read().strip().upper(),
 ).with_binaries({
   # Every binary in this file should also be repeated here.
   # Always use 

Re: [PROPOSAL] Source releases vs artifact releases

[Jake Farrell]

In order to make this repeatable it might be good to split this off
entirely into its own aurora-packaging repo. If its still in the main repo
then when we create the release branch the packaging source will still be
in the new release branch, but the packaging code would not necessarily
line up with that given branched release (like we have currently for the
0.9.0 branch). For people checking out the release branch and not the
source distribution this would be more confusing.

To eliminate this potential guessing game and expanding on Bill's proposal
I would advocate for us to make the packaging its own repo,
aurora-packaging, and add a set of docker files so we can automate the
build of the given release deb/rpm's and script the process for creating
tags for each 0.9.0-1.rpm or 0.9.0-2.deb ...

-Jake

On Mon, Jul 27, 2015 at 6:40 PM, Bill Farner wfar...@apache.org wrote:

 Hi folks,

 An issue that we have not yet officially addressed is release management as
 it pertains to binary artifacts we produce of Aurora.  Today, when we cut a
 release, say 0.9.0, we essentially take a snapshot of (most of) our
 repository as a basis for voting and eventual distribution.

 An outstanding question thus far has been how a release is affected when we
 need to change scripts and configurations for binary distributions [1] to
 produce a working binary artifact.  By some standards, a bug fix to an RPM
 spec might require another official source release/vote.

 I've had several useful discussions with Jake Farrell about this, and we
 brought the discussion to the asfinfra hipchat room to hopefully get some
 quick guidance from someone on the ASF board.  Please see the quote below
 if you would like to see the transcript.

 The summary is that the board allows us to produce binaries as we see fit,
 as the ASF does not consider them official releases.  As such, i propose
 that we treat build-support/packaging as distinct from the sources we vote
 on for a source release.  I further propose that we omit
 build-support/packaging from our source distributions.  This will make it
 clear that they are not part of what we are voting on when we cut a
 release.

 With this distinction, i would like for us to adopt the practice of
 considering binary distributions 'downstream' from source distributions,
 and bug fixes to packaging do not require a new source distribution
 release.


 Cheers,

 Bill


 [1]

 https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=tree;f=build-support/packaging;h=c77d9b8ab2d8e6ecea2d8028bcdb250239240ffe;hb=HEAD

 Jake Farrell 12:03 PM
  question for the greater audience about packaging, we just cut and rc and
  voted on it, successfully passed. as part of the src release was code to
  create deb and rpm packages. went to cut the rpm's to vote on bin
 artifacts
  and there is a bug in the rpm spec
 
  Daniel Gruno (Humbedooh) 12:04 PM
  burn and reroll? :)
 
  Jake Farrell 12:05 PM
  would the recommendation be to cut a new rc or would having the deb/rpm
  packaging code in separate repo on its own release be more in line. i.e.,
  package 0.1.0-2.rpm in packaging land
 
  Daniel Gruno (Humbedooh) 12:07 PM
  you could cut a new release and bypass the 72h rule
 
  Bill Farner 12:09 PM
  a goal i'm seeking with this is to decouple source release from binary
  releases, if possible. that way we don't have things like releases for N
  distros that are no-ops because we fixed something in 1. it also means
 that
  we don't have source releases that have no binary releases because of a
  packaging spec bug
  we're currently in the latter situation - we have a perfectly fine 0.9.0
  src release. however, it turns out there's trivial cruft in packaging
 specs
  requiring a post-0.9.0 commit to generate working binaries (key detail -
  commit that does not touch the source)
 
  Daniel Gruno (Humbedooh) 12:12 PM
  aren't binaries still viewed as unofficial convenience?
  iow you can do what you like to it, 'cause it ain't ours
 
  Tony Stevenson ( pctony ) 12:13 PM
  AIUI, yes
  but $AOO etc
 
  Daniel Gruno (Humbedooh) 12:13 PM
  @rbowen you're a board pony, what say you?
 
  Tony Stevenson ( pctony ) 12:13 PM
  neeeigh
 
  Daniel Gruno (Humbedooh) 12:13 PM
  apart from neigh, that is
 
  Rich Bowen 12:13 PM
  Hmm. What?
 
  Daniel Gruno (Humbedooh) 12:14 PM
  bill has a question on ASF binary release policy
 
  Bill Farner 12:14 PM
  details in scrollback, let me know if i've worded poorly :-)
  + Jake's context a few messages before
  concrete example: this line in our rpm spec is incorrect
 
 https://github.com/apache/aurora/blob/master/build-support/packaging/rpm/aurora.spec#L188
  fixing it does not alter what i'd consider the source code of the
 project,
  just the tooling to assemble those sources
 
  Daniel Gruno (Humbedooh) 12:18 PM
  personally, I would favor burning the release and cutting a new with a
  speed vote
  so that people building from source can generate rpms as well
 
  Rich Bowen 12

Re: Roadmap

[Jake Farrell]

Sounds like we have pretty much reached an agreement here on making it
public facing on the website, will get mechanics setup and we can start
iterating on the content from there. Thanks everyone

-Jake

On Wed, Sep 2, 2015 at 12:20 PM, Chamin Nalinda <chm...@gmail.com> wrote:

> +1 I've been in this mailing list for sometime and always wonder from where
> I should start. This is a great move.
>
> On Wed, Sep 2, 2015 at 8:24 AM, Dave Lester <d...@davelester.org> wrote:
>
> > +1!
> >
> > On Tue, Sep 1, 2015, at 07:45 PM, Bill Farner wrote:
> > > :-)
> > >
> > > On Tue, Sep 1, 2015 at 6:44 PM, Jeffrey Davis <
> jeffrey.n.da...@gmail.com
> > >
> > > wrote:
> > >
> > > > +1 to putting it on the website as well, but if and only if it's
> titled
> > > > "squad goals"
> > > >
> > > > On Tue, Sep 1, 2015 at 8:41 PM, Zameer Manji <zma...@apache.org>
> > wrote:
> > > >
> > > > > +1 to putting it on the website.
> > > > >
> > > > > On Tue, Sep 1, 2015 at 4:55 PM, Joseph Smith <yasumo...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Yep, that sounds awesome.
> > > > > >
> > > > > > > On Sep 1, 2015, at 10:04 AM, Joshua Cohen <
> > jco...@twopensource.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > +1 to putting it on the website. I think it would help adoption
> > if we
> > > > > > have
> > > > > > > an up front and easily accessible document that first,
> indicates
> > > > we've
> > > > > > got
> > > > > > > plans!, and then goes on to explain what they are. The caveat
> is
> > that
> > > > > if
> > > > > > > the document gets stale it would serve the opposite purpose ;).
> > > > > > >
> > > > > > > On Mon, Aug 31, 2015 at 9:32 PM, Bill Farner <
> > terasur...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > >> I would love to see this come together!
> > > > > > >>
> > > > > > >> I'm leaning towards putting this on the website.  This gives
> the
> > > > list
> > > > > > >> greater visibility/accessibility and richness.  I don't think
> > JIRA
> > > > is
> > > > > > the
> > > > > > >> best place, since this should evolve over time and is never
> > actually
> > > > > > >> 'finished'.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Mon, Aug 31, 2015 at 11:17 AM, Jake Farrell <
> > jfarr...@apache.org
> > > > >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> In an initiative and make it easier for new people coming to
> > Aurora
> > > > > to
> > > > > > >> know
> > > > > > >>> where to get started and provide community contributions I
> > would
> > > > like
> > > > > > to
> > > > > > >>> start a public roadmap (either a file within our repo or in
> > jira)
> > > > to
> > > > > > >>> make it easier for everyone to track releases and know what
> our
> > > > goals
> > > > > > are
> > > > > > >>> for each release. As part of our next release of 0.10.0 I
> would
> > > > like
> > > > > to
> > > > > > >>> start this process and keep evolving it
> > > > > > >>>
> > > > > > >>> Thoughts?
> > > > > > >>>
> > > > > > >>> -Jake
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Zameer Manji
> > > > >
> > > >
> >
>
>
>
> --
> Chamin Nalinda
> Research Undergraduate
> University of Colombo School of Computing (UCSC).
> Student Member IEEE (92387118)
> Student Member ACM (5654073)
>
> LinkedIn: https://www.linkedin.com/in/chaminnalinda
> GitHub: https://github.com/CoolCK
> SlideShare: http://www.slideshare.net/ChaminNalindaLokuGam/
> Blog: http://techspiro.blogspot.com/
>

Re: [DRAFT] [REPORT] Apache Aurora

[Jake Farrell]

Report must contain the dates for our last committer and PMC additions,
otherwise looks good

-Jake

On Tue, Sep 8, 2015 at 8:04 PM, Bill Farner  wrote:

> Please take a moment to read through a draft of the board report i have
> prepared for Aurora.  I'm happy to take any suggestions for edits prior to
> submitting this tomorrow.
>
>
> ## Description:
>  - Apache Aurora lets you use an Apache Mesos cluster as a private cloud.
> It supports running long-running services, cron jobs, and ad-hoc jobs.
>
> ## Activity:
>  - Release planning underway (0.10.0)
>  - Major effort recently to produce official installable packages (RPMs and
> debs)
>- released of debs for 0.9.0, closed to release of RPMs
>- planning support for unofficial/unsupported nightly packages
>
> ## Health report:
>  - There has been healthy development on Aurora for this period, though we
> hope to see growth in adoption, contributions, and committers.  There has
> been significant effort to minimize the effort required to evaluate
> alternatives to Aurora (e.g. Kubernetes, Marathon), which we believe
> impedes our adoption rate.  Packaging and better introductory documentation
> will our focus to address this.
>
> ## Issues:
>  - There are no issues requiring board attention at this time
>
> ## LDAP committee group/Committership changes:
>
>  - Currently 15 committers and 13 LDAP committee group members.
>  - No new changes to the LDAP committee group or committership since last
>report.
>
> ## Releases:
>
>  - 0.9.0 was released on Thu Jul 23 2015
>
> ## Mailing list activity:
>
>  - dev@aurora.apache.org:
> - 147 subscribers (up 11 in the last 3 months):
> - 293 emails sent to list (437 in previous quarter)
>
>  - revi...@aurora.apache.org:
> - 33 subscribers (up 0 in the last 3 months):
> - 1298 emails sent to list (1419 in previous quarter)
>
>  - iss...@aurora.apache.org:
> - 37 subscribers (down -1 in the last 3 months):
> - 753 emails sent to list (844 in previous quarter)
>
>
> ## JIRA activity:
>
>  - 136 JIRA tickets created in the last 3 months
>  - 103 JIRA tickets closed/resolved in the last 3 months
>

Re: [DRAFT] [REPORT] Apache Aurora

[Jake Farrell]

reporter.a.o is only intended to be a tool to help with collecting some of
the data points, not a copy/paste template. The board has discussed this
and does not like when the reports come in and show minimal changes from
what reporter.a.o has. The committer and pmc last addition dates are hands
down the number 1 item that get flagged in reports as missing and are
requested each board cycle

-Jake

On Tue, Sep 8, 2015 at 9:54 PM, Bill Farner <wfar...@apache.org> wrote:

> Jake - thanks, that section of the report was auto-generated by
> reporter.apache.org.  Do you know if that tool is intended to cover all
> the required points?
>
> On Tue, Sep 8, 2015 at 6:29 PM, Jake Farrell <jfarr...@apache.org> wrote:
>
>> Report must contain the dates for our last committer and PMC additions,
>> otherwise looks good
>>
>> -Jake
>>
>> On Tue, Sep 8, 2015 at 8:04 PM, Bill Farner <wfar...@apache.org> wrote:
>>
>> > Please take a moment to read through a draft of the board report i have
>> > prepared for Aurora.  I'm happy to take any suggestions for edits prior
>> to
>> > submitting this tomorrow.
>> >
>> >
>> > ## Description:
>> >  - Apache Aurora lets you use an Apache Mesos cluster as a private
>> cloud.
>> > It supports running long-running services, cron jobs, and ad-hoc jobs.
>> >
>> > ## Activity:
>> >  - Release planning underway (0.10.0)
>> >  - Major effort recently to produce official installable packages (RPMs
>> and
>> > debs)
>> >- released of debs for 0.9.0, closed to release of RPMs
>> >- planning support for unofficial/unsupported nightly packages
>> >
>> > ## Health report:
>> >  - There has been healthy development on Aurora for this period, though
>> we
>> > hope to see growth in adoption, contributions, and committers.  There
>> has
>> > been significant effort to minimize the effort required to evaluate
>> > alternatives to Aurora (e.g. Kubernetes, Marathon), which we believe
>> > impedes our adoption rate.  Packaging and better introductory
>> documentation
>> > will our focus to address this.
>> >
>> > ## Issues:
>> >  - There are no issues requiring board attention at this time
>> >
>> > ## LDAP committee group/Committership changes:
>> >
>> >  - Currently 15 committers and 13 LDAP committee group members.
>> >  - No new changes to the LDAP committee group or committership since
>> last
>> >report.
>> >
>> > ## Releases:
>> >
>> >  - 0.9.0 was released on Thu Jul 23 2015
>> >
>> > ## Mailing list activity:
>> >
>> >  - dev@aurora.apache.org:
>> > - 147 subscribers (up 11 in the last 3 months):
>> > - 293 emails sent to list (437 in previous quarter)
>> >
>> >  - revi...@aurora.apache.org:
>> > - 33 subscribers (up 0 in the last 3 months):
>> > - 1298 emails sent to list (1419 in previous quarter)
>> >
>> >  - iss...@aurora.apache.org:
>> > - 37 subscribers (down -1 in the last 3 months):
>> > - 753 emails sent to list (844 in previous quarter)
>> >
>> >
>> > ## JIRA activity:
>> >
>> >  - 136 JIRA tickets created in the last 3 months
>> >  - 103 JIRA tickets closed/resolved in the last 3 months
>> >
>>
>
>

Re: JobConfig diff API

[Jake Farrell]

This is one of the hoops encountered when using the Thrift api directly and
not using the client, I'd love to see ExecutorConfig.data move to a thrift
object and not be a string blob

-Jake

On Mon, Sep 14, 2015 at 9:28 PM, Bill Farner  wrote:

> I like the idea of adding this API, but i don't see why it requires us to
> make assumptions about ExecutorConfig.data.  I hope this doesn't mean we
> would be returning a textual representation of a diff.  Can you elaborate
> on that?
>
> On Mon, Sep 14, 2015 at 4:14 PM, Maxim Khutornenko 
> wrote:
>
> > Problem:
> > We currently don't have a good user experience around "aurora job
> > diff" command. The task configs are dumped as "prettified" JSON
> > strings and diffed with the system diff tool. Anyone who tried to use
> > it knows it can be very hard to read especially when it comes to
> > executor data deltas. Also, the implementation is done completely
> > within the Aurora client making it hard to reuse this feature by other
> > clients (e.g.: an external deploy coordination tool).
> >
> > Proposal:
> > Move the diff logic to the scheduler and expose it via a new
> > jobConfigDiff thrift API.
> >
> > Benefits:
> > - Client will no longer have the custom non-reusable logic moving us
> > closer towards a "thin client" goal.
> > - The new RPC can be fully used by any existing or new API clients.
> > - The diff output will be improved via leveraging third party POJO
> > and/or JSON diff libraries [1,2,3, etc.].
> > - The server updater can be partially/fully unified with the new diff
> > logic further improving the overall DRY-ness.
> >
> > Concerns:
> > - The executor data is currently treated as an opaque string blob on
> > the scheduler side. In reality, it's almost guaranteed to be JSON. In
> > order to deliver the best UX, the scheduler would have to start
> > requiring ExecutorConfig.data to be a valid JSON.
> >
> > Any other concerns/objections/comments? I would like to formalize the
> > proposal be EOW if we reach consensus quickly.
> >
> > Thanks,
> > Maxim
> >
> > [1] -
> >
> http://java-object-diff.readthedocs.org/en/latest/getting-started/#getting-started
> > [2] - http://javers.org/documentation/diff-examples/
> > [3] - https://github.com/skyscreamer/JSONassert
> >
>

Re: 0.10.0 Feature Requests

[Jake Farrell]

we should probably spend some time before .10 going through and cleaning up
deprecation todo's left in the code also. I've added this to the Aurora
Roadmap Google doc

-Jake

On Thu, Sep 10, 2015 at 2:09 PM, Bill Farner <wfar...@apache.org> wrote:

> I agree, documentation overhauls are best decoupled from releases.
>
> On Thu, Sep 10, 2015 at 10:49 AM, Jake Farrell <jfarr...@apache.org>
> wrote:
>
> > Think that this is a great idea and agree that we need to spend some time
> > improving our user content, but it should not be a blocker to the next
> > release candidate. Improving our documentation and website should be an
> > ongoing effort
> >
> > -Jake
> >
> >
> >
> > On Thu, Sep 10, 2015 at 1:43 PM, Zameer Manji <zma...@apache.org> wrote:
> >
> > > One thing I would like to see in 0.10.0 is improvement to our
> > > documentation. We have a lot of documentation but I don't think it is
> > well
> > > organized or very accessible to a new user or a prospective user. This
> > > might involve writing new documentation, improving our, website, etc.
> > >
> > > On Tue, Sep 8, 2015 at 9:30 AM, Bill Farner <wfar...@apache.org>
> wrote:
> > >
> > > > In 0.10.0 i would like to see:
> > > >
> > > > - groundwork and initial endpoints in a REST API (part of AURORA-987)
> > > >
> > > > - thermos executor support for a simple task description.  this would
> > be
> > > a
> > > > dramatically reduced json schema that the executor can consume for
> > simple
> > > > use cases where the user is invoking a single shell command
> > > >
> > > > - support for custom executors (AURORA-1376)
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Aug 31, 2015 at 11:18 AM, Zameer Manji <zma...@apache.org>
> > > wrote:
> > > >
> > > > > As discussed in today's IRC meeting I will be heading up the 0.10.0
> > > > > release. What would people like to see in this release?
> > > > >
> > > > > --
> > > > > Zameer Manji
> > > > >
> > > >
> > > > --
> > > > Zameer Manji
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Aurora 0.11.0 debs

[Jake Farrell]

+1

-Jake

On Wed, Dec 23, 2015 at 12:43 PM, Bill Farner  wrote:

> I propose that we accept the following artifacts as the official deb
> packaging for
> Apache Aurora 0.11.0.
>
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The Aurora deb packaging includes the following:
> ---
> The CHANGELOG is available at:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.11.x
>
> The branch used to create the packaging is:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.11.x
>
> The packages are available at:
>
> http://people.apache.org/~wfarner/aurora/distributions/0.11.0/deb/ubuntu-trusty/
>
> The GPG keys used to sign the packages are available at:
> https://dist.apache.org/repos/dist/release/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Wed Jan 6 20:00:00 PT 2015
>
> [ ] +1 Release these as the deb packages for Apache Aurora 0.11.0
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>
> I would like to get the voting started off with my own +1
>

Re: [VOTE] Release Apache Aurora 0.11.0 RC1

[Jake Farrell]

+1

tested using verify-release-candidate

-Jake

On Thu, Dec 17, 2015 at 7:08 PM, Bill Farner  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.11.0 release.
>
> Aurora 0.11.0-rc1 includes the following:
> ---
> The NEWS for this release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=0.11.0-rc1
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=0.11.0-rc1
>
> The branch used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/0.11.0-rc1
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.11.0-rc1/apache-aurora-0.11.0-rc1.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.11.0-rc1/apache-aurora-0.11.0-rc1.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.11.0-rc1/apache-aurora-0.11.0-rc1.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Tue Dec 22 15:18:55 PST 2015
>
> [ ] +1 Release this as Apache Aurora 0.11.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.11.0 because...
>

Re: [VOTE] Release Apache Aurora 0.10.0-1 debs

[Jake Farrell]

+1, debs looks good

-Jake

On Fri, Nov 27, 2015 at 1:34 PM, Bill Farner  wrote:

> I propose that we accept the following artifacts as the official deb
> packaging for
> Apache Aurora 0.10.0.
>
>
> http://people.apache.org/~wfarner/aurora/distributions/0.10.0-1/deb/ubuntu-trusty/
>
> The Aurora deb packaging includes the following:
> ---
> The CHANGELOG is available at:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=blob_plain;f=specs/debian/changelog;hb=refs/heads/0.10.x
>
> The branch used to create the packaging is:
>
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;h=refs/heads/0.10.x
>
> The packages are available at:
>
> http://people.apache.org/~wfarner/aurora/distributions/0.10.0-1/deb/ubuntu-trusty/
>
> The GPG keys used to sign the packages are available at:
> https://dist.apache.org/repos/dist/release/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close in 5 business days, on Thu Dec 4 8:00:00 PT 2015
>
> [ ] +1 Release these as the deb packages for Apache Aurora 0.10.0
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>
> I would like to get the voting started off with my own +1
>

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: 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: [VOTE] Release Apache Aurora 0.11.0 debs

[Jake Farrell]

I pushed the api bindings for 0.8 to repository.a.o [1] after a one off
vote for that specific binary artifact, but we never incorporated that as
part of our official release process. we need to look into making the
convenience binaries (deb, rpm, jar) easier to package and assemble for a
vote at some point

-Jake


[1]: https://repository.apache.org/#nexus-search;quick~aurora

On Fri, Jan 8, 2016 at 5:41 AM, Matthias Bach  wrote:

> Hi,
>
> Am 27.12.2015 um 00:21 schrieb ben...@gmail.com:
> > I've been producing a set of Mesos debs that are not derived from the
> > Mesosphere packages, with the goal of having a set of debs that follow
> > Debian conventions and packaging policies as closely as I can get them.
>
> Great work. This are far more advanced than what I have hacked together
> so far. Especially adding all those man-pages…
>
> Is there any particular reason you did not include the Java bindings,
> though? Or have I just been too blind to find them?
>
> Regards,
> Matthias
>
> --
> Dr. Matthias Bach
> Senior Software Engineer
> *Blue Yonder GmbH*
> Ohiostraße 8
> D-76149 Karlsruhe
>
> Tel +49 (0)721 383 117 6244
> Fax +49 (0)721 383 117 69
>
> matthias.b...@blue-yonder.com 
> www.blue-yonder.com 
> Registergericht Mannheim, HRB 704547
> USt-IdNr. DE DE 277 091 535
> Geschäftsführer: Jochen Bossert, Uwe Weiss (CEO)
>
> 
>

Re: Aurora 0.14.0 release

[Jake Farrell]

Take a look at the "Creating a release" section in docs/development/
committers-guide.md, you will also need to add you GPG key to the necessary
files, feel free to ping me with any questions or bring them up in #aurora
as a number of us have now been RM's before

-Jake

On Mon, Jun 6, 2016 at 6:54 PM, Erb, Stephan 
wrote:

> +1 for a RC this week.
>
> I'd volunteer to serve as a release manager, but will probably need
> someone to walk me through the necessary steps.
> 
> From: Maxim Khutornenko 
> Sent: Tuesday, June 7, 2016 00:15
> To: dev@aurora.apache.org
> Subject: Aurora 0.14.0 release
>
> With the resource refactoring and GPU support landed plus appc
> container ongoing work presumably not requiring any further schema
> changes (Joshua, please correct if that's not the case), how does
> everyone feel about cutting a release candidate this week?
>
> Assuming no objections: anyone wants to be a release manager for 0.14.0?
>

Re: From Aurora 0.14 to 0.15

[Jake Farrell]

+1 to getting caught up with current Mesos version

-Jake

On Sat, Jun 11, 2016 at 6:13 PM, Stephan Erb  wrote:

> Hi everyone,
>
> even though we are still in the process of getting 0.14 out of the
> door, I'd like to propose that we aim for a short release cycle for
> 0.15.
>
> This would entail:
>
> * the update to Mesos 0.28.x
> * no deprecation removals, so that it's easy to update from 0.14 to
> 0.15.
>
> Any objections?
>
> Best Regards,
> Stephan
>

Re: [DRAFT][REPORT]: Apache Aurora

[Jake Farrell]

that was only talked about on the private@aurora list so far so would not
be added to the draft report posted for review on dev@, that detail would
have gone into a different section on the board report

-Jake

On Sat, Jun 11, 2016 at 12:50 AM, Zameer Manji <zma...@apache.org> wrote:

> Jake,
>
> Shouldn't we mention that our PMC Chair has resigned?
>
> On Fri, Jun 10, 2016 at 8:06 PM, Jake Farrell <jfarr...@apache.org> wrote:
>
>> Please take a second to review the board report below and provide any
>> feedback (+1 or any desired modifications). I will submit this report
>> pending any changes monday afternoon
>>
>> -Jake
>>
>>
>>
>> Apache Aurora is a stateless and fault tolerant service scheduler used to
>> schedule jobs onto Apache Mesos such as long-running services, cron jobs,
>> and one off tasks.
>>
>> Project Status
>> -
>> The Apache Aurora community has continued to see growth from new users and
>> contributors while working towards our upcoming 0.14.0 release. The
>> upcoming
>> release will contain a number of bug fixes, stability enhancements and new
>> experimental features added such as Mesos GPU resource support, external
>> webhook support, launching tasks using filesystem image with the new
>> Apache
>> Mesos unified containerizer.
>>
>> Community
>> ---
>> Latest Additions:
>>
>> * PMC addition: Stephan Erb, 2.3.2016
>>
>> Issue backlog status since last report:
>>
>> * Created:   62
>> * Resolved:  80
>>
>> Mailing list activity since last report:
>>
>> * @dev329 messages
>> * @user   103 messages
>>
>> Releases
>> ---
>> Last release: Apache Aurora 0.13.0 released 4.13.2016
>> Release candidate: Apache Aurora 0.14.0 release candidate vote is
>> currently
>> in progress
>>
>
>

Re: [VOTE] Release Apache Aurora 0.14.0 RC0

[Jake Farrell]

+1

-Jake

On Fri, Jun 10, 2016 at 10:23 AM, Stephan Erb  wrote:

> All,
>
> I propose that we accept the following release candidate as the
> official
> Apache Aurora 0.14.0 release.
>
> Aurora 0.14.0-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md
> =rel/0.14.0-rc0
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel
> /0.14.0-rc0
>
> The tag used to create the release candidate is:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/
> tags/rel/0.14.0-rc0
>
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.14.0-rc0/apache-aurora-
> 0.14.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.14.0-rc0/apache-aurora-
> 0.14.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.14.0-rc0/apache-aurora-
> 0.14.0-rc0.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
> The vote will close on Mo 13. Jun 16:00:00 CEST 2016
>
> [ ] +1 Release this as Apache Aurora 0.14.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.14.0 because...
>
>
> Best Regards,
> Stephan

Re: [PROPOSAL] Amend 0.12.0 release goals

[Jake Farrell]

sounds good, +1

-Jake

On Thu, Jan 14, 2016 at 10:02 AM, Bill Farner  wrote:

> Given that we are still playing catch-up to mesos releases (we are on
> 0.25.0, latest is 0.26.0, there's talk of cutting 0.27.0 soon), i would
> like to suggest that we remove these tickets from 0.12.0:
>
> https://issues.apache.org/jira/browse/AURORA-987
> https://issues.apache.org/jira/browse/AURORA-1150
>
> It's slightly unfortunate as these tickets represent the largest planned
> effort for 0.12.0, we had a handful of significant contributions that still
> make this a featureful release:
>
>
> https://github.com/apache/aurora/blob/d542bd1d58bc5dcf6ead95d902c0a8cecbbffe9e/NEWS#L3-L23
>
> Additionally, i would like to recommend that we add the following ticket to
> 0.12.0 since we have an in-fight patch that looks close to completion:
>
> https://issues.apache.org/jira/browse/AURORA-1109
>
>
> Cheers,
>
> Bill
>

Re: [FEEDBACK] Transitioning Aurora leader election to Apache Curator (`-zk_use_curator`)

[Jake Farrell]

+1, will enable on our test clusters to help verify

-Jake

On Tue, Jun 14, 2016 at 7:43 PM, John Sirois  wrote:

> I'd like to move forward with
> https://issues.apache.org/jira/browse/AURORA-1669 asap; ie: removing
> legacy
> (Twitter) commons zookeeper libraries used for Aurora leader election in
> favor of Apache Curator libraries. The change submitted in
> https://reviews.apache.org/r/46286/ is now live in Aurora 0.14.0 and
> Apache
> Curator based service discovery can be enabled with the Aurora scheduler
> flag `-zk_use_curator`.  I'd like feedback from users who enable this
> option.  If you have a test cluster where you can enable `-zk_use_curator`
> and exercise leader failure and failover, I'd be grateful. If you have
> moved to using this option in production with demonstrable improvements or
> even maintenance of status quo, I'd also be grateful for this news. If
> you've found regressions or new bugs, I'd love to know about those as well.
>
> Thanks in advance to all those who find time to test this out on real
> systems!
>

Re: [VOTE] Release Apache Aurora 0.12.0 RC0

[Jake Farrell]

+1, tested with verify-release-candidate

-Jake

On Thu, Jan 28, 2016 at 2:21 AM, John Sirois  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.12.0 release.
>
> Aurora 0.12.0-rc0 includes the following:
> ---
> The NEWS for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.12.0-rc0
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.12.0-rc0
>
> The tag used to create the release candidate is:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/heads/rel/0.12.0-rc0
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.12.0-rc0/apache-aurora-0.12.0-rc0.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Tue Feb 2 00:21:29 MST 2016
>
> [ ] +1 Release this as Apache Aurora 0.12.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.12.0 because...
>
> ---
> Reminder: you can verify the release candidate as I have via:
>
>   ./build-support/release/verify-release-candidate 0.12.0-rc0
>
> If you can deploy the RC to a test cluster and evaluate it there, even
> better.
>

Re: NEWS Layout

[Jake Farrell]

sounds good. thanks Stephan

-Jake

On Tue, Feb 2, 2016 at 2:05 PM, Erb, Stephan 
wrote:

> Hi everyone,
>
> I'd like to propose that we give our NEWS file a little bit more
> structure. Currently, it is quite cluttered [1].
>
> To keep it simple, I'd suggest that we adopt the style from the 0.11
> Aurora blog post:
>
> * New/updated
> * Deprecations and removals
>
> [1] https://github.com/apache/aurora/blob/master/NEWS
> [2] https://aurora.apache.org/blog/aurora-0-11-0-released/
>
>
> Thoughts?
>

Re: [PROPOSAL] Change java thrift code gen

[Jake Farrell]

+1 to making this apart of Thrift, i'm happy to help shepard this on the
Thrift side and get it in as soon as its ready

-Jake

On Wed, Jan 27, 2016 at 8:08 PM, Maxim Khutornenko  wrote:

> I am +1 to making immutable thrift objects solely based on perf numbers.
>
> My biggest concern though is maintenance of a pretty intricate codebase,
> especially when it comes to upgrading any of the frameworks involved.
> Bill's suggestion to explore paths to make this a part of Apache Thrift
> sounds great to me.
>
> On Wed, Jan 27, 2016 at 5:00 PM, Bill Farner  wrote:
>
> > Tony - this would not be a technical fork so much as a spiritual fork.
> > While we would have our own bugs to work out, the only upstream exposure
> > would be IDL or wire format changes.
> >
> > On Wed, Jan 27, 2016 at 4:58 PM, Tony Dong 
> > wrote:
> >
> > > Awesome performance numbers! I don't particularly know the logistics of
> > > upstreaming a change like this, but optimistically I would suggest
> > > upstreaming it to Apache Thrift if possible.
> > >
> > > As someone that maintains a fork of a thrift compiler(fork of
> scrooge), I
> > > have to say that it's not that fun. There's a lot of custom code that
> > needs
> > > to be maintained and a bunch of work to rebase the code periodically.
> > >
> > >
> > >
> > > On Wed, Jan 27, 2016 at 4:51 PM, Bill Farner 
> wrote:
> > >
> > > > Firstly - thanks for the clean organization and delineation of steps
> in
> > > > this change.  Top notch work!
> > > >
> > > > Some of the performance improvements are very nice; and in a
> > particularly
> > > > hot code path.  I will wager a guess that the majority of the savings
> > is
> > > in
> > > > avoiding what amounts to copy constructors between mutable and
> > immutable
> > > > types.  I further wager there are alternative approaches we could
> weigh
> > > to
> > > > achieve those performance improvements.  As an example - you note
> above
> > > > that we could provide a patch to Apache Thrift.  Depending how much
> > > > performance inspires our decision here, it will be prudent to
> evaluate
> > > > alternatives.
> > > >
> > > > I think there are (at least) two major issues worth discussing - code
> > > > volume (which you note) and an increase in logical complexity.  This
> > will
> > > > leave us with a bifurcation in code generation tooling (custom+swift
> > for
> > > > Java, Apache Thrift for python and js).  It's difficult to quantify
> the
> > > > downside of that, but it seems like an unfortunate state with
> potential
> > > for
> > > > compatibility risks.
> > > >
> > > >
> > > > On Wed, Jan 27, 2016 at 2:45 PM, Zameer Manji 
> > wrote:
> > > >
> > > > > Some high level comments without looking at the code.
> > > > >
> > > > > I'm in favor from abandoning the thrift generated java code in
> favor
> > of
> > > > > immutable objects. I think it is easier to reason about and will
> > ensure
> > > > we
> > > > > have less errors in our code. If I understand correctly, the
> ProtoBuf
> > > > > format does this by default, so there some precedent for this style
> > of
> > > > code
> > > > > generation already.
> > > > >
> > > > > I think using Facebook's swift is the best approach here. I would
> be
> > > > > hesitant to accept any custom code generation that involved us
> > parsing
> > > > > thrift IDL files or thrift formats over the wire because I poses a
> > very
> > > > > high maintenance burden.
> > > > >
> > > > > I also think generating the MyBatis mutable classes is superior to
> > our
> > > > > current strategy of manually creating them.
> > > > >
> > > > > Finally, the performance improvements look fantastic. As an
> operator
> > > of a
> > > > > large cluster I am excited to see wholesale performance
> improvements
> > > as I
> > > > > am always concerned that my cluster is approaching the limits of
> what
> > > > > Aurora can handle safely.
> > > > >
> > > > > Overall, I think this change merits a serious discussion from all
> > > > > contributors.
> > > > >
> > > > > On Tue, Jan 26, 2016 at 9:19 PM, John Sirois 
> > > wrote:
> > > > >
> > > > > > On Tue, Jan 26, 2016 at 8:47 PM, John Sirois  >
> > > > wrote:
> > > > > >
> > > > > > > Context: Aurora uses the official Apache Thrift compiler today
> > > plus a
> > > > > > > home-grown python code generator [1] for immutable "entity"
> (I*)
> > > > > > wrappers.
> > > > > > >
> > > > > > > The proposal is to switch from using the Apache Thrift code
> > > generator
> > > > > to
> > > > > > a
> > > > > > > home grown generator.  The proposal comes with a concrete
> example
> > > in
> > > > > the
> > > > > > > form of the actual RBs to effect this change:
> > > > > > > 1. A custom java thrift code generator:
> > > > > > > https://reviews.apache.org/r/42748/
> > > > > > > 2. A custom MyBatis binding code generator powered by 1 above:
> > > > > > 

Re: [PROPOSAL] Rename NEWS to RELEASE-NOTES.md

[Jake Farrell]

LICENSE and NOTICE are the only 2 required named files within the release.
The changelog is an optional item and can be named whatever we like, +1 to
making it easier to understand its purpose

-Jake

On Mon, Mar 14, 2016 at 4:27 PM, Bill Farner  wrote:

> Our NEWS file has turned into a useful source of information, but i think
> the name doesn't clearly illustrate its purpose.  Since we have been
> primarily using it to manage release notes, i propose we rename the file to
> RELEASE-NOTES.md.
>
> As the name implies, i also propose that we formally use markdown syntax.
> This will make for more natural linking to other docs, and direct posting
> to our blog at release time (this is currently a manual process,
> translating NEWS to markdown).
>

[VOTE] Release Apache Aurora 0.13.0 RC0

[Jake Farrell]

All,

I propose that we accept the following release candidate as the official
Apache Aurora 0.13.0 release.

Aurora 0.13.0-rc0 includes the following:
---
The NEWS for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=NEWS=rel/0.13.0-rc0

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.13.0-rc0

The tag used to create the release candidate is:
https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.13.0-rc0

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/aurora/0.13.0-rc0/apache-aurora-0.13.0-rc0.tar.gz

The MD5 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.13.0-rc0/apache-aurora-0.13.0-rc0.tar.gz.md5

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.13.0-rc0/apache-aurora-0.13.0-rc0.tar.gz.asc

The GPG key used to sign the release are available at:
https://dist.apache.org/repos/dist/dev/aurora/KEYS

Please download, verify, and test.

The vote will close on Thu Apr 14 23:24:12 EDT 2016, please vote

[ ] +1 Release this as Apache Aurora 0.13.0
[ ] +0
[ ] -1 Do not release this as Apache Aurora 0.13.0 because...


I'd like to get the voting started with my own +1

-Jake

Re: Seeking 0.13.0 release manager

[Jake Farrell]

I'm happy to step in and take the rm role for .13 if no one else is
interested

-Jake

On Tue, Mar 8, 2016 at 12:39 PM, John Sirois  wrote:

> On Mon, Feb 8, 2016 at 4:02 PM, John Sirois  wrote:
>
> > The main 0.12.0 release has just been made and docs/distributions will
> > soon follow.
> >
> > Though we've barely begun work on it, I'd like to line up a release
> > manager for 0.13.0.
> > I'll be happy to help with pointers and advice.  I have a few document
> and
> > script edits still to come to help smooth out the problem areas I ran
> into,
> > so those should help as well.
> >
> > Please speak up if you're interested!
> >
>
> The 0.13.0 release still needs a release manager.
>
> The 0.13.0 release will be focused again on catching up to mesos releases.
> They are now voting on 0.28.0 and Aurora 0.13.0 will be upgrading to
> 0.27.0.
> There are a few deprecations to manage and there may be more work coming in
> from Maxim, Zameer and Co. optimizing the DB store performance further.
>
> The release tickets for more details:
> deprecations: https://issues.apache.org/jira/browse/AURORA-1585
> backwards incompat changes:
> https://issues.apache.org/jira/browse/AURORA-1586
> rc: https://issues.apache.org/jira/browse/AURORA-1584
>
> Once again, please speak up if you're interested!
>

[DISCUSS]: 0.13.0 release candidate

[Jake Farrell]

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
release candidate. Currently planning on cutting the release candidate this
Wednesday, April 6th, pending no blockers coming out of this discussion
thread. Thoughts, objections?

-Jake


[1]: https://issues.apache.org/jira/browse/AURORA-1584

Re: [PROPOSAL] Move Aurora discussions to Slack?

[Jake Farrell]

A number of people where starting to jump on mesos.slack.com #aurora and I
did not want to start having segmented communication occurring so I asked
Vinod to bridge our irc and the slack rooms with the same bot they are
using currently for #mesos. Thanks Vinod, appreciate the help.

This will let us test out slack and see what the community thinks without
giving up irc, and still maintain all existing logging. If we think this is
a good solution we can look at using our own aurora.slack.com and move the
bridge. thoughts?

-Jake



On Wed, Aug 3, 2016 at 1:43 PM, Zameer Manji <zma...@apache.org> wrote:

> I'm also +0 for the same reasons that John listed.
>
> On Tue, Aug 2, 2016 at 2:44 PM, John Sirois <john.sir...@gmail.com> wrote:
>
>> I'm also +0.
>>
>> I am not a Slack fan, but that said, the barrier to entry on the face is
>> the same if we publicize self-signup like mesos has on their community
>> page
>> [1]: https://mesos-slackin.herokuapp.com/
>> On the negative, we hurt folks like Jake who are connected to many
>> projects
>> via IRC and on the positive (maybe) we cater to the burgeoning set of
>> corporate contributors who are connected to many projects via Slack.
>>
>> Being paired with mesos is what tilits me +0 instead of -0.
>>
>> [1] http://mesos.apache.org/community/
>>
>> On Tue, Aug 2, 2016 at 3:14 PM, Joshua Cohen <jco...@apache.org> wrote:
>>
>> > I'm +0 on this. I agree that Slack is in many ways superior to IRC, but
>> it
>> > also feels like the barrier to entry for Slack is much higher than it is
>> > for IRC which is potentially problematic for an open source community.
>> >
>> > On Tue, Aug 2, 2016 at 4:08 PM, Jake Farrell <jfarr...@apache.org>
>> wrote:
>> >
>> > > There is an irc bridge which relays all messages back as well as an
>> > archive
>> > > bot. Not a huge fan of slack due to it being yet another chat client I
>> > have
>> > > in the background, but if it helps the community stay connected and
>> grow
>> > > and makes things easier then +1 for whatever it is.
>> > >
>> > > Might make sense for us to use the mesos.slack.com #aurora channel
>> that
>> > > way
>> > > the two communities stay close and its easier for users to find and
>> ask
>> > > questions rather than having multiple slacks they have to join and
>> keep
>> > > track of
>> > >
>> > > -Jake
>> > >
>> > >
>> > >
>> > >
>> > > On Tue, Aug 2, 2016 at 4:48 PM, Steve Niemitz <sniem...@apache.org>
>> > wrote:
>> > >
>> > > > +1, I pretty much never remember to open my IRC client anymore.
>> I've
>> > > been
>> > > > using the Mesos Slack for a few weeks now and its way better than
>> > IRC.  I
>> > > > believe they have chat logging still via a bot of some type too?
>> > > >
>> > > > On Tue, Aug 2, 2016 at 4:45 PM, Maxim Khutornenko <ma...@apache.org
>> >
>> > > > wrote:
>> > > >
>> > > > > Mesos community has recently moved to Slack as their canonical
>> chat
>> > > > channel
>> > > > > [1]. Thanks to Stephan, we already have some presence there via
>> > #aurora
>> > > > > channel in Apache Mesos team.
>> > > > >
>> > > > > Should we move our IRC discussions to Slack too?
>> > > > >
>> > > > > [1] - http://markmail.org/message/azd37j64wsozmuhe
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [PROPOSAL] Move Aurora discussions to Slack?

[Jake Farrell]

There is an irc bridge which relays all messages back as well as an archive
bot. Not a huge fan of slack due to it being yet another chat client I have
in the background, but if it helps the community stay connected and grow
and makes things easier then +1 for whatever it is.

Might make sense for us to use the mesos.slack.com #aurora channel that way
the two communities stay close and its easier for users to find and ask
questions rather than having multiple slacks they have to join and keep
track of

-Jake




On Tue, Aug 2, 2016 at 4:48 PM, Steve Niemitz  wrote:

> +1, I pretty much never remember to open my IRC client anymore.  I've been
> using the Mesos Slack for a few weeks now and its way better than IRC.  I
> believe they have chat logging still via a bot of some type too?
>
> On Tue, Aug 2, 2016 at 4:45 PM, Maxim Khutornenko 
> wrote:
>
> > Mesos community has recently moved to Slack as their canonical chat
> channel
> > [1]. Thanks to Stephan, we already have some presence there via #aurora
> > channel in Apache Mesos team.
> >
> > Should we move our IRC discussions to Slack too?
> >
> > [1] - http://markmail.org/message/azd37j64wsozmuhe
> >
>

Re: Aurora 0.15.0 release

[Jake Farrell]

+1, go for it

-Jake

On Thu, Jun 30, 2016 at 1:42 PM, Maxim Khutornenko  wrote:

> Since I have not heard otherwise, I assume no objections.
>
> I am going to cut the release later today unless someone wants to be
> the release manager instead.
>
> On Wed, Jun 29, 2016 at 11:35 AM, Maxim Khutornenko 
> wrote:
> > The Mesos 0.28.2 upgrade has just landed:
> https://reviews.apache.org/r/49384/
> >
> > Anyone against cutting a 0.15.0 release now for the sake of catching
> > up and prepping to Mesos 1.0.0 push?
>

Re: Welcome new committers and PMC members!

[Jake Farrell]

Congratulations Mehrdad and Santhosh

-Jake

On Mon, Feb 6, 2017 at 8:56 PM, Joshua Cohen  wrote:

> I'm happy to announce that we've got two new members to add to our ranks!
>
> Mehrdad Nurolahzade is now a committer and PMC member.
> Santhosh Kumar Shanmugham is now a committer.
>
> Please join me in congratulating them on their new roles!
>
> Cheers,
>
> Joshua
>

Re: Aurora Community Sync

[Jake Farrell]

Thanks Mehrdad
If possible will there be notes taken? Any topics that start to take shape
should be brought back to the dev@ list so others in the community that can
not make the meeting or hangout can participate

Great initiative and thanks to Twitter for hosting
-Jake



On Tue, Sep 6, 2016 at 7:05 PM, Mehrdad Nurolahzade  wrote:

> Hi Devs,
>
> A number of us will be meeting here at Twitter office over lunch to discuss
> topics of mutual interest including:
> - health-check based updates - replicated log - dynamic reservation -
> unified containerizer work
>
> Please join us If you want to share your take, curious to learn more or
> eager to contribute.
>
> *Time:* Wednesday Sep 7, 2016 12:30pm PST
> *Google Hangouts link:* https://hangouts.google.com/
> hangouts/_/twitter.com/
> aurora-sync
>
> Cheers,
> Mehrdad
>

Re: [VOTE] Release Apache Aurora 0.16.0 RC2

[Jake Farrell]

+1

Verified using ./build-support/release/verify-release-candidate 0.16.0-rc2

-Jake



On Thu, Sep 22, 2016 at 3:12 PM, Joshua Cohen  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.16.0 release.
>
> Aurora 0.16.0-rc2 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> RELEASE-NOTES.md=rel/0.16.0-rc2
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> CHANGELOG=rel/0.16.0-rc2
>
> The tag used to create the release candidate is:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=
> shortlog;h=refs/tags/rel/0.16.0-rc2
>
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> apache-aurora-0.16.0-rc2.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> apache-aurora-0.16.0-rc2.tar.gz.md5
>
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> apache-aurora-0.16.0-rc2.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Sun Sep 25 14:11:09 CDT 2016
>
> [ ] +1 Release this as Apache Aurora 0.16.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.16.0 because...
>
> 
> 
>

[VOTE] Release Apache Aurora 0.16.0 API Artifacts

[Jake Farrell]

All,
I have packaged up and staged the API jar/source artifacts from Apache
Aurora 0.16.0
release using publishToMavenLocal, signing them with my gpg key and
deployed them to
the Apache staging repo [1]. I propose that we accept this staging repo as
part of
the official Apache Aurora 0.16.0 release artifacts.

Aurora 0.16.0 API artifacts staging repo details include:
---
The branch used to create the staged release candidate artifacts:
https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=tag;h=2475679782231dbd2e44bebf9cac4bc4e2e01b6e

The staged release candidate artifacts are available at:
https://repository.apache.org/content/repositories/orgapacheaurora-1003

The GPG key used to sign the release artifacts are available at:
https://dist.apache.org/repos/dist/dev/aurora/KEYS

Please download, verify, and test.

The vote will close on Tuesday Oct 4 12:00:00 EDT 2016

[ ] +1 Release this as Apache Aurora 0.16.0 API Artifacts
[ ] +0
[ ] -1 Do not release this as Apache Aurora 0.16.0 API Artifacts because...

I would like to get the voting started with my own +1

-Jake


[1]: https://repository.apache.org/content/repositories/orgapacheaurora-1003

Re: [VOTE] Release Apache Aurora 0.16.0 RC2

[Jake Farrell]

not a blocker for the release candidate, can update the CHANGELOG in trunk
and fix version on the ticket

-Jake

On Thu, Sep 22, 2016 at 3:18 PM, Joshua Cohen  wrote:

> Note: I forgot to mark AURORA-1779 as fixed in 0.16.0 before cutting this
> RC, so that isn't reflected in the changelog. I don't consider that a
> blocker to release, but if others disagree I can cut rc3.
>
> On Thu, Sep 22, 2016 at 2:12 PM, Joshua Cohen  wrote:
>
> > All,
> >
> > I propose that we accept the following release candidate as the official
> > Apache Aurora 0.16.0 release.
> >
> > Aurora 0.16.0-rc2 includes the following:
> > ---
> > The RELEASE NOTES for the release are available at:
> > https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> > RELEASE-NOTES.md=rel/0.16.0-rc2
> >
> > The CHANGELOG for the release is available at:
> > https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> > CHANGELOG=rel/0.16.0-rc2
> >
> > The tag used to create the release candidate is:
> > https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=
> > shortlog;h=refs/tags/rel/0.16.0-rc2
> >
> > The release candidate is available at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> > apache-aurora-0.16.0-rc2.tar.gz
> >
> > The MD5 checksum of the release candidate can be found at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> > apache-aurora-0.16.0-rc2.tar.gz.md5
> >
> > The signature of the release candidate can be found at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.16.0-rc2/
> > apache-aurora-0.16.0-rc2.tar.gz.asc
> >
> > The GPG key used to sign the release are available at:
> > https://dist.apache.org/repos/dist/dev/aurora/KEYS
> >
> > Please download, verify, and test.
> >
> > The vote will close on Sun Sep 25 14:11:09 CDT 2016
> >
> > [ ] +1 Release this as Apache Aurora 0.16.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Aurora 0.16.0 because...
> >
> > 
> > 
> >
>

[RESULT][VOTE] Release Apache Aurora 0.16.0 API Artifacts

[Jake Farrell]

Closing this vote thread

1. publishToMavenLocal should have picked up the sources, not sure what
happened there. will go dig back through the code and see what was missed.

2. not sure if e2e is the right place for this as it would need to pull
from a pre-release repo that always changes, though agree that some
validation would be good.

3. AURORA-1751 is the capturing ticket for this artifact not getting
released as part of the process and has an initial howto and outline for
follow up to automate this process.

-Jake



On Fri, Sep 30, 2016 at 9:59 AM, John Sirois <jsir...@apache.org> wrote:

> -1 for 3 reasons:
>
> 1. No sources:
> $ zipinfo ~/desktop/aurora-api-0.16.0-sources.jar
> Archive:  /home/jsirois/desktop/aurora-api-0.16.0-sources.jar
> Zip file size: 261 bytes, number of entries: 2
> drwxr-xr-x  2.0 unx0 b- defN 16-Sep-29 23:35 META-INF/
> -rw-r--r--  2.0 unx   25 b- defN 16-Sep-29 23:35 META-INF/MANIFEST.MF
> 2 files, 25 bytes uncompressed, 29 bytes compressed:  -16.0%
>
> 2. No viable way to test: It seems like it would be good to have a small
> bit of example code that could consume the jar and use it to talk to the
> scheduler - presumably this test setup could be added into the e2e tests.
> 3. No release automation: A doc at the least, a script ideally.
>
> Of these 3 it makes sense to me that 2 and 3 could be coming later - but
> filed issues would be good. Number 1 though should be fixed it seems to me.
>
> On Thu, Sep 29, 2016 at 9:54 PM, Jake Farrell <jfarr...@apache.org> wrote:
>
>> All,
>> I have packaged up and staged the API jar/source artifacts from Apache
>> Aurora 0.16.0
>> release using publishToMavenLocal, signing them with my gpg key and
>> deployed them to
>> the Apache staging repo [1]. I propose that we accept this staging repo as
>> part of
>> the official Apache Aurora 0.16.0 release artifacts.
>>
>> Aurora 0.16.0 API artifacts staging repo details include:
>> ---
>> The branch used to create the staged release candidate artifacts:
>> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=tag;h
>> =2475679782231dbd2e44bebf9cac4bc4e2e01b6e
>>
>> The staged release candidate artifacts are available at:
>> https://repository.apache.org/content/repositories/orgapacheaurora-1003
>>
>> The GPG key used to sign the release artifacts are available at:
>> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>>
>> Please download, verify, and test.
>>
>> The vote will close on Tuesday Oct 4 12:00:00 EDT 2016
>>
>> [ ] +1 Release this as Apache Aurora 0.16.0 API Artifacts
>> [ ] +0
>> [ ] -1 Do not release this as Apache Aurora 0.16.0 API Artifacts
>> because...
>>
>> I would like to get the voting started with my own +1
>>
>> -Jake
>>
>>
>> [1]: https://repository.apache.org/content/repositories/orgapache
>> aurora-1003
>>
>
>

Re: Trouble publishing Aurora 0.16.0 binaries to bintray

[Jake Farrell]

There should be no source tar ball for the binary artifacts, just the deb's
and rpm's which bintray requires that you upload individually. You can use
dist.apache.org to stage the files for the vote and after it is successful
upload them to bintray, we should also look at adding in some scripting for
this to help automate the process

-Jake



On Wed, Oct 19, 2016 at 5:25 PM, Joshua Cohen  wrote:

> Hi all,
>
> I'm trying to get a vote out for the 0.16.0 binaries, but I'm running into
> some issues publishing the binaries. I'm wondering if those who have done
> this in the past have any advice.
>
> The problem seems to boil down to this: when I upload the tarball generated
> by the release-candidate script, bintray does not give me the option to
> explode it. Uploading it directly via curl, rather than the UI, I get an
> error back telling me that it's not a valid type of file to explode, for
> some reason it reads it as an octet-stream rather than a tarball (I even
> tried forcing it by specifying a Content-Type header on the curl request to
> no avail).
>
> If I change the release-candidate script to generate a tar.gz instead of a
> .tar, then I am able to get bintray to give me the option to explode the
> archive, however it still fails because for some reason it's trying to sign
> the files in the archive, but the signature is already present. I've
> confirmed that the option to GPG sign files is not selected for my
> repository.
>
> At this point I'm at a loss for how to continue, as there does not seem to
> be any way to upload the binaries and have bintray explode them, which is
> required for the binary to actually be usable.
>
> You can see what I've uploaded in its current tar form here:
> https://dl.bintray.com/jcohen/aurora/
>
> Any advice is appreciated!
>
> Cheers,
>
> Joshua
>

[REPORT] Apache Aurora - March 2017

[Jake Farrell]

 Please find below our March draft board report, take a second to review
and let me know if any changes are needed

-Jake



Apache Aurora is a stateless and fault tolerant service scheduler used to
schedule jobs onto Apache Mesos such as long-running services, cron jobs,
and one off tasks.

Project Status
-
The Apache Aurora community has continued to see growth from new
contributors over the last quarter while working on our latest 0.17.0
release,
which was successfully released on February 6th. There has been a great
deal of open discussions on the mailing lists surrounding dynamic
reservations, rolling restarts and recently the idea of leveraging Apache
Aurora to start Apache Mesos Maintenance. The Apache
Aurora PMC also added a new committer, Santhosh Shanmugham, as
well as added a new PMC member Mehrdad Nurolahzade.

Community
---
Latest Additions:

* Committer addition: Santhosh Kumar Shanmugham, 2.9.2017
* PMC addition:  Mehrdad Nurolahzade, 2.24.2017

Issue backlog status since last report:

* Created:   50
* Resolved: 51

Mailing list activity since last report:

* @dev 124 messages
* @user24 messages
* @reviews  1292 messages

Releases
---
Last release: Apache Aurora 0.17.0 released 02.06.2017

Re: [VOTE] Release Apache Aurora 0.18.0 RC0

[Jake Farrell]

+1

Thanks Santhosh for helping shepherd this release

-Jake


On Fri, Jun 9, 2017 at 8:13 PM, Santhosh Kumar Shanmugham <
sshanmug...@twitter.com.invalid> wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.18.0 release.
>
> Aurora 0.18.0-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> RELEASE-NOTES.md=rel/0.18.0-rc0
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> CHANGELOG=rel/0.18.0-rc0
>
> The tag used to create the release candidate is:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=
> shortlog;h=refs/tags/rel/0.18.0-rc0
>
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.18.0-rc0/
> apache-aurora-0.18.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.18.0-rc0/
> apache-aurora-0.18.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.18.0-rc0/
> apache-aurora-0.18.0-rc0.tar.gz.asc
>
> The GPG key used to sign the release are available at:
> https://dist.apache.org/repos/dist/dev/aurora/KEYS
>
> Please download, verify, and test.
>
> The vote will close on Mon Jun 12 17:12:10 PDT 2017
>
> [ ] +1 Release this as Apache Aurora 0.18.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.18.0 because...
>
> Thanks,
> -Santhosh
>

[REPORT] Apache Aurora - Sept 2017

[Jake Farrell]

Apache Aurora is a stateless and fault tolerant service scheduler used to
schedule jobs onto Apache Mesos such as long-running services, cron jobs,
and one off tasks.

Project Status
-
The Apache Aurora community has continued to see growth from new
contributors over the last quarter while working on our latest 0.18.0
release,
which was successfully released on June 19th, 2017. There has been a great
open discussions occurring on the mailing lists surrounding hot standby in
replicas to reduce failover time and a design doc has been proposed.

Community
---
Latest Additions:

* Committer addition: Santhosh Kumar Shanmugham, 2.9.2017
* PMC addition:  Mehrdad Nurolahzade, 2.24.2017

Issue backlog status since last report:

* Created:   11
* Resolved: 14

Mailing list activity since last report:

* @dev 114 messages
* @user3 messages
* @reviews   317 messages

Releases
---
Last release: Apache Aurora 0.18.0 released 06.19.2017

[REPORT] Apache Aurora - December 2017

[Jake Farrell]

 Please find below the draft report for December, if anyone has any
modifications or additions please let me know

-Jake



Apache Aurora is a stateless and fault tolerant service scheduler used to
schedule jobs onto Apache Mesos such as long-running services, cron jobs,
and one off tasks.

Project Status
-
The Apache Aurora community has seen a huge growth from new
contributors and user activity over the last quarter. We have successfully
released two new versions of Apache Aurora during this time also,
0.18.1 security release to address CVE-2016-4437 [1] and a regular
planned release of 0.19.0.

Community
---
Latest Additions:

* Committer addition: Santhosh Kumar Shanmugham, 2.9.2017
* PMC addition:  Mehrdad Nurolahzade, 2.24.2017

Issue backlog status since last report:

* Created:   17
* Resolved: 22

Mailing list activity since last report:

* @dev 140 messages
* @user112 messages (3 in previous reporting cycle!!)
* @reviews   1207 messages

Releases
---
Last release:
* Apache Aurora 0.18.1 released 10.31.2017. Security release
* Apache Aurora 0.19.0 released 11.9.2017

[1]: https://www.cvedetails.com/cve/CVE-2016-4437/

Re: [REPORT] Apache Aurora - June 2018

[Jake Farrell]

+1, submitted

Thanks Renan for drafting

-Jake

On Sat, Jun 16, 2018 at 4:03 PM, Renan DelValle  wrote:

> Please find the draft report for June below, if anyone has any
> modifications or addition please let me know.
>
> Jake, feel free to submit this on the community's behalf once all
> modifications and additions are done.
>
> -Renan
>
> Apache Aurora is a stateless and fault tolerant service scheduler used to
> schedule jobs onto Apache Mesos such as long-running services, cron jobs,
> and one off tasks.
>
> Project Status
> -
> The Apache Aurora community has seen growth from new
> contributors and user activity over the last quarter. We have successfully
> released one new versions of Apache Aurora during this time: a regular
> planned release of 0.20.0.
>
> Community
> ---
> Latest Additions:
>
> * Jordan Ly was added to the PMC on Wed May 02 2018
> * Santhosh Kumar Shanmugham was added to the PMC on Wed May 02 2018
>
> Issue backlog status since last report:
>
> * Created:   10 in the last 3 months
> * Resolved: 8 in the last 3 months
>
> Mailing list activity since last report:
>
> * @dev 108 messages
> * @user20 messages
> * @reviews   397 messages
>
> Releases
> ---
> Last release:
> * Apache Aurora 0.20.0 released 4.2.2018
>

Re: Slack IRC Gateway support ending

[Jake Farrell]

No specific policy that I'm aware of. All decisions must occur on list,
outside of that having a Slack, IRC or other is pretty much left up to each
project and how we want to best foster and help support and grow our
community

-Jake

On Wed, Mar 14, 2018 at 4:55 PM, Renan DelValle 
wrote:

> Agreed. Maybe Jake can shine some light on wether Apache has a policy.
>
> One thing I forgot to mention is that the loss of the IRC gateway means we
> no longer have free access to our older chat logs. (The free version of
> Slack limits the amount of history users have access to.)
>
> So that is something else to consider.
>
> On Wed, Mar 14, 2018 at 10:37 AM, David McLaughlin  > wrote:
>
>> I don't have a strong opinion here, the whole chat space is very flavor
>> of the month. Does Apache have a policy?
>>
>>
>>
>> On Tue, Mar 13, 2018 at 3:04 PM, Renan DelValle  wrote:
>>
>>> Hi all,
>>>
>>> Slack has announced that their gateway for IRC will no longer be
>>> available after May 15th, 2018. [1]
>>>
>>> mslackbot was last seen in our IRC channel on February 9th, 2018. [2]
>>>
>>> I would like to hear some feedback from the community as to how we
>>> should proceed.
>>>
>>> My personal experience has been that folks find it difficult to find
>>> their way into our Slack channel, but once they do, the experience is
>>> better than IRC.
>>>
>>> Should also be noted that I haven't seen participation form our IRC
>>> channel in at least six months.
>>>
>>> Still, Slack is a walled garden and we're an open source community, so
>>> I'd like some input on wether:
>>>
>>> A. We should continue discussions in Slack and advertising Slack channel
>>> in our website. If yes, in what capacity (official or unofficial).
>>> B. We should we continue to link to our IRC channel from our website
>>> considering it has been inactive for so long.
>>>
>>> - Renan
>>>
>>> [1] https://get.slack.help/hc/en-us/articles/201727913-Connect-t
>>> o-Slack-over-IRC-and-XMPP
>>> [2] https://wilderness.apache.org/channels/?f=aurora/2018-02-09
>>>
>>
>>
>

Re: Aurora Board Report

[Jake Farrell]

Thanks Renan
Just bought a new house and in the middle of a move and missed the board
report reminder, thanks for picking this up and drafting the report, much
appreciated

-Jake

On Tue, Sep 18, 2018 at 3:58 PM Renan DelValle  wrote:

> Please find the draft report for September below, if anyone has any
> modifications or addition please let me know.
>
> Jake, feel free to submit this on the community's behalf once all
> modifications and additions are done.
>
> -Renan
>
> Apache Aurora is a stateless and fault tolerant service scheduler used to
> schedule jobs onto Apache Mesos such as long-running services, cron jobs,
> and one off tasks.
>
> Project Status
> -
> The Apache Aurora community has seen consistent involvement from
> contributors and consistent user activity over the last quarter. We have
> successfully
> released one new versions of Apache Aurora during this time: a regular
> planned release of 0.21.0.
>
> Community
> ---
> Latest Additions:
>
> * No new PMC members added in the last 3 months
>
> Issue backlog status since last report:
>
> * Created:   5 in the last 3 months
> * Resolved: 3 in the last 3 months
> * Issues created on GitHub: 4 in the last 3 months
> * Issues resolved on GitHub: 1 in the last 3 months
>
> Mailing list activity since last report:
>
> * @dev 97 messages
> * @user12 messages
> * @reviews   179 messages
>
> Releases
> ---
> Last release:
> *  0.21.0 was released on Sun Sep 09 2018
>