ReddwarfUsingHeat

Main requirements

 * Not modifying the api
 * Minimizing architecture differences
 * Make it optional
 * Make sure that the nova uuid is accessible, or that all state interaction to nova is managed by heat

Benefits

 * Reddwarf instrumenting on create
 * Currently we are responsible for making sure the instance is prov'd and services are installed. this can be mitigated by using heat
 * package installation becomes a moot point. no need to write code to manage apt dependencies
 * Clustering becomes easier as heat takes care of it for us
 * Configuration is more flexible
 * If a company wants a particular image.. done.
 * If a company wants "extra" bits, like a log collection agent in the image.. done.
 * You get the picture

Risks

 * Keep a stable reddwarf api without many architecture changes
 * The guest install flow will be different, but not drastically. Also the same w/ the creation of the instance.
 * Make it optional for time being
 * need to be agile enough to still rely on the original provisioning architecture
 * need to have legacy instance support, as in, if a instance was created w/o heat, it needs to stay managed w/o heat
 * flags for all new builds require heat, and eventually deprecate / remove non heat support
 * n+1?, or to graduate incubation?
 * Not every deployed cloud is using heat
 * We need to make sure that an installer can stand up reddwarf w/o a hard dependency on heat
 * For instance, we could point reddwarf to rax or hp cloud today and it would work.

Explanation
Reddwarf will talk to heat to provision single instances and clusters. Below is the only flow that will change for reddwarf -- viz. the create (orchestrate) instance. There is no api change from the customer perspective; they are abstracted from the provisioning work required to give them a working database instance. Heat, does, however, vastly simplify the installation process of the database (eg. mysql), and lets our guest focus on what it needs to -- securing the db.

The only touch points from reddwarf into nova itself are 1) create instance, 2) resize instance, 3) check status, 4) delete instance. This is a very minimal set of interactions.

Current high level provisioning

 * 1) api calls task manager
 * 2) ASYNC task manager creates instance and volume (if volume support enabled)
 * 3) instance is booted, guest is either 1) installed in some way [1], or 2) already on image
 * 4) guest receives message saying it is a ______ database (in this case its MySQL)
 * 5) guest installs db software, generates a user, os_admin, w root privs
 * 6) guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [2]
 * 7) guest informs TM that its done
 * 8) task manager puts a message in the guest queue
 * 9) task manager waits for guest to finish "prepare"
 * 10) TM changes status of instance to active

[1] we do not mandate _how_ the guest is installed. you can rsync, cloud-init package install, etc etc etc...

[2] we dont claim this is the best solution for 102% of people, but it is a solution that works for most people right out of the gate. It's a secure instance.

With Heat high level provisioning

 * 1) api calls task manager
 * 2) ASYNC task manager instructs to heat to create instance w/ or w/o a volume
 * 3) heat creates instance and volume as necessary
 * 4) heat installs db software
 * 5) heat sets os_admin user/pass (if possible)
 * 6) heat installs guest, heat signals to task manager its finished
 * 7) guest takes over
 * 8) guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [ see 2 above ]
 * 9) guest informs TM that its done
 * 10) task manager puts message in guest queue
 * 11) task manager waits for heat to finish installation
 * 12) task manager gets message heat is done, waits for guest to finish securing mysql
 * 13) TM changes status of instance to active