<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I still think, it is better to have the <b>InstanceGroupPolicy </b>model to store references to actual
<b>Policy</b> 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
<b>Policy</b> objects are also instances of a <b>Policy</b> 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. </div>
<div><br>
</div>
<div>Why have a separate InstanceGroupPolicy model ?</div>
<div> This is because it lets us assign a policy object to an InstanceGroup as a whole, or to an InstanceGroupMemberConnection. The
<b>Policy</b> 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. </div>
<div><br>
</div>
<div>For the policy model, you can expect rows in the DB each representing different policy instances something like- </div>
<div> {id: 1111, uuid: "SOME-UUID-1", name: "anti-colocation-1", type: "anti-colocation", properties: {level: "rack"}}</div>
<div>
<div> {id: 2222, uuid: "SOME-UUID-2", name: "anti-colocation-2", type: "anti-colocation", properties: {level: "PM"}}</div>
</div>
<div>
<div> {id: 3333, uuid: "SOME-UUID-3", name: "network-reachabilty-1", type: "network-reachability" properties: {}}</div>
</div>
<div><br>
</div>
<div>And for the InstanceGroupPolicy model, you can expect rows such as </div>
<div>{id: 55555, policy: "SOME-UUID-1", type: "group", edge_id: "", group_id: 12345}</div>
<div>{id: 66666, policy: "SOME-UUID-1", type: "group", edge_id: "", group_id: 22334} </div>
<div><br>
</div>
<div>Regards,</div>
<div>Yathi. </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>><br>
<span style="font-weight:bold">Date: </span>Monday, October 14, 2013 7:12 PM<br>
<span style="font-weight:bold">To: </span>Yathiraj Udupi <<a href="mailto:yudupi@cisco.com">yudupi@cisco.com</a>><br>
<span style="font-weight:bold">Cc: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [scheduler] Policy Model<br>
</div>
<div><br>
</div>
<div>
<div><font size="2" face="sans-serif">Consider the example at </font><a href="https://docs.google.com/drawings/d/1nridrUUwNaDrHQoGwSJ_KXYC7ik09wUuV3vXw1MyvlY"><font size="2" face="sans-serif">https://docs.google.com/drawings/d/1nridrUUwNaDrHQoGwSJ_KXYC7ik09wUuV3vXw1MyvlY</font></a><br>
<br>
<font size="2" face="sans-serif">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.</font><br>
<br>
<font size="2" face="sans-serif">Regards,</font> <br>
<font size="2" face="sans-serif">Mike</font> <br>
<br>
<br>
<br>
<font size="1" color="#5f5f5f" face="sans-serif">From: </font><font size="1" face="sans-serif">"Yathiraj Udupi (yudupi)" <<a href="mailto:yudupi@cisco.com">yudupi@cisco.com</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">To: </font><font size="1" face="sans-serif">Mike Spreitzer/Watson/IBM@IBMUS,
</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Cc: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Date: </font><font size="1" face="sans-serif">10/14/2013 01:38 PM</font><br>
<font size="1" color="#5f5f5f" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [scheduler] Policy Model</font><br>
<hr noshade="">
<br>
<br>
<br>
<font size="2" face="Calibri">Mike, </font><br>
<br>
<font size="2" face="Calibri">Like I proposed in my previous email about the model and the APIs,
</font><br>
<br>
<font size="2" face="Calibri">About the InstanceGroupPolicy, why not leave it as is, and introduce a new abstract model class called Policy. </font><br>
<font size="2" face="Calibri">The InstanceGroupPolicy will be a reference to a Policy object saved separately.
</font><br>
<font size="2" face="Calibri">and the "policy" field will point to the saved Policy object's unique name or id.
</font><br>
<br>
<font size="2" face="Calibri">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.
</font><br>
<br>
<font size="2" face="Calibri">This is in alignment with the model for InstanceGroupMember, which is a reference to an actual Instance Object saved in the DB.
</font><br>
<br>
<font size="2" face="Calibri">I will color all the diamonds black to make it a composition I the UML diagram.
</font><br>
<br>
<font size="2" face="Calibri">Thanks,</font> <br>
<font size="2" face="Calibri">Yathi. </font><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<font size="2" face="Calibri"><b>From: </b>Mike Spreitzer <</font><a href="mailto:mspreitz@us.ibm.com"><font size="2" color="blue" face="Calibri"><u>mspreitz@us.ibm.com</u></font></a><font size="2" face="Calibri">><b><br>
Date: </b>Monday, October 14, 2013 7:14 AM<b><br>
To: </b>Yathiraj Udupi <</font><a href="mailto:yudupi@cisco.com"><font size="2" color="blue" face="Calibri"><u>yudupi@cisco.com</u></font></a><font size="2" face="Calibri">><b><br>
Cc: </b>OpenStack Development Mailing List <</font><a href="mailto:openstack-dev@lists.openstack.org"><font size="2" color="blue" face="Calibri"><u>openstack-dev@lists.openstack.org</u></font></a><font size="2" face="Calibri">><b><br>
Subject: </b>[scheduler] Policy Model</font> <br>
<br>
<font size="2" face="sans-serif">Could we agree on the following small changes to the model you posted last week?</font><font size="2" face="Calibri"><br>
</font><font size="2" face="sans-serif"><br>
1. Rename InstanceGroupPolicy to InstanceGroupPolicyUse</font><font size="2" face="Calibri"><br>
</font><font size="2" face="sans-serif"><br>
2. In InstanceGroupPolicy[Use], rename the "policy" field to "policy_type"</font><font size="2" face="Calibri"><br>
</font><font size="2" face="sans-serif"><br>
3. Add an InstanceGroupPolicyUseProperty table, holding key/value pairs (two strings) giving the properties of the policy uses</font><font size="2" face="Calibri"><br>
</font><font size="2" face="sans-serif"><br>
4. Color all the diamonds black</font><font size="2" face="Calibri"> <br>
</font><font size="2" face="sans-serif"><br>
Thanks,</font><font size="2" face="Calibri"> </font><font size="2" face="sans-serif"><br>
Mike</font> <br>
</div>
</div>
</span>
</body>
</html>