ReddwarfUsingHeat
Contents
Reddwarf using heat
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?
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
- api calls task manager
- ASYNC task manager creates instance and volume (if volume support enabled)
- instance is booted, guest is either 1) installed in some way [1], or 2) already on image
- guest receives message saying it is a ______ database (in this case its MySQL)
- guest installs db software, generates a user, os_admin, w root privs
- guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [2]
- guest informs TM that its done
- task manager puts a message in the guest queue
- task manager waits for guest to finish "prepare"
- 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
- api calls task manager
- ASYNC task manager instructs to heat to create instance w/ or w/o a volume
- heat creates instance and volume as necessary
- heat installs db software
- heat sets os_admin user/pass (if possible)
- heat installs guest, heat signals to task manager its finished
- guest takes over
- guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [ see 2 above ]
- guest informs TM that its done
- task manager puts message in guest queue
- task manager waits for heat to finish installation
- task manager gets message heat is done, waits for guest to finish securing mysql
- TM changes status of instance to active