Difference between revisions of "ReddwarfUsingHeat"
(→Explainings) |
(→Explainings) |
||
Line 33: | Line 33: | ||
=====Current high level provisioning===== | =====Current high level provisioning===== | ||
# api calls task manager | # api calls task manager | ||
− | # task manager creates instance and volume (if volume support enabled) | + | # '''''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 | # 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 receives message saying it is a ______ database (in this case its MySQL) | ||
Line 41: | Line 39: | ||
## guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [2] | ## guest secures db in whatever way it deems necessary for security (queries, privs, etc, etc..) [2] | ||
## guest informs TM that its done | ## 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 | # TM changes status of instance to active | ||
Line 48: | Line 48: | ||
=====With Heat high level provisioning===== | =====With Heat high level provisioning===== | ||
# api calls task manager | # api calls task manager | ||
− | # task manager instructs to heat to create instance w/ or w/o a volume | + | # '''''ASYNC''''' task manager instructs to heat to create instance w/ or w/o a volume |
## heat creates volume/instance | ## heat creates volume/instance | ||
## heat installs db software | ## heat installs db software |
Revision as of 20:56, 3 May 2013
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
- 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. Its 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 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.