<font size=2 face="sans-serif">I would suggest not to generalize too much..
e.g., restrict the discussion to PlacementPolicy. If anyone else would
want to use a similar construct for other purposes -- it can be generalized
later.</font>
<br><font size=2 face="sans-serif">For example, the notion of 'policy'
already exists in other places in OpenStack in the context of security,
and we also plan to introduce a different kind of 'policies' for scheduler
configurations in different managed domains (e.g., aggregates), but I wonder
whether it is important (or makes sense) making all of them 'inherit' from
the same base model.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Yathiraj Udupi
(yudupi)" <yudupi@cisco.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Mike Spreitzer <mspreitz@us.ibm.com>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">15/10/2013 07:33 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[scheduler] Policy Model</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>The Policy model object has a lifecycle of its own.
 This is because this<br>
policy object can possibly be used outside the scope of the InstanceGroup<br>
effort.  Hence I don't see a problem in a policy administrator, or
any<br>
user, if allowed, to maintain this set of policies outside the scope of<br>
InstanceGroups.  <br>
<br>
However a group author will maintain the InstanceGroupPolicy objects, and<br>
refer a policy that is appropriate to his requirement.  If a new Policy<br>
object needs to be registered for a new requirement, that has to be done<br>
by this user, if allowed.<br>
<br>
About your question regarding dangling references, that situation should<br>
not be allowed,  hence a delete of the Policy object should not be<br>
allowed, if there is some other object referring it. This can be<br>
implemented right, by adding a proper association between the models.<br>
<br>
This way, a generic Policy model can apply to other scenarios that may<br>
come up in Openstack.<br>
<br>
Regards,<br>
Yathi. <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>