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 the
InstanceGroupPolicy model. The actual Policy objects are also instances of a
Policy model. They are indeed instances of a model so I don't see a problem
keeping the name this way. The Policy model defines the name, type, id, and
properties of a specific policy. The "definition" of the Policy lies in the
actual implementation Iogic (wherever a policy is used) using the given policy
object, i.e., its policy name/type, and properties. I agree the Policy model
can have a type field, and the name can be something specific for a given
instance of the Policy model.
Why have a separate InstanceGroupPolicy model ?
This is because it lets us assign a policy object to an InstanceGroup as a
whole, or to an InstanceGroupMemberConnection. The Policy object can have its
own lifecycle, say it can still be associated to just an Instance, and can be
used while booting up that instance alone.
For the policy model, you can expect rows in the DB each representing different
policy instances something like-
{id: 1111, uuid: "SOME-UUID-1", name: "anti-colocation-1", type:
"anti-colocation", properties: {level: "rack"}}
{id: 2222, uuid: "SOME-UUID-2", name: "anti-colocation-2", type:
"anti-colocation", properties: {level: "PM"}}
{id: 3333, uuid: "SOME-UUID-3", name: "network-reachabilty-1", type:
"network-reachability" properties: {}}
And for the InstanceGroupPolicy model, you can expect rows such as
{id: 55555, policy: "SOME-UUID-1", type: "group", edge_id: "", group_id: 12345}
{id: 66666, policy: "SOME-UUID-1", type: "group", edge_id: "", group_id: 22334}
Regards,
Yathi.
From: Mike Spreitzer <mspre...@us.ibm.com<mailto:mspre...@us.ibm.com>>
Date: Monday, October 14, 2013 7:12 PM
To: Yathiraj Udupi <yud...@cisco.com<mailto:yud...@cisco.com>>
Cc: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [scheduler] Policy Model
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)"
<yud...@cisco.com<mailto:yud...@cisco.com>>
To: Mike Spreitzer/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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 <mspre...@us.ibm.com<mailto:mspre...@us.ibm.com>>
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi <yud...@cisco.com<mailto:yud...@cisco.com>>
Cc: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
