Open Stack

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 <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>>
Date: Monday, October 14, 2013 7:12 PM
To: Yathiraj Udupi <yudupi at cisco.com<mailto:yudupi at cisco.com>>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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)" <yudupi at cisco.com<mailto:yudupi at cisco.com>>
To:        Mike Spreitzer/Watson/IBM at IBMUS,
Cc:        OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto: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<mailto:mspreitz at us.ibm.com>>
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi <yudupi at cisco.com<mailto:yudupi at cisco.com>>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto: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/20131015/9e173df8/attachment.html>