You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Petr Novak <os...@gmail.com> on 2016/12/13 19:09:07 UTC
Can I consider other framework tasks as a resource? Does it make sense?
Hello,
I want to execute tasks which requires some other tasks from other
framework(s) already running. I'm thinking where such logic/strategy/policy
belongs in principle. I understand scheduling as a process to decide where
to execute task according to some resources availability, typically CPU,
mem, net, hdd etc.
If my task require other tasks running could I generalize and consider that
those tasks from other frameworks are kind of required resources and put
this logic/strategy decisions into scheduler? Like if I want to run my task
collocated with some other tasks on the same node I have to make this
decision somewhere.
Does it make any sense? I'm asking because I have never thought about other
frameworks/tasks as "resources" so that I could put them into scheduler to
satisfy my understanding of a scheduler. Or it rather belongs higher like to
a framework, or lower to an executor? Should scheduler be dedicated to
decisions about resources which are offered and am I mixing concepts?
Or I just should keep distinction between resources and
requirements/policies or whatever but anyway does this kind of logic still
belongs to scheduler or it should be somewhere else? I'm trying to
understand which logic should be in scheduler and what should go somewhere
else.
Many thanks,
Petr
Re: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Sharma Podila <sp...@netflix.com>.
Response below:
On Thu, Dec 15, 2016 at 5:22 AM, Petr Novak <os...@gmail.com> wrote:
> It is very helpful. I will take a deeper look on Fenzo.
> Isn’t pretty much everything external knowledge to a scheduler? CPU, mem,
> net, storage… these all information has to somehow get into scheduler. But
> for these there is an internal support by Mesos via resource offers and it
> is what I think you mean by internal vs. external.
>
Yes, that's right.
>
>
> What I’m thinking is that there is already a mechanism in Mesos how to get
> information into scheduler but it is not extendable by custom resource
> types. Thinking about offered resources I have also realized that there is
> a common trait to them – they are consumable. When one task accepts some
> resources they are not available to other tasks. Hence probably if I would
> like to represent other constraints as resources they would have to have
> this property. Then, in theory, they could by plugged into Mesos resources
> mechanism. Possibly not all constraints can be modelled as consumables and
> the approach through pluggable scheduling library like Fenzo might be more
> flexible.
>
Constraints can be on non-consumables. For example, we have constraints on
custom attributes, not just resources. The trick is to get the information
on other tasks on the agent back into the scheduler. Today we do this only
among tasks of the same framework, so, Fenzo know about all of them. If
there is a way to get the dynamic task scheduling info for the other
frameworks, you could, for example, add those into Fenzo and let it
maintain state and do the constraints.
>
>
> My original question was basically about what counts as scheduling so that
> when I need to model some constraint how to place a task I would know where
> it belongs in my framework’s code. It seems to be answered. Thanks a lot.
>
>
>
> *From:* Sharma Podila [mailto:spodila@netflix.com]
> *Sent:* 15. prosince 2016 1:59
> *To:* user@mesos.apache.org
>
> *Subject:* Re: Can I consider other framework tasks as a resource? Does
> it make sense?
>
>
>
> In general, placing a task based on certain constraints (e.g., locality
> with other tasks) is a scheduling concern. The complexity in your scenario
> is that the constraint specification requires knowledge external to your
> scheduler. If you are able to route that external information (on what and
> where other frameworks' tasks are running) into your scheduler, then, you
> should be able to achieve the locality constraints in your scheduler.
>
>
>
> If your scheduler happens to be running on the JVM, our open source Fenzo
> scheduling library can be useful. Or at least provide one idea on how your
> could write a scheduler that deals with such constraints. In Fenzo, for
> example, you'd write a custom plugin to handle the locality by using the
> external information, that I refer to above, to "score" agents that fit
> your task better. Fenzo will then pick the best agent to launch your task
> for locality.
>
>
>
> One limitation is the fact that you'd have little to no control on
> ensuring that the agents on which those other frameworks' tasks are running
> on will have additional resources available to fit your tasks. And that
> offers from those agents will arrive at your scheduler. Some variation of
> "delay scheduling" can help the latter by rejecting offers from agents that
> do not contain the tasks of interest from other frameworks.
>
>
>
>
>
> On Wed, Dec 14, 2016 at 10:33 AM, Petr Novak <os...@gmail.com> wrote:
>
> Thanks a lot for the input.
>
>
>
> “Y scheduler can accept a rule how to check readiness on startup”
>
>
>
> Based on it seems like +1 that I can consider it as a responsibility of a
> scheduler.
>
>
>
> Cheers,
>
> Petr
>
>
>
>
>
> *From:* Alex Rukletsov [mailto:alex@mesosphere.com]
> *Sent:* 14. prosince 2016 13:01
> *To:* user
> *Subject:* Re: Can I consider other framework tasks as a resource? Does
> it make sense?
>
>
>
> Task dependency is probably too vague to discuss specifically. Mesos
> currently does not explicitly support arbitrary task dependencies. You
> mentioned colocation, one type of dependency, so let's look at it.
>
>
>
> If I understood you correctly, you would like to colocate a task from
> framework B to the same node where a task from framework A is running. The
> first problem is to get a list of such nodes (and keep them updated,
> because task may crash, migrate and so on). This can be done, say, by using
> Mesos DNS or alike. The second problem is to ensure that framework gets
> enough resources from that nodes. A possible solution here is to put both
> frameworks A and B into the same role and use dynamic reservations to
> ensure enough resources are laid away for both tasks. Disadvantages: you
> should know about all dependencies upfront, frameworks should be in the
> same role.
>
>
>
> Now the question is, why would you need to colocate workloads? I would say
> this is something you should avoid if possible, like any extra constraint
> that complicate the system. Probably the only 100% legitimate use case for
> colocation is data locality. Solving this particular problem seems easier
> than to address arbitrary task dependencies.
>
>
>
> If all you try to achieve is making sure a specific service represented by
> a framework X is running and ready in the cluster, you can do that by
> running specific checks before starting a depending framework Y or
> launching a new task in this framework. If your question is about whether Y
> should know about X and know how to check readiness of X in the cluster,
> I'd say you'd better keep that abstracted: Y scheduler can accept a rule
> how to check readiness on startup.
>
>
>
> On Wed, Dec 14, 2016 at 5:14 AM, haosdent <ha...@gmail.com> wrote:
>
> Hi, @Petr.
>
>
>
> > Like if I want to run my task collocated with some other tasks on the
> same node I have to make this decision somewhere.
>
> Do you mean "POD" here?
>
>
>
> For my cases, if there are some dependencies between my tasks, I use
> database, message queue or zookeeper to implement my requirement.
>
>
>
> On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
>
> Hello,
>
> I want to execute tasks which requires some other tasks from other
> framework(s) already running. I’m thinking where such logic/strategy/policy
> belongs in principle. I understand scheduling as a process to decide where
> to execute task according to some resources availability, typically CPU,
> mem, net, hdd etc.
>
>
>
> If my task require other tasks running could I generalize and consider
> that those tasks from other frameworks are kind of required resources and
> put this logic/strategy decisions into scheduler? Like if I want to run my
> task collocated with some other tasks on the same node I have to make this
> decision somewhere.
>
>
>
> Does it make any sense? I’m asking because I have never thought about
> other frameworks/tasks as “resources” so that I could put them into
> scheduler to satisfy my understanding of a scheduler. Or it rather belongs
> higher like to a framework, or lower to an executor? Should scheduler be
> dedicated to decisions about resources which are offered and am I mixing
> concepts?
>
>
>
> Or I just should keep distinction between resources and
> requirements/policies or whatever but anyway does this kind of logic still
> belongs to scheduler or it should be somewhere else? I’m trying to
> understand which logic should be in scheduler and what should go somewhere
> else.
>
>
>
> Many thanks,
>
> Petr
>
>
>
>
>
>
>
> --
>
> Best Regards,
>
> Haosdent Huang
>
>
>
>
>
RE: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Petr Novak <os...@gmail.com>.
It is very helpful. I will take a deeper look on Fenzo.
Isn’t pretty much everything external knowledge to a scheduler? CPU, mem, net, storage… these all information has to somehow get into scheduler. But for these there is an internal support by Mesos via resource offers and it is what I think you mean by internal vs. external.
What I’m thinking is that there is already a mechanism in Mesos how to get information into scheduler but it is not extendable by custom resource types. Thinking about offered resources I have also realized that there is a common trait to them – they are consumable. When one task accepts some resources they are not available to other tasks. Hence probably if I would like to represent other constraints as resources they would have to have this property. Then, in theory, they could by plugged into Mesos resources mechanism. Possibly not all constraints can be modelled as consumables and the approach through pluggable scheduling library like Fenzo might be more flexible.
My original question was basically about what counts as scheduling so that when I need to model some constraint how to place a task I would know where it belongs in my framework’s code. It seems to be answered. Thanks a lot.
From: Sharma Podila [mailto:spodila@netflix.com]
Sent: 15. prosince 2016 1:59
To: user@mesos.apache.org
Subject: Re: Can I consider other framework tasks as a resource? Does it make sense?
In general, placing a task based on certain constraints (e.g., locality with other tasks) is a scheduling concern. The complexity in your scenario is that the constraint specification requires knowledge external to your scheduler. If you are able to route that external information (on what and where other frameworks' tasks are running) into your scheduler, then, you should be able to achieve the locality constraints in your scheduler.
If your scheduler happens to be running on the JVM, our open source Fenzo scheduling library can be useful. Or at least provide one idea on how your could write a scheduler that deals with such constraints. In Fenzo, for example, you'd write a custom plugin to handle the locality by using the external information, that I refer to above, to "score" agents that fit your task better. Fenzo will then pick the best agent to launch your task for locality.
One limitation is the fact that you'd have little to no control on ensuring that the agents on which those other frameworks' tasks are running on will have additional resources available to fit your tasks. And that offers from those agents will arrive at your scheduler. Some variation of "delay scheduling" can help the latter by rejecting offers from agents that do not contain the tasks of interest from other frameworks.
On Wed, Dec 14, 2016 at 10:33 AM, Petr Novak <os...@gmail.com> wrote:
Thanks a lot for the input.
“Y scheduler can accept a rule how to check readiness on startup”
Based on it seems like +1 that I can consider it as a responsibility of a scheduler.
Cheers,
Petr
From: Alex Rukletsov [mailto:alex@mesosphere.com]
Sent: 14. prosince 2016 13:01
To: user
Subject: Re: Can I consider other framework tasks as a resource? Does it make sense?
Task dependency is probably too vague to discuss specifically. Mesos currently does not explicitly support arbitrary task dependencies. You mentioned colocation, one type of dependency, so let's look at it.
If I understood you correctly, you would like to colocate a task from framework B to the same node where a task from framework A is running. The first problem is to get a list of such nodes (and keep them updated, because task may crash, migrate and so on). This can be done, say, by using Mesos DNS or alike. The second problem is to ensure that framework gets enough resources from that nodes. A possible solution here is to put both frameworks A and B into the same role and use dynamic reservations to ensure enough resources are laid away for both tasks. Disadvantages: you should know about all dependencies upfront, frameworks should be in the same role.
Now the question is, why would you need to colocate workloads? I would say this is something you should avoid if possible, like any extra constraint that complicate the system. Probably the only 100% legitimate use case for colocation is data locality. Solving this particular problem seems easier than to address arbitrary task dependencies.
If all you try to achieve is making sure a specific service represented by a framework X is running and ready in the cluster, you can do that by running specific checks before starting a depending framework Y or launching a new task in this framework. If your question is about whether Y should know about X and know how to check readiness of X in the cluster, I'd say you'd better keep that abstracted: Y scheduler can accept a rule how to check readiness on startup.
On Wed, Dec 14, 2016 at 5:14 AM, haosdent <ha...@gmail.com> wrote:
Hi, @Petr.
> Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Do you mean "POD" here?
For my cases, if there are some dependencies between my tasks, I use database, message queue or zookeeper to implement my requirement.
On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
Hello,
I want to execute tasks which requires some other tasks from other framework(s) already running. I’m thinking where such logic/strategy/policy belongs in principle. I understand scheduling as a process to decide where to execute task according to some resources availability, typically CPU, mem, net, hdd etc.
If my task require other tasks running could I generalize and consider that those tasks from other frameworks are kind of required resources and put this logic/strategy decisions into scheduler? Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Does it make any sense? I’m asking because I have never thought about other frameworks/tasks as “resources” so that I could put them into scheduler to satisfy my understanding of a scheduler. Or it rather belongs higher like to a framework, or lower to an executor? Should scheduler be dedicated to decisions about resources which are offered and am I mixing concepts?
Or I just should keep distinction between resources and requirements/policies or whatever but anyway does this kind of logic still belongs to scheduler or it should be somewhere else? I’m trying to understand which logic should be in scheduler and what should go somewhere else.
Many thanks,
Petr
--
Best Regards,
Haosdent Huang
Re: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Sharma Podila <sp...@netflix.com>.
In general, placing a task based on certain constraints (e.g., locality
with other tasks) is a scheduling concern. The complexity in your scenario
is that the constraint specification requires knowledge external to your
scheduler. If you are able to route that external information (on what and
where other frameworks' tasks are running) into your scheduler, then, you
should be able to achieve the locality constraints in your scheduler.
If your scheduler happens to be running on the JVM, our open source Fenzo
scheduling library can be useful. Or at least provide one idea on how your
could write a scheduler that deals with such constraints. In Fenzo, for
example, you'd write a custom plugin to handle the locality by using the
external information, that I refer to above, to "score" agents that fit
your task better. Fenzo will then pick the best agent to launch your task
for locality.
One limitation is the fact that you'd have little to no control on ensuring
that the agents on which those other frameworks' tasks are running on will
have additional resources available to fit your tasks. And that offers from
those agents will arrive at your scheduler. Some variation of "delay
scheduling" can help the latter by rejecting offers from agents that do not
contain the tasks of interest from other frameworks.
On Wed, Dec 14, 2016 at 10:33 AM, Petr Novak <os...@gmail.com> wrote:
> Thanks a lot for the input.
>
>
>
> “Y scheduler can accept a rule how to check readiness on startup”
>
>
>
> Based on it seems like +1 that I can consider it as a responsibility of a
> scheduler.
>
>
>
> Cheers,
>
> Petr
>
>
>
>
>
> *From:* Alex Rukletsov [mailto:alex@mesosphere.com]
> *Sent:* 14. prosince 2016 13:01
> *To:* user
> *Subject:* Re: Can I consider other framework tasks as a resource? Does
> it make sense?
>
>
>
> Task dependency is probably too vague to discuss specifically. Mesos
> currently does not explicitly support arbitrary task dependencies. You
> mentioned colocation, one type of dependency, so let's look at it.
>
>
>
> If I understood you correctly, you would like to colocate a task from
> framework B to the same node where a task from framework A is running. The
> first problem is to get a list of such nodes (and keep them updated,
> because task may crash, migrate and so on). This can be done, say, by using
> Mesos DNS or alike. The second problem is to ensure that framework gets
> enough resources from that nodes. A possible solution here is to put both
> frameworks A and B into the same role and use dynamic reservations to
> ensure enough resources are laid away for both tasks. Disadvantages: you
> should know about all dependencies upfront, frameworks should be in the
> same role.
>
>
>
> Now the question is, why would you need to colocate workloads? I would say
> this is something you should avoid if possible, like any extra constraint
> that complicate the system. Probably the only 100% legitimate use case for
> colocation is data locality. Solving this particular problem seems easier
> than to address arbitrary task dependencies.
>
>
>
> If all you try to achieve is making sure a specific service represented by
> a framework X is running and ready in the cluster, you can do that by
> running specific checks before starting a depending framework Y or
> launching a new task in this framework. If your question is about whether Y
> should know about X and know how to check readiness of X in the cluster,
> I'd say you'd better keep that abstracted: Y scheduler can accept a rule
> how to check readiness on startup.
>
>
>
> On Wed, Dec 14, 2016 at 5:14 AM, haosdent <ha...@gmail.com> wrote:
>
> Hi, @Petr.
>
>
>
> > Like if I want to run my task collocated with some other tasks on the
> same node I have to make this decision somewhere.
>
> Do you mean "POD" here?
>
>
>
> For my cases, if there are some dependencies between my tasks, I use
> database, message queue or zookeeper to implement my requirement.
>
>
>
> On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
>
> Hello,
>
> I want to execute tasks which requires some other tasks from other
> framework(s) already running. I’m thinking where such logic/strategy/policy
> belongs in principle. I understand scheduling as a process to decide where
> to execute task according to some resources availability, typically CPU,
> mem, net, hdd etc.
>
>
>
> If my task require other tasks running could I generalize and consider
> that those tasks from other frameworks are kind of required resources and
> put this logic/strategy decisions into scheduler? Like if I want to run my
> task collocated with some other tasks on the same node I have to make this
> decision somewhere.
>
>
>
> Does it make any sense? I’m asking because I have never thought about
> other frameworks/tasks as “resources” so that I could put them into
> scheduler to satisfy my understanding of a scheduler. Or it rather belongs
> higher like to a framework, or lower to an executor? Should scheduler be
> dedicated to decisions about resources which are offered and am I mixing
> concepts?
>
>
>
> Or I just should keep distinction between resources and
> requirements/policies or whatever but anyway does this kind of logic still
> belongs to scheduler or it should be somewhere else? I’m trying to
> understand which logic should be in scheduler and what should go somewhere
> else.
>
>
>
> Many thanks,
>
> Petr
>
>
>
>
>
>
>
> --
>
> Best Regards,
>
> Haosdent Huang
>
>
>
RE: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Petr Novak <os...@gmail.com>.
Thanks a lot for the input.
“Y scheduler can accept a rule how to check readiness on startup”
Based on it seems like +1 that I can consider it as a responsibility of a scheduler.
Cheers,
Petr
From: Alex Rukletsov [mailto:alex@mesosphere.com]
Sent: 14. prosince 2016 13:01
To: user
Subject: Re: Can I consider other framework tasks as a resource? Does it make sense?
Task dependency is probably too vague to discuss specifically. Mesos currently does not explicitly support arbitrary task dependencies. You mentioned colocation, one type of dependency, so let's look at it.
If I understood you correctly, you would like to colocate a task from framework B to the same node where a task from framework A is running. The first problem is to get a list of such nodes (and keep them updated, because task may crash, migrate and so on). This can be done, say, by using Mesos DNS or alike. The second problem is to ensure that framework gets enough resources from that nodes. A possible solution here is to put both frameworks A and B into the same role and use dynamic reservations to ensure enough resources are laid away for both tasks. Disadvantages: you should know about all dependencies upfront, frameworks should be in the same role.
Now the question is, why would you need to colocate workloads? I would say this is something you should avoid if possible, like any extra constraint that complicate the system. Probably the only 100% legitimate use case for colocation is data locality. Solving this particular problem seems easier than to address arbitrary task dependencies.
If all you try to achieve is making sure a specific service represented by a framework X is running and ready in the cluster, you can do that by running specific checks before starting a depending framework Y or launching a new task in this framework. If your question is about whether Y should know about X and know how to check readiness of X in the cluster, I'd say you'd better keep that abstracted: Y scheduler can accept a rule how to check readiness on startup.
On Wed, Dec 14, 2016 at 5:14 AM, haosdent <ha...@gmail.com> wrote:
Hi, @Petr.
> Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Do you mean "POD" here?
For my cases, if there are some dependencies between my tasks, I use database, message queue or zookeeper to implement my requirement.
On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
Hello,
I want to execute tasks which requires some other tasks from other framework(s) already running. I’m thinking where such logic/strategy/policy belongs in principle. I understand scheduling as a process to decide where to execute task according to some resources availability, typically CPU, mem, net, hdd etc.
If my task require other tasks running could I generalize and consider that those tasks from other frameworks are kind of required resources and put this logic/strategy decisions into scheduler? Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Does it make any sense? I’m asking because I have never thought about other frameworks/tasks as “resources” so that I could put them into scheduler to satisfy my understanding of a scheduler. Or it rather belongs higher like to a framework, or lower to an executor? Should scheduler be dedicated to decisions about resources which are offered and am I mixing concepts?
Or I just should keep distinction between resources and requirements/policies or whatever but anyway does this kind of logic still belongs to scheduler or it should be somewhere else? I’m trying to understand which logic should be in scheduler and what should go somewhere else.
Many thanks,
Petr
--
Best Regards,
Haosdent Huang
Re: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Alex Rukletsov <al...@mesosphere.com>.
Task dependency is probably too vague to discuss specifically. Mesos
currently does not explicitly support arbitrary task dependencies. You
mentioned colocation, one type of dependency, so let's look at it.
If I understood you correctly, you would like to colocate a task from
framework B to the same node where a task from framework A is running. The
first problem is to get a list of such nodes (and keep them updated,
because task may crash, migrate and so on). This can be done, say, by using
Mesos DNS or alike. The second problem is to ensure that framework gets
enough resources from that nodes. A possible solution here is to put both
frameworks A and B into the same role and use dynamic reservations to
ensure enough resources are laid away for both tasks. Disadvantages: you
should know about all dependencies upfront, frameworks should be in the
same role.
Now the question is, why would you need to colocate workloads? I would say
this is something you should avoid if possible, like any extra constraint
that complicate the system. Probably the only 100% legitimate use case for
colocation is data locality. Solving this particular problem seems easier
than to address arbitrary task dependencies.
If all you try to achieve is making sure a specific service represented by
a framework X is running and ready in the cluster, you can do that by
running specific checks before starting a depending framework Y or
launching a new task in this framework. If your question is about whether Y
should know about X and know how to check readiness of X in the cluster,
I'd say you'd better keep that abstracted: Y scheduler can accept a rule
how to check readiness on startup.
On Wed, Dec 14, 2016 at 5:14 AM, haosdent <ha...@gmail.com> wrote:
> Hi, @Petr.
>
> > Like if I want to run my task collocated with some other tasks on the
> same node I have to make this decision somewhere.
> Do you mean "POD" here?
>
> For my cases, if there are some dependencies between my tasks, I use
> database, message queue or zookeeper to implement my requirement.
>
> On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
>
>> Hello,
>>
>> I want to execute tasks which requires some other tasks from other
>> framework(s) already running. I’m thinking where such logic/strategy/policy
>> belongs in principle. I understand scheduling as a process to decide where
>> to execute task according to some resources availability, typically CPU,
>> mem, net, hdd etc.
>>
>>
>>
>> If my task require other tasks running could I generalize and consider
>> that those tasks from other frameworks are kind of required resources and
>> put this logic/strategy decisions into scheduler? Like if I want to run my
>> task collocated with some other tasks on the same node I have to make this
>> decision somewhere.
>>
>>
>>
>> Does it make any sense? I’m asking because I have never thought about
>> other frameworks/tasks as “resources” so that I could put them into
>> scheduler to satisfy my understanding of a scheduler. Or it rather belongs
>> higher like to a framework, or lower to an executor? Should scheduler be
>> dedicated to decisions about resources which are offered and am I mixing
>> concepts?
>>
>>
>>
>> Or I just should keep distinction between resources and
>> requirements/policies or whatever but anyway does this kind of logic still
>> belongs to scheduler or it should be somewhere else? I’m trying to
>> understand which logic should be in scheduler and what should go somewhere
>> else.
>>
>>
>>
>> Many thanks,
>>
>> Petr
>>
>>
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
RE: Can I consider other framework tasks as a resource? Does it make sense?
Posted by Petr Novak <os...@gmail.com>.
Hi,
My question is conceptual about what is scheduler in a cluster-wide context and what counts as scheduler responsibility. The actual implementation is not that important but rather where you put that dependency logic, who decides if dependencies are satisfied. It is not about PODs because dependent services doesn’t have to run in the same pod.
It seems to me that Mesos scheduler is defined like that it decides if and where a given task should be executed based on offered resources. In many application offered resources are possibly not enough to decide if to run a task. E.g. state of dependent services, licenses etc.
I’m asking if there is any discussion, guidelines, best practices where these decisions belong when designing a framework. Can it still be a scheduler responsibility? Should it be in some other module, e.g. policy engine. I just try to understand where scheduler responsibilities start and end.
If I would define scheduler as an entity deciding if and where (and how?) to execute a task based on state of resources and once decided the actual execution is delegated to an executor and I would like to consider all that logic above as a scheduler responsibility, then I have to either extend my definition of a scheduler or I have to be able to map everything as a resource.
After all set of running services could be considered as a resource. REST is as well trying to represent everything as a resource.
I’m probably trying to think too much,
Petr
From: haosdent [mailto:haosdent@gmail.com]
Sent: 14. prosince 2016 5:14
To: user
Subject: Re: Can I consider other framework tasks as a resource? Does it make sense?
Hi, @Petr.
> Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Do you mean "POD" here?
For my cases, if there are some dependencies between my tasks, I use database, message queue or zookeeper to implement my requirement.
On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
Hello,
I want to execute tasks which requires some other tasks from other framework(s) already running. I’m thinking where such logic/strategy/policy belongs in principle. I understand scheduling as a process to decide where to execute task according to some resources availability, typically CPU, mem, net, hdd etc.
If my task require other tasks running could I generalize and consider that those tasks from other frameworks are kind of required resources and put this logic/strategy decisions into scheduler? Like if I want to run my task collocated with some other tasks on the same node I have to make this decision somewhere.
Does it make any sense? I’m asking because I have never thought about other frameworks/tasks as “resources” so that I could put them into scheduler to satisfy my understanding of a scheduler. Or it rather belongs higher like to a framework, or lower to an executor? Should scheduler be dedicated to decisions about resources which are offered and am I mixing concepts?
Or I just should keep distinction between resources and requirements/policies or whatever but anyway does this kind of logic still belongs to scheduler or it should be somewhere else? I’m trying to understand which logic should be in scheduler and what should go somewhere else.
Many thanks,
Petr
--
Best Regards,
Haosdent Huang
Re: Can I consider other framework tasks as a resource? Does it make sense?
Posted by haosdent <ha...@gmail.com>.
Hi, @Petr.
> Like if I want to run my task collocated with some other tasks on the
same node I have to make this decision somewhere.
Do you mean "POD" here?
For my cases, if there are some dependencies between my tasks, I use
database, message queue or zookeeper to implement my requirement.
On Wed, Dec 14, 2016 at 3:09 AM, Petr Novak <os...@gmail.com> wrote:
> Hello,
>
> I want to execute tasks which requires some other tasks from other
> framework(s) already running. I’m thinking where such logic/strategy/policy
> belongs in principle. I understand scheduling as a process to decide where
> to execute task according to some resources availability, typically CPU,
> mem, net, hdd etc.
>
>
>
> If my task require other tasks running could I generalize and consider
> that those tasks from other frameworks are kind of required resources and
> put this logic/strategy decisions into scheduler? Like if I want to run my
> task collocated with some other tasks on the same node I have to make this
> decision somewhere.
>
>
>
> Does it make any sense? I’m asking because I have never thought about
> other frameworks/tasks as “resources” so that I could put them into
> scheduler to satisfy my understanding of a scheduler. Or it rather belongs
> higher like to a framework, or lower to an executor? Should scheduler be
> dedicated to decisions about resources which are offered and am I mixing
> concepts?
>
>
>
> Or I just should keep distinction between resources and
> requirements/policies or whatever but anyway does this kind of logic still
> belongs to scheduler or it should be somewhere else? I’m trying to
> understand which logic should be in scheduler and what should go somewhere
> else.
>
>
>
> Many thanks,
>
> Petr
>
>
>
--
Best Regards,
Haosdent Huang