Ruby,

The Custom constraint class was something Yathiraj mentioned a while back.  But 
yes the idea is that MemoryCapacityConstraint would be a special case of what 
we can express in the custom constraints.

Tim


On Mar 18, 2015, at 10:05 AM, 
ruby.krishnasw...@orange.com<mailto:ruby.krishnasw...@orange.com> wrote:

Hello

o) custom constraint class
What did you mean by the “custom” constraint class?

  Did you mean we specify a “meta model” to specify constraints?  And then each 
“Policy” specifying a constraint  ( ) will lead to generation of the constraint 
in that meta-model.
Then the solver-scheduler could pick up the constraint?

This then will not require the “solver scheduler” to implement specific 
constraint classes such as “MemoryCapacityConstraint”.

We may have rules (not in sense of Datalog ☺ ) for name (e.g. variables or 
constants) generation?


Ruby

De : Tim Hinrichs [mailto:thinri...@vmware.com]
Envoyé : mercredi 18 mars 2015 16:34
À : OpenStack Development Mailing List (not for usage questions)
Objet : Re: [openstack-dev] [Congress] [Delegation] Meeting scheduling

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) 
<yud...@cisco.com<mailto:yud...@cisco.com>> 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" 
<thinri...@vmware.com<mailto:thinri...@vmware.com>> 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: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to