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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > Thank you! > > On Thu, Dec 3, 2015 at 1:40 PM, Vinod Kone <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > > > >
