<tt><font size=2>"Yathiraj Udupi (yudupi)" <yudupi@cisco.com>
wrote on 10/14/2013 11:43:34 PM:<br>
<br>
> ... </font></tt>
<br><tt><font size=2>> <br>
> For the policy model, you can expect rows in the DB each <br>
> representing different policy instances something like- </font></tt>
<br>
<br><tt><font size=2>>  {id: 1111, uuid: "SOME-UUID-1",
name: "anti-colocation-1",  type: <br>
> "anti-colocation", properties: {level: "rack"}}</font></tt>
<br>
<br><tt><font size=2>>  {id: 2222, uuid: "SOME-UUID-2",
name: "anti-colocation-2",  type: <br>
> "anti-colocation", properties: {level: "PM"}}</font></tt>
<br>
<br><tt><font size=2>>  {id: 3333, uuid: "SOME-UUID-3",
name: "network-reachabilty-1",  <br>
> type: "network-reachability" properties: {}}</font></tt>
<br><tt><font size=2>> <br>
> And for the InstanceGroupPolicy model, you can expect rows such as
</font></tt>
<br>
<br><tt><font size=2>> {id: 55555, policy: "SOME-UUID-1",
type: "group", edge_id: "", <br>
> group_id: 12345}</font></tt>
<br>
<br><tt><font size=2>> {id: 66666, policy: "SOME-UUID-1",
type: "group", edge_id: "", <br>
> group_id: 22334} </font></tt>
<br>
<br><tt><font size=2>Do you imagine just one policy object of a given contents,
or many?  Put another way, would every InstanceGroupPolicy object
that wants to apply a rack-level anti-collocation policy use SOME-UUID-1?</font></tt>
<br>
<br><tt><font size=2>Who or what created the record with id 1111?  Who
or what decides to delete it, and when and why?  What about dangling
references?  It seems to me that needing to answer these questions
simply imposes unnecessary burdens.  If the "type" and "properties"
fields of record id 1111 were merged inline (replacing the policy:SOME-UUID-1
field) into records id 5555, 6666, and the other uses, then there are no
hard questions to answer; the group author knows what policies he wants
to apply and where, and he simply writes them there.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>