Re: Shepherding new contributions

Apache by-laws ;)). On Fri, Feb 27, 2015 at 10:39 AM, Henry Saputra wrote: > Do you know how MAINTAINERS file work for Mesos? > > Does it list different committers for each areas of Mesos? > > - Henry > > On Fri, Feb 27, 2015 at 10:07 AM, Joshua Cohen > wrote: > >

Re: Shepherding new contributions

tra > wrote: > > > This would work. > > Anyone assigned as reviewer in the RB need to either execute the > > review or excuse themselves to make sure all "ship it" votes are > > accounted for. > > > > - Henry > > > > On Tue, Feb 24, 2015 at

Re: Testing Done in RB?

; On Feb 23, 2015, at 10:55, Joshua Cohen wrote: > > > > 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

Re: Shepherding new contributions

> responsibilities. > > > Meaning, no concept of owners or maintainers for particular parts that > > > could insinuate different hierarchy of approval for commits from one > > > to another PMCs/ committers. > > > > > > This needs to be thought out car

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: Testing Done in RB?

he commit message size and makes for a hard to read arbitrary > > length/formatted commit. The RB link should be enough to get commit > > details and testing done. > > > > On Mon, Feb 23, 2015 at 10:35 AM, Joshua Cohen > > wrote: > > > This came up in a review a

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: Soliciting feature requests for 0.8.0

Big +1 for getting Shiro in, as it will require a deprecation cycle before we can remove the old auth system, and the less time we have both hanging around the better. I'd love to see better packaging/distribution as well (AURORA-951). On Thu, Feb 19, 2015 at 9:40 AM, Jake Farrell wrote: > Woul

Re: [VOTE] Graduate Apache Aurora as a TLP

+1! On Wednesday, February 18, 2015, Dan Norris wrote: > +1 > > On Wed, Feb 18, 2015 at 9:41 PM, Maxim Khutornenko > wrote: > > > +1 > > > > On Wed, Feb 18, 2015 at 6:09 PM, Steve Niemitz > > > wrote: > > > +1 > > > > > > On Wed, Feb 18, 2015 at 6:08 PM, Kevin Sweeney > > > wrote: > > > > > >

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

class (or risk > having #ifdef-like logic everywhere in SchedulerThriftInterface). > > On Wed, Feb 11, 2015 at 3:49 PM, Joshua Cohen > wrote: > > > How do you envision things looking in the intermediate phase where we > have > > support for both security modes? > > &

Re: [DISCUSS] Use the Apache Shiro framework for scheduler security

How do you envision things looking in the intermediate phase where we have support for both security modes? I imagine it's easy enough on the Shiro side of if we go with the AOP annotations for authorization (the interceptor can just check if security_mode == SHIRO before doing anything), but that

Re: Seeking volunteers to create scheduler REST API RFC

thrift objects and have that also as an option (along > > with json at least) to go over a http 2.0 end point? > > > > ~ Joestein > > > > On Mon, Feb 9, 2015 at 5:31 PM, Brian Wickman > wrote: > > > > > +1 > > > > > > On Mon, Feb 9,

Re: Seeking volunteers to create scheduler REST API RFC

I'd love to help out with this as well. On Mon, Feb 9, 2015 at 1:25 PM, Bill Farner wrote: > Hi folks, > > Before embarking on work [1] to build a REST* API for the scheduler, it's > important that we come up with a sound design. Following up from today's > IRC meeting, i would like to gather a

Re: Subject: [VOTE] Release Apache Aurora 0.7.0 (incubating) RC3

+1, md5sum and signature are valid, java, python e2e tests all pass. On Tue, Feb 3, 2015 at 6:09 PM, Jake Farrell wrote: > +1 for 0.7.0 rc3 > > I created AURORA-1099 for the missing license headers and they are being > addressed in trunk > > -Jake > > > Apache Aurora release checklist > - >

Re: [Announcement] New Committer: Joshua Cohen

Thanks! On Tue, Feb 3, 2015 at 7:16 AM, Bill Farner wrote: > Welcome aboard! > > On Tuesday, February 3, 2015, Jake Farrell wrote: > > > On behalf of the Apache Aurora PPMC, I would like to welcome our newest > > committer to the project: > > > >

Re: Coordinated update configuration

+1 for option #1 with a default of None. On Wed, Jan 28, 2015 at 8:12 AM, Maxim Khutornenko wrote: > Thanks David, I agree. Unless there are other opinions, I will proceed > with #1. > > On Tue, Jan 27, 2015 at 11:04 AM, David McLaughlin > wrote: > > The heartbeat requirement feature should be

Re: [VOTE] Release Apache Aurora 0.7.0 (incubating) RC2

+1 md5 matches, signature is valid, java, python and end to end tests all pass. On Wed, Jan 28, 2015 at 11:18 AM, Zameer Manji wrote: > +1 Release this as Apache Aurora 0.7.0 > > The MD5 hash matches. > The signature is valid. > Python tests pass. > Java tests pass. > I was also able to build al

Re: Java Styleguide

https://reviews.apache.org/r/29691/ :) On Thursday, January 8, 2015, Jake Farrell wrote: > We probably should link or add this to our docs so new contributors who are > not watching the dev list currently do not miss this > > -Jake > > On Wed, Jan 7, 2015 at 8:01 PM, Joshu

Java Styleguide

Hi folks, Some recent reviews have been met with stylistic feedback. This is important as maintaining a consistent style reduces noise as people reformat code to individual preferences. Unfortunately our code style was previously completely undocumented. Good news, this is no longer the case! Auro

Re: Should we continue to maintain fine-grained python BUILD targets?

I agree, pants is heavily biased towards 1 directory, 1 package, 1 build target. If we're going to stay with pants I'd prefer to stick with that convention. If we're going to simplify the build structure I think we should take that as impetus to move away from pants entirely. On Tue, Jan 6, 2015 a

Re: [DISCUSS] Deprecate use of mock.patch?

; System.setOut(oldSystemOut); > } > } > > in our tests but that's mutable global state and makes our code brittle for > exactly the same 4 reasons as above. > > I don't think there's anything about Python that makes mutable global state > an inherently bet

