Open Stack

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.
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.

Regards,
Alex




From:   "Yathiraj Udupi (yudupi)" <yudupi at cisco.com>
To:     Mike Spreitzer <mspreitz at us.ibm.com>, 
Cc:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>
Date:   15/10/2013 07:33 AM
Subject:        Re: [openstack-dev] [scheduler] Policy Model



The Policy model object has a lifecycle of its own.  This is because this
policy object can possibly be used outside the scope of the InstanceGroup
effort.  Hence I don't see a problem in a policy administrator, or any
user, if allowed, to maintain this set of policies outside the scope of
InstanceGroups. 

However a group author will maintain the InstanceGroupPolicy objects, and
refer a policy that is appropriate to his requirement.  If a new Policy
object needs to be registered for a new requirement, that has to be done
by this user, if allowed.

About your question regarding dangling references, that situation should
not be allowed,  hence a delete of the Policy object should not be
allowed, if there is some other object referring it. This can be
implemented right, by adding a proper association between the models.

This way, a generic Policy model can apply to other scenarios that may
come up in Openstack.

Regards,
Yathi. 


















_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/0f0a71ea/attachment.html>