Comment 2 for bug 1704788

Agreed with Matt about a communication problem.
The Ocata consensus was about to say that we would stop using custom drivers also for scheduler, but still accepting custom filters (so people wanting to have a specific driver could just create a filter for the FilterScheduler that would be calling the 3rd-party driver).

That said, what could we do ? I'm not sure modifying the [scheduler]/driver option for accepting strings instead of choices (the string being the entrypoint name in setup.cfg) should be acceptable because that would mean we would go against the consensus we had in Ocata.

The real problem is that we previously accepted people to not use our scheduler drivers without asking them why they don't use them. Is that because something is missing for being verified ? Is that because people would want a different scheduler behaviour (for example say a shared-state scheduler or a two-level scheduler like Mesos) ?

Now that we have Placement in Ocata for making sure that hosts being verified by the filters are all accepting resource requests for RAM, disk and CPU, I still do think we can explicitly say to people wanting to use a totally separate scheduler logic to discuss with us why they need that. I honestly think there is room for improvement about custom logics.