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/resize
- 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
- 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
- Heat is going thru a refactor in the next cycle
- There is much talk of a dsl, and many improvements to heat in the next cycle
- Its understood that heat is stable enough to be put in now
- Keep a stable reddwarf api w/o many architecture changes
- 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?
Explainings
The way i see it, reddwarf will talk to heat to provision single instances and clusters.
Current high level provisioning
- api calls task manager
- task manager creates instance and volume (if volume support enabled)
- task manager puts a message in the guest queue
- task manager waits for guest to finish "prepare"
- 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
- 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. Its a secure instance.
With Heat high level provisioning
- api calls task manager
- task manager instructs to heat to create instance w/ or w/o a volume
- heat creates volume/instance
- 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
Heat vastly simplifies the installation process of mysql, and lets our guest focus on what it needs to, securing the db.