ds,
Alex
From: "Yathiraj Udupi (yudupi)"
To: Mike Spreitzer ,
Cc: OpenStack Development Mailing List
Date: 15/10/2013 07:33 AM
Subject: Re: [openstack-dev] [scheduler] Policy Model
The Policy model object has a lifecycle of its own. This is because this
policy
The Policy model object has a lifecycle of its own. This is because this
policy object can possibly be used outside the scope of the InstanceGroup
effort. Hence I don't see a problem in a policy administrator, or any
user, if allowed, to maintain this set of policies outside the scope of
Instance
"Yathiraj Udupi (yudupi)" 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: {lev
I still think, it is better to have the InstanceGroupPolicy model to store
references to actual Policy objects that can have their own lifecycle. I am
still finding it hard to understand, as to why you emphasize on "uses". Each
InstanceGroupPolicy object stored in the DB is an instance of th
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
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 poi
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 s
