Open Stack

Consider the example at 
https://docs.google.com/drawings/d/1nridrUUwNaDrHQoGwSJ_KXYC7ik09wUuV3vXw1MyvlY

We could indeed have distinct policy objects.  But I think they are policy 
*uses*, not policy *definitions* --- which is why is prefer to give them 
less prominent lifecycles.  In the example cited above, one policy use 
object might be: {id: <some int>, type: anti_collocation, properties: 
{level: rack}}, and there are four references to it; another policy use 
object might be {id: <some int>, type: network_reachability}, and there 
are three references to it.  What object should own the policy use 
objects?  You might answer that policy uses are owned by groups.  I do not 
think it makes sense to give them a more prominent lifecycle.  As I said, 
my preference would be to give them a less prominent lifecycle.  I would 
be happy to see each policy use owned by an InstanceGroupPolicy[Use] that 
references it and allow only one reference per policy use --- in other 
words, make the InstanceGroupPolicy[Use] class inherit from the Policy Use 
class.  And since I am not proposing that anything else inherit from the 
Policy Use class, I would even more prefer to see its contents simply 
merged inline into the InstanceGroupPolicy[Use] class.

Regards,
Mike



From:   "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
To:     Mike Spreitzer/Watson/IBM at IBMUS, 
Cc:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>
Date:   10/14/2013 01:38 PM
Subject:        Re: [scheduler] Policy Model



Mike, 

Like I proposed in my previous email about the model and the APIs, 

About the InstanceGroupPolicy, why not leave it as is, and introduce a new 
abstract model class called Policy. 
The InstanceGroupPolicy will be a reference to a Policy object saved 
separately. 
and the "policy" field will point to the saved Policy object's unique name 
or id. 

The new class Policy – can have the usual fields – id, name, uuid, and a 
dictionary of key-value pairs for any additional arguments about the 
policy. 

This is in alignment with the model for InstanceGroupMember, which is a 
reference to an actual Instance Object saved in the DB. 

I will color all the diamonds black to make it a composition I the UML 
diagram. 

Thanks,
Yathi. 







From: Mike Spreitzer <mspreitz at us.ibm.com>
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi <yudupi at cisco.com>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: [scheduler] Policy Model

Could we agree on the following small changes to the model you posted last 
week?

1.  Rename InstanceGroupPolicy to InstanceGroupPolicyUse

2.  In InstanceGroupPolicy[Use], rename the "policy" field to 
"policy_type"

3.  Add an InstanceGroupPolicyUseProperty table, holding key/value pairs 
(two strings) giving the properties of the policy uses

4.  Color all the diamonds black 

Thanks, 
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131014/24919669/attachment.html>