Re: Attempting to Push Aurora to ~11 requests/second

19 PM, Bill Farner wrote: >> >> > I'm slightly doubtful that GC is the issue (based on background from Ryan >> > in IRC), but i could be wrong. Trying out a sample script would help us >> > confirm or deny, though. >> > >> > -=Bill >>

Re: Attempting to Push Aurora to ~11 requests/second

This time gap of over 2 seconds suggests there may have been an intensive GC and/or IO operation that paused processing long enough for the ZK session timeout to expire: I0316 18:22:55.396108 20795 replica.cpp:508] Replica received write request for position 22669 I0316 18:22:57.621 THREAD1905 org

Re: Build failed in Jenkins: Aurora #908

Looking. On Fri, Feb 27, 2015 at 2:19 PM, Apache Jenkins Server wrote: > See > > Changes: > > [wfarner] Update thrift API and internal code to use JobUpdateSummary.key > rather than job key and id. > > [maxim] Fixing cron update quota checking.

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: [VOTE] Graduate Apache Aurora as a TLP

RESOLVED, that the office of "Vice President, Apache Aurora" be >> > > and hereby is created, the person holding such office to >> > > serve at the direction of the Board of Directors as the chair >> > > of the Apache Aurora Project, and to have primary r

Re: [proposal] Deprecate the Thermos CLI

it an unsupported tool. Filed AURORA-1131 >> <https://issues.apache.org/jira/browse/AURORA-1131>. This is already on >> my >> radar as part of AURORA-1027 >> <https://issues.apache.org/jira/browse/AURORA-1027>. >> >> On Wed, Feb 18, 2015 at 9:19 AM,

Re: [proposal] Deprecate the Thermos CLI

> Moving parts should either provide value or be obliterated from our source > tree. I generally agree. In this particular case it's still unclear to me - in the absence of Thermos CLI and Observer, how do we conduct live site executor/thermos troubleshooting? On Tue, Feb 17, 2015 at 7:45 PM, Bi

Re: reasonable preemption delay to use

The watch_secs is triggered when a task enters RUNNING. In order for the rolling update to not fail early the restart_threshold [1] needs to be bumped up to account for the preemption delay. As for the default preemption delay, it was implemented to avoid unnecessary churn in the cluster. Larger/c

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

in Sweeney wrote: > I'm proposing more-or-less the "if > SHIRO_ENABLED do shiro_auth else do old_stuff" approach so that the > SHIRO_ENABLED branch can throw UnsupportedOperationException for a period > of time. > > On Wed, Feb 11, 2015 at 4:14 PM, Maxim Khutornenk

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

onceptually different changes that will benefit from small > reviews. If I take the approach of ripping out the current framework first > we could be left in an "old way's broken, new way's not finished yet" state. > > On Wed, Feb 11, 2015 at 4:03 PM, Maxim Khutornenk

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

Any example? The original code fragment suggest our current security model does not map cleanly into shiro. I am +1 on the first pass to reduce the "if-else" ugliness if possible. On Wed, Feb 11, 2015 at 3:57 PM, Kevin Sweeney wrote: > I'm thinking that flag will control which Guice bindings are

Re: Feature proposal: ability to apply a block on all updates in the scheduler

+1 to the proposal. However, the ticket already exists: https://issues.apache.org/jira/browse/AURORA-1091. On Wed, Feb 11, 2015 at 11:51 AM, David McLaughlin wrote: > Hi aurora-dev, > > I'd like to propose a feature that I think could be useful to > admins/operators of Aurora clusters. The featur

[RESULT][VOTE] Release Apache Aurora 0.7.0 (incubating) RC3

