[openstack-dev] [heat] suggestion for lock/protect stack blueprint

KOFFMAN, Noa (Noa) noa.koffman at alcatel-lucent.com
Thu Apr 9 19:07:01 UTC 2015


Hey everyone,


Regarding the lock-stack blueprint, Following Steve and Pavlo's
suggestions, I created the following blueprint in heat-specs.

This is the launchpad link:

https://blueprints.launchpad.net/heat/+spec/lock-stack

on Wed, Apr 8, 2015 at 4:54 PM Steve Hardy wrote:
>We might consider making this a stack >"action", e.g like suspend/resume -
>actions are intended for stack-wide >operations which affect the stack state
>but not it's definition, so it seems like >potentially a good fit


on Wed, Apr 8, 2015 at 4:59 PM Pavlo Shchelokovskyy wrote:
>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.


I would appriciate any comment, suggestions and reviews

Thanks

Noa Koffman

Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-----Original Message-----
From: Pavlo Shchelokovskyy [pshchelokovskyy at mirantis.com]
Received: Wednesday, 08 Apr 2015, 16:59
To: OpenStack Development Mailing List (not for usage questions) [openstack-dev at lists.openstack.org]
Subject: Re: [openstack-dev] [heat] suggestion for lock/protect stack blueprint

Hi Noa,

would you kindly propose this blueprint as a spec in heat-specs project on review.openstack.org<http://review.openstack.org>? 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 freenode.net<http://freenode.net>), we'll gladly help you with that.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com<http://www.mirantis.com>

On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) <noa.koffman at alcatel-lucent.com<mailto:noa.koffman at alcatel-lucent.com>> wrote:
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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/031f5168/attachment.html>


More information about the OpenStack-dev mailing list