Open Stack

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 <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>>
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi <yudupi at cisco.com<mailto:yudupi at cisco.com>>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131014/4b71ae3b/attachment.html>