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 <mspre...@us.ibm.com<mailto:mspre...@us.ibm.com>> Date: Monday, October 14, 2013 7:14 AM To: Yathiraj Udupi <yud...@cisco.com<mailto:yud...@cisco.com>> Cc: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
