Hi,
When deploying stacks is it possible to add service requirements in for example rancher-compose.yml?
For example: “this service requires a host with >2 cores and >4 Gb of RAM” or
"this service must run on another host than that service"
BR,
/Martin
There are optional field to set the required [milli]CPUs and RAM on the service, which will be used by the scheduler is set.
[Anti-]Affinity is in the scheduling tab, "The host must not have…
Can I set the required milliCPUs and RAM in docker-compose.yml or rancher-compose.yml?
See list of options: https://docs.rancher.com/rancher/v1.3/en/cattle/scheduling/
I didn’t find any macros/variables for host resources, also there is only match (nothing like higher/lower). So only way is to setup another labels on hosts which will contain this information and than setup affinity rule in docker compose file (with exact match).
For CPU/MEM I think that placement should be left to Rancher, but sometimes will be good to have some option like this for other affinities. You can create issue in Github, and you will see.
Yes! The easiest way to find out how to put those settings in a yaml is to apply the settings through the Rancher UI, then view the stack configuration. ( It is the little paper icon in the upper right of the stack page ) That will show you the exact docker-compose.yml and rancher-compose.yml files that rancher uses for your stack.
Also you can find documentation on the docker engine parameters here.
The docker-compose equivalents are documented here.
oh I really like this. not.
Honestly I would thing a little doc page would be just awesome, instead of this “please reverse-engineer using a test service” approach. 
why? simple: I want my colleagues to annotate all their containers / catalogs / etc., and now I have to reverse-engineer (work I have to do) and write a docs page (work I have to do), and that is just not … cool. I also might miss something, or get something wrong, etc … .
Please write some docs here.
I understand. Here is a specific example:
docker-compose.yml
version: '2'
services:
my-service:
mem_reservation: 52428800
mem_limit: 104857600
memswap_limit: 157286400
cpuset: '0, 3'
cpu_shares: 100
rancher-compose.yml
version: '2'
services:
my-service:
milli_cpu_reservation: 500
Note: Apparently the mili_cpu_reservation has to go inside the rancher-compose.yml because it is not an official docker setting.
I hope this is more helpful. Sorry about that. 
nothing to be sorry about - unless you’re part of the crew which writes Rancher docs 
.
in any case - really helpful example, thanks very much! is there any source about the milli_cpu_reservation I can read up? and how it is different from the cpu_shares settin in the docker-compose file?
Honestly, I haven’t found a whole lot of real documentation on these parameters. The docker engine reference’s only description for cpu_shares is “CPU shares (relative weight)”. As for mili_cpu_reservation, due to the fact that it has to go in the rancher-compose.yml, I’m pretty sure that it is Rancher specific, and I haven’t seen any Rancher docs on any of these parameters.
Here is my understanding ( though it is mostly a guess ) :
mili_cpu_reservation is like mem_reservation and is used by the scheduler to decide whether or not a host has enough CPU to host a container. For example: if you had a container with a mili_cpu_reservation: 2000 ( i.e. 2 CPUs ), then it wouldn’t put that container on a host with only 1 CPU.cpu_shares is a relative weight for the priority that a container has on the CPU. For example: if two containers have the same number of shares, they should both get an equal share of the processor. If one has more than the other, the one with more should get more of the processor’s time.That’s just my best guess so don’t take me as an authority on the subject.
so happy that I’m not the only one confused about this. sure I can read up on the docker settings, but like you said - it’s rancher-compose.yml that’s holding mili_cpu_reservation, so I’d expect a bit of documentation from rancher folks here. I have guessed the same, but I really don’t like guessing.
we are heavily bound to cattle for the moment, so this lack of docs is hurting us a bit cause I really want to start using resource-based scheduling for our services. we had a couple of problems with containers running amok (for various reasons), and my personal goal is to provide an environment where this can’t happen any more, because the scheduler makes somewhat intelligent decisions based on resource usage. I probably can restrict docker to kill the container on resource over-use, but that does not solve the problem that the scheduler can still “overload” a host with too many containers.
@vincent / @denise / etc. (randomly adressing rancher staff here ;)) - any comments about information sources? or your plans on how to develop this? current state? you put this in the release notes, so I naturally want to use it assuming that it is widely available.
(p.s.: Please don’t refer to the UI. that’s not the “right” way to control resource restrictions … it should be done in the catalog entries IMHO)
(p.p.s: also a super simple example might be all that is needed, and sorry if there is one and I didn’t find it yet - but on the scheduling docs page mentioned in the post of VAdamec above the string “cpu” or “resource” does not appear even once)
Hi,
my findings about resource based scheduling with cattle are:
Memory reservation can be set through UI and docker-compose.yml file. CPU reservations should be possible in the UI and the rancher-compose.yml file (for later I opened an issue: https://github.com/rancher/rancher/issues/8545 )
nothing (for memory you can use the memory limit)
no you can’t see it but in the db (a join of instance,host over instance_host_map in the DB)
no (except DB level)
nothing happens, you can’t query this, no webhook…
So far my findings.
Reservations affect only scheduling. Each host has a total amount of RAM/CPU available, and every container which has reservations subtract from the available amount. If there is no host with the requested amount available, scheduling fails. If a container does not specify any reservation, then nothing is subtracted.
None of this affects how much resource a container can actually use, which there are separate limit settings for.