Re: [RESULT][VOTE] Move Aurora to Apache Attic

[Renan DelValle]

Thanks for the kind words Rick!

It's great to hear that the work we've done here has been so well 
received and has helped you folks get to where you all wanted to go.


This project is definitely something special and as we transition to the 
next chapter, I wanted to take a moment to reflect on that.


I've been so fortunate as to have been introduced to it around 2015 when 
I was still a grad student. Along with Mesos, Aurora served as the spark 
that eventually led me to a PhD dissertation and to a full time job at 
PayPal.


At PayPal, Aurora has served as an immensely solid foundational bedrock 
for our internal product. At the same time many folks involved with this 
project have become pivotal mentors for me for which I'm very thankful.


So thanks to all involved with this project now or in the past and 
here's to the next chapter!


-Renan

On 2/7/20 1:29 PM, Rick Mangi wrote:

I just want to thank everybody who's put in so much work on this project
over the past (5?) years. We're a very small team here but we found aurora
to be a great fit for us and we're still using it for most of our services.
It's been reliable, easy to customize and use. We haven't been able to help
out on the core project but we have a lot of custom components and
experience operating aurora that we hope will be helpful going forward. I
think being available as a non-apache project on github might turn out to
be a positive move for the future of aurora as people might feel more open
to committing to or forking it.

Either way, from all of us a Chartbeat, thank you to everybody who worked
on it so far. You've been a tremendous help to us.

Rick

On Fri, Feb 7, 2020 at 3:28 PM Renan DelValle  wrote:


All,

The vote to move the Apache Aurora project into the Attic has passed.

+1 (Binding)
--
Renan DelValle
Stephan Erb
Bill Farner
Mauricio Garavaglia
Dave Lester
John Sirois

+1 (Non-Binding)
--
Se Choi
Rick Mangi

There were no 0 or -1 votes. Thank you to all who voted.

I know it wasn't an easy vote to make but I hope to see you present in
this new iteration of the project.

As stated the project will be rebooted at
https://github.com/aurora-scheduler
The home page of the reboot can be found at
https://aurora-scheduler.github.io/

-Renan

[RESULT][VOTE] Move Aurora to Apache Attic

[Renan DelValle]

All,

The vote to move the Apache Aurora project into the Attic has passed.

+1 (Binding)
--
Renan DelValle
Stephan Erb
Bill Farner
Mauricio Garavaglia
Dave Lester
John Sirois

+1 (Non-Binding)
--
Se Choi
Rick Mangi

There were no 0 or -1 votes. Thank you to all who voted.

I know it wasn't an easy vote to make but I hope to see you present in this new 
iteration of the project.

As stated the project will be rebooted at https://github.com/aurora-scheduler
The home page of the reboot can be found at https://aurora-scheduler.github.io/

-Renan


2020-02-06 17:15 GMT-08:00 John Sirois:
> +1
> 
> On Thu, Feb 6, 2020, 3:34 PM Stephan Erb  wrote:
> 
>> With a heavy heart:
>> +1 (binding)
>> On Wed, 2020-02-05 at 08:15 +0900, thinker0 wrote:
>> > +2
>> > 2020년 2월 5일 (수) 오전 2:22, Mauricio Garavaglia <
>> mauriciogaravag...@gmail.com>님이작성:
>> > > +1
>> > > On Mon, Feb 3, 2020 at 8:27 PM Dave Lester  wrote:
>> > > > +1 (binding)
>> > > > On 2020/02/03 22:59:56, Rick Mangi  wrote:
>> > > > > +1
>> > > > > We love Aurora :-)
>> > > > >
>> > > > > On Mon, Feb 3, 2020 at 3:54 PM Bill Farner 
>> wrote:
>> > > > > > +1
>> > > > > > Aurora has always been about pragmatism, and right now, this is
>> the
>> > > > best
>> > > > > > route for new and existing users.
>> > > > > > On Fri, Jan 31, 2020 at 5:13 PM Renan DelValle > >
>> > > > wrote:
>> > > > > > > +1 (with a fair bit of sadness but hope for the future of the
>> > > > project)
>> > > > > > > 2020-01-31 17:11 GMT-08:00 Renan DelValle:
>> > > > > > > > Folks,
>> > > > > > > > As discussed previously, the project activity has diminished
>> to
>> > > the
>> > > > > > > point that the overhead of being an Apache project outweighs
>> the
>> > > > benefits
>> > > > > > > of being under the Apache umbrella.
>> > > > > > > > If this vote passes, the PMC will be dissolved, our current
>> > > project
>> > > > > > > resources will be moved into the Attic, and the project will
>> reboot
>> > > > in
>> > > > > > > Github under https://github.com/aurora-scheduler
>> > > > > > > > The vote will close on Fri Feb 7 12:00:00 2020 San Francisco
>> Time
>> > > > > > > > [ ] +1 Move Aurora into the Apache Attic and dissolve the
>> PMC[ ] +0[ ] -1 Move Aurora into the Apache Attic and dissolve the PMC
>> > > > > > because...
>>
> 

Re: [VOTE] Move Aurora to Apache Attic

[Renan DelValle]

+1 (with a fair bit of sadness but hope for the future of the project)

2020-01-31 17:11 GMT-08:00 Renan DelValle:
> Folks,
> 
> As discussed previously, the project activity has diminished to the point 
> that the overhead of being an Apache project outweighs the benefits of being 
> under the Apache umbrella.
> 
> If this vote passes, the PMC will be dissolved, our current project resources 
> will be moved into the Attic, and the project will reboot in Github under 
> https://github.com/aurora-scheduler
> 
> The vote will close on Fri Feb 7 12:00:00 2020 San Francisco Time
> 
> [ ] +1 Move Aurora into the Apache Attic and dissolve the PMC
> [ ] +0
> [ ] -1 Move Aurora into the Apache Attic and dissolve the PMC because...

[VOTE] Move Aurora to Apache Attic

[Renan DelValle]

Folks,

As discussed previously, the project activity has diminished to the point that 
the overhead of being an Apache project outweighs the benefits of being under 
the Apache umbrella.

If this vote passes, the PMC will be dissolved, our current project resources 
will be moved into the Attic, and the project will reboot in Github under 
https://github.com/aurora-scheduler

The vote will close on Fri Feb 7 12:00:00 2020 San Francisco Time

[ ] +1 Move Aurora into the Apache Attic and dissolve the PMC
[ ] +0
[ ] -1 Move Aurora into the Apache Attic and dissolve the PMC because...

[DISCUSSION] Move Apache Aurora into the Attic, reboot project on Github, and dissolve Aurora PMC

[Renan DelValle]

Folks,

Per the guidelines to move a project to the Apache Attic [1] and in an effort 
be fully transparent with the community, I am making it public that we intend 
to move the Apache Aurora project into the Attic and rebooting the project 
under its own organization on Github.

As the number of contributors has dwindled with time, we've come to the point 
where there has only been a sole contributor since September, 2019.

The overhead of running the project as an Apache project is non-negligible and 
as much as love calling the ASF our home, it feels like the time has come
to move our project out of the ASF umbrella to a home of its own. 

Therefore, I propose moving the project to its own organization in Github. To 
that end I have reserved the organization name aurora-scheduler in Github[2].

I'd also like to note that this decision is not final until the PMC votes on it 
publicly on the dev list and that everyone should feel free to chime in on this 
discussion.

I will keep this discussion open until Friday, 12 PM San Francisco time. After 
that, I will be calling for a vote publicly to proceed with moving the project 
to the Attic.

-Renan

[1] https://attic.apache.org/process.html
[2] https://github.com/aurora-scheduler

Website moved to git and misc updates

[Renan DelValle]

Folks,

I've taken some time this holiday to tackle some backlogged issues for 
our project. In particular, I've put a fair amount of work towards 
moving our website from SVN to Git. I'm happy to say the move was a 
success.


Our website now resides at https://github.com/apache/aurora-website with 
the asf-site branch being shown at https://aurora.apache.org/ and the 
asf-staging branch being shown at https://aurora.staged.apache.org/


As part of this effort I've moved our website generating tooling from 
vagrant to docker.


The Dockerfile used to generate the image resides at 
https://github.com/apache/aurora-website/blob/asf-staging/Dockerfile 
while a Docker image resides at 
https://hub.docker.com/repository/docker/apache/aurora-website with the 
tag dev.


Hopefully this allows us to move towards automating the generation of 
the site any time documentation is updated.


Some minutia and background on this:

With the release of 0.22.0[1], our website had to be updated to reflect 
the latest release. When I tried to update the website, our Vagrant 
setup had become stale since the 0.21.0 release to the point that it 
broke. Some dependencies needed a newer version of Ruby (>= 2.0.0) which 
led me to updating our static site generator, Middleman[2], to the 
latest version 4.3.5. Everything worked fine with a newer version of 
Ruby, 2.5.0, and the website was updated, until I tried navigating the 
site and realized the upgrade had generated broken links.


Something had changed between our previous version 3.4.1 and the latest 
release regarding how pretty urls[3] are generated. I was unsuccessful 
in finding a fix to issue in a timely manner. Therefore I decided to 
roll back to the previous version. To get a version (Ruby 2.0.0) that 
worked without breaking anything else, I decided to roll out a docker 
image with RVM[4] which puts us in control of our own Ruby version.


With our current setup, we can now get the image from the 
apache/aurora-website repo and everything is ready to generate the site 
immediately which hopefully allows us to avoid landing in this scenario 
again.


Hope everyone had a wonderful new year!

-Renan

[1] http://aurora.apache.org/blog/aurora-0-22-0-released/

[2] https://middlemanapp.com/

[3] https://middlemanapp.com/advanced/pretty-urls

[4] https://rvm.io/

Upgrading dependencies

[Renan DelValle]

Folks,

Just wanted to give a heads up that I've been working on upgrading some 
of our project's dependencies. I'm going to try to get through these 
upgrades in a quick manner. In order to keep moving and not lose 
momentum, I'll be merging stuff into the master somewhat quickly. If 
anyone sees anything that could be done better or a problem that needs 
addressing, feel free to comment on the PR, even if it has already been 
closed.



Thanks!

-Renan

Re: [RESULT][VOTE] Release Apache Aurora 0.22.0 RC1

[Renan DelValle]

Aurora 0.22.0 includes the following:
---
The CHANGELOG for the release is available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.22.0

The tag used to create the release with is rel/0.22.0:
https://gitbox.apache.org/repos/asf?p=aurora.git=shortlog=refs/tags/rel/0.22.0

The release is available at:
https://dist.apache.org/repos/dist/release/aurora/0.22.0/apache-aurora-0.22.0.tar.gz

The SHA-512 checksum of the release can be found at:
https://dist.apache.org/repos/dist/release/aurora/0.22.0/apache-aurora-0.22.0.tar.gz.sha512

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

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


On Thu, 12 Dec 2019 15:41:57 -0800 (PST), "Renan DelValle"  
wrote:

> All,
> The vote to accept Apache Aurora 0.22.0 RC1 as the official Apache Aurora
> 0.22.0 release has passed.
> 
> +1 (Binding)
> ------
> Renan DelValle
> Stephan Erb
> Mauricio Garavaglia
> 
> There were no 0 or -1 votes. Thank you to all who helped make this release.
> 
> -Renan
> 
> On Thu, 12 Dec 2019 22:58:42 +0100, Stephan Erb  wrote:
> 
> > +1
> > Thanks for driving this!
> > 
> > On Wed, 2019-12-04 at 19:45 -0300, Mauricio Garavaglia wrote:
> > > +1 All tests passed
> > > On Tue, Dec 3, 2019 at 6:37 PM Renan DelValle  wrote:
> > > > Kicking the voting off with a +1 from me.
> > > > Ran the end to end tests successfully.
> > > > On Tue, 03 Dec 2019 13:36:31 -0800 (PST), "Renan DelValle" 
> > > >  wrote:
> > > > > All,
> > > > > I propose that we accept the following release candidate as the 
> > > > > officialApache Aurora 0.22.0 release.
> > > > > Aurora 0.22.0-rc1 includes the following:---The RELEASE NOTES for the 
> > > > > release are available at:
> > > > https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc1
> > > > > The CHANGELOG for the release is available 
> > > > > at:https://github.com/apache/aurora/milestone/2?closed=1
> > > > > 
> > > > > The tag used to create the release candidate is:
> > > > https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.22.0-rc1
> > > > > The release candidate is available at:
> > > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz
> > > > > The SHA-512 checksum of the release candidate can be found at:
> > > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz.sha512
> > > > > The signature of the release candidate can be found at:
> > > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.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 Fri Dec  6 13:30:12 PST 2019
> > > > > [ ] +1 Release this as Apache Aurora 0.22.0[ ] +0[ ] -1 Do not 
> > > > > release this as Apache Aurora 0.22.0 because...
> > > > 
> > > > 

[RESULT][VOTE] Release Apache Aurora 0.22.0 RC1

[Renan DelValle]

All,
The vote to accept Apache Aurora 0.22.0 RC1 as the official Apache Aurora
0.22.0 release has passed.

+1 (Binding)
--
Renan DelValle
Stephan Erb
Mauricio Garavaglia

There were no 0 or -1 votes. Thank you to all who helped make this release.

-Renan

On Thu, 12 Dec 2019 22:58:42 +0100, Stephan Erb  wrote:

> +1
> Thanks for driving this!
> 
> On Wed, 2019-12-04 at 19:45 -0300, Mauricio Garavaglia wrote:
> > +1 All tests passed
> > On Tue, Dec 3, 2019 at 6:37 PM Renan DelValle  wrote:
> > > Kicking the voting off with a +1 from me.
> > > Ran the end to end tests successfully.
> > > On Tue, 03 Dec 2019 13:36:31 -0800 (PST), "Renan DelValle" 
> > >  wrote:
> > > > All,
> > > > I propose that we accept the following release candidate as the 
> > > > officialApache Aurora 0.22.0 release.
> > > > Aurora 0.22.0-rc1 includes the following:---The RELEASE NOTES for the 
> > > > release are available at:
> > > https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc1
> > > > The CHANGELOG for the release is available 
> > > > at:https://github.com/apache/aurora/milestone/2?closed=1
> > > > 
> > > > The tag used to create the release candidate is:
> > > https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.22.0-rc1
> > > > The release candidate is available at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz
> > > > The SHA-512 checksum of the release candidate can be found at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz.sha512
> > > > The signature of the release candidate can be found at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.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 Fri Dec  6 13:30:12 PST 2019
> > > > [ ] +1 Release this as Apache Aurora 0.22.0[ ] +0[ ] -1 Do not release 
> > > > this as Apache Aurora 0.22.0 because...
> > > 
> > > 

Docker Compose based dev setup

[Renan DelValle]

All,

In an effort to simplify the development process I've been working on a way to 
create a Mesos/Aurora dev cluster using docker-compose[1]. 

I'd love to get some feedback on what can be improved. I've been doing some 
development myself using this project and it has cut down the time I've spent 
waiting for vagrant to recreate the dev VM by several minutes.

The guide can be found here: 
https://github.com/ridv/aurora-docker/wiki/Docker-Compose-Dev-Environment

Future improvements may include building everything inside a container so that 
no dependencies are needed in the local box.

- Renan


[1] https://docs.docker.com/compose/

Re: [VOTE] Release Apache Aurora 0.22.0 RC1

[Renan DelValle]

Kicking the voting off with a +1 from me.

Ran the end to end tests successfully.

On Tue, 03 Dec 2019 13:36:31 -0800 (PST), "Renan DelValle"  
wrote:

> All,
> 
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.22.0 release.
> 
> Aurora 0.22.0-rc1 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc1
> 
> The CHANGELOG for the release is available at:
> https://github.com/apache/aurora/milestone/2?closed=1
> 
> The tag used to create the release candidate is:
> https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.22.0-rc1
> 
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz
> 
> The SHA-512 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz.sha512
> 
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.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 Fri Dec  6 13:30:12 PST 2019
> 
> [ ] +1 Release this as Apache Aurora 0.22.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.22.0 because...

[VOTE] Release Apache Aurora 0.22.0 RC1

[Renan DelValle]

All,

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

Aurora 0.22.0-rc1 includes the following:
---
The RELEASE NOTES for the release are available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc1

The CHANGELOG for the release is available at:
https://github.com/apache/aurora/milestone/2?closed=1

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

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

The SHA-512 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.0-rc1.tar.gz.sha512

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc1/apache-aurora-0.22.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 Fri Dec  6 13:30:12 PST 2019

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

[RESULT][VOTE] Release Apache Aurora 0.22.0 RC0

[Renan DelValle]

Voting -1, marking this release as failed, and closing the vote on this release 
candidate.

As Stephan Erb pointed out, we are currently failing our end to end tests.

Will investigate a solution and call for a new release candidate.

-Renan

On Tue, 22 Oct 2019 13:05:56 -0700 (PDT), "Renan DelValle"  
wrote:

> All,
> 
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.22.0 release.
> 
> Aurora 0.22.0-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc0
> 
> The CHANGELOG for the release is available at:
> https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.22.0-rc0
> 
> The tag used to create the release candidate is:
> https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.22.0-rc0
> 
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc0/apache-aurora-0.22.0-rc0.tar.gz
> 
> The SHA-512 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc0/apache-aurora-0.22.0-rc0.tar.gz.sha512
> 
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc0/apache-aurora-0.22.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 Fri Oct 25 13:04:04 PDT 2019
> 
> [ ] +1 Release this as Apache Aurora 0.22.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.22.0 because...

[VOTE] Release Apache Aurora 0.22.0 RC0

[Renan DelValle]

All,

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

Aurora 0.22.0-rc0 includes the following:
---
The RELEASE NOTES for the release are available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.22.0-rc0

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

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

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

The SHA-512 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc0/apache-aurora-0.22.0-rc0.tar.gz.sha512

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.22.0-rc0/apache-aurora-0.22.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 Fri Oct 25 13:04:04 PDT 2019

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

Re: Planning for 0.22.0 release

[Renan DelValle]

Cool, then I'll create an RC either today or tomorrow and start the voting.

Thanks folks!

On 10/20/19 5:54 AM, Stephan Erb wrote:

Sounds good from my side as well.

+1

On 15.10.19, 19:20, "Mauricio Garavaglia"  wrote:

 +1
 
 On Mon, Oct 14, 2019 at 7:03 PM Renan DelValle  wrote:
 
 > Folks,

 >
 > We've accumulated enough changes where I feel comfortable beginning the
 > voting process for a release candidate for Aurora 0.22.0
 >
 > Aurora 0.22.0 would be compatible all the way up to Mesos 1.6.x.
 >
 > Releasing 0.22.0 would allow us to have a saner path for operators to
 > upgrade their Mesos version as we want to also not fall too far behind
 > Mesos' latest version.
 >
 > If enough in the community thinks it would be a good idea to create a
 > release candidate and call for a vote, I will start create an RC and call
 > for a vote in the coming days.
 >
 > -Renan
 >
 



To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://jda.com/privacy-policy.

Planning for 0.22.0 release

[Renan DelValle]

Folks,

We've accumulated enough changes where I feel comfortable beginning the
voting process for a release candidate for Aurora 0.22.0

Aurora 0.22.0 would be compatible all the way up to Mesos 1.6.x.

Releasing 0.22.0 would allow us to have a saner path for operators to
upgrade their Mesos version as we want to also not fall too far behind
Mesos' latest version.

If enough in the community thinks it would be a good idea to create a
release candidate and call for a vote, I will start create an RC and call
for a vote in the coming days.

-Renan

[NOTICE] PMC Chair change

[Renan DelValle]

All,

First, I wish to sincerely thank Jake Farrell who stepped up to lead this
project at a very critical time and has been a great champion of the
project. We wouldn't still be here without your contributions Jake, thank
you.

Second, I wanted to inform the community that yesterday the Apache board
approved my nomination to be the new PMC Chair for Aurora.

I appreciate and am grateful for the trust that the PMC has been placed in
me and I hope folks will join me in continuing to keep this awesome project
alive.

