It's too difficult to understand your interoperability perspective. I think carefully that situation will not be occurred. because My suggestion isn't disturb the current behavior.
I just add a configuration file, and add a check logic, If there is no configuration file, nova-api execute current behavior normally. 2014-02-04 Russell Bryant <rbry...@redhat.com>: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
