<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<span style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:11pt; color:black">Hey everyone,<br>
<br>
<br>
Regarding the lock-stack blueprint, Following Steve and Pavlo's<br>
suggestions, I created the following blueprint in heat-specs.<br>
<br>
This is the launchpad link: <br>
<br>
https://blueprints.launchpad.net/heat/+spec/lock-stack<br>
<br>
on Wed, Apr 8, 2015 at 4:54 PM Steve Hardy wrote:<br>
>We might consider making this a stack >"action", e.g like suspend/resume -<br>
>actions are intended for stack-wide >operations which affect the stack state<br>
>but not it's definition, so it seems like >potentially a good fit<br>
<br>
<br>
on Wed, Apr 8, 2015 at 4:59 PM Pavlo Shchelokovskyy wrote:<br>
>would you kindly propose this blueprint >as a spec in heat-specs project on >review.openstack.org? It is way easier >to discuss specs in a Gerrit review >format than in ML.<br>
<br>
<br>
I would appriciate any comment, suggestions and reviews<br>
<br>
Thanks<br>
<br>
Noa Koffman  <br>
<br>
Sent from my Android phone using Symantec TouchDown (www.symantec.com)<br>
<br>
<span style="color:black">-----Original Message----- <br>
<b>From:</b> Pavlo Shchelokovskyy [pshchelokovskyy@mirantis.com]<br>
<b>Received:</b> Wednesday, 08 Apr 2015, 16:59<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions) [openstack-dev@lists.openstack.org]<br>
<b>Subject:</b> Re: [openstack-dev] [heat] suggestion for lock/protect stack blueprint<br>
<br>
</span></span>
<div>
<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>
</div>
</body>
</html>