Looking forward to our release of 0.22.0.

-Renan

Python 2 is being sunset on January, 2020

[Renan DelValle]

All,

Python 2 is on it's way out and will no longer be receiving security
updates after Jan 1st, 2020. [1] Aurora currently has a few components
which are currently only compatible with Python 2 including thermos.
Running Aurora components that are only compatible with Python 2 may become
an increasing security liability from the set sunsetting date.

I've opened up an issue on our Github to track/discuss this issue:
https://github.com/apache/aurora/issues/68

Justin Venus has been kind enough to offer his support and expertise in
this field to help shepherd this really important task.

Right now we're looking for guidance from the community as to the direction
we want to go in:

Do we want to drop support for Python 2 and asks users to migrate to Python
3 ASAP?

or

Do we want to move towards deprecating support for Python 2 slowly over the
next year with an EOL support of (around) the end of 2020 while maintaining
both Python2 and Python3 support until then?

Ideally, we'd go for the second approach but the truth is we're lacking in
devpower. If we go the second route there is no guarantee that we would get
there in time to avoid putting systems at risk.

I'd love to hear everyone's take on this.

-Renan

[1] https://www.python.org/doc/sunset-python-2/

Moving website from svnpubsub to gitpubsub

[Renan DelValle]

All,

I plan on filing a request to move our website from svnpubsub[1] to
gitpubsub[1] as this will make it easier to keep the latest documentation
up to date using a CI.

It looks like this was attempted a while ago (
https://github.com/apache/aurora-website) but it was never finished.

Unless anyone feels we should stick with svnpubsub, I'll be filing a
request with Apache Infra next week.


-Renan

[1] https://www.apache.org/dev/project-site.html#intro

Merging Batch Aware Auto Pause and preparing 0.22.0 for release

[Renan DelValle]

Folks,

Pending a sanity check from Mauricio for the changes he requested, I'm
looking to merge PR #54 (https://github.com/apache/aurora/pull/54) which
will add Batch Aware Auto Pausing within the next two weeks.

This feature will come in pretty well tested but I want to label it as a
beta feature for the time being.

Following the merging of this feature, I'm going to be looking to shepherd
PR #59 (https://github.com/apache/aurora/pull/59) to get it to a point
where it's ready to be merged. (Whether this makes it into 0.22.0 will be a
matter of how long it takes to get into better shape.)

I will also be looking at an approximate time to cut 0.22.0 since I think
we've accumulated enough changes to warrant a release.

If anyone has any opinions on the above, please speak up, otherwise I'll go
ahead with the plan as outlined above.

-Renan

New PMC member: Mauricio Garavaglia

[Renan DelValle]

All,

It is my pleasure to announce that Mauricio Garavaglia has agreed to join
the Aurora PMC. His membership acceptance comes at a crucial time for the
project to continue to exist as an Apache project.

Finally, just a friendly reminder that we're still looking for folks to
help maintain the project.

-Renan

Re: Status and Health of the Aurora Project

[Renan DelValle]

I'm still willing to dedicate time to the project. Since this announcement
was made I've heard from a few users offline. Looks like none of us really
want to see this project end up in the Apache Attic.

Folks who want to contribute: would any of you feel comfortable stepping up
and becoming committers? Right now I think that's our biggest hurdle. We
need votes to get releases out and code reviews to get patches in.

-Renan

On Sat, Jun 15, 2019 at 1:19 PM Mauricio Garavaglia <
mauriciogaravag...@gmail.com> wrote:

> Hello!
>
> I'm not working with Aurora anymore, but I have experience in the code base
> and operating it at scale. I certainly wouldn't want to see it go the
> attic. I'll be glad to help with the chores.
>
>
> On Fri, Jun 14, 2019 at 9:17 AM  wrote:
>
> > We are still strong users of aurora, but have not made any contributions.
> > Would be happy to help to keep it alive though.
> >
> > > On Jun 14, 2019, at 10:21 AM, thinker0  wrote:
> > >
> > > Is there a new challenge?
> > >
> > > 2019년 6월 14일 (금) 오후 11:09, Stephan Erb 님이 작성:
> > >
> > >> Dear Aurora community,
> > >>
> > >> the Apache Aurora project has seen a significant slowdown of user and
> > >> contributor activity over the most recent months. This can partially
> be
> > >> attributed to the overall stability and maturity of the project, but
> > more
> > >> importantly this is due to other external projects that managed to win
> > the
> > >> developer mindshare within the container orchestration field (e.g.,
> > general
> > >> purpose cloud providers, Kubernetes, ...).
> > >>
> > >> An Apache project requires at least three active PMC members and an
> > active
> > >> Chair. We are currently not meeting these requirements.
> > >>
> > >> I am are hereby asking the community to step up if you would like the
> > >> project to remain active. If there is sufficient interest and
> > volunteers,
> > >> we can reboot the PMC with new members. If there is not, then the
> Aurora
> > >> project will need to be moved to the Apache attic.
> > >>
> > >> Greetings and thanks to all current and former Aurora users,
> > contributors,
> > >> and PMC members.
> > >>
> > >> Best regards,
> > >> Stephan
> > >>
> >
>

ASF Board Report for Aurora March 2019

[Renan DelValle]

All,

Proposing this as our March Board report. If no changes are proposed, I
will send it by 12 PM San Francisco time on March 13th, 2019.

-Renan

-

## Description:

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.

## Issues

The project might be heading towards the Apache Attic in the future,
unless the community interest increases again. We will need advice on when
and how we should make this transition.

## Health report

The Apache Aurora project has seen a significant slowdown of user and
contributor activity over the most recent months. This can partially be
attributed to the overall stability and maturity of the project, but
more importantly this is due to other external projects that managed to
win the developer mindshare within the container orchestration field
(e.g., general purpose cloud providers, Kubernetes, ...).

## PMC changes:

 - Currently 21 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Jordan Ly on Wed May 02 2018

## Committer base changes:

 - Currently 22 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Renan DelValle at Fri Jan 26 2018

Issue backlog status since last report:

* 0 JIRA tickets created in the last 3 months
* 0 JIRA tickets closed/resolved in the last 3 months

Mailing list activity since last report:

* @dev 9 messages (127 in previous quarter)
* @user2 messages (13 in previous quarter)
* @reviews 22 messages (181 in previous quarter)
* @issues  8 messages (15 in previous quarter)


## Releases:

 - Last release was 0.21.0 on Sun Sep 09 2018

## Mailing list activity:

Activity for this project is on a downward trajectory. As noted above, this
project may be headed for the Attic if this trend continues.

 - dev@aurora.apache.org:
- 152 subscribers (down -1 in the last 3 months):
- 19 emails sent to list (90 in previous quarter)

 - announceme...@aurora.apache.org:
- 47 subscribers (up 1 in the last 3 months):
- 0 emails sent to list (0 in previous quarter)

 - iss...@aurora.apache.org:
- 36 subscribers (down -1 in the last 3 months):
- 0 emails sent to list (17 in previous quarter)

 - revi...@aurora.apache.org:
- 31 subscribers (up 0 in the last 3 months):
- 8 emails sent to list (146 in previous quarter)

 - u...@aurora.apache.org:
- 87 subscribers (up 1 in the last 3 months):
- 1 emails sent to list (9 in previous quarter)

Re: How can I change the ThermosExecutor DEBUG log to INFO?

[Renan DelValle]

Doesn't look like it's currently an option. It seems like all components
are set to DEBUG.
https://github.com/apache/aurora/search?q=set_disk_log_level_q=set_disk_log_level

May be a good idea to have this a parameter.

On Mon, Feb 18, 2019 at 8:56 PM thinker0  wrote:

> How can I change the DEBUG log to INFO?
>
>
> https://github.com/apache/aurora/blob/master/src/main/python/apache/aurora/executor/bin/thermos_executor_main.py#L57
>

Re: Combining limit and dedicated constraint

[Renan DelValle]

I tried this out and the task that was previously scheduled was not able to
hop over so it looks like the issue is probably outside of Aurora.

Thanks Bill!

On Mon, Feb 4, 2019 at 6:52 PM Bill Farner  wrote:

> I’m pretty sure I’ve seen this combination working in the (distant) past,
> for limit:1 and other values.
>
> As a sanity check, if you remove the host that _is_ having the task
> scheduled, does the task move to the other host?
>
> On Mon, Feb 4, 2019 at 5:10 PM Renan DelValle 
> wrote:
>
> > I have two dedicated nodes with a dedicated X attribute. I launched a Job
> > containing the dedicated constraint X and a limit:1 and the job has two
> > instances.
> > Only one instance is able to find a match while the other alternates
> > between being vetoed for not matching the dedicated attribute and not
> > matching the limit attribute.
> >
> > I've checked that the offers from the dedicated nodes are coming through
> > with the right attributes.
> > Has anyone else been able to do this successfully?
> >
> > -Renan
> >
>

Combining limit and dedicated constraint

[Renan DelValle]

I have two dedicated nodes with a dedicated X attribute. I launched a Job
containing the dedicated constraint X and a limit:1 and the job has two
instances.
Only one instance is able to find a match while the other alternates
between being vetoed for not matching the dedicated attribute and not
matching the limit attribute.

I've checked that the offers from the dedicated nodes are coming through
with the right attributes.
Has anyone else been able to do this successfully?

-Renan

Re: [DISCUSSION] Potential braking change in Mesos 1.6 upgrade - docker thermos based tasks and aurora task ssh

[Renan DelValle]

+1 to this idea.

It's a good stop gap solution while we explore a better options as well as
explore possible corner cases the change to 750 brings.

I know that you're busy, so thanks for looking into this as well!

-Renan

On Mon, Oct 22, 2018 at 9:26 PM Stephan Erb 
wrote:

> Hi Renan,
>
> Unfortunately, it might even be a bit more complicated: The executor is
> normally launched as root and then drops the privileges for each Thermos
> process once it got forked successfully. If the Mesos filesystem
> permissions are too narrow, then subsequent operations managed by those
> processes will fail. Most notably, the executor will crash whenever it
> tries to rotate log files. At least this is the behavior of the Mesos
> containerize before the fix you have referenced.
>
> In the Docker case, the executor always runs as root. However, there might
> even be other similar issues that only show up for long running containers.
> I therefore see the broken SSH as a symptom of an underlying issue that we
> need to address.
>
> Given that this is currently blocking our progress: Should we consider a
> chmod in
> https://github.com/apache/aurora/blob/32776792d273b36afbf4a1bab69a66fb06163ffd/src/main/python/apache/aurora/executor/common/sandbox.py#L173
> to restore the previous umask of 755 for the sandbox directory?
>
> Best regards,
> Stephan
>
> On 16.10.18, 03:47, "Renan DelValle"  wrote:
>
> All,
>
> As you may know Mesos has changed the default permissions for the
> sandbox
> from 755 (-rwxr-xr-x) to 750 (-rwxr-x---) (
> https://issues.apache.org/jira/browse/MESOS-8332).
>
> Stephan Erb fixed most of the breakage caused by this change with his
> recent patch
>
> https://github.com/apache/aurora/commit/32776792d273b36afbf4a1bab69a66fb06163ffd
>
> Unfortunately, when it comes to docker based containers, the issue is
> a bit
> more complicated.
>
> Stephan and I have both looked into this and have been posting our
> findings
> here:
> https://github.com/apache/aurora/pull/42
>
> Unfortunately, and I speak for myself here, I don't think there is an
> easy
> way to keep our promise to allow users to aurora task ssh into the
> sandbox
> of a docker container based task.
>
> Problem:
>
> When a docker container is launched, it is launched in its own
> namespace
> and every command is run as root (uid=0) by default. This means two
> things:
>
> A) None of the users of the host exist inside the container and
> therefore
> we don't know the uid of the role inside the job key.
>
> B) The sandbox for the dockerized task are owned by uid=0 and gid=0 on
> both
> the container and the host.
>
> Before Mesos 1.6, the permissions were open enough to allow aurora
> task ssh
> to see the sandbox of a docker based task on the host.
>
> From Mesos 1.6 on, aurora task ssh will not be able to see anything
> inside
> of the sandbox of a docker based task since by default it is run under
> user=role.
>
> tl;dr: default aurora task ssh lacks the permissions to see docker
> container based thermos sandboxes.
>
> Solutions:
>
> 1. Find a way to mirror host users in container. (Not partial to this
> as it
> adds a lot of complexity)
>
> 2. Allow users to provide images with uids that match the local boxes.
> (Messy and error prone)
>
> 4. Leave as is (broken aurora task ssh for docker container based
> thermos
> sandboxes) and leave it to operators to provide access to these
> sandboxes. Users
> should still be able to see these files in the sandbox through the
> Aurora
> observer UI and Mesos UI (Sane but potentially burdensome on
> operators).
>
> I'd love to hear other solutions if anyone else has thought of this
> problem.
>
> -Renan
>
>
>

[DISCUSSION] Potential braking change in Mesos 1.6 upgrade - docker thermos based tasks and aurora task ssh

[Renan DelValle]

All,

As you may know Mesos has changed the default permissions for the sandbox
from 755 (-rwxr-xr-x) to 750 (-rwxr-x---) (
https://issues.apache.org/jira/browse/MESOS-8332).

Stephan Erb fixed most of the breakage caused by this change with his
recent patch
https://github.com/apache/aurora/commit/32776792d273b36afbf4a1bab69a66fb06163ffd

Unfortunately, when it comes to docker based containers, the issue is a bit
more complicated.

Stephan and I have both looked into this and have been posting our findings
here:
https://github.com/apache/aurora/pull/42

Unfortunately, and I speak for myself here, I don't think there is an easy
way to keep our promise to allow users to aurora task ssh into the sandbox
of a docker container based task.

Problem:

When a docker container is launched, it is launched in its own namespace
and every command is run as root (uid=0) by default. This means two things:

A) None of the users of the host exist inside the container and therefore
we don't know the uid of the role inside the job key.

B) The sandbox for the dockerized task are owned by uid=0 and gid=0 on both
the container and the host.

Before Mesos 1.6, the permissions were open enough to allow aurora task ssh
to see the sandbox of a docker based task on the host.

>From Mesos 1.6 on, aurora task ssh will not be able to see anything inside
of the sandbox of a docker based task since by default it is run under
user=role.

tl;dr: default aurora task ssh lacks the permissions to see docker
container based thermos sandboxes.

Solutions:

1. Find a way to mirror host users in container. (Not partial to this as it
adds a lot of complexity)

2. Allow users to provide images with uids that match the local boxes.
(Messy and error prone)

4. Leave as is (broken aurora task ssh for docker container based thermos
sandboxes) and leave it to operators to provide access to these
sandboxes. Users
should still be able to see these files in the sandbox through the Aurora
observer UI and Mesos UI (Sane but potentially burdensome on operators).

I'd love to hear other solutions if anyone else has thought of this problem.

-Renan

Re: svn commit: r1842285 - in /aurora/3rdparty: centos/7/python/ debian/jessie64/python/ ubuntu/trusty64/python/ ubuntu/xenial64/python/

[Renan DelValle]

Uploaded :)

-Renan

On Mon, Oct 1, 2018 at 1:00 PM Renan DelValle 
wrote:

> Hi thinker0,
>
> First off, many thanks for your recent contributions. They're very much
> appreciated.
>
> I tried to build CentOS 6 and was unfortunately unsuccessful for 1.5.1 and
> 1.6.1 (even with our previous Vagrantbox setup). The gcc compiler got
> caught in a loop for some macro and eventually crashed. Is there any chance
> you can fix this?
>
> I currently don't have enough bandwidth to triage this issue, but if
> you're able to get the builds working, I'd gladly upload it.
>
> -Renan
>
> On Mon, Oct 1, 2018 at 1:31 AM thinker0  wrote:
>
>> Please CentOS 6
>>
>> ^_^
>>
>> 2018년 9월 29일 (토) 06:54, 님이 작성:
>>
>> > Author: renan
>> > Date: Fri Sep 28 21:54:50 2018
>> > New Revision: 1842285
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1842285=rev
>> > Log:
>> > Adding Mesos 1.6.1 eggs for Centos7, Debian Jessie, Ubuntu Trusty, and
>> > Ubuntu Xenial.
>> >
>> > Added:
>> >
>> >
>> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >  (with props)
>> >
>> >
>> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >  (with props)
>> >
>> >
>> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >  (with props)
>> >
>> >
>> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >  (with props)
>> >
>> > Added:
>> >
>> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> > URL:
>> >
>> http://svn.apache.org/viewvc/aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
>> >
>> >
>> ==
>> > Binary file - no diff available.
>> >
>> > Propchange:
>> >
>> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >
>> >
>> --
>> > svn:mime-type = application/octet-stream
>> >
>> > Added:
>> >
>> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> > URL:
>> >
>> http://svn.apache.org/viewvc/aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
>> >
>> >
>> ==
>> > Binary file - no diff available.
>> >
>> > Propchange:
>> >
>> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >
>> >
>> --
>> > svn:mime-type = application/octet-stream
>> >
>> > Added:
>> >
>> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> > URL:
>> >
>> http://svn.apache.org/viewvc/aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
>> >
>> >
>> ==
>> > Binary file - no diff available.
>> >
>> > Propchange:
>> >
>> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >
>> >
>> --
>> > svn:mime-type = application/octet-stream
>> >
>> > Added:
>> >
>> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> > URL:
>> >
>> http://svn.apache.org/viewvc/aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
>> >
>> >
>> ==
>> > Binary file - no diff available.
>> >
>> > Propchange:
>> >
>> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
>> >
>> >
>> --
>> > svn:mime-type = application/octet-stream
>> >
>> >
>> >
>>
>

executor name in getTasksWithoutConfigs

[Renan DelValle]

All,

Right now the thrift API getTasksWithoutConfigs returns a null
executorConfig. This makes it impossible for the Web UI to differentiate
between thermos tasks which conform to the format that the observer expects
and non-thermos based tasks which do not follow a specific sandbox layout.

What this translates to is broken links in the UI for non-thermos tasks. If
we could differentiate between the tasks we may be able to provide a better
UI experience (including not having a link at all).

In order to differentiate in the web UI, I propose this we modify the
getTasksWithoutConfigs to return task objects with the executorConfig.name
set. executorConfig.data would still be nulled out in
*https://github.com/apache/aurora/blob/master/src/main/java/org/apache/aurora/scheduler/thrift/ReadOnlySchedulerImpl.java#L174
*

I may be wrong but I can't think of any security issues this may cause as
the default executor name is exposed through the API.

If the community agrees this is an OK change to make I will go ahead and
submit a patch to enable this functionality as well as a web UI fix.

-Renan

Re: svn commit: r1842285 - in /aurora/3rdparty: centos/7/python/ debian/jessie64/python/ ubuntu/trusty64/python/ ubuntu/xenial64/python/

[Renan DelValle]

Hi thinker0,

First off, many thanks for your recent contributions. They're very much
appreciated.

I tried to build CentOS 6 and was unfortunately unsuccessful for 1.5.1 and
1.6.1 (even with our previous Vagrantbox setup). The gcc compiler got
caught in a loop for some macro and eventually crashed. Is there any chance
you can fix this?

I currently don't have enough bandwidth to triage this issue, but if you're
able to get the builds working, I'd gladly upload it.

-Renan

On Mon, Oct 1, 2018 at 1:31 AM thinker0  wrote:

