Thanks Ben. Some thoughts below:
>From a scheduler's perspective the difference between the two models is:
>
> (1) expressing "how much more" you need
> (2) expressing an offer "matcher"
>
> So:
>
> (1) covers the middle part of the demand quantity spectrum we currently
> have: unsuppressed -> inf
I think we're agreed:
-There are no schedulers modeling the existing per-agent time-based
filters that mesos is tracking, and we shouldn't go in a direction that
encourages frameworks to try to model and manage these. So, we should be
very careful in considering something like CLEAR_FILTERS. W
Hi all,
The API working group will meet tomorrow, Dec. 11 at 11am PST. On the
agenda we have:
- Proposed calls for the scheduler API:
- UNSUPPRESS
- CLEAR_FILTER
- REQUEST_RESOURCE
- Adding a new 'ResourceQuantity' type
- Improving the scheduler operation reconciliati
There are two options for contributing:
1) You can make a pull request against the GitHub mirror:
https://github.com/apache/mesos . We generally only use PRs for minor
changes, like typos, documentation, or uploading binaries. See
http://mesos.apache.org/documentation/latest/beginner-contribution
I have a working version. How should I make the patch? A branch in the git
repository? Do I need to get permissions?
--
Dmitrii Kishchukov.
Leading software developer
Submission Portal Team
On 12/6/18, 12:56 PM, "Vinod Kone" wrote:
Dmitrii.
That approach sounds reasonable.
Hi Ben et al.,
I'd expect frameworks to *always* know how to accept or decline offers in
general. More involved frameworks might know how to suppress offers. I don't
expect that any framework models filters and their associated durations in
detail (that's why I called them a Mesos implementatio