al (rather than a branch you're on, since the branch >> may have additional commits on it over the final hash). >> >> John >> >> On Thu Feb 05 2015 at 12:50:21 PM Maxim Khutornenko >> wrote: >> >>> Hi All, >>> >>> The Apache Auro

[VOTE] Release Apache Aurora 0.7.0 (incubating) RC3

Hi All, The Apache Aurora project has voted to release 0.7.0-incubating, our third release. The team voted in favor of this release with 7 binding +1s, 1 non-binding +1. 3 of the binding +1 votes were from IPMC members. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-aurora-dev/2

[RESULT][VOTE] Release Apache Aurora 0.7.0 (incubating) RC3

gt;> Signature file look good >> DISCLAIMER file exists >> NOTICE file looks good >> LICENSE file looks good >> No 3rd party executables in source artifact >> Source artifact build and passed tests >> >> +1 (binding) >> >> - Henry >> &g

Re: Heartbeat mechanism auditing

ent behavior: ROLLING_[FORWARD | BACK]. On Thu, Jan 29, 2015 at 4:19 PM, David McLaughlin wrote: > On Thu, Jan 29, 2015 at 2:45 PM, Maxim Khutornenko wrote: > >> To add a bit of history to the topic, the current design has been >> debated heavily here [1] and an active/lazy

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

All, I propose that we accept the following release candidate as the official Apache Aurora 0.7.0 release. Aurora 0.7.0-rc3 includes the following: --- The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=incubator-aurora.git&f=CHANGELOG&hb=0.7.0-rc3 The bran

[RESULT][VOTE] Release Apache Aurora 0.7.0 (incubating) RC2

LAIMER and LICENSE files look good. >> > >> No 3rd party executables. >> > >> >> > >> Small detail -1 because NOTICE file need to be updated to Copyright >> > 2014-2015. >> > >> I would think some IP

Re: Heartbeat mechanism auditing

To add a bit of history to the topic, the current design has been debated heavily here [1] and an active/lazy consensus was reached around implementing the first iteration as lightweight as possible without persisting any durable state. My take on this - we should proceed as originally proposed gi

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

> Small detail -1 because NOTICE file need to be updated to Copyright 2014-2015. > I would think some IPMC members will cry foul. > If JIRA is file against NOTICE file then +1 from me. > > - Henry > > > On Tue, Jan 27, 2015 at 5:25 PM, Maxim Khutornenko wrote: >> A

Re: Coordinated update configuration

eConfig and > optional field in the thrift API. > > On Tue, Jan 27, 2015 at 10:21 AM, Maxim Khutornenko > wrote: > >> We are working on AURORA-690 to support external service coordinated >> job updates. The feature design was proposed in [1] and discussed in >> [2]. >

[RESULT] [VOTE] Release Apache Aurora 0.7.0 (incubating) RC1

Since we have found a blocking bug (AURORA-1065) declaring this vote failed. RC2 vote is out. -- Forwarded message -- From: Maxim Khutornenko Date: Mon, Jan 26, 2015 at 4:23 PM Subject: [VOTE] Release Apache Aurora 0.7.0 (incubating) RC1 To: dev@aurora.incubator.apache.org All

[VOTE] Release Apache Aurora 0.7.0 (incubating) RC2

All, I propose that we accept the following release candidate as the official Apache Aurora 0.7.0 release. Aurora 0.7.0-rc2 includes the following: --- The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=incubator-aurora.git&f=CHANGELOG&hb=0.7.0-rc2 The bran

Re: AURORA-507

Thanks for reaching out! We are most likely going to deprecate the acquireLock and releaseLock RPCs once the client updater is removed (AURORA-785). There are plenty of other entry level items to chose from [1] though and we would greatly appreciate your help! https://issues.apache.org/jira/brows

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

gt;>> >>> > Anyone else seeing test_thermos_executor.py hang when running the tests >>> > through ./build-support/jenkins/build.sh? >>> > >>> > On Mon, Jan 26, 2015 at 4:23 PM, Maxim Khutornenko >>> > wrote: >>> > >>

Coordinated update configuration

We are working on AURORA-690 to support external service coordinated job updates. The feature design was proposed in [1] and discussed in [2]. The one remaining question I would like to discuss here is how to expose the coordinated update configuration to the user. The approaches as I see: 1. Exp

[VOTE] Release Apache Aurora 0.7.0 (incubating) RC1

All, I propose that we accept the following release candidate as the official Apache Aurora 0.7.0 release. Aurora 0.7.0-rc1 includes the following: --- The CHANGELOG for the release is available at: https://git-wip-us.apache.org/repos/asf?p=incubator-aurora.git&f=CHANGELOG&hb=0.7.0-rc1 The bran

Re: When (if ever) should we require JDK 8?

I am big +1 on the migration but I am afraid jumping into it too soon may lock out everyone from upgrading their Aurora cluster until they have 1.8 infra support. The 0.9.0 sounds about right unless there is a pushback from our customers. On Thu, Jan 22, 2015 at 12:04 PM, Kevin Sweeney wrote: >

Re: Next Apache Aurora IRC meeting, rescheduled for Tuesday 1/20?

It should have been sent, though I can't find it in my mailbox for some reason. http://wilderness.apache.org/archives/aurora-20_01_2015-3883.html On Tue, Jan 20, 2015 at 12:44 PM, Henry Saputra wrote: > No recording for today meeting? > > On Sat, Jan 17, 2015 at 5:28 PM, Dave Lester wrote: >> >

Re: Build failed in Jenkins: Aurora #808

Looking. Tests were passing before rebasing. On Wed, Jan 7, 2015 at 1:20 PM, Apache Jenkins Server wrote: > See > > Changes: > > [maxim] Implementing dual read the PopulatedJobConfig struct > > [wfarner] Change index to point to API thrift docume

Re: aurora watch_secs change

Here is in-person discussion follow up. Participants: Moses, wickman, kevints, maxim. The proposal we came up with does not require implementing scheduler health checks (AURORA-279). The idea is to require the executor to move a task from STARTING to RUNNING only when its health checks are satisfi

Re: aurora watch_secs change

Resending as my original post got dropped somehow. Here is in-person discussion follow up. Participants: Moses, wickman, kevints, maxim. The proposal we came up with does not require implementing scheduler health checks (AURORA-279). The idea is to require the executor to move a task from STARTIN

Re: Using immutables.org for Java code

ed to change the compiler we should first >>> evaluate if we can move to a library like immutables.org. >>> >>> On Tue, Dec 16, 2014 at 9:44 AM, Maxim Khutornenko >>> wrote: >>> > >>> > It looks quite interesting

Re: Using immutables.org for Java code

It looks quite interesting as a general case for immutability. As for replacing our immutable thrift implementation, is there anything in particular you noticed in immutables.org that we currently lack?

Re: some questions

You can get slaves (and more) from the /mesos/state.json endpoint. If using vagrant, e.g.: http://192.168.33.7:5050/master/state.json On Mon, Dec 15, 2014 at 3:19 PM, Zameer Manji wrote: > The output of /slaves is not in a machine readable format. I believe there > is a ticket somewhere that trac

Re: Constantly getting TASK_LOST from Mesos and THROTTLED from Aurora

You are most likely missing a mesos egg for your platform. See related thread [1] on how to workaround this problem. Thanks, Maxim [1] - http://mail-archives.apache.org/mod_mbox/aurora-dev/201410.mbox/%3CCAHD-6f8PkS84Fdp_Y3gnzZtk=TKgmV=02kh4e+5akm6ozdr...@mail.gmail.com%3E On Tue, Dec 9, 2014 a

Re: 0.7.0 Release Manager

I am willing to give it a try unless someone else wants it badly :) Thanks, Maxim On Mon, Dec 8, 2014 at 12:45 PM, Jake Farrell wrote: > Full process has been documented here [1] and will require whoever is the > RM to have their gpg key added to the KEYS file. Happy to help them through > the p

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

