Open Stack

"Yathiraj Udupi (yudupi)" <yudupi at cisco.com> 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: 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} 

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?

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.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/c46832d2/attachment.html>