ReddwarfUsingHeat

Reddwarf using heat

Main requirements

• Not modifying the api
• Minimizing architecture differences
• Until heat has gone through its incubation, 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 a moving target
  • There is much talk of a dsl, and many improvements to heat while its in incubation.
• Keep a stable reddwarf api w/o many architecture changes
• Make it optional for time being
  • Since its a moving target, we need to be agile enough to still rely on the original provisioning architecture

Explainings

The way i see it, reddwarf will talk to heat...mmmm lunch time