I am with Joshua on this. The increased complexity and indirection is not the tradeoff I would fight for. The lack of coverage is a bigger problem in my opinion. Requiring patch-less unit tests may just encourage a proliferation of un-pythonic patterns and more obstacles on the way to improving our

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

+1 All java/python/e2e tests pass with the workaround of copying gradlew-related stuff from a working branch. On Mon, Nov 17, 2014 at 11:23 AM, Zameer Manji wrote: > +1 The MD5 of the tarball is correct > +1 The Java tests pass > +0 We don't distribute gradlew in the tarball > +1 The Python test

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

+1(ish) from me. -1 gradlew is missing in the .tar.gz making it impossible to follow the deployment instructions without having a system installed gradle or using one from another branch. +1 all unit tests passing On Wed, Nov 12, 2014 at 3:19 PM, David McLaughlin wrote: > +1 from me > > +1 java

Cron job quota checking

Hi all, If you run cron jobs AND use resource quota checking for your production jobs please read further. We are planning to remove the existing loophole [1] for cron jobs sliding under the quota check radar. The proposed approach is to count cron job templates towards the production consumption

Re: Build failed in Jenkins: Aurora #674

To make it clear, I suggest softening the coverage check introduced here: https://reviews.apache.org/r/26902/. On Wed, Oct 22, 2014 at 9:24 AM, Maxim Khutornenko wrote: >> Instruction coverage must be greater than 0.88 > > Apparently, there is a difference in how the coverage i

Re: Build failed in Jenkins: Aurora #674

