{"action":"created","issue":{"url":"https://api.github.com/repos/coreos/fleet/issues/1055","labels_url":"https://api.github.com/repos/coreos/fleet/issues/1055/labels{/name}","comments_url":"https://api.github.com/repos/coreos/fleet/issues/1055/comments","events_url":"https://api.github.com/repos/coreos/fleet/issues/1055/events","html_url":"https://github.com/coreos/fleet/issues/1055","id":51156626,"number":1055,"title":"RFC: Requirements for an extensible scheduling system","user":{"login":"jonboulle","id":2601015,"avatar_url":"https://avatars.githubusercontent.com/u/2601015?v=3","gravatar_id":"","url":"https://api.github.com/users/jonboulle","html_url":"https://github.com/jonboulle","followers_url":"https://api.github.com/users/jonboulle/followers","following_url":"https://api.github.com/users/jonboulle/following{/other_user}","gists_url":"https://api.github.com/users/jonboulle/gists{/gist_id}","starred_url":"https://api.github.com/users/jonboulle/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jonboulle/subscriptions","organizations_url":"https://api.github.com/users/jonboulle/orgs","repos_url":"https://api.github.com/users/jonboulle/repos","events_url":"https://api.github.com/users/jonboulle/events{/privacy}","received_events_url":"https://api.github.com/users/jonboulle/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/coreos/fleet/labels/discussion","name":"discussion","color":"c7def8"},{"url":"https://api.github.com/repos/coreos/fleet/labels/scheduler","name":"scheduler","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2014-12-05T23:01:43Z","updated_at":"2015-05-11T21:41:39Z","closed_at":null,"body":"fleet’s current scheduling engine is rudimentary, and there have been various proposals ([1][1] [2][2] [3][3] [4][4]) to either enhance the complexity of the scheduling within fleet, or provide a means for users to extend it without needing to run a custom branch of fleet.\r\n\r\n[1]: https://github.com/coreos/fleet/issues/922\r\n[2]: https://github.com/coreos/fleet/issues/747\r\n[3]: https://github.com/coreos/fleet/issues/945\r\n[4]: https://github.com/coreos/fleet/issues/1049\r\n\r\n\r\nThis issue aims to capture the design requirements and restrictions for a solution to these requests, such that it can be implemented in a way a) keeping with fleet’s architecture and design goals, and b) without impacting existing users of fleet.\r\n\r\n(Bear in mind that this is a work in progress proposal, not a final set of hard requirements; please provide feedback below).\r\n\r\nThe solution should be:\r\n- _Pluggable_\r\n  - There should exist a simple request-response interface for scheduling plugins to connect with fleet. Some options previously proposed include an extremely simple HTTP endpoint or command-line interface.\r\n  - It should not be necessary to spin a custom build of fleet to add new scheduling capabilities\r\n  - There should be no new deployable fleet components (i.e. retain the situation of a single binary per host (`fleetd`) for fleet itself)\r\n- _Backwards-compatible_ and _behaviour preserving_\r\n  - fleet should continue to be usable “out of the box” for basic/common use cases (i.e. there should be a simple default scheduling mechanism similar to today, and users should not need to write a plugin to use fleet)\r\n  - In the default configuration, the performance and efficiency of fleet should not be compromised from today’s situation\r\n  - impact on (i.e. code changes to) existing fleet architecture and internals should be minimized\r\n  - no additions to the fleet [API](https://github.com/coreos/fleet/blob/master/Documentation/api-v1.md); extending the unit file with `X-Fleet` options should be sufficient\r\n- _Understandable_\r\n  - The introduction of pluggable schedulers will necessarily impact the performance and behaviour of fleet. The plug-in functionality should be structured such that it is easy to differentiate between issues in fleet itself and in plugins.\r\n\r\nSince comparisons will inevitably arise, we will take this opportunity to draw a distinction between what we’re aiming for and the Mesos [framework model](http://mesos.apache.org/documentation/latest/app-framework-development-guide/). We do _not_ anticipate the API between fleet and the pluggable schedulers becoming arbitrarily complex (ideally it should be limited to the single request-response described above), and we would still consider fleet to be the “entrypoint” for users deploying applications (c.f. Mesos, where the entrypoint is typically the scheduler). To put it another way, schedulers should plug in _behind_ fleet rather than _on top of_ fleet."},"comment":{"url":"https://api.github.com/repos/coreos/fleet/issues/comments/101057494","html_url":"https://github.com/coreos/fleet/issues/1055#issuecomment-101057494","issue_url":"https://api.github.com/repos/coreos/fleet/issues/1055","id":101057494,"user":{"login":"vassilevsky","id":252023,"avatar_url":"https://avatars.githubusercontent.com/u/252023?v=3","gravatar_id":"","url":"https://api.github.com/users/vassilevsky","html_url":"https://github.com/vassilevsky","followers_url":"https://api.github.com/users/vassilevsky/followers","following_url":"https://api.github.com/users/vassilevsky/following{/other_user}","gists_url":"https://api.github.com/users/vassilevsky/gists{/gist_id}","starred_url":"https://api.github.com/users/vassilevsky/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vassilevsky/subscriptions","organizations_url":"https://api.github.com/users/vassilevsky/orgs","repos_url":"https://api.github.com/users/vassilevsky/repos","events_url":"https://api.github.com/users/vassilevsky/events{/privacy}","received_events_url":"https://api.github.com/users/vassilevsky/received_events","type":"User","site_admin":false},"created_at":"2015-05-11T21:41:39Z","updated_at":"2015-05-11T21:41:39Z","body":"I see that there was an attempt to bring machine resources into play, but it was deleted in ab275c1d510a72d5ff221c18490efcf0f08f8d01 (although `resource` dir is still there). I wonder why you decided to do that."}}