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
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
Yathiraj Udupi (yudupi) yud...@cisco.com wrote on 10/14/2013 11:43:34
PM:
...
For the policy model, you can expect rows in the DB each
representing different policy instances something like-
{id: , uuid: SOME-UUID-1, name: anti-colocation-1, type:
anti-colocation, properties:
Udupi (yudupi) yud...@cisco.com
To: Mike Spreitzer mspre...@us.ibm.com,
Cc: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: 15/10/2013 07:33 AM
Subject:Re: [openstack-dev] [scheduler] Policy Model
The Policy model object has a lifecycle of its own
