aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Khutornenko <>
Subject Re: Golang Aurora lib, multiple executor support, integrate mesos task related fields
Date Mon, 13 Jun 2016 17:09:50 GMT
David pinged me offline suggesting I misread the proposal for (2) as
an attempt to support multiple executors per task rather than "per
cluster". If that's the case, I am happy to change my vote for (2) to
+1. I don't see much harm (aside from possible UI inconsistencies)
from multiple executor types sharing the same cluster.

On Mon, Jun 13, 2016 at 9:54 AM,  <> wrote:
> I will leave Renan for a detailed response.
> If aurora can schedule Job A with thermos and Job B that requires a different executor
that is a first class concept in mesos, why is there a objection? Renan's patch of replacing
thermos executor is already in aurora. However right now aurora can statically configure only
one executor. And so we want a job submission dynamically can call out the executor type.
> Please clarify your views.
> Right now the docker integration story in mesos is weak (current and also the new universal
containerizer). We see much value in using executors like
> With aurora jobs.
> Points 2 and points 3 make the custom executor story stronger. (For example we will run
both thermos and compose executor depending on job type)
> Point 1, I agree. That is outside of aurora and most likely will be a shim on top of
generated go thrift bindings but a helper to easily test custom executors.
> Last time when we reviewed with aurora team, it came out current aurora cli is tightly
coupled with thermos objects for jobs and hence keep it as is.
> Thx
> Sent from my iPhone
>> On Jun 13, 2016, at 9:19 AM, Maxim Khutornenko <> wrote:
>> I am with Rick and David on this. The (1) and (2) feel like building a
>> parallel universe within Aurora without a clear justification on the
>> long-term benefits for the community.
>> I am strong -1 on bringing yet another language into the Aurora
>> ecosystem without identifying the strategic upside. As David
>> suggested, any efforts towards building the first-class REST API
>> instead would go a long way and will be much appreciated by everyone.
>> I also don't see a reason to support multiple executors per task. That
>> feels like re-creating thermos in a thermos-less world.
>> As for (3), I'd like to see more details on the mechanics here but
>> generally positive towards supporting more TaskInfo features in
>> Aurora.
>>> On Sun, Jun 12, 2016 at 11:46 AM,  <> wrote:
>>> 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 <>
>>>> Hi David,
>>>> On Fri, Jun 10, 2016 at 12:33 AM, David McLaughlin <>
>>>> wrote:
>>>>> On Thu, Jun 9, 2016 at 5:44 PM, meghdoot bhattacharya <
>>>>>> wrote:
>>>>>> Comments inline
>>>>>>     From: David McLaughlin <>
>>>>>> To:
>>>>>> Sent: Thursday, June 9, 2016 5:13 PM
>>>>>> Subject: Re: Golang Aurora lib, multiple executor support, integrate
>>>>>> mesos task related fields
>>>>>> On Thu, Jun 9, 2016 at 2:21 PM, Renan DelValle <>
>>>>>> wrote:
>>>>>>> Hello all,
>>>>>>> I'd like to (re-)introduce myself. My name's Renan DelValle and
>>>>> had
>>>>>>> the pleasure of being part of the Aurora community for the last
year or
>>>>>> so.
>>>>>>> Last year I worked to allow Aurora to utilize custom executors.
>>>>> the
>>>>>>> help from Bill Farner, Kevin Sweeney, and Joshua Cohen, that
>>>>>> became
>>>>>>> a reality and made into Aurora late last year. (Also got to show
>>>>> early
>>>>>>> beta at MesosCon!)
>>>>>>> For this year's summer, I have some new goals which I invite
anyone to
>>>>>>> provide input on.
>>>>>>> 1. Create a Golang library that works as an alternative to Aurora's
>>>>>> Python
>>>>>>> client and Pystachio. The initial goal of this library is to
>>>>> the
>>>>>>> most critical job related Thrift API's. (Admin operations can
>>>>> to
>>>>>>> be done from the Aurora CLI). Since we support custom executors,
>>>>> need
>>>>>> a
>>>>>>> way that's not so tied to thermos (as Pystachio is) to send jobs
>>>>>>> configurations to Aurora (and by extension the custom executor).
>>>>>> You can easily add support for a different configuration format without
>>>>>> having to rewrite the CLI in Go. You'd do that by adding your own
>>>>>> noun/verbs to the client or replacing existing commands. For example,
>>>>>> Twitter we have our own version of 'aurora update start' that plugs
>>>>> an
>>>>>> internal Deploy Orchestration Service and we have a whole other command
>>>>> for
>>>>>> federated deploys. I can show you how we do that.
>>>>>> The first thing I thought of though was - this seems like a perfect
>>>>>> starting point to get serious about a HTTP+JSON API for Aurora. Having
>>>>> that
>>>>>> would make it trivial to do a CLI in any language you want, and the
>>>>> Python
>>>>>> CLI would really only be there to do Pystachio evaluation.
>>>>>>>> CLI integrations is not useful for a lot of different reasons.
We need
>>>>>> API's from other orchestration points from different components and
>>>>>> we would package it in a go library. Uber, I believe has taken the
>>>>>> route (info from this mesoscon)
>>>>>> We are not writing a replacement cli tool. As noted admin operations
>>>>> would
>>>>>> heavily leverage current aurora cli.
>>>>>> I think REST work has been postponed and attempted few times in past.
>>>>>> cannot wait for that.
>>>>> This is the dev list for contributions to the project, so I assumed we
>>>>> discussing adding a Go CLI to Apache Aurora. Our API is Thrift and Thrift
>>>>> has Go bindings so you're all set for whatever custom tooling you're
>>>>> building. Please use the users list for feedback on that.
>>>> While I'm very thankful for your input on the matter, my original text very
>>>> clearly said:
>>>> "1. Create a Golang library that works as an *alternative* to
>>>> Aurora's Python client and Pystachio."
>>>> I believe every single item I have listed has the potential to become a
>>>> useful contribution to this project.
>>>> Therefore, I feel that it is prudent continue the discussion here (unless
>>>> others feel similarly).
>>>> -Renan
>>>>>>> 2. Create support for using multiple executors within a single
>>>>>>> scheduler instance. As of right now, only a single executor can
>>>>> for
>>>>>>> each Aurora scheduler instance. The idea is to allow the Aurora
>>>>> scheduler
>>>>>>> to support multiple executors such that they can be used alongside
>>>>>>> another, providing flexibility for running jobs.
>>>>>> Just for my own understanding - what problems are you solving with
>>>>>> custom executor? Sorry if you've explained this to the lists before.
>>>>>> I ask because I'd really like to see Aurora stop treating the executor
>>>>>> config as an opaque blob and being more opinionated. The
>>>>> Thermos/Scheduler
>>>>>> abstraction really hinders what type of user experience (UI) we can
>>>>> build,
>>>>>> and other frameworks do a much better job by being more opinionated
>>>>>> pulling executor data into the scheduler UI.
>>>>>>>> We probably don't need to debate on this point. Executor
is a first
>>>>>> class mesos citizen and time is right for aurora to have good support
>>>>>> it.In our case, we have kubernetes like pods modeled through
>>>>> docker-compose
>>>>>> and the executor manages that. Scheduler UI main features should
not get
>>>>>> bogged down or be held back for a particular executor. That feels
>>>>>> incredibly restrictive. If a special UI mode for thermos executor
>>>>>> created, that should be fine. We do have to differentiate the scheduler
>>>>> and
>>>>>> thermos and aurora team has done a great job of not hard coupling
>>>>> two.
>>>>>>> 3. I'd like to add support for some first class Mesos task related
>>>>>> fields.
>>>>>>> These would be optional and/or have defaults so that the regular
>>>>>> CLI
>>>>>>> does not break. One of the examples I'm interested in integrating
>>>>> the
>>>>>>> Mesos Fetcher so that resources can be downloaded into the sandbox
>>>>>> the
>>>>>>> custom executor may need. (The executor path will never be exposed
>>>>>> this
>>>>>>> will be defined serverside and be static).
>>>>>> Wouldn't the mesos-fetcher call just be another process to be passed
>>>>>> your executor? I have to admit I don't know enough about how the
>>>>>> fetcher works.
>>>>>>>> Apache Mesos - Fetcher
>>>>>> We may add other first class fields.
>>>>>>> If anyone has any feedback on these, I'd be very glad to hear
>>>>>>> That's it for me for now, thanks!
>>>>>>> -Renan
>>>>>> |
>>>>>> |
>>>>>> |
>>>>>> |   |    |
>>>>>>  |
>>>>>> |
>>>>>> |
>>>>>> |   |
>>>>>> Apache Mesos - Fetcher
>>>>>>  |   |
>>>>>> |
>>>>>> |

View raw message