> Instruction coverage must be greater than 0.88 Apparently, there is a difference in how the coverage is calculated depending on the environment. I can't build locally unless I bump up the min coverage to 0.88 but that trips jenkins build. I suggest we either convert this error to message or add

Re: Proposal: External Update Coordination

Oct 15, 2014 at 7:49 PM, Bill Farner wrote: >> >> > David - the plan is to synthesize the waiting state. Exactly how is not >> > yet certain. >> > >> > On Wednesday, October 15, 2014, Maxim Khutornenko >> > wrote: >> > >> > > It

Re: Proposal: External Update Coordination

t performs an update action, >> and >> >> if none is present it simply refuses to perform the action. If the >> >> partition heals a new heartbeat will arrive (if the update being >> monitored >> >> should still be allowed to proceed) and the schedu

Re: Proposal: External Update Coordination

t;> > I think we should assess that after building the rest of the feature. >> IIUC >> > the rest of the code doesn't care if the update is initially paused. >> > >> > -=Bill >> > >> > On Wed, Oct 15, 2014 at 11:50 AM, Maxim K

Re: Proposal: External Update Coordination

Oct 14, 2014 at 12:16 PM, Kevin Sweeney >> > wrote: >> > >> > > I think waiting for the first heartbeat before taking any action is the >> > > simpler solution here as it allows the implementation to be entirely >> > > soft-state and still catche

Re: Proposal: External Update Coordination

of > heartbeats serve as a uniform "unknown or unhealthy" signal? > > -=Bill > > On Mon, Oct 13, 2014 at 5:25 PM, Maxim Khutornenko wrote: > >> I am still +1 on the idea to have default paused state on creation. I >> think we could still differentiate betwee

Re: Proposal: External Update Coordination

is that we may have to wait a maximum of one heartbeat > interval to find out that an update should be paused. > > On Mon, Oct 13, 2014 at 4:55 PM, Maxim Khutornenko wrote: > >> The main reason I preferred the lack-of-ACK approach over an explicit >> NACK one is simplicity. As J

Re: Proposal: External Update Coordination

sume when we receive another ACK. In other words, a service toggling >> unhealthy might not be deemed safe to proceed. >> >> Perhaps just sending OK (or a NOOP equivalent) in case of a user-paused job >> > update would make more sense as there is nothing monitoring service could

Re: Proposal: External Update Coordination

the > heartbeats and the scheduler? > > On Fri, Oct 10, 2014 at 12:47 PM, Maxim Khutornenko > wrote: > >> Hi all, >> >> We are proposing a new feature for the scheduler updater, which you >> may find helpful. >> >> I have posed a brief feature summ

Re: Health Check Disabler Discussion

+1 to the #1. Disabling health checks is like signing a waiver where all health check guarantees are off. On Fri, Oct 10, 2014 at 2:23 PM, David Pan wrote: > Hi Aurora, > > I am currently working on a feature that allows for health checks to be > disabled temporarily for a running instance of a j

Re: Proposal: External Update Coordination

e user can resume at any time. I'd > > propose we have a different response here. You really don't want to > "stop" > > monitoring the update while it is in a non-terminal state. You might want > > to be aware that your heartbeat is a no-op, though. >

Proposal: External Update Coordination

Hi all, We are proposing a new feature for the scheduler updater, which you may find helpful. I have posed a brief feature summary here: https://github.com/maxim111333/incubator-aurora/blob/hb_doc/docs/update-heartbeat.md Please, reply with your feedback/concerns/comments. Thanks, Maxim

Re: Build failed in Jenkins: Aurora #629

This is tracked by https://reviews.apache.org/r/26428/. On Wed, Oct 8, 2014 at 11:31 AM, Joe Smith wrote: > Thanks Bill. > > On Wed, Oct 8, 2014 at 11:28 AM, Bill Farner wrote: > >> Bumped into these as well after rebasing >> https://reviews.apache.org/r/26308 >> >> I've rolled cleanups into my

Re: Build failed in Jenkins: Aurora #625

Hm... Pre-commit hook did not catch this. Looking. On Tue, Oct 7, 2014 at 3:50 PM, Apache Jenkins Server wrote: > See > > Changes: > > [maxim] Fixing unhandled error logging in updater > > -- > [...truncate

Re: Error handling in the aurora client

> > The full backtrace goes off to a file in the user's home dir somewhere >> and >> > then you can ask them to run a command passing the pill ref to get the >> full >> > error report without worry of re-running some non-idempotent command, >> etc. >

Re: Error handling in the aurora client

+1 on dumping the stack for unhandled errors as long as they are not caused by KeyboardInterrupt. That would definitely help troubleshooting transient errors when --reveal-errors is not a good option. On Thu, Oct 2, 2014 at 1:19 PM, David McLaughlin wrote: > Because we allow things like hooks, I

Re: H2 database admin console

+1 on the command-line approach. There was a bit of a debate around it when it was proposed for the framework auth but its simplicity outweighed potential security concerns. On Tue, Sep 16, 2014 at 10:34 AM, Kevin Sweeney wrote: > There's precedent to take secrets as a properties file on the comm

Re: aurora maintenance mode

Hi Bhuvan, Looks like you are missing a cluster name argument in your command. Something like "aurora_admin start_maintenance_hosts --hosts= " should do it. Thanks, Maxim On Thu, Aug 21, 2014 at 1:01 PM, Bhuvan Arumugam wrote: > I'm trying to use aurora_admin command to bring few hosts in > mai

Re: Propsal: Centralizing update orchestration in Aurora

gt; > On Fri, Jul 25, 2014 at 3:54 PM, Maxim Khutornenko wrote: > >> I am a bit confused. Are you suggesting we retain the current client >> updater algorithm or only the scheduler primitives it currently >> employs? >> >> On Fri, Jul 25, 2014 at 3:36 PM, Bill Fa

Re: Propsal: Centralizing update orchestration in Aurora

at 2:40 PM, Bill Farner wrote: >> >> > I think the current API primitives used for updates (kill, add) will >> > continue to make sense, so a client could implement updates that way. >> > However, these will not appear as updates to the scheduler. &

Re: Propsal: Centralizing update orchestration in Aurora

Retaining client update algorithm would require extra work on the scheduler side to satisfy visibility requirements Bill outlined above, which may not worth the effort. That would also create ground for inconsistent update expectations and experience. On Fri, Jul 25, 2014 at 1:34 PM, Brian Wickma

Re: Proposal: API changes to getTasksStatus

ly fetch. > > > -=Bill > > > On Wed, Jun 18, 2014 at 5:10 PM, Maxim Khutornenko > wrote: > > > Small correction. TBase does not support lookup by field names, so the > > format would have to be a list of field IDs: > > > > // Defines a set of thrift pa

Re: Proposal: API changes to getTasksStatus

to support a name-to-id conversion if we still want a readable format like "assignedTask.instanceId" (converts to [1,6]). On Wed, Jun 18, 2014 at 1:21 PM, Maxim Khutornenko wrote: > Bumping up this thread as pagination does not solve client cases where all > tasks must be pulled for

Re: Proposal: API changes to getTasksStatus

Bumping up this thread as pagination does not solve client cases where all tasks must be pulled for evaluation. Example: SLA commands in aurora_admin. I would like to explore the #2 idea proposed by David and subsequently outlined by Bill/Suman. Specifically, I am proposing to add an optional for

SLA stats

I wanted to summarize a few details about the new SLA stats feature in the scheduler as I realized that code comments and AURORA-290may not tell the whole picture clearly. The primary goal of the feature is collection and monitoring of Aurora job S

Re: Adding shorthands, defaults, and initialization files to the aurora client

get both the context object containing the processed > parameters, and the bare argument list that was passed on the command line. > It's easy to build a hook an kill/killall that says "If the parameters > aren't in the bare argument list, then abort". > >

Re: Handling of aurora update when job/task cannot be scheduled

> > When a aurora create is done and if one or more instances are in PENDING > state, those instances may never get scheduled for the reasons you > mentioned in point 1 Fair point. However, creating a job with a large number of instances coming up all at the same time is undesirable due to reasons

Re: Adding shorthands, defaults, and initialization files to the aurora client

Then, if the user ran "`aurora job create`" without any parameters, > it would automatically be expanded to > "`aurora job create west/markcc/test/myservice > ./src/aurora/myservice.aurora`". The power of this feature is a bit worrying. It's very easy to forget what init file defaults to. At the

Re: Handling of aurora update when job/task cannot be scheduled

Thanks for the proposal, Anindya. I do have some concerns about it though: - The task in PENDING state might never get scheduled due to variety of reasons, e.g.: unsatisfied constraints, unreasonable resource requirements and etc. Furthermore, if the task eventually gets scheduled, it may never re

Re: [jira] [Commented] (AURORA-366) ScheduledThreadPoolExecutor in AsyncModule does not log unhandled errors.

/issues.apache.org/jira/browse/AURORA-366 > > Project: Aurora > > Issue Type: Bug > > Components: Scheduler > >Reporter: Maxim Khutornenko > >Assignee: Maxim Khutornenko > >Priority: Critical >

Re: Combining vagrant master machines

+1. Having that many VMs to boot up every time makes me looking for other alternatives. On Tue, Apr 1, 2014 at 8:43 AM, Bill Farner wrote: > Does anybody have an issue with me combining the 'master' components in our > vagrant configuration to one machine? Currently we have three machines: > z

[jira] [Created] (AURORA-130) Add explicit python thrift dependencies into BUILD targets

Maxim Khutornenko created AURORA-130: Summary: Add explicit python thrift dependencies into BUILD targets Key: AURORA-130 URL: https://issues.apache.org/jira/browse/AURORA-130 Project: Aurora

[jira] [Created] (AURORA-94) Refactor/remove SchedulerCore in favor of StateManager

Maxim Khutornenko created AURORA-94: --- Summary: Refactor/remove SchedulerCore in favor of StateManager Key: AURORA-94 URL: https://issues.apache.org/jira/browse/AURORA-94 Project: Aurora

[jira] [Updated] (AURORA-88) get_quota -h lists --cluster as deprecated

[ https://issues.apache.org/jira/browse/AURORA-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Khutornenko updated AURORA-88: Issue Type: Bug (was: Task) > get_quota -h lists --cluster as depreca

[jira] [Created] (AURORA-93) Convert from "shard" to "instance" in aurora client commands

Maxim Khutornenko created AURORA-93: --- Summary: Convert from "shard" to "instance" in aurora client commands Key: AURORA-93 URL: https://issues.apache.org/jira/browse/AURORA-93

[jira] [Created] (AURORA-88) get_quota -h lists --cluster as deprecated

Maxim Khutornenko created AURORA-88: --- Summary: get_quota -h lists --cluster as deprecated Key: AURORA-88 URL: https://issues.apache.org/jira/browse/AURORA-88 Project: Aurora Issue Type

[jira] [Created] (AURORA-82) Introduce a DRAINED task state into the scheduler state machine

Maxim Khutornenko created AURORA-82: --- Summary: Introduce a DRAINED task state into the scheduler state machine Key: AURORA-82 URL: https://issues.apache.org/jira/browse/AURORA-82 Project: Aurora

[jira] [Commented] (AURORA-40) aurora_admin scheduler_print_recovery_tasks is broken

[ https://issues.apache.org/jira/browse/AURORA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13872897#comment-13872897 ] Maxim Khutornenko commented on AURORA-40: - https://reviews.apache.org/r/1

[jira] [Created] (AURORA-40) aurora_admin scheduler_print_recovery_tasks is broken

Maxim Khutornenko created AURORA-40: --- Summary: aurora_admin scheduler_print_recovery_tasks is broken Key: AURORA-40 URL: https://issues.apache.org/jira/browse/AURORA-40 Project: Aurora

[jira] [Resolved] (AURORA-36) Remove scheduler_list_job_updates verb from aurora_admin

[ https://issues.apache.org/jira/browse/AURORA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Khutornenko resolved AURORA-36. - Resolution: Fixed > Remove scheduler_list_job_updates verb from aurora_ad

[jira] [Commented] (AURORA-36) Remove scheduler_list_job_updates verb from aurora_admin

[ https://issues.apache.org/jira/browse/AURORA-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13870124#comment-13870124 ] Maxim Khutornenko commented on AURORA-36: - https://reviews.apache.org/r/1

[jira] [Created] (AURORA-36) Remove scheduler_list_job_updates verb from aurora_admin

Maxim Khutornenko created AURORA-36: --- Summary: Remove scheduler_list_job_updates verb from aurora_admin Key: AURORA-36 URL: https://issues.apache.org/jira/browse/AURORA-36 Project: Aurora

Re: Review Request 16629: Client quota check (server side)

il. To reply, visit: https://reviews.apache.org/r/16629/#review31265 ------- On Jan. 4, 2014, 1:53 a.m., Maxim Khutornenko wrote: > > --- > This is an automati

Re: Review Request 16668: Adding java code coverage reporting into Aurora build.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16668/#review31263 --- Thanks. Submitted. - Maxim Khutornenko On Jan. 6, 2014, 8:33 p.m

Review Request 16668: Adding java code coverage reporting into Aurora build.

oaded/files/2014/01/06/1a11f81b-1535-4c51-a6e4-96ffc9ae5480__Report.tiff Code.tiff https://reviews.apache.org/media/uploaded/files/2014/01/06/2e1da342-9a1d-48b2-9b48-664760af8518__Code.tiff Thanks, Maxim Khutornenko

Re: Review Request 16636: Ensure SchedulerActive event is dispatched before leader is advertised.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16636/#review31242 --- Ship it! Ship It! - Maxim Khutornenko On Jan. 4, 2014, 11:21

Re: Review Request 16444: Client side changes for the client quota check.

5843bb4d3698abc5c4a48ee6eaf2be85e9415a06 src/test/python/apache/aurora/client/commands/test_update.py ccc3ee9d97de4373b05ad2de8d88939510c2f052 Diff: https://reviews.apache.org/r/16444/diff/ Testing --- ./pants src/test/python/twitter/aurora/client:all Thanks, Maxim Khutornenko

Re: Review Request 16629: Client quota check (server side)

/aurora/gen/api.thrift 480b8f472bcfbe547a91c41638250350a0110334 src/test/java/org/apache/aurora/scheduler/thrift/SchedulerThriftInterfaceTest.java 91c1c24448092e1b3454844ab8074ed030383594 Diff: https://reviews.apache.org/r/16629/diff/ Testing --- gradle build Thanks, Maxim Khutornenko

Re: Review Request 16629: Client quota check (server side)

l here? Shouldn't the caller just > > not call in if the provided lock is null? > > Maxim Khutornenko wrote: > This is a convenience method for cases like getQuota() where Lock > presence is optional as it's used in both locked (update, create) and > unlocked (get

Re: Review Request 16629: Client quota check (server side)

l here? Shouldn't the caller just > > not call in if the provided lock is null? > > Maxim Khutornenko wrote: > This is a convenience method for cases like getQuota() where Lock > presence is optional as it's used in both locked (update, create) and > unlocked (get

Re: Review Request 16629: Client quota check (server side)

#file415153line461> > > > > remove extra space Done. - Maxim --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16629/#review31197 ------- On Jan. 4, 2014, 12:03 a.m., Maxim Khutornenko

Review Request 16629: Client quota check (server side)

/diff/ Testing --- gradle build Thanks, Maxim Khutornenko

Re: Review Request 16444: Client side changes for the client quota check.

This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16444/#review31162 --- On Jan. 3, 2014, 9:21 p.m., Maxim Khutornenko wrote: > > ---

Re: Review Request 16444: Client side changes for the client quota check.

ccc3ee9d97de4373b05ad2de8d88939510c2f052 Diff: https://reviews.apache.org/r/16444/diff/ Testing --- ./pants src/test/python/twitter/aurora/client:all Thanks, Maxim Khutornenko

Re: Review Request 16444: Client side changes for the client quota check.

/apache/aurora/client/commands/test_update.py ccc3ee9d97de4373b05ad2de8d88939510c2f052 Diff: https://reviews.apache.org/r/16444/diff/ Testing --- ./pants src/test/python/twitter/aurora/client:all Thanks, Maxim Khutornenko

Re: Review Request 16444: Client side changes for the client quota check.

src/test/python/apache/aurora/client/commands/test_update.py ccc3ee9d97de4373b05ad2de8d88939510c2f052 Diff: https://reviews.apache.org/r/16444/diff/ Testing --- ./pants src/test/python/twitter/aurora/client:all Thanks, Maxim Khutornenko

Re: Review Request 16444: Client side changes for the client quota check.

account for sum() and mocking specifics). src/test/python/apache/aurora/client/api/test_quota_check.py <https://reviews.apache.org/r/16444/#comment59501> Done. - Maxim Khutornenko On Jan. 3, 2014, 1:23 a.m., Maxim Khutornenko wrote: > > ---

Re: Review Request 16444: Client side changes for the client quota check.

src/test/python/apache/aurora/client/commands/test_update.py ccc3ee9d97de4373b05ad2de8d88939510c2f052 Diff: https://reviews.apache.org/r/16444/diff/ Testing --- ./pants src/test/python/twitter/aurora/client:all Thanks, Maxim Khutornenko

  1   2   >