> Please CentOS 6
>
> ^_^
>
> 2018년 9월 29일 (토) 06:54, 님이 작성:
>
> > Author: renan
> > Date: Fri Sep 28 21:54:50 2018
> > New Revision: 1842285
> >
> > URL: http://svn.apache.org/viewvc?rev=1842285=rev
> > Log:
> > Adding Mesos 1.6.1 eggs for Centos7, Debian Jessie, Ubuntu Trusty, and
> > Ubuntu Xenial.
> >
> > Added:
> >
> >
> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >  (with props)
> >
> >
> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >  (with props)
> >
> >
> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >  (with props)
> >
> >
> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >  (with props)
> >
> > Added:
> >
> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> > URL:
> >
> http://svn.apache.org/viewvc/aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
> >
> >
> ==
> > Binary file - no diff available.
> >
> > Propchange:
> >
> aurora/3rdparty/centos/7/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >
> >
> --
> > svn:mime-type = application/octet-stream
> >
> > Added:
> >
> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> > URL:
> >
> http://svn.apache.org/viewvc/aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
> >
> >
> ==
> > Binary file - no diff available.
> >
> > Propchange:
> >
> aurora/3rdparty/debian/jessie64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >
> >
> --
> > svn:mime-type = application/octet-stream
> >
> > Added:
> >
> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> > URL:
> >
> http://svn.apache.org/viewvc/aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
> >
> >
> ==
> > Binary file - no diff available.
> >
> > Propchange:
> >
> aurora/3rdparty/ubuntu/trusty64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >
> >
> --
> > svn:mime-type = application/octet-stream
> >
> > Added:
> >
> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> > URL:
> >
> http://svn.apache.org/viewvc/aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg?rev=1842285=auto
> >
> >
> ==
> > Binary file - no diff available.
> >
> > Propchange:
> >
> aurora/3rdparty/ubuntu/xenial64/python/mesos.executor-1.6.1-py2.7-linux-x86_64.egg
> >
> >
> --
> > svn:mime-type = application/octet-stream
> >
> >
> >
>

Re: Build failed in Jenkins: AuroraBot #159733

[Renan DelValle]

Thank you for turning it off. It looks like the jenkins worker nodes are
having connectivity issues. In either case, we don't really need this
anymore since we have travis-ci to take it's place.

I'll work on moving aurora-packaging to travis-ci as well.

-Renan

On Fri, Sep 28, 2018 at 5:47 AM Stephan Erb 
wrote:

