Open Stack

Hi Noa,

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. If you need a help with submitting a spec for a review,
come to our IRC channel (#heat at freenode.net), we'll gladly help you with
that.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Apr 8, 2015 at 3:43 PM, KOFFMAN, Noa (Noa) <
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://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/20150408/3ce689ca/attachment.html>