You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Varun Gupta <va...@uber.com> on 2018/05/02 17:31:45 UTC
Add hostname or agentid in rescind offers callback
Hi,
Currently in our implementation we maintain two maps.
Hostname -> []Offers
offerID -> Hostname
Second map is needed because rescind offers callback only provides offerid
and we need hostname to do performant lookup in first map.
Is it feasible to add hostname or agentid in rescind offers?
Thanks,
Varun
Re: Add hostname or agentid in rescind offers callback
Posted by Benjamin Mahler <bm...@apache.org>.
No, it doesn't sound reasonable to me given the provided reasoning.
On Sun, May 6, 2018 at 11:54 PM Varun Gupta <va...@uber.com> wrote:
> Does the feature request seems reasonable?
> On Wed, May 2, 2018 at 7:35 PM Varun Gupta <va...@uber.com> wrote:
>
> > Implementation is only needed for V1 API.
> > On Wed, May 2, 2018 at 7:31 PM Varun Gupta <va...@uber.com> wrote:
> >
> >> We aggregate all the offers for a host, such that placement engine can
> >> pack multiple tasks that can be launched on this host using aggregated
> >> resources. If offers are unused for that host then they will be
> implicitly
> >> declined.
> >>
> >> Placement cycle has two components
> >> - determine tasks that can be launched on this host and enque those
> tasks
> >> to be launched.
> >> - second is to deque and launch them.
> >>
> >> During this placement cycle, offers can be rescinded and accordingly
> >> placement has to be adjusted. For that we maintain second map of offer
> id
> >> -> host name.
> >>
> >> Benefits of adding host name and agent id in rescind offer callback.
> >> - Mutex locks to synchronize both maps, leads to some performance hit.
> >> - Managing second map, is more code and prone to bugs.
> >> - Little overhead on heap memory and GC.
> >> On Wed, May 2, 2018 at 5:08 PM Benjamin Mahler <bm...@apache.org>
> >> wrote:
> >>
> >>> I'm a -1 on adding redundant information in the message.
> >>>
> >>> The scheduler can maintain an index of offers by offer id to address
> this
> >>> issue:
> >>>
> >>> hostname -> offers
> >>> offer_id -> offer
> >>>
> >>> On Wed, May 2, 2018 at 11:39 AM, Vinod Kone <vi...@apache.org>
> >>> wrote:
> >>>
> >>> > Can I ask why you are indexing the offers by hostname? Is it to
> better
> >>> > handle agent removal / unreachable signal?
> >>> >
> >>> > Looking at the code
> >>> > <
> >>>
> https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036
> >>> >
> >>> > ,
> >>> > I think master has the requested information (agent id, hostname) so
> >>> we can
> >>> > include it in the rescind message!
> >>> >
> >>> > But there are couple things to discuss.
> >>> >
> >>> > The extra information to be included in rescind message is
> technically
> >>> > redundant. So we need to figure out a guideline on what information
> >>> should
> >>> > be included / not included (e.g., should we include agent IP too) in
> >>> such
> >>> > calls.
> >>> >
> >>> > Second, adding this extra information in v1 scheduler API would be
> >>> > relatively easy. But adding this to v0 API would be hard. Which API
> do
> >>> you
> >>> > need to be updated?
> >>> >
> >>> >
> >>> > On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com>
> wrote:
> >>> >
> >>> > > Hi,
> >>> > >
> >>> > > Currently in our implementation we maintain two maps.
> >>> > >
> >>> > > Hostname -> []Offers
> >>> > >
> >>> > > offerID -> Hostname
> >>> > >
> >>> > > Second map is needed because rescind offers callback only provides
> >>> > offerid
> >>> > > and we need hostname to do performant lookup in first map.
> >>> > >
> >>> > > Is it feasible to add hostname or agentid in rescind offers?
> >>> > >
> >>> > > Thanks,
> >>> > > Varun
> >>> > >
> >>> >
> >>>
> >>
>
Re: Add hostname or agentid in rescind offers callback
Posted by Varun Gupta <va...@uber.com>.
Does the feature request seems reasonable?
On Wed, May 2, 2018 at 7:35 PM Varun Gupta <va...@uber.com> wrote:
> Implementation is only needed for V1 API.
> On Wed, May 2, 2018 at 7:31 PM Varun Gupta <va...@uber.com> wrote:
>
>> We aggregate all the offers for a host, such that placement engine can
>> pack multiple tasks that can be launched on this host using aggregated
>> resources. If offers are unused for that host then they will be implicitly
>> declined.
>>
>> Placement cycle has two components
>> - determine tasks that can be launched on this host and enque those tasks
>> to be launched.
>> - second is to deque and launch them.
>>
>> During this placement cycle, offers can be rescinded and accordingly
>> placement has to be adjusted. For that we maintain second map of offer id
>> -> host name.
>>
>> Benefits of adding host name and agent id in rescind offer callback.
>> - Mutex locks to synchronize both maps, leads to some performance hit.
>> - Managing second map, is more code and prone to bugs.
>> - Little overhead on heap memory and GC.
>> On Wed, May 2, 2018 at 5:08 PM Benjamin Mahler <bm...@apache.org>
>> wrote:
>>
>>> I'm a -1 on adding redundant information in the message.
>>>
>>> The scheduler can maintain an index of offers by offer id to address this
>>> issue:
>>>
>>> hostname -> offers
>>> offer_id -> offer
>>>
>>> On Wed, May 2, 2018 at 11:39 AM, Vinod Kone <vi...@apache.org>
>>> wrote:
>>>
>>> > Can I ask why you are indexing the offers by hostname? Is it to better
>>> > handle agent removal / unreachable signal?
>>> >
>>> > Looking at the code
>>> > <
>>> https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036
>>> >
>>> > ,
>>> > I think master has the requested information (agent id, hostname) so
>>> we can
>>> > include it in the rescind message!
>>> >
>>> > But there are couple things to discuss.
>>> >
>>> > The extra information to be included in rescind message is technically
>>> > redundant. So we need to figure out a guideline on what information
>>> should
>>> > be included / not included (e.g., should we include agent IP too) in
>>> such
>>> > calls.
>>> >
>>> > Second, adding this extra information in v1 scheduler API would be
>>> > relatively easy. But adding this to v0 API would be hard. Which API do
>>> you
>>> > need to be updated?
>>> >
>>> >
>>> > On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Currently in our implementation we maintain two maps.
>>> > >
>>> > > Hostname -> []Offers
>>> > >
>>> > > offerID -> Hostname
>>> > >
>>> > > Second map is needed because rescind offers callback only provides
>>> > offerid
>>> > > and we need hostname to do performant lookup in first map.
>>> > >
>>> > > Is it feasible to add hostname or agentid in rescind offers?
>>> > >
>>> > > Thanks,
>>> > > Varun
>>> > >
>>> >
>>>
>>
Re: Add hostname or agentid in rescind offers callback
Posted by Varun Gupta <va...@uber.com>.
Implementation is only needed for V1 API.
On Wed, May 2, 2018 at 7:31 PM Varun Gupta <va...@uber.com> wrote:
> We aggregate all the offers for a host, such that placement engine can
> pack multiple tasks that can be launched on this host using aggregated
> resources. If offers are unused for that host then they will be implicitly
> declined.
>
> Placement cycle has two components
> - determine tasks that can be launched on this host and enque those tasks
> to be launched.
> - second is to deque and launch them.
>
> During this placement cycle, offers can be rescinded and accordingly
> placement has to be adjusted. For that we maintain second map of offer id
> -> host name.
>
> Benefits of adding host name and agent id in rescind offer callback.
> - Mutex locks to synchronize both maps, leads to some performance hit.
> - Managing second map, is more code and prone to bugs.
> - Little overhead on heap memory and GC.
> On Wed, May 2, 2018 at 5:08 PM Benjamin Mahler <bm...@apache.org> wrote:
>
>> I'm a -1 on adding redundant information in the message.
>>
>> The scheduler can maintain an index of offers by offer id to address this
>> issue:
>>
>> hostname -> offers
>> offer_id -> offer
>>
>> On Wed, May 2, 2018 at 11:39 AM, Vinod Kone <vi...@apache.org> wrote:
>>
>> > Can I ask why you are indexing the offers by hostname? Is it to better
>> > handle agent removal / unreachable signal?
>> >
>> > Looking at the code
>> > <
>> https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036>
>> > ,
>> > I think master has the requested information (agent id, hostname) so we
>> can
>> > include it in the rescind message!
>> >
>> > But there are couple things to discuss.
>> >
>> > The extra information to be included in rescind message is technically
>> > redundant. So we need to figure out a guideline on what information
>> should
>> > be included / not included (e.g., should we include agent IP too) in
>> such
>> > calls.
>> >
>> > Second, adding this extra information in v1 scheduler API would be
>> > relatively easy. But adding this to v0 API would be hard. Which API do
>> you
>> > need to be updated?
>> >
>> >
>> > On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > Currently in our implementation we maintain two maps.
>> > >
>> > > Hostname -> []Offers
>> > >
>> > > offerID -> Hostname
>> > >
>> > > Second map is needed because rescind offers callback only provides
>> > offerid
>> > > and we need hostname to do performant lookup in first map.
>> > >
>> > > Is it feasible to add hostname or agentid in rescind offers?
>> > >
>> > > Thanks,
>> > > Varun
>> > >
>> >
>>
>
Re: Add hostname or agentid in rescind offers callback
Posted by Varun Gupta <va...@uber.com>.
We aggregate all the offers for a host, such that placement engine can pack
multiple tasks that can be launched on this host using aggregated
resources. If offers are unused for that host then they will be implicitly
declined.
Placement cycle has two components
- determine tasks that can be launched on this host and enque those tasks
to be launched.
- second is to deque and launch them.
During this placement cycle, offers can be rescinded and accordingly
placement has to be adjusted. For that we maintain second map of offer id
-> host name.
Benefits of adding host name and agent id in rescind offer callback.
- Mutex locks to synchronize both maps, leads to some performance hit.
- Managing second map, is more code and prone to bugs.
- Little overhead on heap memory and GC.
On Wed, May 2, 2018 at 5:08 PM Benjamin Mahler <bm...@apache.org> wrote:
> I'm a -1 on adding redundant information in the message.
>
> The scheduler can maintain an index of offers by offer id to address this
> issue:
>
> hostname -> offers
> offer_id -> offer
>
> On Wed, May 2, 2018 at 11:39 AM, Vinod Kone <vi...@apache.org> wrote:
>
> > Can I ask why you are indexing the offers by hostname? Is it to better
> > handle agent removal / unreachable signal?
> >
> > Looking at the code
> > <
> https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036>
> > ,
> > I think master has the requested information (agent id, hostname) so we
> can
> > include it in the rescind message!
> >
> > But there are couple things to discuss.
> >
> > The extra information to be included in rescind message is technically
> > redundant. So we need to figure out a guideline on what information
> should
> > be included / not included (e.g., should we include agent IP too) in such
> > calls.
> >
> > Second, adding this extra information in v1 scheduler API would be
> > relatively easy. But adding this to v0 API would be hard. Which API do
> you
> > need to be updated?
> >
> >
> > On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com> wrote:
> >
> > > Hi,
> > >
> > > Currently in our implementation we maintain two maps.
> > >
> > > Hostname -> []Offers
> > >
> > > offerID -> Hostname
> > >
> > > Second map is needed because rescind offers callback only provides
> > offerid
> > > and we need hostname to do performant lookup in first map.
> > >
> > > Is it feasible to add hostname or agentid in rescind offers?
> > >
> > > Thanks,
> > > Varun
> > >
> >
>
Re: Add hostname or agentid in rescind offers callback
Posted by Benjamin Mahler <bm...@apache.org>.
I'm a -1 on adding redundant information in the message.
The scheduler can maintain an index of offers by offer id to address this
issue:
hostname -> offers
offer_id -> offer
On Wed, May 2, 2018 at 11:39 AM, Vinod Kone <vi...@apache.org> wrote:
> Can I ask why you are indexing the offers by hostname? Is it to better
> handle agent removal / unreachable signal?
>
> Looking at the code
> <https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036>
> ,
> I think master has the requested information (agent id, hostname) so we can
> include it in the rescind message!
>
> But there are couple things to discuss.
>
> The extra information to be included in rescind message is technically
> redundant. So we need to figure out a guideline on what information should
> be included / not included (e.g., should we include agent IP too) in such
> calls.
>
> Second, adding this extra information in v1 scheduler API would be
> relatively easy. But adding this to v0 API would be hard. Which API do you
> need to be updated?
>
>
> On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com> wrote:
>
> > Hi,
> >
> > Currently in our implementation we maintain two maps.
> >
> > Hostname -> []Offers
> >
> > offerID -> Hostname
> >
> > Second map is needed because rescind offers callback only provides
> offerid
> > and we need hostname to do performant lookup in first map.
> >
> > Is it feasible to add hostname or agentid in rescind offers?
> >
> > Thanks,
> > Varun
> >
>
Re: Add hostname or agentid in rescind offers callback
Posted by Vinod Kone <vi...@apache.org>.
Can I ask why you are indexing the offers by hostname? Is it to better
handle agent removal / unreachable signal?
Looking at the code
<https://github.com/apache/mesos/blob/master/src/master/master.cpp#L11036> ,
I think master has the requested information (agent id, hostname) so we can
include it in the rescind message!
But there are couple things to discuss.
The extra information to be included in rescind message is technically
redundant. So we need to figure out a guideline on what information should
be included / not included (e.g., should we include agent IP too) in such
calls.
Second, adding this extra information in v1 scheduler API would be
relatively easy. But adding this to v0 API would be hard. Which API do you
need to be updated?
On Wed, May 2, 2018 at 10:31 AM, Varun Gupta <va...@uber.com> wrote:
> Hi,
>
> Currently in our implementation we maintain two maps.
>
> Hostname -> []Offers
>
> offerID -> Hostname
>
> Second map is needed because rescind offers callback only provides offerid
> and we need hostname to do performant lookup in first map.
>
> Is it feasible to add hostname or agentid in rescind offers?
>
> Thanks,
> Varun
>