You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by John Omernik <jo...@omernik.com> on 2015/12/03 20:34:49 UTC
Native Lib vs. Rest API
Somewhere in the back of my brain I thought I read something about a
migration away from using the mesos native lib and going to a more generic
API approach to support better portability and less reliance on the lib.
I read about this before I understood things well (or as well I do now I
should say). Am I misremembering reading about this? I can't find any
stories/documentation on this. If I am correct on this, can someone point
me to a JIRA or a discussion on how this is supposed to work? I.e. is the
goal to migrate all frameworks off the native library to deprecate it etc?
Thanks, sorry for the weird questions.
John
Re: Native Lib vs. Rest API
Posted by Anand Mazumdar <an...@mesosphere.io>.
One minor clarification:
> * AuthN support for HTTP API: https://issues.apache.org/jira/browse/MESOS-3923 <https://issues.apache.org/jira/browse/MESOS-3923>
> ** Required in order to be able to use persistent volumes or dynamic reservations (added in 0.25.0)
You should be able to use persistent volumes/dynamic reservations via the HTTP Scheduler API with AuthN disabled on the master <http://mesos.apache.org/documentation/latest/configuration/> (via —no-authenticate flag ).
-anand
> On Dec 3, 2015, at 5:05 PM, Ben Whitehead <be...@mesosphere.io> wrote:
>
> There is an example framework in the repo that creates some `sleep` tasks based on resource offers.
>
> Regarding status there are still a number of items that require implementation from mesos before they can be supported by mesos-rxjava.
>
> * AuthN support for HTTP API: https://issues.apache.org/jira/browse/MESOS-3923 <https://issues.apache.org/jira/browse/MESOS-3923>
> ** Required in order to be able to use persistent volumes or dynamic reservations (added in 0.25.0)
> * Master Redirection: https://issues.apache.org/jira/browse/MESOS-3832 <https://issues.apache.org/jira/browse/MESOS-3832>
>
> Custom Executors still require the use of libmesos.
>
> The full set of JIRA issues for the HTTP APIs can be seen here: https://issues.apache.org/jira/browse/MESOS-3302 <https://issues.apache.org/jira/browse/MESOS-3302>
>
> Regarding functionality, due to the new design of the Mesos HTTP API some things that libmesos took care of for the user before now have to be taken care of by the user. For example, reconnecting to the master if the connection is lost. Users have to ACK task status updates that have a specified UUID. One thing that only exists in the new HTTP API is the idea of inverse offers (https://issues.apache.org/jira/browse/MESOS-1474 <https://issues.apache.org/jira/browse/MESOS-1474>) to facilitate maintenance on mesos agents.
>
> I also don't yet have a jar published to maven central or sonatype (snapshot hopefully in the next week or so).
>
> The other change that isn't really about functionality is the paradigm change. The new HTTP APIs are modeled as an event stream rather than actor messages (translated to callbacks in the current libmesos api).
>
> Hope this answers your question.
>
> --Ben Whitehead
>
> On Thu, Dec 3, 2015 at 3:37 PM, Charles Allen <charles.allen@metamarkets.com <ma...@metamarkets.com>> wrote:
> @Ben : Is the status of the mesos-rxjava MORE or LESS functional than the legacy mesos .jar with the native library?
>
> On Thu, Dec 3, 2015 at 12:05 PM Ben Whitehead <ben.whitehead@mesosphere.io <ma...@mesosphere.io>> wrote:
> Hi John,
>
> If you're using Java there is already a prototype client atop the new Scheduler HTTP API using RxJava: https://github.com/mesosphere/mesos-rxjava <https://github.com/mesosphere/mesos-rxjava> Happy to provide more info if interested.
>
> --Ben Whitehead
>
> On Thu, Dec 3, 2015 at 11:52 AM, John Omernik <john@omernik.com <ma...@omernik.com>> wrote:
> Thank you!
>
> On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <vinodkone@apache.org <ma...@apache.org>> wrote:
> Yes, that's the plan.
>
> Here are the related epics tracking the work: MESOS-2288 <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302 <https://issues.apache.org/jira/browse/MESOS-3302>
>
> The user doc for the scheduler API is https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md <https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md>
>
> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <john@omernik.com <ma...@omernik.com>> wrote:
> Somewhere in the back of my brain I thought I read something about a migration away from using the mesos native lib and going to a more generic API approach to support better portability and less reliance on the lib.
>
> I read about this before I understood things well (or as well I do now I should say). Am I misremembering reading about this? I can't find any stories/documentation on this. If I am correct on this, can someone point me to a JIRA or a discussion on how this is supposed to work? I.e. is the goal to migrate all frameworks off the native library to deprecate it etc?
>
> Thanks, sorry for the weird questions.
>
> John
>
>
>
>
Re: Native Lib vs. Rest API
Posted by Ben Whitehead <be...@mesosphere.io>.
There is an example framework in the repo that creates some `sleep` tasks
based on resource offers.
Regarding status there are still a number of items that require
implementation from mesos before they can be supported by mesos-rxjava.
* AuthN support for HTTP API:
https://issues.apache.org/jira/browse/MESOS-3923
** Required in order to be able to use persistent volumes or dynamic
reservations (added in 0.25.0)
* Master Redirection: https://issues.apache.org/jira/browse/MESOS-3832
Custom Executors still require the use of libmesos.
The full set of JIRA issues for the HTTP APIs can be seen here:
https://issues.apache.org/jira/browse/MESOS-3302
Regarding functionality, due to the new design of the Mesos HTTP API some
things that libmesos took care of for the user before now have to be taken
care of by the user. For example, reconnecting to the master if the
connection is lost. Users have to ACK task status updates that have a
specified UUID. One thing that only exists in the new HTTP API is the idea
of inverse offers (https://issues.apache.org/jira/browse/MESOS-1474) to
facilitate maintenance on mesos agents.
I also don't yet have a jar published to maven central or sonatype
(snapshot hopefully in the next week or so).
The other change that isn't really about functionality is the paradigm
change. The new HTTP APIs are modeled as an event stream rather than actor
messages (translated to callbacks in the current libmesos api).
Hope this answers your question.
--Ben Whitehead
On Thu, Dec 3, 2015 at 3:37 PM, Charles Allen <charles.allen@metamarkets.com
> wrote:
> @Ben : Is the status of the mesos-rxjava MORE or LESS functional than the
> legacy mesos .jar with the native library?
>
> On Thu, Dec 3, 2015 at 12:05 PM Ben Whitehead <be...@mesosphere.io>
> wrote:
>
>> Hi John,
>>
>> If you're using Java there is already a prototype client atop the new
>> Scheduler HTTP API using RxJava:
>> https://github.com/mesosphere/mesos-rxjava Happy to provide more info if
>> interested.
>>
>> --Ben Whitehead
>>
>> On Thu, Dec 3, 2015 at 11:52 AM, John Omernik <jo...@omernik.com> wrote:
>>
>>> Thank you!
>>>
>>> On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <vi...@apache.org> wrote:
>>>
>>>> Yes, that's the plan.
>>>>
>>>> Here are the related epics tracking the work: MESOS-2288
>>>> <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302
>>>> <https://issues.apache.org/jira/browse/MESOS-3302>
>>>>
>>>> The user doc for the scheduler API is
>>>> https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md
>>>>
>>>> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <jo...@omernik.com> wrote:
>>>>
>>>>> Somewhere in the back of my brain I thought I read something about a
>>>>> migration away from using the mesos native lib and going to a more generic
>>>>> API approach to support better portability and less reliance on the lib.
>>>>>
>>>>> I read about this before I understood things well (or as well I do now
>>>>> I should say). Am I misremembering reading about this? I can't find any
>>>>> stories/documentation on this. If I am correct on this, can someone point
>>>>> me to a JIRA or a discussion on how this is supposed to work? I.e. is the
>>>>> goal to migrate all frameworks off the native library to deprecate it etc?
>>>>>
>>>>> Thanks, sorry for the weird questions.
>>>>>
>>>>> John
>>>>>
>>>>
>>>>
>>>
>>
Re: Native Lib vs. Rest API
Posted by Charles Allen <ch...@metamarkets.com>.
@Ben : Is the status of the mesos-rxjava MORE or LESS functional than the
legacy mesos .jar with the native library?
On Thu, Dec 3, 2015 at 12:05 PM Ben Whitehead <be...@mesosphere.io>
wrote:
> Hi John,
>
> If you're using Java there is already a prototype client atop the new
> Scheduler HTTP API using RxJava:
> https://github.com/mesosphere/mesos-rxjava Happy to provide more info if
> interested.
>
> --Ben Whitehead
>
> On Thu, Dec 3, 2015 at 11:52 AM, John Omernik <jo...@omernik.com> wrote:
>
>> Thank you!
>>
>> On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <vi...@apache.org> wrote:
>>
>>> Yes, that's the plan.
>>>
>>> Here are the related epics tracking the work: MESOS-2288
>>> <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302
>>> <https://issues.apache.org/jira/browse/MESOS-3302>
>>>
>>> The user doc for the scheduler API is
>>> https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md
>>>
>>> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <jo...@omernik.com> wrote:
>>>
>>>> Somewhere in the back of my brain I thought I read something about a
>>>> migration away from using the mesos native lib and going to a more generic
>>>> API approach to support better portability and less reliance on the lib.
>>>>
>>>> I read about this before I understood things well (or as well I do now
>>>> I should say). Am I misremembering reading about this? I can't find any
>>>> stories/documentation on this. If I am correct on this, can someone point
>>>> me to a JIRA or a discussion on how this is supposed to work? I.e. is the
>>>> goal to migrate all frameworks off the native library to deprecate it etc?
>>>>
>>>> Thanks, sorry for the weird questions.
>>>>
>>>> John
>>>>
>>>
>>>
>>
>
Re: Native Lib vs. Rest API
Posted by Ben Whitehead <be...@mesosphere.io>.
Hi John,
If you're using Java there is already a prototype client atop the new
Scheduler HTTP API using RxJava: https://github.com/mesosphere/mesos-rxjava
Happy to provide more info if interested.
--Ben Whitehead
On Thu, Dec 3, 2015 at 11:52 AM, John Omernik <jo...@omernik.com> wrote:
> Thank you!
>
> On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <vi...@apache.org> wrote:
>
>> Yes, that's the plan.
>>
>> Here are the related epics tracking the work: MESOS-2288
>> <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302
>> <https://issues.apache.org/jira/browse/MESOS-3302>
>>
>> The user doc for the scheduler API is
>> https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md
>>
>> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <jo...@omernik.com> wrote:
>>
>>> Somewhere in the back of my brain I thought I read something about a
>>> migration away from using the mesos native lib and going to a more generic
>>> API approach to support better portability and less reliance on the lib.
>>>
>>> I read about this before I understood things well (or as well I do now I
>>> should say). Am I misremembering reading about this? I can't find any
>>> stories/documentation on this. If I am correct on this, can someone point
>>> me to a JIRA or a discussion on how this is supposed to work? I.e. is the
>>> goal to migrate all frameworks off the native library to deprecate it etc?
>>>
>>> Thanks, sorry for the weird questions.
>>>
>>> John
>>>
>>
>>
>
Re: Native Lib vs. Rest API
Posted by John Omernik <jo...@omernik.com>.
Thank you!
On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <vi...@apache.org> wrote:
> Yes, that's the plan.
>
> Here are the related epics tracking the work: MESOS-2288
> <https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302
> <https://issues.apache.org/jira/browse/MESOS-3302>
>
> The user doc for the scheduler API is
> https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md
>
> On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <jo...@omernik.com> wrote:
>
>> Somewhere in the back of my brain I thought I read something about a
>> migration away from using the mesos native lib and going to a more generic
>> API approach to support better portability and less reliance on the lib.
>>
>> I read about this before I understood things well (or as well I do now I
>> should say). Am I misremembering reading about this? I can't find any
>> stories/documentation on this. If I am correct on this, can someone point
>> me to a JIRA or a discussion on how this is supposed to work? I.e. is the
>> goal to migrate all frameworks off the native library to deprecate it etc?
>>
>> Thanks, sorry for the weird questions.
>>
>> John
>>
>
>
Re: Native Lib vs. Rest API
Posted by Vinod Kone <vi...@apache.org>.
Yes, that's the plan.
Here are the related epics tracking the work: MESOS-2288
<https://issues.apache.org/jira/browse/MESOS-2288> and MESOS-3302
<https://issues.apache.org/jira/browse/MESOS-3302>
The user doc for the scheduler API is
https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md
On Thu, Dec 3, 2015 at 11:34 AM, John Omernik <jo...@omernik.com> wrote:
> Somewhere in the back of my brain I thought I read something about a
> migration away from using the mesos native lib and going to a more generic
> API approach to support better portability and less reliance on the lib.
>
> I read about this before I understood things well (or as well I do now I
> should say). Am I misremembering reading about this? I can't find any
> stories/documentation on this. If I am correct on this, can someone point
> me to a JIRA or a discussion on how this is supposed to work? I.e. is the
> goal to migrate all frameworks off the native library to deprecate it etc?
>
> Thanks, sorry for the weird questions.
>
> John
>