On 02/03/2014 07:25 PM, Jae Sang Lee wrote: > Hi, Stackers. > > The deadline for icehouse comes really quickly and I understand that there > are a lot of work todo, but I would like get your attention about my > blueprint for configurable locked vm api. > > - https://blueprints.launchpad.net/nova/+spec/configurable-locked-vm-api > > So far, developer places the decoration(@check_instance_lock) in the > function's declaration, > for example) > @wrap_check_policy > @check_instance_lock > @check_instance_cell > @check_instance_state(vm_state=None, task_state=None, > must_have_launched=False) > def delete(self, context, instance): > """Terminate an instance.""" > LOG.debug(_("Going to try to terminate instance"), > instance=instance) > self._delete_instance(context, instance) > > So good, but when administrator want to change API policy for locked vm, > admin must modify source code, and restart. > > I suggest nova api do check api list for locked vm using config file > like policy.json. It just modify a config file, not a code > and don't need to service restart. > > Can you take a small amount of time to approve a blueprint for icehouse-3?
I'm concerned about this idea from an interop perspective. It means that "lock" will not mean the same thing from one cloud to another. That seems like something we should avoid. One thing that might work is to do this from the API side. We could allow the caller of the API to list which operations are locked. The default behavior would be the current behavior of locking all operations. That gives some flexibility and keeps the API call working the same way across clouds. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
