"Yathiraj Udupi (yudupi)" <yud...@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_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
