But we have a working-not-yet-exposed HTTP admin api on the controller that allows for Out Of Band placement.
so the mechanics are there, but not yet integrated w/ the partition allocator.
Thinking that we integrate w/ k8s more deeply next year.
The thinking at least is that at install we generate some machine labels say in /etc/redpanda/labels.json or smth like that and then the partition allocator can take simple constraints.
I worked on a few schedulers for www.concord.io with Fenzo on top of mesos 6 years ago and this worked nicely for both 'affinity', 'soft affinity' and anti-affinity constraints.
Do you have any thoughts on how you'd like this exposed?
So currently the partition allocator - https://github.com/vectorizedio/redpanda/blob/dev/src/v/clus... - is primitive.
But we have a working-not-yet-exposed HTTP admin api on the controller that allows for Out Of Band placement.
so the mechanics are there, but not yet integrated w/ the partition allocator.
Thinking that we integrate w/ k8s more deeply next year.
The thinking at least is that at install we generate some machine labels say in /etc/redpanda/labels.json or smth like that and then the partition allocator can take simple constraints.
I worked on a few schedulers for www.concord.io with Fenzo on top of mesos 6 years ago and this worked nicely for both 'affinity', 'soft affinity' and anti-affinity constraints.
Do you have any thoughts on how you'd like this exposed?