aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Khutornenko <ma...@apache.org>
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,  <meghdoot_b@yahoo.com.invalid> 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
> https://github.com/mesos/docker-compose-executor
> 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 <maxim@apache.org> 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,  <rick@chartbeat.com> 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 <rdelval1@binghamton.edu>
wrote:
>>>>
>>>> Hi David,
>>>>
>>>> On Fri, Jun 10, 2016 at 12:33 AM, David McLaughlin <david@dmclaughlin.com>
>>>> wrote:
>>>>
>>>>> On Thu, Jun 9, 2016 at 5:44 PM, meghdoot bhattacharya <
>>>>> meghdoot_b@yahoo.com.invalid> wrote:
>>>>>
>>>>>> Comments inline
>>>>>>
>>>>>>     From: David McLaughlin <dmclaughlin@apache.org>
>>>>>> To: dev@aurora.apache.org
>>>>>> 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 <rdelval1@binghamton.edu>
>>>>>> 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.
With
>>>>> the
>>>>>>> help from Bill Farner, Kevin Sweeney, and Joshua Cohen, that
feature
>>>>>> 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 Aurora's
>>>>>> 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,
we
>>>>> 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
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 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
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 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
Aurora
>>>>>>> scheduler instance. As of right now, only a single executor can
exist
>>>>> for
>>>>>>> each Aurora scheduler instance. The idea is to allow the Aurora
>>>>> 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 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
and
>>>>>> 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
is
>>>>>> 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
the
>>>>> 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
Aurora
>>>>>> CLI
>>>>>>> does not break. One of the examples I'm interested in integrating
is
>>>>> 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
>>>>>>  |   |
>>>>>>
>>>>>> |
>>>>>>
>>>>>> |
>>>>>

Mime
View raw message