Let scheduler maintain different kinds of tasks

[Martin Westergaard Lassen]

Two main usage patterns has come up to back this feature

• Compositions of schedulers. One "main" scheduler can maintain another scheduler
• Server/agent applications, like CI servers and some SQL databases

[Martin Westergaard Lassen]

I suggest a configuration format where tasks are put into a task field

spring:
  application:
    name: sample

mesos:
  master: leader.mesos:5050
  zookeeper:
    server: leader.mesos:2181
  tasks:
    - name: server
      command: nc -l ${SERVER_PORT}
      docker:
        image: alpine
      resources:
        count: 1
        cpus: 0.1
        mem: 64
        ports:
          server-port:
            host: ANY
            container: 80
    - name: slave
      command: ./connect server.sample.mesos
      docker:
        image: alpine
      resources:
        count: 1
        cpus: 0.1
        mem: 64

Only new thing is that mesos.* has been moved into mesos.tasks[n].* and a mesos.tasks[n].name has been added.

Another solution is moving mesos.* properties into mesos.tasks.name.*

[Phil Winder]

Are you going to try and maintain backwards compatibility?

Fine otherwise.

[Martin Westergaard Lassen]

@philwinder When we reach 1.0 I will. Until then we're still in development 🎱

[Ares]

@mwl
This is a very useful feature！
Can you provide a preliminary implementation code?

[Martin Westergaard Lassen]

@chinaares Thanks for your feedback. Until I've seen otherwise I think it's a bit of an anti-pattern. Maybe you can provide a use case and we can discuss it from there?

[Ares]

@mwl
Thank you for your reply .
I think this feature enables finer grained resource coordination and management. Otherwise, we can only deploy a large number of framework for specific applications. I have two use case to discuss:

1. To deploy same package jar with different resource requirment, but right now I have to deploy multiple framework with different resources. And I hope could unified management the task from the jar;
2. In my framework, my service with multiple implements，I want to manage the count of each service dynamic and unified.

Although mesos can manage all resources, but specific applications are forced to decentralized management by many frameworks, will greatly increase the complexity of maintenance.

[Ares]

@mwl Add a little，Framework should be positioned to address application layer issues. And not every application is simple to just one type task requirement. Scalability at the task layer should greatly enhance the framework's ability to support complex applications.

Any help will be appreciated!