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)" <yud...@cisco.com> To: Mike Spreitzer <mspre...@us.ibm.com>, Cc: OpenStack Development Mailing List <openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
