Consider the example at
https://docs.google.com/drawings/d/1nridrUUwNaDrHQoGwSJ_KXYC7ik09wUuV3vXw1MyvlY
We could indeed have distinct policy objects. But I think they are policy
*uses*, not policy *definitions* --- which is why is prefer to give them
less prominent lifecycles. In the example cited above, one policy use
object might be: {id: <some int>, type: anti_collocation, properties:
{level: rack}}, and there are four references to it; another policy use
object might be {id: <some int>, type: network_reachability}, and there
are three references to it. What object should own the policy use
objects? You might answer that policy uses are owned by groups. I do not
think it makes sense to give them a more prominent lifecycle. As I said,
my preference would be to give them a less prominent lifecycle. I would
be happy to see each policy use owned by an InstanceGroupPolicy[Use] that
references it and allow only one reference per policy use --- in other
words, make the InstanceGroupPolicy[Use] class inherit from the Policy Use
class. And since I am not proposing that anything else inherit from the
Policy Use class, I would even more prefer to see its contents simply
merged inline into the InstanceGroupPolicy[Use] class.
Regards,
Mike
From: "Yathiraj Udupi (yudupi)" <yud...@cisco.com>
To: Mike Spreitzer/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List
<openstack-dev@lists.openstack.org>
Date: 10/14/2013 01:38 PM
Subject: Re: [scheduler] Policy Model
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>
Date: Monday, October 14, 2013 7:14 AM
To: Yathiraj Udupi <yud...@cisco.com>
Cc: OpenStack Development Mailing List <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
