[RESULT][VOTE] Graduate Apache Aurora as a TLP

With 26 +1 votes (12 binding, 14 community), and zero negative, the community vote for Apache Aurora (incubating) to graduate from the Incubator and become a Top Level Project passes. I will get the Incubator PMC VOTE started later today and cc the dev list. Great job everyone -Jake Binding (12,

Apache Aurora graduation IPMC vote

Graduation vote has been started on the IPMC list http://s.apache.org/EPo -Jake

Testing Done in RB?

This came up in a review and I figured it'd be better discussed here rather than in a review that most folks probably aren't reading. Do people find value in this section being filled in? The argument against is generally that it's always the same value and if we wait for a ship it from ReviewBot

Re: Testing Done in RB?

I am +1 on filling the test section as it may be a good indicator of what testing has been attempted (e.g. java-only, python-only, python sub-target, vagrant e2e, vagrant manual). I am -1 on having this included into the commit message as it blows up the commit message size and makes for a hard to

Re: Testing Done in RB?

I'm generally -1 to requiring humans to perform (what i perceive to be) superfluous redundant tasks. In this case, the standard suite of tests should be expected as part of any patch affecting code, which is why the review bot runs them. For that reason, i've mostly been using 'Testing done' to r

Re: Testing Done in RB?

If we decide to remove the 'Testing Done' section from commit messages then we should definitely update CONTRIBUTING.md[1] to codify the practice. [1] https://github.com/apache/incubator-aurora/blob/master/CONTRIBUTING.md On Mon, Feb 23, 2015 at 10:52 AM, Bill Farner wrote: > I'm generally -1 t

Summary of IRC Meeting in #aurora

Summary of IRC Meeting in #aurora at Mon Feb 23 19:01:06 2015: Attendees: thalin, davmclau, dnorris, t3hSteve, jfarrell, jcohen, wfarner, ro_, kts, jaybuff, mkhutornenko, zmanji, Floomi, dlester, Ming, mindscratch - Preface - graduation - incompatible change in beta updater API - scheduler REST

Shepherding new contributions

Hey, With the increased interest in Aurora, the project has started to receive more contributions from non-committers. By default we do not populate the "People" line in the review, meaning there is no responsible person to ensure we accept or reject contributions. I think we should establish She

Re: Shepherding new contributions

+1, I was thinking about this over the weekend. Mesos has recently been discussing adding MAINTAINERS files across the code to document who should be informed about changes within. I'm not sure Aurora is ready to go that far since generally it will either include all active committers or result in

Re: Shepherding new contributions

I think establishing MAINTAINERS/OWNERS files is another valid way of doing this. On Mon, Feb 23, 2015 at 12:00 PM, Joshua Cohen wrote: > +1, I was thinking about this over the weekend. > > Mesos has recently been discussing adding MAINTAINERS files across the code > to document who should be in

Re: [proposal] Deprecate the Thermos CLI

I actually find that the observer fits this usecase just as well, and is a better interface since the scheduler gives users a link to it on each host as well. I’m looking to decrease build complexity, and removing this would be a great victory for that. > On Feb 18, 2015, at 12:56 PM, Maxim Kh

Re: [proposal] Deprecate the Thermos CLI

Perhaps i was unclear - i was saying that the thermos CLI cannot be counted on as a debugging tool when other executors are in play. -=Bill On Mon, Feb 23, 2015 at 1:12 PM, Joseph Smith wrote: > I actually find that the observer fits this usecase just as well, and is a > better interface since

Jenkins build is back to normal : Aurora #891

See

Re: [proposal] Deprecate the Thermos CLI

I don't see how that follows. Are you saying that if Aurora can start scheduling Hadoop containers, people can't count on their Hadoop tools for debugging? On Mon, Feb 23, 2015 at 2:02 PM, Bill Farner wrote: > Perhaps i was unclear - i was saying that the thermos CLI cannot be counted > on as a

Re: [proposal] Deprecate the Thermos CLI

I agree with Brian here - the thermos CLI is equivalent to a read-write observer. I wonder if we can change this into a discussion about features - what features of the CLI are necessary and which are superfluous? On Mon, Feb 23, 2015 at 3:33 PM, Brian Wickman wrote: > I don't see how that follo

Re: Shepherding new contributions

+1 to the idea. A first step in the right direction might be to do something you (unintentionally?) implied - default People. We could do this in .reviewboardrc [1], and let the people in there serve as dispatchers to find the right reviewers. I'm happy to volunteer to be in that list if that so

Re: [proposal] Deprecate the Thermos CLI

I'm saying that if Aurora launched Hadoop containes, we can no longer use the thermos CLI as view into what Aurora has scheduled on the host. Happy to break the conversation down into one of features. -=Bill On Mon, Feb 23, 2015 at 3:39 PM, Kevin Sweeney wrote: > I agree with Brian here - the

Re: [proposal] Deprecate the Thermos CLI

I think the thermos CLI is overloaded a bit. It shows operators what is running on the machine via Thermos. This happens to serve two use cases: 1. Checking what Aurora has scheduled on the machine. 2. Checking the state of Thermos run processes. #1 Should be provided by Mesos and we should

Re: [proposal] Deprecate the Thermos CLI

Couldn't (yet-to-be-surfaced) information in the sandbox satisfy #2? -=Bill On Mon, Feb 23, 2015 at 3:58 PM, Zameer Manji wrote: > I think the thermos CLI is overloaded a bit. It shows operators what is > running on the machine via Thermos. This happens to serve two use cases: > >1. Checkin

Re: [proposal] Deprecate the Thermos CLI

Just adding our experience here: We've never used the thermos CLI nor do we even install it on our slaves (is that even where it's supposed to go?). The scheduler + observer + mesos UI have been enough to troubleshoot 99% of the problems we've run into. On Mon, Feb 23, 2015 at 3:58 PM, Zameer Ma

Build failed in Jenkins: Aurora #892

See Changes: [kevints] Split out ReadOnlySchedulerImplTest. [wickman] Fix swallowed exceptions in health check test, improve gc executor tests. -- [...truncated 4197 lines...] platfo

Jenkins build is back to normal : AuroraBot #3996

See

Jenkins build is back to normal : Aurora #893

See

Re: [proposal] Deprecate the Thermos CLI

Possibly. Without the CLI I don't see how we can access the data. On Mon, Feb 23, 2015 at 4:01 PM, Bill Farner wrote: > Couldn't (yet-to-be-surfaced) information in the sandbox satisfy #2? > > -=Bill > > On Mon, Feb 23, 2015 at 3:58 PM, Zameer Manji wrote: > > > I think the thermos CLI is overl

Re: Shepherding new contributions

Ok, we need to be careful about this maintainers/owners or shepherds business. Apache Spark got into some trouble from board when introducing this concept. First of all, in the eyes of ASF, all (P)PMCs have equal rights and responsibilities. Meaning, no concept of owners or maintainers for partic