It could be possible to not schedule a unit in a node without memory?

[aledbf]

The problem that I frequently see is that fleet schedule units (docker containers) in one some node without watching if the node has memory available.
Just something simple: not schedule units in a node with less than 100MB (just as an example)

[wuqixuan]

@aledbf , I think it could be possible, currently fleetd only schedule as per the number of units one node has.
I think we can design and implement one scheduler plugin framework, each plugin can focus different requirement as per particular resource.
@bcwaldon, how do you think ?

[aledbf]

@wuqixuan just in case, I don't want any kind of control over the scheduling. Just not schedule unita in a node with no memory (or less than X MB, not configurable by the user)

[wuqixuan]

Without configuration, directly do the hardcode limit with 100MB or 200MB may not be good. Suggest simply giving some configuration item in fleetd.conf.

[odgrim]

I second the ability to make fleet "resource aware". It's a reality of life that some containers are heavier than others and being able to schedule containers while being resource aware is a crucial next step.

I've already ran into a use case where I have a caching proxy and don't want to share the host with anything that might soak up a ton of iops or ram.... and an haproxy instance that I don't want sharing a host with anything that would soak a lot of bandwidth. The workaround is to have extremely exhaustive conflict lists in the unit.

A slightly simpler baby-step might be to create a "resource requirements" point metric on an integer scale and assign node classes corresponding integer points representing resource availability. Then a host with 10 resource points might run 2 4-point class containers but not 3.

[bcwaldon]

making fleet more "resource aware" has been discussed at length:

#1055
#1049

It really isn't simple to do this without first elevating available resource information to the scheduler, and I don't want to start going down that path until we address the larger issues above.