If we keep the current C++ scheduler API as it is, then I think framework
can never receive inverse offer in its "resourceOffers()" callback, the
reason is, In SchedulerProcess::initialize(), we have the following code:
install<ResourceOffersMessage>(
&SchedulerProcess::resourceOffers,
&ResourceOffersMessage::offers,
&ResourceOffersMessage::pids);
In the above code, only "offers" and "pids" fields of ResourceOffersMessage
are passed into SchedulerProcess::resourceOffers() when it is invoked, but
the "inverse_offers" field of ResourceOffersMessage is NOT passed into it.
Regards,
Qian Zhang （张乾）
Developer, IBM Platform Computing
Phone: 86-29-68797144 | Tie-Line: 87144
IBM
E-mail: [email protected]
Chat: zhq527725 陕西省西安市高新区
高新六路42号中清大
厦3层
“An educated man should know everything about Xian,
Shaanxi
something and something about everything" Province
710075
China
From: Guangya Liu <[email protected]>
To: [email protected]
Date: 09/14/2015 23:29
Subject: Re: Do we still need to add InverseOffer support to Scheduler
API?
Thanks Haosdent and Joris, I see that the host maintain patch (
https://reviews.apache.org/r/37180/diff/8#0) is also sending
"ResourceOffersMessage" to framework so the framework can still use
"ResourceOffer" to handle the inverseOffer when framework got the
inverseOffer, right?
Thanks,
Guangya
On Mon, Sep 14, 2015 at 11:15 PM, haosdent <[email protected]> wrote:
> Hi @Guangya Liu. V1 API support both mesos call frameworks or frameworks
> call mesos.
>
>
>
https://docs.google.com/document/d/1pnIY_HckimKNvpqhKRhbc9eSItWNFT-priXh_urR-T0/edit
>
> And I think Java or Python API libraries would be deprecated and more out
> to a better place to maintain in the future(Also maybe support more
> languages through V1 API). Continue to add them to old APIs may be not a
> good choice.
>
> On Mon, Sep 14, 2015 at 11:02 PM, Guangya Liu <[email protected]> wrote:
>
> > Hi Joris,
> >
> > I think that those APIs are still needed as HTTP API is mainly
initiated
> by
> > operator, the current call for HTTP API including TEARDOWN, ACCEPT,
> > DECLINE, REVIVE, KILL, SHUTDOWN etc, but the offer related operations
> such
> > as offer and InverserOffers are initiatedby mesos master, the master
need
> > notify the framework for those offers via the callbacks. Comments?
> >
> > Thanks,
> >
> > Guangya
> >
> > On Mon, Sep 14, 2015 at 10:42 PM, Joris Van Remoortere <
> > [email protected]>
> > wrote:
> >
> > > Hi Qian,
> > >
> > > There is no current plan to add this to the old API. Those tickets
were
> > > created pre-V1 API.
> > > Currently the goal is to encourage developers to use the V1 API to
have
> > > access to new features such as maintenance primitives.
> > >
> > > Joris
> > >
> > > On Mon, Sep 14, 2015 at 10:22 AM, Qian AZ Zhang <[email protected]>
> > > wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > In the maintenance epic (MESOS-1474), I see there are 3 tasks
created
> > to
> > > > add InverseOffer support to Scheduler API:
> > > > MESOS-2063 Add InverseOffer to C++ Scheduler API
> > > > MESOS-2064 Add InverseOffer to Java Scheduler API
> > > > MESOS-2065 Add InverseOffer to Python Scheduler API
> > > >
> > > > I think we have already supported Schedule HTTP API, so do we still
> > need
> > > to
> > > > update the C++ scheduler API (and the Java/Python binding) to
support
> > > > InverseOffer? If so, I think we may need to update all the example
> > > > frameworks as well. Take C++ scheduler API as an example, we may
need
> > to
> > > > add a new callback inverseResourceOffers() in the Scheduler class,
> and
> > > each
> > > > example framework's scheduler needs to implement it.
> > > >
> > > >
> > > > Regards,
> > > > Qian Zhang
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
