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

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 passe

Re: [VOTE] Move Aurora to Apache Attic

+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

Re: [NOTICE] PMC Chair change

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 > > > -- [image: chartbeat-gmail-...@2x.png] Rick Mangi Senior Director of Data Engineering Chartbeat 917.848.3619 | @rmangi | r...@chartbeat.com 826 Broadway, 6th Fl., New York, NY 10003

Re: Python 2 is being sunset on January, 2020

We at Chartbeat are fine with the move to python 3. > On Sep 13, 2019, at 9:40 PM, Renan DelValle wrote: > > Folks, > > Please chime in as we need feedback from the community to figure out a path > forward. > > If there is no feedback received by the end of next week the plan will be > to

Re: New PMC member: Mauricio Garavaglia

Awesome! > On Jul 24, 2019, at 4:26 PM, Stephan Erb wrote: > > Welcome :) We are glad to have you on board! > > On 24.07.19, 21:17, "Renan DelValle" wrote: > >All, > >It is my pleasure to announce that Mauricio Garavaglia has agreed to join >the Aurora PMC. His membership

Re: Status and Health of the Aurora Project

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

Re: [DISCUSS] State of the Community

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

Re: Sunsetting official binary package for Ubuntu 14.04 after Aurora 0.21.0

We still have some trusty servers out there, so I’d say no :) > On Apr 10, 2018, at 3:40 PM, Renan DelValle wrote: > > 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

Re: schedule task instances spreading them based on a host attribute.

this a non problem. > > I understand the push for job anti-affinity (ie don't put too many kafka > workers in general on one host), but I would imagine it would be for > reliability reasons not for performance reasons. > > On Thu, Mar 30, 2017 at 12:16 PM, Rick Mangi

Re: schedule task instances spreading them based on a host attribute.

ity reasons not for performance reasons. > > On Thu, Mar 30, 2017 at 12:16 PM, Rick Mangi <r...@chartbeat.com> wrote: > >> Performance and utilization mostly. The kafka consumers are CPU bound (and >> sometimes network) and the rest of our jobs are mostly memory bound.

Re: schedule task instances spreading them based on a host attribute.

is pretty strong. > On Mar 30, 2017, at 2:35 PM, Zameer Manji <zma...@apache.org> wrote: > > Rick, > > Can you share why it would be nice to spread out these different jobs on > different hosts? Is it for reliability, performance, utilization, etc? > > On Thu, Mar 30, 2

Re: schedule task instances spreading them based on a host attribute.

t; Out of curiosity do your Kafka consumers span multiple jobs? Otherwise host > constraints solve that problem right? > >> On Mar 30, 2017, at 10:34 AM, Rick Mangi <r...@chartbeat.com> wrote: >> >> I think the complexity is a great rationale for having a pluggable >>

Re: schedule task instances spreading them based on a host attribute.

ed - that decision will > basically be permanent until the host you're on goes down. At least with > how things work now, with each scheduling attempt the job has a fresh > chance of being put in an ideal slot. > > On Thu, Mar 30, 2017 at 8:12 AM, Rick Mangi <r...@chartbeat

Re: schedule task instances spreading them based on a host attribute.

the number of kafka consumers running on the same physical box. Best, Rick On 2017-03-06 14:44 (-0400), Mauricio Garavaglia <m...@gmail.com> wrote: > Hello!> > > I have a job that have multiple instances (>100) that'd I like to spread> > across the hosts in a

Re: [DRAFT][REPORT] Apache Aurora - September 2016

Hey all, Is there a link to a list of jira tickets to be included? I couldn’t find it browsing around. Sorry if this is a silly question. Best, Rick > On Sep 6, 2016, at 2:52 PM, Jake Farrell <jfarr...@apache.org> wrote: > > Please take a second to review the draft boa

Re: Golang Aurora lib, multiple executor support, integrate mesos task related fields

I generally shy away from technical goals that are based on a choice of language. What is it about a go client that can't be done by extending the existing client? > On Jun 12, 2016, at 2:00 PM, Renan DelValle wrote: > > Hi David, > > On Fri, Jun 10, 2016 at 12:33