Re: [DISCUSS] Deprecate use of mock.patch?

gt; encourage a proliferation of un-pythonic patterns and more obstacles > on the way to improving our python code coverage. > > On Wed, Nov 19, 2014 at 4:02 PM, Joshua Cohen > wrote: > > As I mentioned in that review, I'm not sold on the idea. I feel that it > > leads

Re: [DISCUSS] Deprecate use of mock.patch?

As I mentioned in that review, I'm not sold on the idea. I feel that it leads to a fair amount of extra code that exists solely to support testing. One of the nice things about dynamic languages is they allow you to avoid this sort of boilerplate. The main problem in that review is just that the wr

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

Oh, forgot to add: +0: I had to bump memory for Vagrant image to 2 gigs. But no one else seems to be having this problem. On Mon, Nov 17, 2014 at 3:45 PM, Joshua Cohen wrote: > +1 > > signature looks valid. > md5 matches > java tests pass > python tests pass > v1 and v2 e

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC2

+1 signature looks valid. md5 matches java tests pass python tests pass v1 and v2 e2e tests pass. +0 gradlew shenanigans. Overall: +1 On Mon, Nov 17, 2014 at 2:55 PM, Maxim Khutornenko wrote: > +1 > > All java/python/e2e tests pass with the workaround of copying > gradlew-related stuff from

Re: Build failed in Jenkins: Aurora #731

Failing the build on this check is just too flaky (coverage numbers vary slightly based on JVM). Going to send a review to make it advisory only. On Wed, Nov 12, 2014 at 3:28 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > >

Re: [VOTE] Release Apache Aurora 0.6.0 (incubating) RC1

+1 overall All tests pass (java, python, e2e), signatures/md5 verified. On Wed, Nov 12, 2014 at 3:00 PM, Zameer Manji wrote: > +1 Ship it! > > +1 Java tests pass. > +1 Python tests pass. > +1 End to end tests pass. > > On Wed, Nov 12, 2014 at 2:02 PM, Bill Farner wrote: > > > Reminder - the vo

Re: ubuntu 12.04 LTS - pants.venv => build error

pants.venv gets created by the pants bootstrap script, so that *shouldn't* be a problem. The error you pasted is a problem we've been experiencing intermittently with our builds: https://github.com/pantsbuild/pex/issues/18. Is this happening on every build for you? In theory if it's just a connecti

