<div dir="ltr">Hi Noa,<div><br></div><div>would you kindly propose this blueprint as a spec in heat-specs project on <a href="http://review.openstack.org">review.openstack.org</a>? It is way easier to discuss specs in a Gerrit review format than in ML. If you need a help with submitting a spec for a review, come to our IRC channel (#heat at <a href="http://freenode.net">freenode.net</a>), we'll gladly help you with that.</div><div><br></div><div>Best regards,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div>
<br><div class="gmail_quote">On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) <span dir="ltr"><<a href="mailto:noa.koffman@alcatel-lucent.com" target="_blank">noa.koffman@alcatel-lucent.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
I would like to suggest a blueprint to allow locking/protecting a<br>
stack. Similar to: nova server "lock" or glance-image "--is-protected"<br>
flag.<br>
Once a stack is locked, the only operation allowed on the stack is<br>
"unlock" - heat engine should reject any stack operations and ignore<br>
signals that modify the stack (such as scaling).<br>
<br>
The lock operation should have a "lock_resources" flag (default = True):<br>
When True: perform heat lock and enable lock/protect for each stack<br>
resource that supports it (nova server, glance image,...).<br>
when False: perform heat lock - which would lock the stack and all<br>
nested stacks (actions on resources will not be effected).<br>
<br>
Use-cases:<br>
1. we received several requests from application vendors, to allow<br>
"maintenance mode" for the application. When in maintenance no topology<br>
changes are permitted. For example a maintenance mode is required for<br>
a clustered DB app that needs a manual reboot of one of its servers -<br>
when the server reboots all the other servers are redistributing the<br>
data among themselves which causes high CPU levels which in turn might<br>
cause an undesired scale out (which will cause another CPU spike and so<br>
on...).<br>
2. some cloud-admins have a configuration stack that initializes the<br>
cloud (Creating networks, flavors, images, ...) and these resources<br>
should always exist while the cloud exists. Locking these configuration<br>
stacks, will prevent someone from accidently deleting/modifying the<br>
stack or its resources.<br>
<br>
This feature might even raise in significance, once convergence phase 2<br>
is in place, and many other automatic actions are performed by heat.<br>
The ability to manually perform admin actions on the stack with no<br>
interruptions is important.<br>
<br>
Any thoughts/comments/suggestions are welcome.<br>
<br>
Thanks<br>
Noa Koffman.<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>