aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Golang Aurora lib, multiple executor support, integrate mesos task related fields
Date Mon, 13 Jun 2016 17:33:03 GMT
Got it. Thx Max.
Renan will starting working on 2 and 3, involving and updating you all.


Sent from my iPhone

> On Jun 13, 2016, at 10:09 AM, Maxim Khutornenko <> wrote:
> 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 I've
>>>>>> 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 an
>>>>>> 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
>>>>>>> Python
>>>>>>>> client and Pystachio. The initial goal of this library is
to support
>>>>>> the
>>>>>>>> most critical job related Thrift API's. (Admin operations
can continue
>>>>>> 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
>>>>>>>> configurations to Aurora (and by extension the custom executor).
>>>>>>> You can easily add support for a different configuration format
>>>>>>> having to rewrite the CLI in Go. You'd do that by adding your
own custom
>>>>>>> noun/verbs to the client or replacing existing commands. For
example, at
>>>>>>> Twitter we have our own version of 'aurora update start' that
plugs into
>>>>>> an
>>>>>>> internal Deploy Orchestration Service and we have a whole other
>>>>>> 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.
>>>>>> that
>>>>>>> would make it trivial to do a CLI in any language you want, and
>>>>>> 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 hence
>>>>>>> we would package it in a go library. Uber, I believe has taken
the same
>>>>>>> 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. We
>>>>>>> cannot wait for that.
>>>>>> This is the dev list for contributions to the project, so I assumed
we were
>>>>>> discussing adding a Go CLI to Apache Aurora. Our API is Thrift and
>>>>>> 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
>>>>> 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
>>>>> 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 exist
>>>>>> for
>>>>>>>> each Aurora scheduler instance. The idea is to allow the
>>>>>> scheduler
>>>>>>>> to support multiple executors such that they can be used
alongside one
>>>>>>>> another, providing flexibility for running jobs.
>>>>>>> Just for my own understanding - what problems are you solving
with your
>>>>>>> custom executor? Sorry if you've explained this to the lists
>>>>>>> I ask because I'd really like to see Aurora stop treating the
>>>>>>> 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 for
>>>>>>> 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
>>>>>> 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
>>>>>>> fields.
>>>>>>>> These would be optional and/or have defaults so that the
regular Aurora
>>>>>>> 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 that
>>>>>>> the
>>>>>>>> custom executor may need. (The executor path will never be
exposed as
>>>>>>> this
>>>>>>>> will be defined serverside and be static).
>>>>>>> Wouldn't the mesos-fetcher call just be another process to be
passed to
>>>>>>> your executor? I have to admit I don't know enough about how
the Mesos
>>>>>>> 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 it.
>>>>>>>> That's it for me for now, thanks!
>>>>>>>> -Renan
>>>>>>> |
>>>>>>> |
>>>>>>> |
>>>>>>> |   |    |
>>>>>>> |
>>>>>>> |
>>>>>>> |
>>>>>>> |   |
>>>>>>> Apache Mesos - Fetcher
>>>>>>> |   |
>>>>>>> |
>>>>>>> |

View raw message