Re: Build failed in Jenkins: Aurora #660

https://github.com/pantsbuild/pex/issues/18 :( On Fri, Oct 17, 2014 at 10:28 AM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See > > Changes: > > [wfarner] Make README.md more informative. > > [wfarner] Fix table of contents in co

Re: Proposal: External Update Coordination

gt; >> > > >> > > wrote: > > >> >> > > >> > > > > If the goal is to reduce complexity now and add > > features > > >> >> > later, > > >> >> > > why > > >> >

Re: Storage is not READY

Hi Joe, It sounds like you haven't initialized the mesos replicated log. See the documentation here: https://github.com/apache/incubator-aurora/blob/master/docs/deploying-aurora-scheduler.md#initializing-the-replicated-log Cheers, Joshua On Thu, Oct 16, 2014 at 9:13 AM, Joe Stein wrote: > My

Re: Proposal: External Update Coordination

"The heratbeatJobUpdate RPC serves as an ACK, but we don't have a NACK. If we are going to let lack-of-ACK serve as the NACK, i don't think it's safe to resume when we receive another ACK. In other words, a service toggling unhealthy might not be deemed safe to proceed." Lack-of-ACK is the scena

Re: Proposal: documentation before code

I'm +1 on the sentiment. My main concern is with the potential for effort to be gated on documentation review. This essentially requires design review for all new features before development begins. Great in theory, but I worry in practice things may get held up while we try to work out details tha

Re: Health Check Disabler Discussion

I'm in camp #2, I don't feel that it adds a significant amount of complexity to the health check logic, and it provides a substantial safeguard against users accidentally shooting themselves in the foot by accidentally leaving a health check snoozed. On Fri, Oct 10, 2014 at 2:32 PM, Maxim Khutorne

Re: Proposal: External Update Coordination

In theory when the user resumes they'd also resume monitoring (and thus resume heartbeats)? Maybe the resumeJobUpdate RPC needs to support pauseIfNoHeartbeatsAfterMs as well? I'm not sure what a monitoring/heartbeating service would do with its record of a paused job while it's paused. How would i

Re: Build failed in Jenkins: Aurora #633

I think this is the same flakiness we saw once when I ran this locally. It wasn't repeatable though. On Wed, Oct 8, 2014 at 2:17 PM, Zameer Manji wrote: > https://issues.apache.org/jira/browse/AURORA-819 > > On Wed, Oct 8, 2014 at 2:10 PM, Bill Farner wrote: > >> Can you? >> >> -=Bill >> >> On

Re: Error handling in the aurora client

Came here to make the same suggestion John makes. What if we present friendly error messages to the user, but write stack traces to a log file that the user can upload in the event of unexpected/unhandled exceptions. IMO the reason for not wanting to rely on users re-running commands with a verbose

Re: pants release to support overriding interpreter

Hi Bhuvan, I'm trying to work with the pants devs to get a new release cut that includes the repo-wide interpreter requirement. Stay tuned! Cheers, Joshua On Thu, Sep 18, 2014 at 8:04 PM, Bhuvan Arumugam wrote: > This is more of pants/pex question. I'm posting it here, as most of > pants/pex

Re: H2 database admin console

; > (-framework_authentication_file), my vote is that we follow that. > > > > On Tue, Sep 16, 2014 at 10:17 AM, Joshua Cohen > > > wrote: > > > >> Providing the password directly via the command line seems like it > would be > >> a security issue (

Re: H2 database admin console

Providing the password directly via the command line seems like it would be a security issue (anyone who can `ps` on the box could see the password?). Is there something I'm missing? Would it be possible (and if so, would it be desirable?) to start up the web console as a user who only has read acc

Re: Unable to assign Jira issue to myself?

Sep 4, 2014 at 4:11 PM, Zameer Manji > wrote: > > > I think Chris Lambert needs to give you some some sort of extra > permission. > > > > > > On Thu, Sep 4, 2014 at 3:58 PM, Joshua Cohen > > > wrote: > > > > > Anyone know if I need

Unable to assign Jira issue to myself?

Anyone know if I need to get a permission in Jira in order to do this? Thanks! Joshua