I responded in the gdoc. Here’s a copy. One of my goals for delegation is to avoid asking people to write policy statements specific to any particular domain-specific solver. People ought to encode policy however they like, and the system ought to figure out how best to enforce that policy (delegation being one option).
Assuming that's a reasonable goal, I see two options for delegation to solverScheduler (1) SolverScheduler exposes a custom constraint class. Congress generates the LP program from the Datalog, similar to what is described in this doc, and gives that LP program as custom constraints to the SolverScheduler. SolverScheduler is then responsible for enforcing that policy both during provisioning of new servers and for monitoring/migrating servers once provisioning is finished. (2) The Congress adapter for SolverScheduler understands the semantics of MemoryCapacityConstraint, identifies when the user has asked for that constraint, and replaces that part of the LP program with the MemoryCapacityConstraint. We probably want a combination of (1) and (2) so that we handle any gaps in the pre-defined constraints that SolverScheduler has, while at the same time leveraging the pre-defined constraints when possible. Tim On Mar 17, 2015, at 6:09 PM, Yathiraj Udupi (yudupi) <[email protected]<mailto:[email protected]>> wrote: Hi Tim, I posted this comment on the doc. I am still pondering over a possibility of have a policy-driven scheduler workflow via the Solver Scheduler placement engine, which is also LP based like you describe in your doc. I know in your initial meeting, you plan to go over your proposal of building a VM placement engine that subscribes to the Congress DSE, I probably will understand the Congress workflows better and see how I could incorporate this proposal to talk to the Solver Scheduler to make the placement decisions. The example you provide in the doc, is a very good scenario, where a VM placement engine should continuously monitor and trigger VM migrations. I am also interested in the case of a policy-driven scheduling for the initial creation of VMs. This is where say people will call Nova APIs and create a new set of VMs. Here the scheduler workflow should address the constraints as imposed from the user's policies. Say the simple policy is " Host's free RAM >= 0.25 * Memory_Capacity" I would like the scheduler to use this policy as defined from Congress, and apply it during the scheduling as part of the Nova boot call. I am really interested in and need help in coming up with a solution integrating Solver Scheduler, so say if I have an implementation of a "MemoryCapacityConstraint", which takes a hint value "free_memory_limit" (0.25 in this example), could we have a policy in Datalog placement_requirement(id) :- nova:host(id), solver_scheduler:applicable_constraints(id, ["MemoryCapacityConstraint", ]), applicable_metadata(id, {"free_memory_limit": 0.25, }) This policy could be set and delegated by Congress to solver scheduler via the "set_policy" API. or the Solver Scheduler can query Congress via a "get_policy" API to get this policy, and incorporate it as part of the solver scheduler workflow ? Does this sound doable ? Thanks, Yathi. On 3/16/15, 11:05 AM, "Tim Hinrichs" <[email protected]<mailto:[email protected]>> wrote: Hi all, The feedback on the POC delegation proposal has been mostly positive. Several people have asked for a meeting to discuss further. Given time zone constraints, it will likely be 8a or 9a Pacific. Let me know in the next 2 days if you want to participate, and we will try to find a day that everyone can attend. https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1ksDilJYXV-2D5AXWON8PLMedDKr9NpS8VbT0jIy-5FMIEtI_edit&d=AwMFAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=uiVXAFxgoK-F8a3oNLDykcTSmPGUMW2_kFB_BnUEBFg&s=GWRQesGone_FbZRHXZmIcQd5MB20CHkriADqVNVnxiA&e=> Thanks! Tim __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]<mailto:[email protected]>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
