Icehouse Design Summit

Problem determination for template deployment is currently limited to logging. The user can set different level of verbosity in the log and typically has to rerun the deployment multiple times to debug the problems. Based on our experience with template development and debugging, as well as feedback from customers, we propose employing the concept of live debugger that is common in software development. A template, e.g. HOT, would be treated at a program, and the user can use the debugger to break into the deployment at the point of error or other points to inspect the partial stack, resources, environment, scripts, etc. During the debugging session, the deployment would be paused and the user can control the execution with single stepping, resuming, etc. User can enter the debugger by different methods: (1) break on error, (2) set breakpoints, (3) attach to a template being deployed.
The declarative nature of HOT and the concurrent deployment do present some challenges, making the debugger somewhat different from a typical program debugger. We also want to handle activation (cloud-init, cfn-init) and configuration managers used in the template (Chef, Puppet) in a seamless manner as if they are part of the template.

Heat can greatly reduce the amount of work cloud administrator has to deal with if everything goes well. However, things can get quite complicated when the automation process fails at some point. Users of Heat have to login every VMs (could be many) to figure what went wrong by examing the cloud-init and tools logs. So a way to retrieve the cloud-init and tools logs to let users to exam conveniently is desired, which is what this proposal tries to address.

(Session proposed by Thoms Spatzier)