> I have disabled the build https://builds.apache.org/job/AuroraBot/ for
> now in order to stop this madness.
>
> It looks like as if there is a general issue with the Apache build
> infrastructure.
>
> On 28.09.18, 14:34, "Apache Jenkins Server" 
> wrote:
>
> See 
>
> --
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on ubuntu-eu2 (ubuntu trusty) in workspace <
> https://builds.apache.org/job/AuroraBot/ws/>
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://github.com/apache/aurora.git
> # timeout=10
> Fetching upstream changes from https://github.com/apache/aurora.git
>  > git --version # timeout=10
>  > git fetch --tags --progress https://github.com/apache/aurora.git
> +refs/heads/*:refs/remotes/origin/*
> ERROR: Error fetching remote repo 'origin'
> hudson.plugins.git.GitException: Failed to fetch from
> https://github.com/apache/aurora.git
> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
> at hudson.scm.SCM.checkout(SCM.java:504)
> at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
> at
> jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
> at hudson.model.Run.execute(Run.java:1794)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
> at
> hudson.model.ResourceController.execute(ResourceController.java:97)
> at hudson.model.Executor.run(Executor.java:429)
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags
> --progress https://github.com/apache/aurora.git
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout:
> stderr: error: missing object referenced by
> 'refs/tags/jenkins-AuroraBot-156903'
> error: missing object referenced by
> 'refs/tags/jenkins-AuroraBot-156908'
> error: missing object referenced by
> 'refs/tags/jenkins-AuroraBot-156909'
> remote: Enumerating objects: 673, done.
> remote: Counting objects:   0% (1/572)   remote: Counting
> objects:   1% (6/572)   remote: Counting objects:   2% (12/572)
>remote: Counting objects:   3% (18/572)   remote: Counting
> objects:   4% (23/572)   remote: Counting objects:   5% (29/572)
>remote: Counting objects:   6% (35/572)   remote: Counting
> objects:   7% (41/572)   remote: Counting objects:   8% (46/572)
>remote: Counting objects:   9% (52/572)   remote: Counting
> objects:  10% (58/572)   remote: Counting objects:  11% (63/572)
>remote: Counting objects:  12% (69/572)   remote: Counting
> objects:  13% (75/572)   remote: Counting objects:  14% (81/572)
>remote: Counting objects:  15% (86/572)   remote: Counting
> objects:  16% (92/572)   remote: Counting objects:  17% (98/572)
>remote: Counting objects:  18% (103/572)   remote: Counting
> objects:  19% (109/572)   remote: Counting objects:  20% (115/572)
>  remote: Counting objects:  21% (121/572)   remote:
> Counting objects:  22% (126/572)   remote: Counting objects:  23%
> (132/572)   remote: Counting objects:  24% (138/572)
>  remote: Counting objects:  25% (143/572)   remote: Counting
> objects:  26% (149/572)   remote: Counting objects:  27% (155/572)
>  remote: Counting objects:  28% (161/572)   remote:
> Counting objects:  29% (166/572)   remote: Counting objects:  30%
> (172/572)   remote: Counting objects:  31% (178/572)
>  remote: Counting objects:  32% (184/572)   remote: Counting
> objects:  33% (189/572)   remote: Counting objects:  34% (195/572)
>  remote: Counting objects:  35% (201/572)   remote:
> Counting objects:  36% (206/572)   remote: Counting objects:  37%
> (212/572)   remote: Counting objects:  38% (218/572)
>  remote: Counting objects:  39% (224/572)   remote: Counting
> objects:  40% (229/572)   remote: Counting objects:  41% (235/572)
>  remote: 

Aurora Board Report

[Renan DelValle]

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

Volunteers needed

[Renan DelValle]

All,

We are in dire need of folks who would be willing to commit time to review
patches and submit patches to maintain the project. Small things like
submitting a patch to upgrade our Mesos dependency (or any other dependency
really) go a long way towards keeping the project up to date.

Unfortunately, many of the members of the Aurora Project Management
Committee (PMC) have either moved on from the project or are not in a
position to dedicate time to the project.

I brought up the topic of PMC inactivity on September 5th to the PMC. Until
today I've only heard from two other PMC members about this topic
privately. That is the current situation the project is currently in.

This means there is a very real chance that if we don't get volunteers, the
project will fall behind and, ultimately, become unmaintained.

Therefore if you use this project and would like to see its development
continue, please consider helping us maintain it by submitting patches or
code reviews.

Thanks

-Renan

Unofficial Binaries for Aurora 0.21.0

[Renan DelValle]

All,

Since we voted to eliminate official binary packages with our last official
binary release being 0.20.0, I'm providing UNOFFICIAL binary packages for
the community via my own personal bintray account for 0.21.0

These unofficial packages were created with
https://github.com/apache/aurora-packaging/tree/0.21.x

I've tested these packages using our scripts in aurora-packaging.

If you run into any issues, please e-mail me personally (not through the
mailing list).

The binaries may be found here (they are signed with my GPG key for safety):

https://dl.bintray.com/rdelvalle/aurora

Thanks,

-Renan

Re: [RESULT][VOTE] Release Apache Aurora 0.21.0 RC1

[Renan DelValle]

Aurora 0.21.0 includes the following:
---
The CHANGELOG for the release is available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0

The tag used to create the release with is rel/0.21.0:
https://gitbox.apache.org/repos/asf?p=aurora.git=shortlog=refs/tags/rel/0.21.0

The release is available at:
https://dist.apache.org/repos/dist/release/aurora/0.21.0/apache-aurora-0.21.0.tar.gz

The SHA-512 checksum of the release can be found at:
https://dist.apache.org/repos/dist/release/aurora/0.21.0/apache-aurora-0.21.0.tar.gz.sha512

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

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

On Mon, Sep 10, 2018 at 8:51 PM Renan DelValle 
wrote:

> All,
> The vote to accept Apache Aurora 0.21.0 RC1 as the official Apache Aurora
> 0.21.0 release has passed.
>
> +1 (Binding)
> ------
> Renan DelValle
> Stephan Erb
> David McLaughlin
>
> There were no 0 or -1 votes. Thank you to all who helped make this release.
>
> On Mon, Sep 10, 2018 at 8:38 PM David McLaughlin 
> wrote:
>
>> +1(ish)
>>
>> I have not been able to get the release verification script to work on my
>> laptop for a while. Something with my local environment. But I ran the
>> testing steps manually and they pass.
>>
>> On Mon, Sep 10, 2018 at 5:14 AM, Stephan Erb > >
>> wrote:
>>
>> > +1 (binding). Release verification has passed for me as well.
>> >
>> > On 06.09.18, 23:01, "Renan DelValle"  wrote:
>> >
>> > Ran the verify release script, +1 (binding) from me.
>> >
>> > On Thu, Sep 6, 2018 at 2:00 PM Renan DelValle <
>> > renanidelva...@gmail.com>
>> > wrote:
>> >
>> > > All,
>> > >
>> > > I propose that we accept the following release candidate as the
>> > official
>> > > Apache Aurora 0.21.0 release.
>> > >
>> > > Aurora 0.21.0-rc1 includes the following:
>> > > ---
>> > > The RELEASE NOTES for the release are available at:
>> > >
>> > > https://gitbox.apache.org/repos/asf?p=aurora.git=
>> > RELEASE-NOTES.md=rel/0.21.0-rc1
>> > >
>> > > The CHANGELOG for the release is available at:
>> > >
>> > > https://gitbox.apache.org/repos/asf?p=aurora.git=
>> > CHANGELOG=rel/0.21.0-rc1
>> > >
>> > > The tag used to create the release candidate is:
>> > >
>> > > https://gitbox.apache.org/repos/asf?p=aurora.git;a=
>> > shortlog;h=refs/tags/rel/0.21.0-rc1
>> > >
>> > > The release candidate is available at:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
>> > apache-aurora-0.21.0-rc1.tar.gz
>> > >
>> > > The SHA-512 checksum of the release candidate can be found at:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
>> > apache-aurora-0.21.0-rc1.tar.gz.sha512
>> > >
>> > > The signature of the release candidate can be found at:
>> > >
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
>> > apache-aurora-0.21.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 Sun Sep  9 14:00:00 2018 San Francisco Time
>> > >
>> > > [ ] +1 Release this as Apache Aurora 0.21.0
>> > > [ ] +0
>> > > [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
>> > >
>> >
>> >
>> >
>>
>

[RESULT][VOTE] Release Apache Aurora 0.21.0 RC1

[Renan DelValle]

All,
The vote to accept Apache Aurora 0.21.0 RC1 as the official Apache Aurora
0.21.0 release has passed.

+1 (Binding)
--
Renan DelValle
Stephan Erb
David McLaughlin

There were no 0 or -1 votes. Thank you to all who helped make this release.

On Mon, Sep 10, 2018 at 8:38 PM David McLaughlin 
wrote:

> +1(ish)
>
> I have not been able to get the release verification script to work on my
> laptop for a while. Something with my local environment. But I ran the
> testing steps manually and they pass.
>
> On Mon, Sep 10, 2018 at 5:14 AM, Stephan Erb 
> wrote:
>
> > +1 (binding). Release verification has passed for me as well.
> >
> > On 06.09.18, 23:01, "Renan DelValle"  wrote:
> >
> > Ran the verify release script, +1 (binding) from me.
> >
> > On Thu, Sep 6, 2018 at 2:00 PM Renan DelValle <
> > renanidelva...@gmail.com>
> > wrote:
> >
> > > All,
> > >
> > > I propose that we accept the following release candidate as the
> > official
> > > Apache Aurora 0.21.0 release.
> > >
> > > Aurora 0.21.0-rc1 includes the following:
> > > ---
> > > The RELEASE NOTES for the release are available at:
> > >
> > > https://gitbox.apache.org/repos/asf?p=aurora.git=
> > RELEASE-NOTES.md=rel/0.21.0-rc1
> > >
> > > The CHANGELOG for the release is available at:
> > >
> > > https://gitbox.apache.org/repos/asf?p=aurora.git=
> > CHANGELOG=rel/0.21.0-rc1
> > >
> > > The tag used to create the release candidate is:
> > >
> > > https://gitbox.apache.org/repos/asf?p=aurora.git;a=
> > shortlog;h=refs/tags/rel/0.21.0-rc1
> > >
> > > The release candidate is available at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
> > apache-aurora-0.21.0-rc1.tar.gz
> > >
> > > The SHA-512 checksum of the release candidate can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
> > apache-aurora-0.21.0-rc1.tar.gz.sha512
> > >
> > > The signature of the release candidate can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/
> > apache-aurora-0.21.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 Sun Sep  9 14:00:00 2018 San Francisco Time
> > >
> > > [ ] +1 Release this as Apache Aurora 0.21.0
> > > [ ] +0
> > > [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
> > >
> >
> >
> >
>

Re: [VOTE] Release Apache Aurora 0.21.0 RC1

[Renan DelValle]

Ran the verify release script, +1 (binding) from me.

On Thu, Sep 6, 2018 at 2:00 PM Renan DelValle 
wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.21.0 release.
>
> Aurora 0.21.0-rc1 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.21.0-rc1
>
> The CHANGELOG for the release is available at:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0-rc1
>
> The tag used to create the release candidate is:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.21.0-rc1
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/apache-aurora-0.21.0-rc1.tar.gz
>
> The SHA-512 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/apache-aurora-0.21.0-rc1.tar.gz.sha512
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/apache-aurora-0.21.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 Sun Sep  9 14:00:00 2018 San Francisco Time
>
> [ ] +1 Release this as Apache Aurora 0.21.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
>

[VOTE] Release Apache Aurora 0.21.0 RC1

[Renan DelValle]

All,

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

Aurora 0.21.0-rc1 includes the following:
---
The RELEASE NOTES for the release are available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.21.0-rc1

The CHANGELOG for the release is available at:
https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0-rc1

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

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

The SHA-512 checksum of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/apache-aurora-0.21.0-rc1.tar.gz.sha512

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc1/apache-aurora-0.21.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 Sun Sep  9 14:00:00 2018 San Francisco Time

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

[RESULT][VOTE] Release Apache Aurora 0.21.0 RC0

[Renan DelValle]

Changing my vote to a -1 and closing this vote as failed.

-Renan

On Wed, Sep 5, 2018 at 5:28 AM Stephan Erb 
wrote:

> Renan, thanks for taking up the release manager role (again)!
>
> This PR https://github.com/apache/aurora/pull/28 is currently still open.
> This would imply that users of Aurora 0.22 won't be able to update to Mesos
> 1.6.0. This breaks our +-1 version compatibility assumption. Should we get
> the patch merged before the release?
>
> Best regards,
> Stephan
>
> On 04.09.18, 21:43, "Renan DelValle"  wrote:
>
> Kicking off the vote with a +1 (binding) from me.
>
> Ran verify release script and everything passed.
>
> -Renan
>
> On Tue, Sep 4, 2018 at 12:30 PM Renan DelValle 
> wrote:
>
> > All,
> >
> > I propose that we accept the following release candidate as the
> official
> > Apache Aurora 0.21.0 release.
> >
> > Aurora 0.21.0-rc0 includes the following:
> > ---
> > The RELEASE NOTES for the release are available at:
> >
> >
> https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.21.0-rc0
> >
> > The CHANGELOG for the release is available at:
> >
> >
> https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0-rc0
> >
> > The tag used to create the release candidate is:
> >
> >
> https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.21.0-rc0
> >
> > The release candidate is available at:
> >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz
> >
> > The SHA-512 checksum of the release candidate can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz.sha512
> >
> > The signature of the release candidate can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.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 Fri Sep  7 12:30:00 2018 San Francisco Time
> >
> > [ ] +1 Release this as Apache Aurora 0.21.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
> >
>
>
>

[NOTICE] Calling for Lazy Consensus on PR #28

[Renan DelValle]

All,

Giving notice to other PMC members (and community members) in the interest
of getting 0.21.0 out the door:

Given that this PR has been open for 27 days and is needed for our release,
I'm calling for lazy consensus[1] on it. If no one reviews or opposes this
patch by Friday, September 7th 2018 at 12 PM San Francisco time, I'll be
merging it that day and cutting 0.21.0-RC1.

Please, if you want your voice heard on this patch, make an effort to do a
code review and leave a comment here:
https://github.com/apache/aurora/pull/28

Thanks

-Renan

[1] https://www.apache.org/foundation/voting.html#LazyConsensus

Re: [VOTE] Release Apache Aurora 0.21.0 RC0

[Renan DelValle]

You are indeed correct that making this release as is would break our - +1
Mesos version promise.

Changing my vote to a -1 and closing this vote as failed.

Hopefully someone else can be the second reviewer on the that PR today and
we can have an RC1 to vote on by the end of the day San Francisco time.

-Renan


On Sep 5, 2018 5:28 AM, "Stephan Erb"  wrote:

Renan, thanks for taking up the release manager role (again)!

This PR https://github.com/apache/aurora/pull/28 is currently still open.
This would imply that users of Aurora 0.22 won't be able to update to Mesos
1.6.0. This breaks our +-1 version compatibility assumption. Should we get
the patch merged before the release?

Best regards,
Stephan


On 04.09.18, 21:43, "Renan DelValle"  wrote:

Kicking off the vote with a +1 (binding) from me.

Ran verify release script and everything passed.

-Renan

On Tue, Sep 4, 2018 at 12:30 PM Renan DelValle  wrote:

> All,
>
> I propose that we accept the following release candidate as the
official
> Apache Aurora 0.21.0 release.
>
> Aurora 0.21.0-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
>
>
https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.21.0-rc0
>
> The CHANGELOG for the release is available at:
>
>
https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0-rc0
>
> The tag used to create the release candidate is:
>
>
https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.21.0-rc0
>
> The release candidate is available at:
>
>
https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz
>
> The SHA-512 checksum of the release candidate can be found at:
>
>
https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz.sha512
>
> The signature of the release candidate can be found at:
>
>
https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.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 Fri Sep  7 12:30:00 2018 San Francisco Time
>
> [ ] +1 Release this as Apache Aurora 0.21.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
>

Re: [VOTE] Release Apache Aurora 0.21.0 RC0

[Renan DelValle]

Kicking off the vote with a +1 (binding) from me.

Ran verify release script and everything passed.

-Renan

On Tue, Sep 4, 2018 at 12:30 PM Renan DelValle  wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.21.0 release.
>
> Aurora 0.21.0-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git=RELEASE-NOTES.md=rel/0.21.0-rc0
>
> The CHANGELOG for the release is available at:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.21.0-rc0
>
> The tag used to create the release candidate is:
>
> https://gitbox.apache.org/repos/asf?p=aurora.git;a=shortlog;h=refs/tags/rel/0.21.0-rc0
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz
>
> The SHA-512 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.0-rc0.tar.gz.sha512
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.21.0-rc0/apache-aurora-0.21.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 Fri Sep  7 12:30:00 2018 San Francisco Time
>
> [ ] +1 Release this as Apache Aurora 0.21.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.21.0 because...
>

Re: Regarding our recent move to gitbox

[Renan DelValle]

Kicking off this discussion with my own opinions inline:


On Tue, Jul 31, 2018 at 5:04 PM Renan DelValle  wrote:

> All,
>
> I wanted to take a few minutes to explain what our recent change to gitbox
> means in practice.
>
> For our users:
> * The change is (hopefully) not very impactful. The only thing that
> changes is the location of the aurora and aurora-packing repositories.
> Update those as needed by your usage.
> * You may now depend on the github repository as the main source of aurora
> code.
>
> For our developers (and, more importantly, future developers):
> * You can now make contributions by making Pull Requests through the
> github.com UI!
> * Contributors may still submit contributions through the Review Board
> workflow.
>
> For our committers:
> * You can now commit Pull Requests directly through the github UI.
> * You may also continue to commit contributions through the Review Board
> workflow.
> * Origin is now g...@github.com:apache/aurora.git All pushes committing
> new code from contributions should be made there.
> * aurora-packaging has a protected master branch. This means commits
> cannot be directly pushed to master -- only through pull requests. This is
> to avoid accidental pushes to the master. Review Board flow is still
> possible here but an extra step is required.
>
> Finally a few points of discussion:
>
> * Should we enable issues on github for both aurora and aurora-packaging?
> If yes, should this replace JIRA for aurora and aurora-packaging? (A vote
> is probably in order for this if the overall sentiment is positive)
>

I'm +1 for enabling github issues on both aurora and aurora-packaging. With
a strong +1 for enabling them on aurora-packaging.

I would like github issues to take over for JIRA as I feel JIRA is too
heavy weight for our current level of activity.


>
> * Should we eventually make the master branch on aurora be protected? If
> yes, when should the cutover be?
>

For me this is something that should eventually be done. I can't recall any
push by accident moments that have taken place but better safe than sorry.
In either case, I don't feel too strongly about this.

>
>
* Should we favor PRs as the main way of making contributions? When (if at
> all) should Review Board be favored over PRs?
>

For all new contributors, I am of the opinion that PRs are the easiest way
for new contributors to make an impact. Therefore, I feel we should favor
PRs for new contributors and old contributors may feel free to choose for
themselves.


>
> * For pull requests, what should our PR merge model be?
> The choices are:
>  - Merge commit
>  - Squash and merge
>  - Rebase and merge
>
> Note: Squash and merge is the closest to our current Review Board workflow.
>

Our squash and merge like merge has served us well in the past. I vote to
use this merge method on PRs as well for consistency with Review Board
contributions.


>
> * We need a CI for contributions made through github. Suggestions,
> recommendations, as well as help setting them up are very much welcome.
>

No opinions here but Travis CI looks like the path of least resistance.

>
> -Renan
>

Regarding our recent move to gitbox

[Renan DelValle]

All,

I wanted to take a few minutes to explain what our recent change to gitbox
means in practice.

For our users:
* The change is (hopefully) not very impactful. The only thing that changes
is the location of the aurora and aurora-packing repositories. Update those
as needed by your usage.
* You may now depend on the github repository as the main source of aurora
code.

For our developers (and, more importantly, future developers):
* You can now make contributions by making Pull Requests through the
github.com UI!
* Contributors may still submit contributions through the Review Board
workflow.

For our committers:
* You can now commit Pull Requests directly through the github UI.
* You may also continue to commit contributions through the Review Board
workflow.
* Origin is now g...@github.com:apache/aurora.git All pushes committing new
code from contributions should be made there.
* aurora-packaging has a protected master branch. This means commits cannot
be directly pushed to master -- only through pull requests. This is to
avoid accidental pushes to the master. Review Board flow is still possible
here but an extra step is required.

Finally a few points of discussion:

* Should we enable issues on github for both aurora and aurora-packaging?
If yes, should this replace JIRA for aurora and aurora-packaging? (A vote
is probably in order for this if the overall sentiment is positive)

* Should we eventually make the master branch on aurora be protected? If
yes, when should the cutover be?

* Should we favor PRs as the main way of making contributions? When (if at
all) should Review Board be favored over PRs?

* For pull requests, what should our PR merge model be?
The choices are:
 - Merge commit
 - Squash and merge
 - Rebase and merge

Note: Squash and merge is the closest to our current Review Board workflow.

* We need a CI for contributions made through github. Suggestions,
recommendations, as well as help setting them up are very much welcome.

-Renan

Re: [ANNOUNCEMENT] aurora and aurora-packaging repositories moved to gitbox

[Renan DelValle]

Correction to that last announcement:

New addresses are

* aurora: https://gitbox.apache.org/repos/asf/aurora.git
* aurora-packaging: https://gitbox.apache.org/repos/asf/aurora-packaging.git

Alternatively, you may choose to use the github location directly at:

* aurora: https://github.com/apache/aurora.git
* aurora-packaging: https://github.com/apache/aurora-packaging.git

Apologies for the noise.

-Renan

On Mon, Jul 30, 2018 at 10:30 AM Renan DelValle  wrote:

> All,
>
> As of today we have transitioned our git repositories for aurora and
> aurora-packaging from git-wip to gitbox.
>
> The old address for the aurora git repository was:
> https://git-wip-us.apache.org/repos/asf/aurora.git
>
> The new address for the aurora git repository is:
> https://gitbox.apache.org/repos/asf/?p=aurora.git
>
> The old address for the aurora-packing git repository was:
> https://git-wip-us.apache.org/repos/asf/aurora-packaging.git
>
> The new address for the aurora-packing git repository is:
> https://gitbox.apache.org/repos/asf/?p=aurora-packaging.git
>
> Please bear with us while we solve any issues related to this migration.
>
> If you notice something that has been broken with this change, please
> don't hesitate to let us know!
>
> -Renan
>
>

[ANNOUNCEMENT] aurora and aurora-packaging repositories moved to gitbox

[Renan DelValle]

All,

As of today we have transitioned our git repositories for aurora and
aurora-packaging from git-wip to gitbox.

The old address for the aurora git repository was:
https://git-wip-us.apache.org/repos/asf/aurora.git

The new address for the aurora git repository is:
https://gitbox.apache.org/repos/asf/?p=aurora.git

The old address for the aurora-packing git repository was:
https://git-wip-us.apache.org/repos/asf/aurora-packaging.git

The new address for the aurora-packing git repository is:
https://gitbox.apache.org/repos/asf/?p=aurora-packaging.git

Please bear with us while we solve any issues related to this migration.

If you notice something that has been broken with this change, please don't
hesitate to let us know!

-Renan

0.21.0 Release Planning

[Renan DelValle]

All,

Given that a pretty serious bug affects versions of Mesos lower than 1.5.0 (
https://issues.apache.org/jira/browse/MESOS-7215), I wanted to bring up the
topic of cutting a release tested against Mesos 1.5.0.

Between SLA aware Maintenance and SLA aware updates, along with a few other
patches here and there, I also think we also have enough new features to
warrant a release.

Ideally, I'd like to wait until Jordan Ly's SLA aware updates patch (
https://reviews.apache.org/r/67696/) lands before cutting this release.

Thoughts?

-Renan

[NOTICE] Aurora is moving to Apache GitBox

[Renan DelValle]

All,

The vote to move from the legacy ASF git hosting to the GitBox service has
passed. When we finish our move we cannot guarantee that the the legacy ASF
git repository will continue to be operational. Thus, I encourage users to
evaluate dependencies and prepare to make changes accordingly.

As we transition from our ReviewBoard workflow to our GitHub based workflow
we will be doing our best to keep the turbulence to a minimum but
unforeseen challenges may rise up.

I ask that users bear with us and report any issues they encounter during
and after our transition. I'd also like to ask for help updating our
documentation to reflect our change in workflow once the migration is over.

Thanks!

-Renan

[RESULT] [VOTE] Move project to Apache GitBox service

[Renan DelValle]

All,

The vote to move the Apache Aurora project to the Apache GitBox service has
passed.

+1 (Binding)
--
Renan DelValle
Jordan Ly
David McLaughlin
Santhosh Kumar Shanmugham

+1 (Non-binding)
--
Mauricio Garavaglia
Nicolas Donatucci

There were no 0 or -1 votes. Thank you to all who participated.

On Tue, Jun 12, 2018 at 6:18 PM Mauricio Garavaglia <
mauriciogaravag...@gmail.com> wrote:

> +1
>
> On Tue, Jun 12, 2018, 5:48 PM Nicolas Donatucci 
> wrote:
>
> > +1
> >
> > On Tue, Jun 12, 2018 at 4:11 PM, David McLaughlin <
> dmclaugh...@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > On Tue, Jun 12, 2018 at 11:19 AM, Jordan Ly 
> > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Jun 12, 2018 at 11:16 AM, Renan DelValle 
> > > wrote:
> > > > > Kicking the vote off with a +1 from me since I feel it will
> simplify
> > > our
> > > > > patch submission process and lower the difficulty bar for new
> > > > contributors.
> > > > >
> > > > > On Tue, Jun 12, 2018 at 11:14 AM Renan DelValle 
> > > > wrote:
> > > > >
> > > > >> All,
> > > > >>
> > > > >> I propose we move our project into the GitBox service. This will
> > allow
> > > > us
> > > > >> to read and write to our repositories on the GitHub platform
> > enabling
> > > > us to
> > > > >> accept pull requests for both the aurora and aurora-packaging
> > > > repositories.
> > > > >>
> > > > >> If this vote passes, the pull request workflow will replace our
> > > current
> > > > >> ReviewBoard patch submission process.
> > > > >>
> > > > >> The vote will close on Tuesday Jun 19th 2018 at 11:30:00 San
> > Francisco
> > > > >> time.
> > > > >>
> > > > >> [ ] +1 Move the aurora and aurora-packaging repositories to the
> > Apache
> > > > >> GitBox service
> > > > >> [ ] +0
> > > > >> [ ] -1 Keep the aurora and aurora-packaging repositories on GitHub
> > as
> > > a
> > > > >> read only mirrors because...
> > > > >>
> > > >
> > >
> >
>

[REPORT] Apache Aurora - June 2018

[Renan DelValle]

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: [VOTE] Move project to Apache GitBox service

[Renan DelValle]

Kicking the vote off with a +1 from me since I feel it will simplify our
patch submission process and lower the difficulty bar for new contributors.

On Tue, Jun 12, 2018 at 11:14 AM Renan DelValle  wrote:

> All,
>
> I propose we move our project into the GitBox service. This will allow us
> to read and write to our repositories on the GitHub platform enabling us to
> accept pull requests for both the aurora and aurora-packaging repositories.
>
> If this vote passes, the pull request workflow will replace our current
> ReviewBoard patch submission process.
>
> The vote will close on Tuesday Jun 19th 2018 at 11:30:00 San Francisco
> time.
>
> [ ] +1 Move the aurora and aurora-packaging repositories to the Apache
> GitBox service
> [ ] +0
> [ ] -1 Keep the aurora and aurora-packaging repositories on GitHub as a
> read only mirrors because...
>

[VOTE] Move project to Apache GitBox service

[Renan DelValle]

All,

I propose we move our project into the GitBox service. This will allow us
to read and write to our repositories on the GitHub platform enabling us to
accept pull requests for both the aurora and aurora-packaging repositories.

If this vote passes, the pull request workflow will replace our current
ReviewBoard patch submission process.

The vote will close on Tuesday Jun 19th 2018 at 11:30:00 San Francisco time.

[ ] +1 Move the aurora and aurora-packaging repositories to the Apache
GitBox service
[ ] +0
[ ] -1 Keep the aurora and aurora-packaging repositories on GitHub as a
read only mirrors because...

Re: [DISCUSS] Move project to GitBox service

[Renan DelValle]

Looks like we're all pretty much on board with this idea. This thread was
made with the intention to see if anyone opposed the idea so I'll call the
actual vote now. Sorry for the confusion!

On Tue, Jun 12, 2018 at 9:38 AM Santhosh Kumar Shanmugham
 wrote:

> +1
>
> On Tue, Jun 12, 2018 at 7:37 AM Mauricio Garavaglia <
> mauriciogaravag...@gmail.com> wrote:
>
> > +1
> >
> > On Tue, Jun 12, 2018 at 2:01 AM, David McLaughlin <
> dmclaugh...@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > Thanks for kicking off the vote!
> > >
> > > On Mon, Jun 11, 2018 at 5:27 PM, Renan DelValle 
> > wrote:
> > >
> > > > All,
> > > >
> > > > I wanted to bring up for discussion moving the project from our
> current
> > > > ReviewBoard based workflow to a GitHub pull request based workflow
> > > through
> > > > the use of the ASF's GitBox service[1].
> > > >
> > > > The GitBox service would allow us to read/write to our GitHub
> > repository
> > > > instead of only mirroring our Apache hosted repository. This means
> we'd
> > > be
> > > > able to take pull requests through the GitHub platform instead of
> > taking
> > > > patches though ReviewBoard.
> > > >
> > > > It's worth mentioning that the Aurora community is responsible for
> two
> > > > repositories: aurora and aurora-packaging. I believe moving to this
> > model
> > > > would greatly simplify our patch submission process and would lower
> the
> > > > barrier of entry to new contributors for both of these repositories.
> > > >
> > > > Looking forward to hearing the community's thoughts on this idea.
> > > >
> > > > - Renan
> > > >
> > > > [1] https://reference.apache.org/committer/git
> > > >
> > >
> >
>

[DISCUSS] Move project to GitBox service

[Renan DelValle]

All,

I wanted to bring up for discussion moving the project from our current
ReviewBoard based workflow to a GitHub pull request based workflow through
the use of the ASF's GitBox service[1].

The GitBox service would allow us to read/write to our GitHub repository
instead of only mirroring our Apache hosted repository. This means we'd be
able to take pull requests through the GitHub platform instead of taking
patches though ReviewBoard.

It's worth mentioning that the Aurora community is responsible for two
repositories: aurora and aurora-packaging. I believe moving to this model
would greatly simplify our patch submission process and would lower the
barrier of entry to new contributors for both of these repositories.

Looking forward to hearing the community's thoughts on this idea.

- Renan

[1] https://reference.apache.org/committer/git

Recovery instructions updates

[Renan DelValle]

Hi all,

We tried following the recovery instructions from
http://aurora.apache.org/documentation/latest/operations/backup-restore/

After our change from the Twitter commons ZK library to Apache Curator,
these instructions are no longer valid.

In order for Aurora to carry out a leader election in the current state,
Aurora has to first connect to a Mesos master. What we ended up doing was
connecting to Mesos master that was had nothing on it to bypass this new
requirement.

Next, wiping away -native_log_file_path did not seem to be enough to
recover from a corrupted mesos replicated log. We had to manually wipe away
entries in ZK and move the snapshot backup directory in order for the
leader to not fall back on either a snapshot or the mesos-log to rehydrate
the leader.

Finally, somehow triggering a manual snapshot generated a snapshot with an
invalid entry which then caused the scheduler to fail after a failover
while trying to catch up on current state.

We are trying to investigate why this took place (it could have been we
didn't give the system enough time to finish hydrating the snapshot), but
the invalid entry which looked something like a Task with all null or 0
values, caused our leaders to fail (which necessitated restoring from an
earlier snapshot) and note that this was only after we triggered the manual
snapshot and BEFORE we tried to restore.

Will report more details as they become available and will provide some doc
updates based on our experience.

-Renan

[RESULT] [VOTE] Discontinue Official Binary Package releases

[Renan DelValle]

All,

The vote to discontinue official binary package releases has passed.

+1 (Binding)
--
Renan DelValle
Stephan Erb
Bill Farner
David McLaughlin
Santhosh Kumar Shanmugham


+1 (Non-binding)
--
Mauricio Garavaglia
Nicolas Donatucci

There were no 0 or -1 votes. Thank you to all who participated.

Note that we do plan to continue maintaining the aurora-packaging scripts
for building your own binaries.


On Tue, May 22, 2018 at 10:16 AM, David McLaughlin 
wrote:

> +1
>
> On Mon, May 21, 2018 at 11:17 PM, Stephan Erb  >
> wrote:
>
> > +1
> >
> > On 21.05.18, 17:00, "Santhosh Kumar Shanmugham"  .INVALID>
> > wrote:
> >
> > +1
> >
> > On Fri, May 18, 2018, 7:03 PM Nicolas Donatucci <
> > ndonatu...@medallia.com>
> > wrote:
> >
> > > +1
> > >
> > > On Fri, May 18, 2018, 22:49 Bill Farner 
> wrote:
> > >
> > > > +1
> > > >
> > > > > On May 18, 2018, at 6:44 PM, Renan DelValle 
> > wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > On Fri, May 18, 2018 at 6:35 PM, Mauricio Garavaglia <
> > > > > mauriciogaravag...@gmail.com> wrote:
> > > > >
> > > > >> +1
> > > > >>
> > > > >>> On Fri, May 18, 2018 at 8:01 PM, Renan DelValle <
> > re...@apache.org>
> > > > wrote:
> > > > >>>
> > > > >>> All,
> > > > >>>
> > > > >>> As has been brought up before, we lack the capacity to
> > continue to
> > > hold
> > > > >>> votes separately for releases and binary releases.
> > > > >>>
> > > > >>> Therefore, I propose that we stop release binary packages
> > until such
> > > a
> > > > >>> time
> > > > >>> as when we can combine voting for release packages and binary
> > > packages
> > > > >>> into
> > > > >>> a single vote.
> > > > >>>
> > > > >>>
> > > > >>> The vote will close on Wed May 25th 16:00:00 PST 2018
> > > > >>>
> > > > >>> [ ] +1 Discontinue Official Binary packages releases
> > > > >>> [ ] +0
> > > > >>> [ ] -1 Continue Official Binary packages releases because...
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> >
>

Re: [DISCUSS] State of the Community

[Renan DelValle]

Thanks for the feedback David!

On Tue, May 22, 2018 at 9:55 AM, David McLaughlin <dmclaugh...@apache.org>
wrote:

> I feel like not getting code reviews is often a symptom of some other
> fundamental issue with how change is introduced to a community.
>
> When I joined the Aurora team at Twitter there were some principals in
> place for getting your changes accepted to the community and I still feel
> like when you follow them, getting code reviews rarely requires more than a
> gentle ping. Maybe none of these have been formally communicated or shared
> externally, but some of the principals I've picked up include:
>
> * Introduce problems before solutions.
> * Get buy-in that this is a problem worth solving.
> * Work towards abstractions that work for the community and not just for
> your specific use case.
> * Solicit early feedback on potential solutions.
> * Get explicit buy-in for the solution (these +1s would be the people you
> add to the reviewers list later). This usually means writing a Design Doc.
> * Plan your work carefully to avoid the dreaded code dumps (where
> possible). For large efforts work towards multiple, small patches that are
> easy to review.
> * Follow-up on review feedback quickly to avoid demanding expensive paging
> and context-switches from your reviewers later.
> * Build trust by thinking through production rollout and rollback
> scenarios.
>

All good points and I think those of us that have been here long enough do
strive to follow these principles. For what it's worth,
I've always really appreciated the feedback from the folks running at scale
when it comes to my contributions. It shows they care
about the project and pushes me to write better code.

That said, since these are mostly unwritten rules, either we need to write
them down or we need to cope with the
fact that some folks may not follow them. What would really be unfortunate
is to lose potential contributors because
they get discouraged after submitting a patch and running into this
"invisible" red tape. I can already see this happening
such as in https://reviews.apache.org/r/66490/

There may not be a solution to that problem (and may be a different problem
altogether) but it would at least be
nice to have an outline of what procedure is expected from potential
contributors.

Another thing I'd like to bring up is that our use of JIRA has drastically
decreased. There is very little activity going on there.
That used to be the starting point of discussion for any contribution. As
engagement has dropped, that's pretty much gone away
leaving us without much defense in shutting down an idea before it's coded.


>
> There is obviously more than just this list, but a lot of the patches that
> struggle to get reviews (or get hard -1s after a bunch of work is done)
> fail on one (or more) of these fundamental ideas.
>

I agree on this point but what concerns me more than the -1's is the lack
of engagement.  For example
https://reviews.apache.org/r/66537/

If we want to engage the community, we gotta give feedback, good or bad.
For me, letting review requests rot is one sure fire indicator to
potential contributors that sending a contribution is not worth their time
or effort (and our process is pretty time consuming given the outline we
tend to follow above).


We should find a way to keep the core tenets outlined above while
streamlining the process.  Maybe move away from reviewboard
into gitbox so we can do code reviews on github? Not sure if this would
help at all, but it may since folks are more familiar with that workflow
so it brings down a barrier for contribution.


(Side note: maybe it's a good time to propose a cleanup in reviewboard. Right
now our group page on reviewboard looks like a graveyard.
In my opinion, anything older than a year isn't likely to be committed and
should therefore be discarded. I can put this to a vote if the general
consensus is
positive towards this idea.)


> It's also worth calling out that having informal discussions on Slack is
> fine, but should also be done on the dev lists, and ideally in the form of
> a written document. This is the best way to include those of who feel like
> Slack is a massive productivity drain :)


Noted, though I will say our slack channel doesn't have much of a pulse
these days either (and hasn't for quite some time).


>
>
I guess this is my long-winded way of saying that I'm a -1 on moving to
> lazy consensus.
>
> I wonder if a lot of the concerns can be solved by just improving
> communication? Maybe we can revive the weekly developer meeting that we
> used to run in IRC.
>

This would be great but sadly I just don't see the engagement we need to be
able to pull this off. We could not even get enough interest to
host an Aurora Meetup, so I see this as an uphill battle if we attempt it.

I could be wrong though

Re: [DISCUSS] State of the Community

[Renan DelValle]

Thanks for your input Stephan, very much appreciated! Replies inline:

On Tue, May 22, 2018 at 12:12 AM, Stephan Erb <stephan@blue-yonder.com>
wrote:

> Hey Renan,
>
> thanks again for bringing this up. In my experience, the pain comes from
> building, testing & voting rather the packaging scripts themselves. I
> therefore think we should discontinue building, but continue to maintain
> the scripts so that users can build them on their own when necessary.
>

Fully agree on this. I will even go as far as making unofficial builds
available for the time being if no one is opposed and if it's not against
Apache policy to do so.

>
> We must be careful though with linking the ‘nightly jenkins builds’ on the
> website. We got called out for this once in the past and had to take the
> link down.
>

Noted, thanks for bringing this up!

>
> We also see a lack of involvement in code reviews. I think we should
> consider setting up a more formal lazy consensus policy
> https://www.apache.org/foundation/voting.html#LazyConsensus : For
> example,  patches maybe merged even with a single ‘ship it’ from a
> committer, if there is neither a ship-it nor a veto from other committers
> within 7 days.
>

I think this is a very valid way forward at this point. How does everyone
else feel about this?

>
> Best regards,
> Stephan
>


-Renan

>
> From: Santhosh Kumar Shanmugham <sshanmug...@twitter.com>
> Reply-To: "u...@aurora.apache.org" <u...@aurora.apache.org>
> Date: Thursday, 17. May 2018 at 22:13
> To: "dev@aurora.apache.org" <dev@aurora.apache.org>
> Cc: "u...@aurora.apache.org" <u...@aurora.apache.org>
> Subject: Re: [DISCUSS] State of the Community
>
> Hello Renan,
>
> I understand your frustration.
>
> I am a strong +1 for automating the release and voting process. I performed
> a release a while back and the process definitely needs it improve
> documentation
> at the least. If one of the members who are more familiar with this
> process can
> create a backlog, I will be happy to chip in.
>
> -Santhosh
>
> On Thu, May 17, 2018 at 12:56 PM, Renan DelValle <re...@apache.org re...@apache.org>> wrote:
> All,
>
> Discussion has been open for 13 days and only one user has chimed in.
> Unfortunately it looks like talking point number one will be a serious
> concern going forward. I will give until tomorrow 12 PM San Francisco time
> for folks to voice their opinion on these issues.
>
> After tomorrow I will call a vote to cease distributions of official binary
> packages from versions 0.21.0 onwards until the process is automated and
> voting for the voting for the binary packages can be combined with the
> tar.gz release.
>
> Since no feedback was received regarding talking point three, the idea will
> be dropped.
>
> -Renan
>
>
> On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelva...@gmail.com<
> mailto:renanidelva...@gmail.com>>
> wrote:
>
> > In some ways, that's some of the best feedback we can get. Very happy to
> > hear that Aurora is working fo well for Chartbeat.
> >
> > I do hope that you guys find some time to help us maintain the project.
> > Every little bit counts!
> >
> > -Renan
> >
> > On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <r...@chartbeat.com r...@chartbeat.com>> wrote:
> >
> >> As strong users of aurora but weak contributors, we at Chartbeat
> >> apologize for our lack of participation. We’re several versions behind
> on
> >> mesos/aurora upgrades and that’s honestly because it works for us :)
> >>
> >> Going forward we’re hoping to be able to participate more, at least with
> >> testing new releases.
> >>
> >> We thank you though!
> >>
> >> Rick and the rest of Chartbeat Engineering
> >>
> >>
> >> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org re...@apache.org>> wrote:
> >> >
> >> > Hello all,
> >> >
> >> > I wanted to bring up a few points for discussion with the community.
> I'd
> >> > really like to hear what the community's thoughts are on these issues
> >> and
> >> > how can resolve them.
> >> >
> >> > 1. Lack of participation. This is due to many members moving on from
> the
> >> > project and becoming dormant. More concerning is the fact that our PMC
> >> > roster sits at 21 members [1] of which fewer than half have
> >> participated in
> >> > the project during the last 6 months.
> >> >
> >> > This

Re: [VOTE] Discontinue Official Binary Package releases

[Renan DelValle]

+1

On Fri, May 18, 2018 at 6:35 PM, Mauricio Garavaglia <
mauriciogaravag...@gmail.com> wrote:

> +1
>
> On Fri, May 18, 2018 at 8:01 PM, Renan DelValle <re...@apache.org> wrote:
>
>> All,
>>
>> As has been brought up before, we lack the capacity to continue to hold
>> votes separately for releases and binary releases.
>>
>> Therefore, I propose that we stop release binary packages until such a
>> time
>> as when we can combine voting for release packages and binary packages
>> into
>> a single vote.
>>
>>
>> The vote will close on Wed May 25th 16:00:00 PST 2018
>>
>> [ ] +1 Discontinue Official Binary packages releases
>> [ ] +0
>> [ ] -1 Continue Official Binary packages releases because...
>>
>
>

[VOTE] Discontinue Official Binary Package releases

[Renan DelValle]

All,

As has been brought up before, we lack the capacity to continue to hold
votes separately for releases and binary releases.

Therefore, I propose that we stop release binary packages until such a time
as when we can combine voting for release packages and binary packages into
a single vote.


The vote will close on Wed May 25th 16:00:00 PST 2018

[ ] +1 Discontinue Official Binary packages releases
[ ] +0
[ ] -1 Continue Official Binary packages releases because...

Re: [DISCUSS] State of the Community

[Renan DelValle]

All,

Discussion has been open for 13 days and only one user has chimed in.
Unfortunately it looks like talking point number one will be a serious
concern going forward. I will give until tomorrow 12 PM San Francisco time
for folks to voice their opinion on these issues.

After tomorrow I will call a vote to cease distributions of official binary
packages from versions 0.21.0 onwards until the process is automated and
voting for the voting for the binary packages can be combined with the
tar.gz release.

Since no feedback was received regarding talking point three, the idea will
be dropped.

-Renan


On Fri, May 4, 2018 at 8:25 PM, Renan DelValle <renanidelva...@gmail.com>
wrote:

> In some ways, that's some of the best feedback we can get. Very happy to
> hear that Aurora is working fo well for Chartbeat.
>
> I do hope that you guys find some time to help us maintain the project.
> Every little bit counts!
>
> -Renan
>
> On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <r...@chartbeat.com> wrote:
>
>> As strong users of aurora but weak contributors, we at Chartbeat
>> apologize for our lack of participation. We’re several versions behind on
>> mesos/aurora upgrades and that’s honestly because it works for us :)
>>
>> Going forward we’re hoping to be able to participate more, at least with
>> testing new releases.
>>
>> We thank you though!
>>
>> Rick and the rest of Chartbeat Engineering
>>
>>
>> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
>> >
>> > Hello all,
>> >
>> > I wanted to bring up a few points for discussion with the community. I'd
>> > really like to hear what the community's thoughts are on these issues
>> and
>> > how can resolve them.
>> >
>> > 1. Lack of participation. This is due to many members moving on from the
>> > project and becoming dormant. More concerning is the fact that our PMC
>> > roster sits at 21 members [1] of which fewer than half have
>> participated in
>> > the project during the last 6 months.
>> >
>> > This inactivity has led the voting process for releases to be held up by
>> > the inability to reach the required minimum 3 votes for releases (both
>> > tar.gz and binary). Our latest binary packaging vote has been going on
>> for
>> > more than a month. [2]
>> >
>> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
>> the
>> > Aurora PMC, we hope to mitigate this issue.
>> >
>> > It would be fantastic to see some initiative from long contributing
>> members
>> > to make a case for themselves for being considered for committer and/or
>> PMC
>> > membership.
>> >
>> > 2. Binary packages. While we have been struggling to get enough votes
>> for
>> > making the release official, the voting process has been marked by a
>> lack
>> > of enthusiasm from the community.
>> >
>> > I know that many folks are using these packages (including myself), but
>> we
>> > need to hear feedback when we call votes. It is not enough to stand by
>> > silently if everything works; please let us know about it.
>> >
>> > As it stands, the enthusiasm (or lack thereof) for binary packages
>> doesn't
>> > justify the overhead involved in releasing them. Therefore I propose
>> that
>> > we drop official binary packages for the next release. This is up for
>> > discussion and I'd love to hear everyone's opinion on this.
>> >
>> > An alternative to ending binary packages would be to automate the
>> process
>> > on tar.gz releases, but that would most likely need to be a community
>> > contribution.
>> >
>> > 3. Version 1.0. I realize this is a touchy subject. While other projects
>> > that were started around the same time as Aurora, such as Mesos itself,
>> > have gone on to make a 1.0 release (indicating the projects maturity),
>> we
>> > have stuck to our 0.X.0 releases.
>> >
>> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
>> > wanted to bring up for discussion how everyone felt about making our
>> next
>> > release a 1.0 release to reflect the stability and maturity of the
>> project.
>> >
>> > That is all from me, if anyone else has any other concerns regarding the
>> > Aurora community, feel free to bring it up in this thread!
>> >
>> > -Renan
>> >
>> >
>> > [1] https://projects.apache.org/committee.html?aurora
>> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
>> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>>
>>
>

Re: (Potentially) Deprecating the Python bindings

[Renan DelValle]

Thermos, the default Aurora executor, still uses the Python bindings. There
are currently no plans to move Thermos to the HTTP APIs as far as I know.

-Renan

On Wed, May 9, 2018 at 11:56 AM, Andrew Schwartzmeyer <
and...@schwartzmeyer.com> wrote:

> Hi Aurora devs,
>
> Are you guys still using the Python bindings, and if so, is there any
> effort underway to switch to the HTTP APIs?
>
> Thanks!
>
>  Original Message 
> Subject: Deprecating the Python bindings
> Date: 05/09/2018 11:51 am
> From: Andrew Schwartzmeyer 
> To: d...@mesos.apache.org, u...@mesos.apache.org
> Reply-To: d...@mesos.apache.org
>
> Hi all,
>
> There are two parallel efforts underway that would both benefit from
> officially deprecating (and then removing) the Python bindings. The first
> effort is the move to the CMake system: adding support to generate the
> Python bindings was investigated but paused (see MESOS-8118), and the
> second effort is the move to Python 3: producing Python 3 compatible
> bindings is under investigation but not in progress (see MESOS-7163).
>
> Benjamin Bannier, Joseph Wu, and I have all at some point just wondered
> how the community would fare if the Python bindings were officially
> deprecated and removed. So please, if this would negatively impact you or
> your project, let me know in this thread.
>
> Thanks,
>
> Andrew Schwartzmeyer
>

Re: [DISCUSS] State of the Community

[Renan DelValle]

In some ways, that's some of the best feedback we can get. Very happy to
hear that Aurora is working fo well for Chartbeat.

I do hope that you guys find some time to help us maintain the project.
Every little bit counts!

-Renan

On Fri, May 4, 2018 at 11:48 AM, Rick Mangi <r...@chartbeat.com> wrote:

> As strong users of aurora but weak contributors, we at Chartbeat apologize
> for our lack of participation. We’re several versions behind on
> mesos/aurora upgrades and that’s honestly because it works for us :)
>
> Going forward we’re hoping to be able to participate more, at least with
> testing new releases.
>
> We thank you though!
>
> Rick and the rest of Chartbeat Engineering
>
>
> > On May 4, 2018, at 2:38 PM, Renan DelValle <re...@apache.org> wrote:
> >
> > Hello all,
> >
> > I wanted to bring up a few points for discussion with the community. I'd
> > really like to hear what the community's thoughts are on these issues and
> > how can resolve them.
> >
> > 1. Lack of participation. This is due to many members moving on from the
> > project and becoming dormant. More concerning is the fact that our PMC
> > roster sits at 21 members [1] of which fewer than half have participated
> in
> > the project during the last 6 months.
> >
> > This inactivity has led the voting process for releases to be held up by
> > the inability to reach the required minimum 3 votes for releases (both
> > tar.gz and binary). Our latest binary packaging vote has been going on
> for
> > more than a month. [2]
> >
> > With the recent additions of Santhosh Kumar Shanmugham and Jordan Ly to
> the
> > Aurora PMC, we hope to mitigate this issue.
> >
> > It would be fantastic to see some initiative from long contributing
> members
> > to make a case for themselves for being considered for committer and/or
> PMC
> > membership.
> >
> > 2. Binary packages. While we have been struggling to get enough votes for
> > making the release official, the voting process has been marked by a lack
> > of enthusiasm from the community.
> >
> > I know that many folks are using these packages (including myself), but
> we
> > need to hear feedback when we call votes. It is not enough to stand by
> > silently if everything works; please let us know about it.
> >
> > As it stands, the enthusiasm (or lack thereof) for binary packages
> doesn't
> > justify the overhead involved in releasing them. Therefore I propose that
> > we drop official binary packages for the next release. This is up for
> > discussion and I'd love to hear everyone's opinion on this.
> >
> > An alternative to ending binary packages would be to automate the process
> > on tar.gz releases, but that would most likely need to be a community
> > contribution.
> >
> > 3. Version 1.0. I realize this is a touchy subject. While other projects
> > that were started around the same time as Aurora, such as Mesos itself,
> > have gone on to make a 1.0 release (indicating the projects maturity), we
> > have stuck to our 0.X.0 releases.
> >
> > Aurora is a mature project wether it is labeled 0.X.0 or X.0.0, but I
> > wanted to bring up for discussion how everyone felt about making our next
> > release a 1.0 release to reflect the stability and maturity of the
> project.
> >
> > That is all from me, if anyone else has any other concerns regarding the
> > Aurora community, feel free to bring it up in this thread!
> >
> > -Renan
> >
> >
> > [1] https://projects.apache.org/committee.html?aurora
> > [2] https://lists.apache.org/thread.html/9df9d142408efffd11a1cdc5e4c1e3
> > 67208cf8e618730f7c761b0f35@%3Cdev.aurora.apache.org%3E
>
>

[RESULT] [VOTE] Release Apache Aurora 0.20.x packages

[Renan DelValle]

All,
The vote to accept the proposed packages as our official binary packages for
 Apache Aurora 0.20.x has passed.


+1 (Binding)
--
Renan DelValle
Stephan Erb
Jordan Ly

There were no 0  or-1 votes. There were no non-binding votes.

The official packages are now available here:
https://dl.bintray.com/apache/aurora/

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

Thank you to all who helped make this release.

-Renan

On Fri, May 4, 2018 at 2:25 PM, Jordan Ly <jorda...@apache.org> wrote:

> +1, downloaded and ran tests for each OS
>
> On Thu, May 3, 2018 at 12:20 PM, Stephan Erb <m...@stephanerb.eu> wrote:
> > +1 for the release as is
> >
> > Am 3. Mai 2018 21:05:32 MESZ schrieb Renan DelValle <re...@apache.org>:
> >>All,
> >>
> >>Do we want to keep the vote open or should I close it as failed? It's
> >>been
> >>nearly a month since I called it.
> >>
> >>I am +1 for making these the official packages as I haven't encountered
> >>any
> >>problem with them so far.
> >>
> >>If we could get two more PMC members to vote so we can close this vote
> >>that'd be great!
> >>
> >>-Renan
> >>
> >>On Tue, Apr 17, 2018 at 6:35 PM, Renan DelValle <re...@apache.org>
> >>wrote:
> >>
> >>> Friendly reminder that this vote is still open, please vote!
> >>>
> >>>
> >>> On Fri, Apr 6, 2018 at 6:40 PM, Renan DelValle <re...@apache.org>
> >>wrote:
> >>>
> >>>> All,
> >>>>
> >>>> I propose that we accept the following artifacts as the official deb
> >>and
> >>>> rpm packaging for
> >>>> Apache Aurora 0.20.x:
> >>>>
> >>>> https://dl.bintray.com/rdelvalle/aurora/
> >>>>
> >>>> ---
> >>>>
> >>>> The branch used to create the packaging is:
> >>>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> >>>> .git;a=tree;hb=refs/heads/0.20.x
> >>>>
> >>>> The packages are available at:
> >>>> https://dl.bintray.com/rdelvalle/aurora/
> >>>>
> >>>> 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. Detailed test instructions are
> >>>> available here:
> >>>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> >>>> .git;a=tree;f=test;hb=refs/heads/0.20.x
> >>>>
> >>>>
> >>>> The vote will close on Mon Apr  9 18:45:00 PDT 2018 or later
> >>>>
> >>>> [ ] +1 Release these as the deb and rpm packages for Apache Aurora
> >>0.20.x
> >>>> [ ] +0
> >>>> [ ] -1 Do not release these artifacts because...
> >>>>
> >>>
> >>>
>

Re: [VOTE] Release Apache Aurora 0.20.x packages

[Renan DelValle]

All,

Do we want to keep the vote open or should I close it as failed? It's been
nearly a month since I called it.

I am +1 for making these the official packages as I haven't encountered any
problem with them so far.

If we could get two more PMC members to vote so we can close this vote
that'd be great!

-Renan

On Tue, Apr 17, 2018 at 6:35 PM, Renan DelValle <re...@apache.org> wrote:

> Friendly reminder that this vote is still open, please vote!
>
>
> On Fri, Apr 6, 2018 at 6:40 PM, Renan DelValle <re...@apache.org> wrote:
>
>> All,
>>
>> I propose that we accept the following artifacts as the official deb and
>> rpm packaging for
>> Apache Aurora 0.20.x:
>>
>> https://dl.bintray.com/rdelvalle/aurora/
>>
>> ---
>>
>> The branch used to create the packaging is:
>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>> .git;a=tree;hb=refs/heads/0.20.x
>>
>> The packages are available at:
>> https://dl.bintray.com/rdelvalle/aurora/
>>
>> 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. Detailed test instructions are
>> available here:
>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>> .git;a=tree;f=test;hb=refs/heads/0.20.x
>>
>>
>> The vote will close on Mon Apr  9 18:45:00 PDT 2018 or later
>>
>> [ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.20.x
>> [ ] +0
>> [ ] -1 Do not release these artifacts because...
>>
>
>

Re: [VOTE] Release Apache Aurora 0.20.x packages

[Renan DelValle]

Friendly reminder that this vote is still open, please vote!


On Fri, Apr 6, 2018 at 6:40 PM, Renan DelValle <re...@apache.org> wrote:

> All,
>
> I propose that we accept the following artifacts as the official deb and
> rpm packaging for
> Apache Aurora 0.20.x:
>
> https://dl.bintray.com/rdelvalle/aurora/
>
> ---
>
> The branch used to create the packaging is:
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> .git;a=tree;hb=refs/heads/0.20.x
>
> The packages are available at:
> https://dl.bintray.com/rdelvalle/aurora/
>
> 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. Detailed test instructions are
> available here:
> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> .git;a=tree;f=test;hb=refs/heads/0.20.x
>
>
> The vote will close on Mon Apr  9 18:45:00 PDT 2018 or later
>
> [ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.20.x
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>

Sunsetting official binary package for Ubuntu 14.04 after Aurora 0.21.0

[Renan DelValle]

Hi all,

We're almost exactly one year away from the end of life of Ubuntu 14.04.[1]
Taking this into consideration, I wanted to see how the community felt
about 0.21.0 being the last release to have official Ubuntu 14.04 packages.

Please let use know what you think!

Thanks,

-Renan

[1] https://www.ubuntu.com/info/release-end-of-life

[VOTE] Release Apache Aurora 0.20.x packages

[Renan DelValle]

All,

I propose that we accept the following artifacts as the official deb and
rpm packaging for
Apache Aurora 0.20.x:

https://dl.bintray.com/rdelvalle/aurora/

---

The branch used to create the packaging is:
https://git1-us-west.apache.org/repos/asf?p=aurora-
packaging.git;a=tree;hb=refs/heads/0.20.x

The packages are available at:
https://dl.bintray.com/rdelvalle/aurora/

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. Detailed test instructions are available
here:
https://git1-us-west.apache.org/repos/asf?p=aurora-
packaging.git;a=tree;f=test;hb=refs/heads/0.20.x


The vote will close on Mon Apr  9 18:45:00 PDT 2018 or later

[ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.20.x
[ ] +0
[ ] -1 Do not release these artifacts because...

[RESULT][VOTE] Release Apache Aurora 0.20.0 RC1

[Renan DelValle]

All,
The vote to accept Apache Aurora 0.20.0 RC1
as the official Apache Aurora 0.20.0 release has passed.


+1 (Binding)
--
Stephan Erb
Santhosh Kumar Shanmugham
Renan DelValle


+1 (Non-binding)
--


There were no 0 or -1 votes. Thank you to all who helped make this release.


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

The tag used to create the release with is rel/0.20.0:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=shortlog=refs/tags/rel/0.20.0

The release is available at:
https://dist.apache.org/repos/dist/release/aurora/0.20.0/apache-aurora-0.20.0.tar.gz

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

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

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

On Tue, Apr 3, 2018 at 3:21 PM, Santhosh Kumar Shanmugham <
sshanmug...@twitter.com.invalid> wrote:

> +1 from me.
>
> On Fri, Mar 30, 2018 at 8:10 AM, Renan DelValle <re...@apache.org> wrote:
>
> > Must be! In that case it doesn't seem like a reason to hold back the
> > release.
> >
> > +1 from me as well.
> >
> > On Fri, Mar 30, 2018 at 8:08 AM, Stephan Erb <s...@apache.org> wrote:
> >
> > > This test seems to pass for me. Maybe some flaky behaviour?
> > >
> > > On Thu, 2018-03-29 at 14:09 -0700, Renan DelValle wrote:
> > > > On my second round of verification, integration tests are getting
> stuck
> > > at:
> > > >
> > > > src/test/python/apache/thermos/monitoring/test_disk.
> > > py::TestMesosDiskCollector::test_mesos_disk_collector_bad_api_path
> > > >
> > > > Can anyone else confirm if this happens to them as well?
> > > >
> > > > -Renan
> > > >
> > > >
> > > >
> > > > On Thu, Mar 29, 2018 at 1:43 AM, Stephan Erb <
> > > stephan@blue-yonder.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Verification script has passed for me now.
> > > > >
> > > > > On 28.03.18, 21:30, "Renan DelValle" <re...@apache.org> wrote:
> > > > >
> > > > > All,
> > > > >
> > > > >
> > > > > I propose that we accept the following release candidate as the
> > > > > official
> > > > >
> > > > > Apache Aurora 0.20.0 release.
> > > > >
> > > > >
> > > > > Aurora 0.20.0-rc1 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.20.0-rc1
> > > > >
> > > > >
> > > > > The CHANGELOG for the release is available at:
> > > > >
> > > > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> > > > > CHANGELOG=rel/0.20.0-rc1
> > > > >
> > > > >
> > > > > 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.20.0-rc1
> > > > >
> > > > >
> > > > > The release candidate is available at:
> > > > >
> > > > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > > > apache-aurora-0.20.0-rc1.tar.gz
> > > > >
> > > > >
> > > > > The MD5 checksum of the release candidate can be found at:
> > > > >
> > > > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > > > apache-aurora-0.20.0-rc1.tar.gz.md5
> > > > >
> > > > >
> > > > > The signature of the release candidate can be found at:
> > > > >
> > > > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > > > apache-aurora-0.20.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 or after Sun Mar  31 12:30:00 PST 2018
> > > > >
> > > > >
> > > > > [ ] +1 Release this as Apache Aurora 0.20.0
> > > > >
> > > > > [ ] +0
> > > > >
> > > > > [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
> > > > >
> > > > >
> > > > >
> > >
> >
>

Re: [VOTE] Release Apache Aurora 0.20.0 RC1

[Renan DelValle]

Must be! In that case it doesn't seem like a reason to hold back the
release.

+1 from me as well.

On Fri, Mar 30, 2018 at 8:08 AM, Stephan Erb <s...@apache.org> wrote:

> This test seems to pass for me. Maybe some flaky behaviour?
>
> On Thu, 2018-03-29 at 14:09 -0700, Renan DelValle wrote:
> > On my second round of verification, integration tests are getting stuck
> at:
> >
> > src/test/python/apache/thermos/monitoring/test_disk.
> py::TestMesosDiskCollector::test_mesos_disk_collector_bad_api_path
> >
> > Can anyone else confirm if this happens to them as well?
> >
> > -Renan
> >
> >
> >
> > On Thu, Mar 29, 2018 at 1:43 AM, Stephan Erb <
> stephan@blue-yonder.com>
> > wrote:
> >
> > > +1
> > >
> > > Verification script has passed for me now.
> > >
> > > On 28.03.18, 21:30, "Renan DelValle" <re...@apache.org> wrote:
> > >
> > > All,
> > >
> > >
> > > I propose that we accept the following release candidate as the
> > > official
> > >
> > > Apache Aurora 0.20.0 release.
> > >
> > >
> > > Aurora 0.20.0-rc1 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.20.0-rc1
> > >
> > >
> > > The CHANGELOG for the release is available at:
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> > > CHANGELOG=rel/0.20.0-rc1
> > >
> > >
> > > 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.20.0-rc1
> > >
> > >
> > > The release candidate is available at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > apache-aurora-0.20.0-rc1.tar.gz
> > >
> > >
> > > The MD5 checksum of the release candidate can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > apache-aurora-0.20.0-rc1.tar.gz.md5
> > >
> > >
> > > The signature of the release candidate can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> > > apache-aurora-0.20.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 or after Sun Mar  31 12:30:00 PST 2018
> > >
> > >
> > > [ ] +1 Release this as Apache Aurora 0.20.0
> > >
> > > [ ] +0
> > >
> > > [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
> > >
> > >
> > >
>

Re: [VOTE] Release Apache Aurora 0.20.0 RC1

[Renan DelValle]

On my second round of verification, integration tests are getting stuck at:

src/test/python/apache/thermos/monitoring/test_disk.py::TestMesosDiskCollector::test_mesos_disk_collector_bad_api_path

Can anyone else confirm if this happens to them as well?

-Renan



On Thu, Mar 29, 2018 at 1:43 AM, Stephan Erb <stephan@blue-yonder.com>
wrote:

> +1
>
> Verification script has passed for me now.
>
> On 28.03.18, 21:30, "Renan DelValle" <re...@apache.org> wrote:
>
> All,
>
>
> I propose that we accept the following release candidate as the
> official
>
> Apache Aurora 0.20.0 release.
>
>
> Aurora 0.20.0-rc1 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.20.0-rc1
>
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> CHANGELOG=rel/0.20.0-rc1
>
>
> 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.20.0-rc1
>
>
> The release candidate is available at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> apache-aurora-0.20.0-rc1.tar.gz
>
>
> The MD5 checksum of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> apache-aurora-0.20.0-rc1.tar.gz.md5
>
>
> The signature of the release candidate can be found at:
>
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc1/
> apache-aurora-0.20.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 or after Sun Mar  31 12:30:00 PST 2018
>
>
> [ ] +1 Release this as Apache Aurora 0.20.0
>
> [ ] +0
>
> [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
>
>
>

Re: [RESULT][VOTE] Release Apache Aurora 0.20.0 RC0

[Renan DelValle]

Working on fixing an issue with the end to end tests.

Will start another vote after it's confirmed that all tests pass.

On Fri, Mar 23, 2018 at 11:17 PM, Meghdoot bhattacharya <
meghdoo...@yahoo.com.invalid> wrote:

> Any progress on 0.20 release?
>
> Thx
>
> > On Mar 12, 2018, at 5:28 PM, Renan DelValle <re...@apache.org> wrote:
> >
> > Changing my vote to a -1 and closing the vote as failed.
> >
> > Based on Stephan's experience, I went back and retested, and found a
> > different error than Stephan found when running the integration tests:
> >
> >   Executing tasks in goals: gen -> pyprep -> test
> > 17:13:42 00:01   [gen]
> > 17:13:42 00:01 [thrift-py]
> > 17:13:42 00:01   [cache]
> >   No cached artifacts for 4 targets.
> >   Invalidated 4 targets.
> > 17:13:42 00:01   [pyprep]
> > 17:13:42 00:01 [interpreter]
> > 17:13:46 00:05 [requirements]
> > 17:13:46 00:05   [cache]
> >   No cached artifacts for 37 targets.
> >   Invalidated 37 targets.
> > 17:14:06 00:25 [sources]
> >   Waiting for background workers to finish.
> > 17:14:06 00:25   [complete]
> >   FAILURE
> > Exception caught: ()
> >
> > Exception message: [Errno 36] File name too long:
> > u'/home/user/aurora/.pants.d/build_invalidator/7/pants_
> > backend_python_tasks2_gather_sources_GatherSources/.pants.
> > d.gen.thrift-py.252d64521cf9.api.src.main.thrift.org.
> > apache.aurora.gen._storage.current.api.src.main.thrift.
> > org.apache.aurora.gen._storage.hash'
> >
> > Filed https://issues.apache.org/jira/browse/AURORA-1980 for this issue.
> >
> > Stephan, if you could, please file the issues for the failures you've
> seen
> > so we can track them.
> >
> >
> > -Renan
> >
> >
> > On Mon, Mar 12, 2018 at 3:14 PM, Stephan Erb <
> stephan@blue-yonder.com>
> > wrote:
> >
> >> Unfortunately, I am unable to get the end-to-end tests to pass, even
> after
> >> a full `vagrant destroy && git clean -xfd`.
> >>
> >> Things I have seen fail:
> >>
> >> • Failures of the curl disabling Mesos maintenance schedules
> >> • Can't check signature: public key not found
> >>
> >> I have tested on two different computers to rule out a bad setup, but
> both
> >> errors have shown up a couple of times now. Could it be that the Vagrant
> >> update has introduced some issues here?
> >>
> >>
> >> On 07.03.18, 21:44, "Renan DelValle" <re...@apache.org> wrote:
> >>
> >>Reminder that the vote for 0.20.0 is still open.
> >>
> >>Kicking off the vote with a +1 from me.
> >>
> >>On Thu, Mar 1, 2018 at 4:39 PM, Renan DelValle <re...@apache.org>
> >> wrote:
> >>
> >>> All,
> >>>
> >>> I propose that we accept the following release candidate as the
> >> official
> >>> Apache Aurora 0.20.0 release.
> >>>
> >>> Aurora 0.20.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.20.0-rc0
> >>>
> >>> The CHANGELOG for the release is available at:
> >>> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> >>> CHANGELOG=rel/0.20.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.20.0-rc0
> >>>
> >>> The release candidate is available at:
> >>> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> >>> apache-aurora-0.20.0-rc0.tar.gz
> >>>
> >>> The MD5 checksum of the release candidate can be found at:
> >>> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> >>> apache-aurora-0.20.0-rc0.tar.gz.md5
> >>>
> >>> The signature of the release candidate can be found at:
> >>> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> >>> apache-aurora-0.20.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 Sun Mar  4 16:35:59 PST 2018
> >>>
> >>> [ ] +1 Release this as Apache Aurora 0.20.0
> >>> [ ] +0
> >>> [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
> >>>
> >>
> >>
> >>
>
>

Re: Slack IRC Gateway support ending

[Renan DelValle]

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 <dmclaugh...@apache.org>
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 <re...@apache.org> 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
>>
>
>

Slack IRC Gateway support ending

[Renan DelValle]

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

[RESULT][VOTE] Release Apache Aurora 0.20.0 RC0

[Renan DelValle]

Changing my vote to a -1 and closing the vote as failed.

Based on Stephan's experience, I went back and retested, and found a
different error than Stephan found when running the integration tests:

   Executing tasks in goals: gen -> pyprep -> test
17:13:42 00:01   [gen]
17:13:42 00:01 [thrift-py]
17:13:42 00:01   [cache]
   No cached artifacts for 4 targets.
   Invalidated 4 targets.
17:13:42 00:01   [pyprep]
17:13:42 00:01 [interpreter]
17:13:46 00:05 [requirements]
17:13:46 00:05   [cache]
   No cached artifacts for 37 targets.
   Invalidated 37 targets.
17:14:06 00:25 [sources]
   Waiting for background workers to finish.
17:14:06 00:25   [complete]
   FAILURE
Exception caught: ()

Exception message: [Errno 36] File name too long:
u'/home/user/aurora/.pants.d/build_invalidator/7/pants_
backend_python_tasks2_gather_sources_GatherSources/.pants.
d.gen.thrift-py.252d64521cf9.api.src.main.thrift.org.
apache.aurora.gen._storage.current.api.src.main.thrift.
org.apache.aurora.gen._storage.hash'

Filed https://issues.apache.org/jira/browse/AURORA-1980 for this issue.

Stephan, if you could, please file the issues for the failures you've seen
so we can track them.


-Renan


On Mon, Mar 12, 2018 at 3:14 PM, Stephan Erb <stephan@blue-yonder.com>
wrote:

> Unfortunately, I am unable to get the end-to-end tests to pass, even after
> a full `vagrant destroy && git clean -xfd`.
>
>  Things I have seen fail:
>
> • Failures of the curl disabling Mesos maintenance schedules
> • Can't check signature: public key not found
>
> I have tested on two different computers to rule out a bad setup, but both
> errors have shown up a couple of times now. Could it be that the Vagrant
> update has introduced some issues here?
>
>
> On 07.03.18, 21:44, "Renan DelValle" <re...@apache.org> wrote:
>
> Reminder that the vote for 0.20.0 is still open.
>
> Kicking off the vote with a +1 from me.
>
> On Thu, Mar 1, 2018 at 4:39 PM, Renan DelValle <re...@apache.org>
> wrote:
>
> > All,
> >
> > I propose that we accept the following release candidate as the
> official
> > Apache Aurora 0.20.0 release.
> >
> > Aurora 0.20.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.20.0-rc0
> >
> > The CHANGELOG for the release is available at:
> > https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> > CHANGELOG=rel/0.20.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.20.0-rc0
> >
> > The release candidate is available at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> > apache-aurora-0.20.0-rc0.tar.gz
> >
> > The MD5 checksum of the release candidate can be found at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> > apache-aurora-0.20.0-rc0.tar.gz.md5
> >
> > The signature of the release candidate can be found at:
> > https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> > apache-aurora-0.20.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 Sun Mar  4 16:35:59 PST 2018
> >
> > [ ] +1 Release this as Apache Aurora 0.20.0
> > [ ] +0
> > [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
> >
>
>
>

Re: [VOTE] Release Apache Aurora 0.20.0 RC0

[Renan DelValle]

Reminder that the vote for 0.20.0 is still open.

Kicking off the vote with a +1 from me.

On Thu, Mar 1, 2018 at 4:39 PM, Renan DelValle <re...@apache.org> wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.20.0 release.
>
> Aurora 0.20.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.20.0-rc0
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=
> CHANGELOG=rel/0.20.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.20.0-rc0
>
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> apache-aurora-0.20.0-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> apache-aurora-0.20.0-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/
> apache-aurora-0.20.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 Sun Mar  4 16:35:59 PST 2018
>
> [ ] +1 Release this as Apache Aurora 0.20.0
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.20.0 because...
>

[VOTE] Release Apache Aurora 0.20.0 RC0

[Renan DelValle]

All,

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

Aurora 0.20.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.20.0-rc0

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANGELOG=rel/0.20.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.20.0-rc0

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

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

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.20.0-rc0/apache-aurora-0.20.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 Sun Mar  4 16:35:59 PST 2018

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

[RESULT][VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

All,
The vote to accept the proposed packages as our official binary packages
for Apache Aurora 0.19.x has passed.


+1 (Binding)
--
Renan DelValle
David McLaughlin
Stephan Erb

There were no 0  or-1 votes. There were no non-binding votes.

The official packages are now available here:
https://dl.bintray.com/apache/aurora/

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

Thank you to all who helped make this release.

-Renan

On Sun, Feb 25, 2018 at 4:20 AM, Stephan Erb <stephan@blue-yonder.com>
wrote:

> +1
>
> On 21.02.18, 20:01, "David McLaughlin" <dmclaugh...@apache.org> wrote:
>
> +1 from me.
>
> On Wed, Feb 21, 2018 at 9:57 AM, Renan DelValle <re...@apache.org>
> wrote:
>
> > Another friendly reminder that we can't release the binary packages
> for
> > 0.19.x without at least three +1 binding votes.
> >
> > Not releasing a package for 0.19.x will create a problem for anyone
> trying
> > to upgrade to later versions as we recommend upgrading version by
> version.
> >
> >  Any and all feedback regarding these binary packages, binding or
> > otherwise, is welcome so that we may fix any issues that crop up.
>     >
> > Thanks,
> >
> > -Renan
> >
> >
> > On Wed, Feb 14, 2018 at 8:43 AM, Renan DelValle <re...@apache.org>
> wrote:
> >
> > > All,
> > >
> > > Friendly reminder to download, verify, and test so we can conclude
> the
> > > voting!
> > >
> > > Thanks!
> > >
> > > -Renan
> > >
> > > On Sun, Feb 11, 2018 at 1:37 PM, Renan DelValle <re...@apache.org>
> > wrote:
> > >
> > >> Kicking off the voting with a +1 (binding) from me.
> > >>
> > >> Tested all distributions using the test scripts.
> > >>
> > >> -Renan
> > >>
> > >> On Sun, Feb 11, 2018 at 1:35 PM, Renan DelValle <re...@apache.org
> >
> > wrote:
> > >>
> > >>> All,
> > >>>
> > >>> I propose that we accept the following artifacts as the official
> deb
> > and
> > >>> rpm packaging for
> > >>> Apache Aurora 0.19.x:
> > >>>
> > >>> https://dl.bintray.com/rdelvalle/aurora/
> > >>>
> > >>> The Aurora deb and rpm packaging includes the following:
> > >>>
> > >>> ---
> > >>>
> > >>> The branch used to create the packaging is:
> > >>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> > >>> .git;a=tree;hb=refs/heads/0.19.x
> > >>>
> > >>> The packages are available at:
> > >>> https://dl.bintray.com/rdelvalle/aurora/
> > >>>
> > >>> 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. Detailed test instructions are
> > >>> available here:
> > >>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
> > >>> .git;a=tree;f=test;hb=refs/heads/0.19.x
> > >>>
> > >>>
> > >>> The vote will close on Wed Feb 14 13:35:18 PST 2018
> > >>>
> > >>> [ ] +1 Release these as the deb and rpm packages for Apache
> Aurora
> > 0.19.x
> > >>> [ ] +0
> > >>> [ ] -1 Do not release these artifacts because...
> > >>>
> > >>> 
> > >>> 
> > >>>
> > >>
> > >>
> > >
> >
>
>
>

Re: Aurora 0.20.0 Release Date

[Renan DelValle]

Waiting to get access to Aurora's Bintray to finish the 0.19.x binary
release and then I will kick off the release for 0.20.0.

On Sun, Feb 25, 2018 at 10:34 AM, Meghdoot bhattacharya <
meghdoo...@yahoo.com.invalid> wrote:

> Any decision on this?
>
> Thx
>
> > On Feb 9, 2018, at 8:04 AM, Stephan Erb <stephan@blue-yonder.com>
> wrote:
> >
> > I think this is a good idea. Development has slowed down enough that it
> should not be difficult to cut a release.
> >
> > On 09.02.18, 02:49, "Renan DelValle" <re...@apache.org> wrote:
> >
> >All,
> >
> >Since Mesos has shipped version 1.5.0 today, should we consider
> releasing
> >0.20.0 (which supports Mesos 1.4.0) so we don't fall too far behind in
> >terms of Mesos compatibility?
> >
> >-Renan
> >
> >
>
>

Re: [VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

Another friendly reminder that we can't release the binary packages for
0.19.x without at least three +1 binding votes.

Not releasing a package for 0.19.x will create a problem for anyone trying
to upgrade to later versions as we recommend upgrading version by version.

 Any and all feedback regarding these binary packages, binding or
otherwise, is welcome so that we may fix any issues that crop up.

Thanks,

-Renan


On Wed, Feb 14, 2018 at 8:43 AM, Renan DelValle <re...@apache.org> wrote:

> All,
>
> Friendly reminder to download, verify, and test so we can conclude the
> voting!
>
> Thanks!
>
> -Renan
>
> On Sun, Feb 11, 2018 at 1:37 PM, Renan DelValle <re...@apache.org> wrote:
>
>> Kicking off the voting with a +1 (binding) from me.
>>
>> Tested all distributions using the test scripts.
>>
>> -Renan
>>
>> On Sun, Feb 11, 2018 at 1:35 PM, Renan DelValle <re...@apache.org> wrote:
>>
>>> All,
>>>
>>> I propose that we accept the following artifacts as the official deb and
>>> rpm packaging for
>>> Apache Aurora 0.19.x:
>>>
>>> https://dl.bintray.com/rdelvalle/aurora/
>>>
>>> The Aurora deb and rpm packaging includes the following:
>>>
>>> ---
>>>
>>> The branch used to create the packaging is:
>>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>>> .git;a=tree;hb=refs/heads/0.19.x
>>>
>>> The packages are available at:
>>> https://dl.bintray.com/rdelvalle/aurora/
>>>
>>> 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. Detailed test instructions are
>>> available here:
>>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>>> .git;a=tree;f=test;hb=refs/heads/0.19.x
>>>
>>>
>>> The vote will close on Wed Feb 14 13:35:18 PST 2018
>>>
>>> [ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.19.x
>>> [ ] +0
>>> [ ] -1 Do not release these artifacts because...
>>>
>>> 
>>> 
>>>
>>
>>
>

Design Doc for Staggered Updates

[Renan DelValle]

HI all,

I'm looking to get feedback on this design proposal for staggered updates:
https://docs.google.com/document/d/1xGk4ueH8YlmJCk6hQJh85u4to4M1VQD0l630IOchvgY/edit#

The goal of this proposal is composed of two main pieces:

1. Create a feature that pauses updates automatically after a batch
completes.

2. Allow variable batch sizes for updates.


-Renan

Re: [VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

All,

Friendly reminder to download, verify, and test so we can conclude the
voting!

Thanks!

-Renan

On Sun, Feb 11, 2018 at 1:37 PM, Renan DelValle <re...@apache.org> wrote:

> Kicking off the voting with a +1 (binding) from me.
>
> Tested all distributions using the test scripts.
>
> -Renan
>
> On Sun, Feb 11, 2018 at 1:35 PM, Renan DelValle <re...@apache.org> wrote:
>
>> All,
>>
>> I propose that we accept the following artifacts as the official deb and
>> rpm packaging for
>> Apache Aurora 0.19.x:
>>
>> https://dl.bintray.com/rdelvalle/aurora/
>>
>> The Aurora deb and rpm packaging includes the following:
>>
>> ---
>>
>> The branch used to create the packaging is:
>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>> .git;a=tree;hb=refs/heads/0.19.x
>>
>> The packages are available at:
>> https://dl.bintray.com/rdelvalle/aurora/
>>
>> 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. Detailed test instructions are
>> available here:
>> https://git1-us-west.apache.org/repos/asf?p=aurora-packaging
>> .git;a=tree;f=test;hb=refs/heads/0.19.x
>>
>>
>> The vote will close on Wed Feb 14 13:35:18 PST 2018
>>
>> [ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.19.x
>> [ ] +0
>> [ ] -1 Do not release these artifacts because...
>>
>> 
>> 
>>
>
>

Re: [VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

Kicking off the voting with a +1 (binding) from me.

Tested all distributions using the test scripts.

-Renan

On Sun, Feb 11, 2018 at 1:35 PM, Renan DelValle <re...@apache.org> wrote:

> All,
>
> I propose that we accept the following artifacts as the official deb and
> rpm packaging for
> Apache Aurora 0.19.x:
>
> https://dl.bintray.com/rdelvalle/aurora/
>
> The Aurora deb and rpm packaging includes the following:
>
> ---
>
> The branch used to create the packaging is:
> https://git1-us-west.apache.org/repos/asf?p=aurora-
> packaging.git;a=tree;hb=refs/heads/0.19.x
>
> The packages are available at:
> https://dl.bintray.com/rdelvalle/aurora/
>
> 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. Detailed test instructions are
> available here:
> https://git1-us-west.apache.org/repos/asf?p=aurora-
> packaging.git;a=tree;f=test;hb=refs/heads/0.19.x
>
>
> The vote will close on Wed Feb 14 13:35:18 PST 2018
>
> [ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.19.x
> [ ] +0
> [ ] -1 Do not release these artifacts because...
>
> 
> 
>

[VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

All,

I propose that we accept the following artifacts as the official deb and
rpm packaging for
Apache Aurora 0.19.x:

https://dl.bintray.com/rdelvalle/aurora/

The Aurora deb and rpm packaging includes the following:

---

The branch used to create the packaging is:
https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;hb=refs/heads/0.19.x

The packages are available at:
https://dl.bintray.com/rdelvalle/aurora/

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. Detailed test instructions are available
here:
https://git1-us-west.apache.org/repos/asf?p=aurora-packaging.git;a=tree;f=test;hb=refs/heads/0.19.x


The vote will close on Wed Feb 14 13:35:18 PST 2018

[ ] +1 Release these as the deb and rpm packages for Apache Aurora 0.19.x
[ ] +0
[ ] -1 Do not release these artifacts because...

Re: [RESULT][VOTE] Release Apache Aurora 0.19.1 RC0

[Renan DelValle]

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

The tag used to create the release with is rel/0.19.1:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=shortlog=refs/tags/rel/0.19.1

The release is available at:
https://dist.apache.org/repos/dist/release/aurora/0.19.1/apache-aurora-0.19.1.tar.gz

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

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

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



On Sun, Feb 11, 2018 at 11:45 AM, Renan DelValle <re...@apache.org> wrote:

> All,
> The vote to accept Apache Aurora 0.19.1 RC0 as the official Apache Aurora 
> 0.19.1
> release has passed.
>
>
> +1 (Binding)
> ------
> Renan DelValle
> Bill Farner
> Stephan Erb
>
> There were no 0 or -1 votes or non-binding votes.
>
> Thank you to all who helped make this release.
>
> On Fri, Feb 9, 2018 at 8:27 AM, Stephan Erb <stephan@blue-yonder.com>
> wrote:
>
>> +1 (binding)
>>
>> On 09.02.18, 02:02, "Bill Farner" <wfar...@apache.org> wrote:
>>
>> +1, binding
>>
>> I did encounter a unit test failure, but maintain my +1 as this test
>> case
>> has been notorious flaky on macOS 10.13.3 (especially for me,
>> apparently).
>> All other checks in the verification script pass.
>>
>>def _run_collector_tests(collector, target, wait):
>>  assert collector.value == 0
>>
>>  collector.sample()
>>  wait()
>>  assert collector.value == 0
>>
>>  f1 = make_file(TEST_AMOUNT_1, dir=target)
>>  wait()
>>> assert collector.value >= TEST_AMOUNT_1.as_(Data.BYTES)
>>E assert 100728832 >= 104857600.0
>>E  +  where 100728832 =
>> > 0x11138de50>.value
>>E  +  and   104857600.0 = > Amount(100,
>> MB)>()
>>E  +where  =
>> Amount(100, MB).as_
>>E  +and   > 0x11018cbd0> =
>> Data.BYTES
>>
>>src/test/python/apache/thermos/monitoring/test_disk.py:44:
>> AssertionError
>>
>> On Wed, Feb 7, 2018 at 3:41 PM, Renan DelValle <
>> renanidelva...@gmail.com>
>> wrote:
>>
>> > This point release fixes the list arg parsing regression
>> experienced due to
>> > switching to JCommander so that we may release binary packages for
>> 0.19.x
>> >
>> > Kicking off the voting with a +1 from me.
>> >
>> > Validated with ./build-support/release/verify-release-candidate
>> 0.19.1-rc0
>> >
>> > On Wed, Feb 7, 2018 at 3:37 PM, Renan DelValle <
>> renanidelva...@gmail.com>
>> > wrote:
>> >
>> > > All,
>> > >
>> > > I propose that we accept the following release candidate as the
>> official
>> > > Apache Aurora 0.19.1 release.
>> > >
>> > > Aurora 0.19.1-rc0 includes the following:
>> > > ---
>> > > The RELEASE NOTES for the release are available at:
>> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEA
>> > > SE-NOTES.md=rel/0.19.1-rc0
>> > >
>> > > The CHANGELOG for the release is available at:
>> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANG
>> > > ELOG=rel/0.19.1-rc0
>> > >
>> > > The tag used to create the release candidate is:
>> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=short
>> > > log;h=refs/tags/rel/0.19.1-rc0
>> > >
>> > > The release candidate is available at:
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
>> > > che-aurora-0.19.1-rc0.tar.gz
>> > >
>> > > The MD5 checksum of the release candidate can be found at:
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
>> > > che-aurora-0.19.1-rc0.tar.gz.md5
>> > >
>> > > The signature of the release candidate can be found at:
>> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
>> > > che-aurora-0.19.1-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 Sat Feb 10 14:00:33 PST 2018
>> > >
>> > > [ ] +1 Release this as Apache Aurora 0.19.1
>> > > [ ] +0
>> > > [ ] -1 Do not release this as Apache Aurora 0.19.1 because...
>> > >
>> >
>>
>>
>>
>

[RESULT][VOTE] Release Apache Aurora 0.19.1 RC0

[Renan DelValle]

All,
The vote to accept Apache Aurora 0.19.1 RC0 as the official Apache
Aurora 0.19.1
release has passed.


+1 (Binding)
--
Renan DelValle
Bill Farner
Stephan Erb

There were no 0 or -1 votes or non-binding votes.

Thank you to all who helped make this release.

On Fri, Feb 9, 2018 at 8:27 AM, Stephan Erb <stephan@blue-yonder.com>
wrote:

> +1 (binding)
>
> On 09.02.18, 02:02, "Bill Farner" <wfar...@apache.org> wrote:
>
> +1, binding
>
> I did encounter a unit test failure, but maintain my +1 as this test
> case
> has been notorious flaky on macOS 10.13.3 (especially for me,
> apparently).
> All other checks in the verification script pass.
>
>def _run_collector_tests(collector, target, wait):
>  assert collector.value == 0
>
>  collector.sample()
>  wait()
>  assert collector.value == 0
>
>  f1 = make_file(TEST_AMOUNT_1, dir=target)
>  wait()
>> assert collector.value >= TEST_AMOUNT_1.as_(Data.BYTES)
>E assert 100728832 >= 104857600.0
>E  +  where 100728832 =
>  0x11138de50>.value
>E  +  and   104857600.0 =  Amount(100,
> MB)>()
>E  +where  =
> Amount(100, MB).as_
>E  +and0x11018cbd0> =
> Data.BYTES
>
>src/test/python/apache/thermos/monitoring/test_disk.py:44:
> AssertionError
>
> On Wed, Feb 7, 2018 at 3:41 PM, Renan DelValle <
> renanidelva...@gmail.com>
> wrote:
>
> > This point release fixes the list arg parsing regression experienced
> due to
> > switching to JCommander so that we may release binary packages for
> 0.19.x
> >
> > Kicking off the voting with a +1 from me.
> >
> > Validated with ./build-support/release/verify-release-candidate
> 0.19.1-rc0
> >
> > On Wed, Feb 7, 2018 at 3:37 PM, Renan DelValle <
> renanidelva...@gmail.com>
> > wrote:
> >
> > > All,
> > >
> > > I propose that we accept the following release candidate as the
> official
> > > Apache Aurora 0.19.1 release.
> > >
> > > Aurora 0.19.1-rc0 includes the following:
> > > ---
> > > The RELEASE NOTES for the release are available at:
> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEA
> > > SE-NOTES.md=rel/0.19.1-rc0
> > >
> > > The CHANGELOG for the release is available at:
> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANG
> > > ELOG=rel/0.19.1-rc0
> > >
> > > The tag used to create the release candidate is:
> > > https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=short
> > > log;h=refs/tags/rel/0.19.1-rc0
> > >
> > > The release candidate is available at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> > > che-aurora-0.19.1-rc0.tar.gz
> > >
> > > The MD5 checksum of the release candidate can be found at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> > > che-aurora-0.19.1-rc0.tar.gz.md5
> > >
> > > The signature of the release candidate can be found at:
> > > https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> > > che-aurora-0.19.1-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 Sat Feb 10 14:00:33 PST 2018
> > >
> > > [ ] +1 Release this as Apache Aurora 0.19.1
> > > [ ] +0
> > > [ ] -1 Do not release this as Apache Aurora 0.19.1 because...
> > >
> >
>
>
>

Aurora 0.20.0 Release Date

[Renan DelValle]

All,

Since Mesos has shipped version 1.5.0 today, should we consider releasing
0.20.0 (which supports Mesos 1.4.0) so we don't fall too far behind in
terms of Mesos compatibility?

-Renan

Re: [VOTE] Release Apache Aurora 0.19.1 RC0

[Renan DelValle]

This point release fixes the list arg parsing regression experienced due to
switching to JCommander so that we may release binary packages for 0.19.x

Kicking off the voting with a +1 from me.

Validated with ./build-support/release/verify-release-candidate 0.19.1-rc0

On Wed, Feb 7, 2018 at 3:37 PM, Renan DelValle <renanidelva...@gmail.com>
wrote:

> All,
>
> I propose that we accept the following release candidate as the official
> Apache Aurora 0.19.1 release.
>
> Aurora 0.19.1-rc0 includes the following:
> ---
> The RELEASE NOTES for the release are available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=RELEA
> SE-NOTES.md=rel/0.19.1-rc0
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git=CHANG
> ELOG=rel/0.19.1-rc0
>
> The tag used to create the release candidate is:
> https://git-wip-us.apache.org/repos/asf?p=aurora.git;a=short
> log;h=refs/tags/rel/0.19.1-rc0
>
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> che-aurora-0.19.1-rc0.tar.gz
>
> The MD5 checksum of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> che-aurora-0.19.1-rc0.tar.gz.md5
>
> The signature of the release candidate can be found at:
> https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/apa
> che-aurora-0.19.1-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 Sat Feb 10 14:00:33 PST 2018
>
> [ ] +1 Release this as Apache Aurora 0.19.1
> [ ] +0
> [ ] -1 Do not release this as Apache Aurora 0.19.1 because...
>

[VOTE] Release Apache Aurora 0.19.1 RC0

[Renan DelValle]

All,

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

Aurora 0.19.1-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.19.1-rc0

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=aurora.git=
CHANGELOG=rel/0.19.1-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.19.1-rc0

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

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

The signature of the release candidate can be found at:
https://dist.apache.org/repos/dist/dev/aurora/0.19.1-rc0/
apache-aurora-0.19.1-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 Sat Feb 10 14:00:33 PST 2018

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

Re: Welcome new committers and PMC member!

[Renan DelValle]

Thanks everyone! I appreciate this opportunity and I'm very excited to be
part of the PMC.

Congrats and welcome to Jordan as well!

-Renan

On Tue, Feb 6, 2018 at 12:49 PM, Stephan Erb <s...@apache.org> wrote:

> Congratulations and welcome!
>
>
> On Tue, 2018-02-06 at 12:11 -0800, Manivannan wrote:
> > Welcome Renan and Jordan!
> >
> > On Tue, Feb 6, 2018 at 11:58 AM, Bill Farner <wfar...@apache.org> wrote:
> >
> > > Folks,
> > >
> > > I'm happy to announce that we have two new developers on the project!
> > >
> > > Renan DelValle is now a committer and PMC member
> > >
> > > Jordan Ly is now a committer
> > >
> > >
> > > Welcome aboard, we're looking forward to your continued contributions!
> > >
> > >
> > > -=Bill
> > >
>

Re: [RESULT] [VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

Should we try releasing the binaries again now that we tackled this issue?
There's been a few folks on the Slack channel have been asking when the
binaries for 0.19 will be released.

-Renan

On Wed, Dec 13, 2017 at 5:23 PM, Bill Farner <wfar...@apache.org> wrote:

> I reverse my vote to -1 and am closing the vote as failed.
>
> Turns out i had some old debs in my dist/ dir, and the test script picked
> those up.  After clearing those, i encounter the same issue.
>
> Here is the culprit:
>
> $ ag -i THERMOS_EXECUTOR_RESOURCES
> specs/debian/aurora-scheduler.startup.sh
> 37:  -thermos_executor_resources="$THERMOS_EXECUTOR_RESOURCES" \
>
> specs/debian/aurora-scheduler.upstart
> 34:  -thermos_executor_resources="$THERMOS_EXECUTOR_RESOURCES" \
>
> specs/debian/aurora-scheduler.init
> 75:-thermos_executor_resources="$THERMOS_EXECUTOR_RESOURCES" \
>
> specs/debian/aurora-scheduler.default
> 65:THERMOS_EXECUTOR_RESOURCES=""
>
> thermos_executor_resources is passed an empty string.  Here is the option
> definition:
>
> @Parameter(names = "-thermos_executor_resources",
> > description = "A comma separated list of additional resources to copy
> > into the sandbox."
> > + "Note: if thermos_executor_path is not the thermos_executor.pex file
> > itself, "
> > + "this must include it.")
> > public List thermosExecutorResources = ImmutableList.of();
>
>
> We expect this to become an empty list, however the parser emits a list of
> size one, containing an empty string.  I've filed AURORA-1962
> <https://issues.apache.org/jira/browse/AURORA-1962> for the issue.
>
>
> On Wed, Dec 13, 2017 at 3:31 PM, Renan DelValle <renanidelva...@gmail.com>
> wrote:
>
> > I'm running into the same issues as Stephan. I tried with Trusty, Xenial,
> > and Jessie. Same issue with all.
> >
> > Somehow a Mesos fetcher entry with a URI value of '' gets injected into
> the
> > task protobuf.
> >
> > This is the command I ran for Trusty:
> > ./test/test-artifact.sh test/deb/ubuntu-trusty/
> > /repo/artifacts/aurora-ubuntu-trusty/dist
> >
> > Oddly enough, we have deployed 0.19.0 packages for trusty without any
> issue
> > on at least two of our test clusters so it may have to do with our
> > artifacts tests?
> >
> > I tried upgrading the trusty box to Mesos 1.2.2 and the problem
> persisted.
> >
> > -Renan
> >
> > On Wed, Dec 13, 2017 at 9:28 AM, Mohit Jaggi <mohit.ja...@uber.com>
> wrote:
> >
> > > +1
> > >
> > > On Wed, Dec 13, 2017 at 9:03 AM, Bill Farner <wfar...@apache.org>
> wrote:
> > >
> > > > We would need at least 2 more binding votes to complete this release.
> > Do
> > > > folks need more time?
> > > >
> > > > On Tue, Dec 12, 2017 at 2:49 PM, thinker0 <think...@gmail.com>
> wrote:
> > > >
> > > > > +1, we 0.19.0 small production tested
> > > > > 2017년 12월 13일 (수) 04:05, Mohit Jaggi <mohit.ja...@uber.com>님이 작성:
> > > > >
> > > > > > +0, we don't use the packages. If you just need someone to test
> and
> > > > > verify,
> > > > > > I can do that. Let me know.
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 9:53 AM, Bill Farner <wfar...@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > > Friendly reminder that the vote is due to close tomorrow!
> > > > > > >
> > > > > > > Stephan - is the issue you described reproducible?  Did i run
> the
> > > > same
> > > > > > test
> > > > > > > command(s) as you?
> > > > > > >
> > > > > > > On Sun, Dec 10, 2017 at 8:32 PM, Bill Farner <
> wfar...@apache.org
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > +1 from me, as the test script passes for all artifacts
> > > > > > > >
> > > > > > > > I did not have time to run them prior to opening the vote;
> but
> > i
> > > do
> > > > > not
> > > > > > > > encounter the failure you did:
> > > > > > > >
> > > > > > > > $ ./test/test-artifact.sh test/deb/debian-jessie/
> > > > > > > > /repo/artifacts/aurora-debian-jessie/dist
> > > > > > > > 

Re: [VOTE] Release Apache Aurora 0.19.x packages

[Renan DelValle]

I'm running into the same issues as Stephan. I tried with Trusty, Xenial,
and Jessie. Same issue with all.

Somehow a Mesos fetcher entry with a URI value of '' gets injected into the
task protobuf.

This is the command I ran for Trusty:
./test/test-artifact.sh test/deb/ubuntu-trusty/
/repo/artifacts/aurora-ubuntu-trusty/dist

Oddly enough, we have deployed 0.19.0 packages for trusty without any issue
on at least two of our test clusters so it may have to do with our
artifacts tests?

I tried upgrading the trusty box to Mesos 1.2.2 and the problem persisted.

-Renan

On Wed, Dec 13, 2017 at 9:28 AM, Mohit Jaggi  wrote:

> +1
>
> On Wed, Dec 13, 2017 at 9:03 AM, Bill Farner  wrote:
>
> > We would need at least 2 more binding votes to complete this release.  Do
> > folks need more time?
> >
> > On Tue, Dec 12, 2017 at 2:49 PM, thinker0  wrote:
> >
> > > +1, we 0.19.0 small production tested
> > > 2017년 12월 13일 (수) 04:05, Mohit Jaggi 님이 작성:
> > >
> > > > +0, we don't use the packages. If you just need someone to test and
> > > verify,
> > > > I can do that. Let me know.
> > > >
> > > > On Tue, Dec 12, 2017 at 9:53 AM, Bill Farner 
> > wrote:
> > > >
> > > > > Friendly reminder that the vote is due to close tomorrow!
> > > > >
> > > > > Stephan - is the issue you described reproducible?  Did i run the
> > same
> > > > test
> > > > > command(s) as you?
> > > > >
> > > > > On Sun, Dec 10, 2017 at 8:32 PM, Bill Farner 
> > > wrote:
> > > > >
> > > > > > +1 from me, as the test script passes for all artifacts
> > > > > >
> > > > > > I did not have time to run them prior to opening the vote; but i
> do
> > > not
> > > > > > encounter the failure you did:
> > > > > >
> > > > > > $ ./test/test-artifact.sh test/deb/debian-jessie/
> > > > > > /repo/artifacts/aurora-debian-jessie/dist
> > > > > > 
> > > > > > OK (all tests passed)
> > > > > > Connection to 127.0.0.1 closed.
> > > > > > ==> aurora_jessie: Forcing shutdown of VM...
> > > > > >
> > > > > > the branch is missing
> > > > > >
> > > > > >
> > > > > > That i cannot speak for, unfortunately.
> > > > > >
> > > > > > For those who have yet to try out the builds, here are the test
> > > > commands
> > > > > i
> > > > > > ran.  You can reproduce these by first downloading the artifacts
> > (in
> > > my
> > > > > > case, they were under artifacts/*)
> > > > > >
> > > > > > ./test/test-artifact.sh test/deb/debian-jessie/
> > > > > > /repo/artifacts/aurora-debian-jessie/dist/
> > > > > > ./test/test-artifact.sh test/deb/ubuntu-trusty/
> > > > > > /repo/artifacts/aurora-ubuntu-trusty/dist/
> > > > > > ./test/test-artifact.sh test/deb/ubuntu-xenial/
> > > > > > /repo/artifacts/aurora-ubuntu-xenial/dist/
> > > > > > ./test/test-artifact.sh test/rpm/centos-7/
> > > > /repo/artifacts/aurora-centos-
> > > > > > 7/dist/rpmbuild/RPMS/x86_64
> > > > > >
> > > > > > Each command took about 5 mins to run in my case.
> > > > > >
> > > > > > A belated thanks to Stephan for adding the test script!
> > > > > >
> > > > > > commit b904b5f
> > > > > >> Author: Stephan Erb 
> > > > > >> Date:   Tue Feb 14 23:33:41 2017 +0100
> > > > > >> Add basic test scripts for RPM and DEB packages
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 10, 2017 at 1:06 PM, Stephan Erb 
> > > wrote:
> > > > > >
> > > > > >> I was just trying to run the validation scripts for Debian
> Jessie
> > > and
> > > > > >> those are failing with the error:
> > > > > >>
> > > > > >>
> > > > > >> I1210 20:48:36.172399  7371 fetcher.cpp:283] Fetching directly
> > into
> > > > the
> > > > > >> sandbox directory
> > > > > >> I1210 20:48:36.172417  7371 fetcher.cpp:220] Fetching URI ''
> > > > > >> Failed to fetch '': A relative path was passed for the resource
> > but
> > > > the
> > > > > >> Mesos framework home was not specified. Please either provide
> this
> > > > > >> config option or avoid using a relative path
> > > > > >>
> > > > > >> End fetcher log for container 48b4029a-231d-441a-98a6-
> > 8c6538fe0efa
> > > > > >> E1210 20:48:36.220979  5590 fetcher.cpp:558] Failed to run
> mesos-
> > > > > >> fetcher: Failed to fetch all URIs for container
> > '48b4029a-231d-441a-
> > > > > >> 98a6-8c6538fe0efa' with exit status: 256
> > > > > >> E1210 20:48:36.221174  5590 slave.cpp:4650] Container
> > > '48b4029a-231d-
> > > > > >> 441a-98a6-8c6538fe0efa' for executor
> > > > 'thermos-vagrant-test-hello_world-
> > > > > >> 0-74b87db4-0d97-4d03-a7f9-9482a1060f20' of framework
> > 208bd6e7-5d17-
> > > > > >> 4257-9564-71af57900310- fail
> > > > > >> ed to start: Failed to fetch all URIs for container
> > '48b4029a-231d-
> > > > > >> 441a-98a6-8c6538fe0efa' with exit status: 256
> > > > > >>
> > > > > >>
> > > > > >> Did those tests work for you?
> > > > > >>
> > > > > >>
> > > > > >> In addition, but most probably unrelated, the branch is missing
> 

Re: Thrift 0.10.0

[Renan DelValle]

Thanks John and Stephan for the hard work!

*NOTE: If you don't use go bindings to interact with Aurora, feel free to
ignore the rest of this message.*

Just a heads up to those those who use go clients and want to maintain
version parity:

Upgrading to bindings generated by Thrift 0.10.0 to maintain version parity
will cause breakage due to a change in the way thrift sets are translated
to go maps by the thrift generator (https://issues.apache.org/jir
a/browse/THRIFT-3467).

Although the thrift issue says this landed in 0.11.0, this change actually
landed in Thrift 0.10.0 (https://github.com/apache/
thrift/commits/0.10.0?after=b2a4d4ae21c789b689dd162deb819665567f481c+139).

-Renan


On Tue, Dec 12, 2017 at 10:43 PM, Bill Farner  wrote:

> After much battling with tools, tests, and jenkins; John upgraded us to
> thrift 0.10.0 by landing r/64290 !
>
> The next time you pull, you will likely notice that you have some stale
> untracked files.  You can safely clean these up:
>
>   $ rm -r build-support/thrift/thrift-0.*
>
> You may also notice that you no longer have to bootstrap the thrift
> compiler by compiling it; meaning that building from scratch should be
> noticeably faster!
>
> I scanned the changelog for thrift 0.9.2, 0.9.3, 0.10.0, and there is only
> one feature i found potentially useful:
>
> THRIFT-640  Support
> deprecation
>
> There are a handful of modest performance improvements that we will benefit
> from:
>
> THRIFT-2877  Optimize
> generated hashCode
> THRIFT-3306  Java:
> TBinaryProtocol: Use 1 temp buffer instead of allocating 8
> THRIFT-2172  Java
> compiler allocates optionals array for every struct with an optional field
> THRIFT-3431  Avoid
> "schemes" HashMap lookups during struct reads/writes
>
>
> Many thanks to John and Stephan for their hard work getting us upgraded!
>

Re: gorealis is now officially a PayPal Open Source Project

[Renan DelValle]

Thanks Bill! Very much appreciate your support and encouragement (as well
as the rest of the community's) since I started contributing. Good to see
you active in the project again.

-Renan

On Mon, Oct 16, 2017 at 2:59 PM, Bill Farner <wfar...@apache.org> wrote:

> Congrats on releasing!
>
> On Oct 16, 2017, 4:15 PM -0500, Renan DelValle <renanidelva...@gmail.com>,
> wrote:
> > Hi all,
> >
> > Just wanted to drop a note about a recent update for gorealis[1]. For
> those
> > who aren't familiar with it, gorealis is a library that aims to enable
> > users to programmatically interact with the Aurora scheduler without
> > dealing with thrift directly.
> >
> > A few days ago the project was moved from my public repository to
> PayPal's
> > Open Source Github repository. Although the team at PayPal has been
> behind
> > it 100% since day one, this shift symbolizes a new level of commitment to
> > the project.
> >
> > We hope that gorealis is helpful both as a a library and as an example of
> > how to engage the Aurora scheduler through thrift.
> >
> > If anyone has any questions regarding the project or how to get started
> > using it, or better yet, wants to make a contribution, feel free to reach
> > out to me by e-mail, through Github, through Slack (mesos.slack.com), or
> > even Tweet at me @renandelvalle
> >
> > Thanks!
> >
> > -Renan
> >
> > [1] https://github.com/paypal/gorealis
>

gorealis is now officially a PayPal Open Source Project

[Renan DelValle]

Hi all,

Just wanted to drop a note about a recent update for gorealis[1]. For those
who aren't familiar with it, gorealis is a library that aims to enable
users to programmatically interact with the Aurora scheduler without
dealing with thrift directly.

A few days ago the project was moved from my public repository to PayPal's
Open Source Github repository. Although the team at PayPal has been behind
it 100% since day one, this shift symbolizes a new level of commitment to
the project.

We hope that gorealis is helpful both as a a library and as an example of
how to engage the Aurora scheduler through thrift.

If anyone has any questions regarding the project or how to get started
using it, or better yet, wants to make a contribution, feel free to reach
out to me by e-mail, through Github, through Slack (mesos.slack.com), or
even Tweet at me @renandelvalle

Thanks!

-Renan

[1] https://github.com/paypal/gorealis

Extending Aurora Pluggable Scheduling Proposal

[Renan DelValle Rueda]

Hello fellow Aurorans,

I'd like to share a proposal doc that seeks to lay out a roadmap for
bringing in new scheduling features to Aurora.

David McLaughlin did a fantastic job of getting the ball rolling with the
pluggable scheduling patches he contributed (1) and I'd like to expand upon
that work.

The overarching idea of this proposal is that everyone has different
scheduling needs and it would be great to enhance Aurora to allow operators
to meet organization specific scheduling needs without imposing them on the
rest of the community.

The features outlined in this proposal are based upon principles from
Fenzo(2) which have enjoyed great success powering Mantis(3) and Titus(4)
at Netflix.

Finally, since this proposal is about scheduling enhancements, I also
thought it would be pertinent to include talk of a feature that attempts to
avoid hosting tasks on misbehaving agents. This is due to the fact that
some of the scheduling policies introduced by this proposal can amplify the
negative effect a bad node can have on performance. (I.e. we keep on
choosing the "bad" node to schedule on and the task keeps on failing
through no fault of its own.)

Would love to hear some feedback on these ideas and/or opinions on what the
next steps should be if we were to embark on this journey.

https://docs.google.com/document/d/11ArMA53chtK-Zb_
KPMV7l_bCvTrUb005XlqzGQ2fTP4/edit#

Thanks!
-Renan

1. https://lists.apache.org/thread.html/50caf01283144ee9dacd24d3fb481a
2ca6120ceaa1289fd5b48620a4@%3Cdev.aurora.apache.org%3E

2. https://github.com/Netflix/Fenzo

3. https://medium.com/netflix-techblog/stream-processing-
with-mantis-78af913f51a6

4. https://medium.com/netflix-techblog/the-evolution-of-
container-usage-at-netflix-3abfc096781b

Re: Aurora reconciliation and Master fail over

[Renan DelValle]

Yup, that looks like the way to go. Going to go ahead and file a ticket on
JIRA for this so that we don't forget. Thanks for digging into this David.

-Renan

On Mon, Jul 17, 2017 at 3:00 PM, David McLaughlin 
wrote:

> Based on the thread in the Mesos dev list, it looks like because they
> don't persist task information so they don't have the task IDs to send when
> they detect the agent is lost during failover. So unless this is changed on
> the Mesos side, we need to act on the slaveLost message and mark all those
> tasks as LOST in Aurora.
>
> Or rely on reconciliation. To reconcile more often, you should keep in
> mind:
>
> 1) Implicit reconciliation sends one message to Mesos and Mesos replies
> with N number of status updates immediately, where N = number of running
> tasks. This process is usually quick (on the order of seconds) due to being
> mostly NOOP status updates. When you have a large number of running tasks
> (say 100k+), you may see some GC pressure due to the flood of status
> updates. If this operation overlapped with another particularly expensive
> operation (like a snapshot) it can cause a huge stop the world GC. But it
> does not otherwise interfere with any operation.
>
> 2) Explicit reconciliation is done in batches, where Aurora batches up all
> running tasks and sends one batch at a time, staggered by some delay. The
> benefit here is there is less GC pressure, but the drawback is if you have
> a lot of running tasks (again, 100k+), it will take over 10 minutes to
> complete. So you have to make sure your reconciliation interval is aligned
> with this (you can always increase the batch size to make this happen
> faster).
>
> Cheers,
> David
>
> On Sun, Jul 16, 2017 at 11:10 AM, Meghdoot bhattacharya <
> meghdoo...@yahoo.com.invalid> wrote:
>
>> Got it. Thx!
>>
>> > On Jul 16, 2017, at 9:49 AM, Stephan Erb  wrote:
>> >
>> > Reconciliation in Aurora is not a specific mode. It just runs
>> > concurrently to other background work such as snapshots or backups [1].
>> >
>> >
>> > Just be aware that we don't have metrics to track the runtime of
>> > explicit and implicit reconciliations. If you use settings that are
>> > overly aggressive, you might overload Auroras queue of incoming Mesos
>> > status updates (for example).
>> >
>> > [1] https://github.com/apache/aurora/blob/c85bffdd6f68312261697eee868d5
>> > 7069adda434/src/main/java/org/apache/aurora/scheduler/reconciliation/Ta
>> > skReconciler.java
>> >
>> >
>> >> On Sat, 2017-07-15 at 22:28 -0700, Meghdoot bhattacharya wrote:
>> >> Thx David for the follow up and confirmation.
>> >> We have started the thread on the mesos dev DL.
>> >>
>> >> So to get clarification on the recon, what is in general effect
>> >> during the recon. Does scheduling and activities like snapshot is
>> >> paused as recon takes place. Trying to see whether to run aggressive
>> >> recon in mean time.
>> >>
>> >> Thx
>> >>
>> >>> On Jul 15, 2017, at 9:33 AM, David McLaughlin > >>> rg> wrote:
>> >>>
>> >>> I've left a comment on the initial RB detailing how the change
>> >>> broke
>> >>> backwards-compatibility. Given that the tasks are marked as lost as
>> >>> soon as
>> >>> the agent reregisters after slaveLost is sent anyway, there doesn't
>> >>> seem to
>> >>> be any reason not to send TASK_LOST too. I think this should be an
>> >>> easy
>> >>> fix.
>> >>>
>> >>> On Sat, Jul 15, 2017 at 9:21 AM, David McLaughlin > >>> he.org>
>> >>> wrote:
>> >>>
>>  Yes, we've confirmed this internally too (Santhosh did the work
>>  here):
>> 
>>  When an agent becomes unreachable while the master is running, it
>>  sends
>> > TASK_LOST events for each task on the agent.
>> > https://github.com/apache/mesos/blob/33093c893773f8c9d293afe
>> > 38e9909f9a2868d32/src/master/master.cpp#L7066-L7107
>> > Marking agent unreachable after failover does not cause
>> > TASK_LOST events.
>> > https://github.com/apache/mesos/blob/33093c893773f8c9d293afe
>> > 38e9909f9a2868d32/src/master/master.cpp#L2036-L2070
>> > Once an agent re-registers it sends TASK_LOST events. Agent
>> > sending
>> > TASK_LOST for tasks that it does not know after a Master
>> > failover.
>> > https://github.com/apache/mesos/blob/33093c893773f8c9d293afe
>> > 38e9909f9a2868d32/src/slave/slave.cpp#L1324-L1383
>> 
>> 
>> 
>>  The separate code path for markUnreachableAfterFailover appears
>>  to have
>>  been added by this commit:
>>  https://github.com/apache/mesos/commit/937c85f2f6528d1ac56ea9a7aa
>>  174c
>>  a0bd371d0c
>> 
>>  And I think this totally breaks the promise of introducing the
>>  PARTITION_AWARE stuff in a backwards-compatible way.
>> 
>>  So right now, yes we rely on reconciliation to finally mark the
>>  tasks as
>>  LOST and reschedule their replacements.
>> 
>>  I think 

Re: Proposal for Pluggable Scheduling in Aurora

[Renan DelValle]

Hi David,

Any updates on the progress of this proposal/feature?

-Renan



On Mon, May 8, 2017 at 5:59 PM, David McLaughlin 
wrote:

> Hi all,
>
> I've posted a patch to enable replacing the scheduling algorithms in
> Aurora. The patch is relatively trivial but has some big implications.
>
> There is a document that outlines the motivation of this patch and some
> future work to make everything more user-friendly:
>
> https://docs.google.com/document/d/1fVHLt9AF-YbOCVCDMQmi5DATVusn-
> tqY8DldKbjVEm0/edit?usp=sharing
>
> Please let me know if you have any comments or concerns.
>
> Thanks,
> David
>

Re: Preparations for 0.17.0

[Renan DelValle]

I'd really like to take care of
https://issues.apache.org/jira/browse/AURORA-1780 for 0.17.0, at least
allow the scheduler to take less drastic measures.

If any one wants to submit any feedback as to how we should tackle this,
I'm all ears.

-Renan

On Thu, Nov 3, 2016 at 4:18 PM, Joshua Cohen  wrote:

> I added https://issues.apache.org/jira/browse/AURORA-1782 to 0.17.0
> Hopefully I'll have time to look into that soon.
>
> On Wed, Nov 2, 2016 at 4:53 PM, Zameer Manji  wrote:
>
> > Thanks for stepping up!
> >
> > I think picking up Mesos 1.1 is ideal for the release and we should block
> > our release until it is out.
> >
> > On Wed, Nov 2, 2016 at 9:24 AM, Erb, Stephan <
> stephan@blue-yonder.com>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I’d like to volunteer as our next release manager and set the release
> > > train for 0.17 into motion.
> > >
> > > Since 0.16 we have fixed several important bugs and should therefore
> aim
> > > for a release in the next 2-4 weeks, if possible. If everything goes
> > > according to plan for the current Mesos release, we should be able to
> > pick
> > > up Mesos 1.1 as well.
> > >
> > > Please tag any blocker issues with `fixVersion 0.17` so that they show
> up
> > > on this dashboard: https://issues.apache.org/
> > jira/browse/AURORA-1014?jql=
> > > project%20%3D%20AURORA%20AND%20fixVersion%20%3D%200.17.0%
> > > 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
> > > 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > Best regards,
> > > Stephan
> > >
> > > --
> > > Zameer Manji
> > >
> >
>