Difference between revisions of "ReddwarfUsingHeat"
(→Risks) |
(→Risks) |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 18: | Line 18: | ||
====Risks==== | ====Risks==== | ||
− | + | * Keep a stable reddwarf api without many architecture changes | |
− | |||
− | |||
− | * Keep a stable reddwarf api | ||
** The guest install flow will be different, but not drastically. Also the same w/ the creation of the instance. | ** 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 | * Make it optional for time being | ||
Line 28: | Line 25: | ||
** flags for all new builds require heat, and eventually deprecate / remove non heat support | ** flags for all new builds require heat, and eventually deprecate / remove non heat support | ||
*** n+1?, or to graduate incubation? | *** 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===== | =====Current high level provisioning===== | ||
Line 44: | Line 46: | ||
# task manager waits for guest to finish "prepare" | # task manager waits for guest to finish "prepare" | ||
# TM changes status of instance to active | # 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... | [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. | + | |
+ | [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===== | =====With Heat high level provisioning===== | ||
# api calls task manager | # api calls task manager | ||
# '''''ASYNC''''' 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 instance and volume as necessary | |
## heat installs db software | ## heat installs db software | ||
## heat sets os_admin user/pass (if possible) | ## heat sets os_admin user/pass (if possible) |
Latest revision as of 18:38, 7 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
- 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.
- We need to make sure that an installer can stand up reddwarf w/o a hard dependency on heat
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