Hey,

I would like to suggest a blueprint to allow locking/protecting a 
stack. Similar to: nova server "lock" or glance-image "--is-protected" 
flag.
Once a stack is locked, the only operation allowed on the stack is 
"unlock" - heat engine should reject any stack operations and ignore 
signals that modify the stack (such as scaling).

The lock operation should have a "lock_resources" flag (default = True):
When True: perform heat lock and enable lock/protect for each stack 
resource that supports it (nova server, glance image,...).
when False: perform heat lock - which would lock the stack and all 
nested stacks (actions on resources will not be effected).

Use-cases:
1. we received several requests from application vendors, to allow 
"maintenance mode" for the application. When in maintenance no topology 
changes are permitted. For example a maintenance mode is required for 
a clustered DB app that needs a manual reboot of one of its servers - 
when the server reboots all the other servers are redistributing the 
data among themselves which causes high CPU levels which in turn might 
cause an undesired scale out (which will cause another CPU spike and so 
on...).
2. some cloud-admins have a configuration stack that initializes the 
cloud (Creating networks, flavors, images, ...) and these resources 
should always exist while the cloud exists. Locking these configuration 
stacks, will prevent someone from accidently deleting/modifying the 
stack or its resources.

This feature might even raise in significance, once convergence phase 2 
is in place, and many other automatic actions are performed by heat. 
The ability to manually perform admin actions on the stack with no 
interruptions is important.

Any thoughts/comments/suggestions are welcome.

Thanks   
Noa Koffman.



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to