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) < [email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
