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 [pshchelokovs...@mirantis.com] Received: Wednesday, 08 Apr 2015, 16:59 To: OpenStack Development Mailing List (not for usage questions) [openstack-dev@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.koff...@alcatel-lucent.com<mailto:noa.koff...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ 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
