Adding support for Orchestration


#1

##Goal##
We are planning to add support of cloud orchestration, i.e., AWS CloudFormation (CFN) and OpenStack Heat. The first phase is to discover stacks and allow users to deploy stacks from templates.

##Introduction##
The AWS CloudFormation and OpenStack Orchestration APIs are centered around stacks, not templates. A template defines resources to be created, instructions how to create them, and parameters needed for actual generation. A stack is a deployed instance of a template. A template does not have a name, it is passed to the stack creation api as an argument in the form of a JSON string, a URL, a URI, or an Object. Stacks however are named. Their corresponding templates are stored with the stacks. CFN APIs can discover existing stacks, retrieve a stack’s template, parameters, resulting resources, stack events, and stack output. Stacks deleted in the past 60 days can be listed, but details (templates, parameters etc.) are not retrievable.

##Features adding to ManageIQ##
Therefore ManageIQ discovery process can only discover stacks and add them to its inventory. We should allow users to create a new stack based on one of the existing stacks. Before deployment the user should be able to view and edit the template retrieved from the existing stack. The user can also provide a new template through a text editor, reading from a local file, or pointing to an url/uri.

CFN template well defines parameters that are needed or optioned in order to deploy a stack. The descriptions can help us render a proper dialog for user inputs.

##Should ManageIQ manage templates?##
###Existing templates###
Since templates are not managed by the cloud, we may add this function to ManageIQ. When stacks are discovered and added to the inventory, their templates can be retrieved and stored too. Since templates are not originally names, we can auto name them by the stack name. Multiple stacks could have been created from the same template, should duplicated templates be identified by the contents? Then template naming will be a problem.

###New templates###
The user should be able to add new templates that have not yet deployed to the cloud. These templates are named by the user. When such a template is deployed to cloud as a stack, it will be added back to the inventory through the stack discovery process. It certainly is a duplicate.

##Modeling##
A new table for stacks is needed. Templates should be saved in stack table or a separated template table, depending on whether we should manage templates.

Cloud resources such as instances (vms table) should have associations with stacks (and templates)