Difference between revisions of "Heat/Providers"

Latest revision as of 00:07, 24 May 2013

Heat "Providers" Resource plugins

This page is an attempt to distill the specification discussed in:

http://lists.openstack.org/pipermail/openstack-dev/2013-April/007989.html

And described in the following BPs:

• https://blueprints.launchpad.net/heat/+spec/provider-resource
• https://blueprints.launchpad.net/heat/+spec/json-parameters
• https://blueprints.launchpad.net/heat/+spec/resource-properties-schema
• https://blueprints.launchpad.net/heat/+spec/resource-template
• https://blueprints.launchpad.net/heat/+spec/stack-metadata
• https://blueprints.launchpad.net/heat/+spec/attributes-schema
• https://blueprints.launchpad.net/heat/+spec/provider-upload

Also see Heat/Environments

What are "Providers"?

Providers are an extension to our existing internal model, which allows user-definable "resource providers" to be specified via templates

It is conceptually similar to (and will internally leverage) our existing nested stack functionality, but with some additional interfaces which make consuming those nested stacks more convenient and more easily reusable. Specifically, a provider template can stand in for any resource type, and need not be identified as an AWS::CloudFormation::Stack resource.

asalkeld

I don't think we should restrict the general provider concept to templates.
To me all resources should register "I provide OS::Compute::Server, my provider name is openstack.org and
 here is the class that implements this." Obviously I am not against the user provided nested-style-user
 provider, just saying we should also support python resources too. 

asalkeld's Talk back radio... er ... IRC

What might all of this give us?

• Users are no longer dependent on the operator to provide the resource type they need, they can supply their own.
• Users can modify built-in types
• Users can share their resource-provider templates
• template complexity is reduced
• modularity and reuse is improved
• provider defined resources could be to be either public, per-tenant, or per-user, again allowing more effective reuse

How might it work in practice?

Here is an example of how it might work to provide an alternate implementation for our internal (nested stack based) AWS::RDS::DBInstance resource:

1 - Get the template for the internal resource implementation

   # heat resource-template-list AWS::RDS::DBInstance
   id  name     type                  default  scope
   1   builtin  AWS::RDS::DBInstance  true     public

   heat resource-template-show 1
   <save cut/paste/modify template> 

2 - Publish the modified resource template, scoped private (per user, this would be the default)

   #heat resource-template-publish AWS::RDS::DBInstance --template-url ~/myspecialdb.template mydb

   #heat resource-template-list --type AWS::RDS::DBInstance
   id  name     type                  default  scope
   1   builtin  AWS::RDS::DBInstance  true     public
   2   mydb     AWS::RDS::DBInstance  false    private

3 - Publish a default, public resource template (this could be a tenant admin action, providing a default template for all tenant users)

   heat resource-template-publish AWS::RDS::DBInstance --public --default --template-file ~/mydefaultdb.template defdb

   heat resource-template-list --type AWS::RDS::DBInstance

   id  name     type                  default  scope
   1   builtin  AWS::RDS::DBInstance  false    public
   2   mydb     AWS::RDS::DBInstance  false    private
   2   defdb    AWS::RDS::DBInstance  true     private

OpenStack Infrastructure's Use Case

 (asalkeld) I want to persue the infrastructure guy's use case, because they are potentially very real users (and good technically - good first victims)
 So their use case is to be able to write one template but run it on HP Cloud or Rackspace cloud or devstack.

 Providers and Environments are a perfect fit here:
 1) we can write different providers for each public cloud (or use libcloud)
 2) we can use the Environment to define the provider and credentials for the clouds

 Concrete steps to achieve this
 1) write a Rackspace server resource type that actually works (no provider yet, just a new resource python plugin)
 2) add the concept of an environment, initially just to pass the special rackspace creds to server plugin
 3) all builtin resources register the resource type that they impement and their provider name
 4) add the provider selection to the environment
 5) add cli/rest api to view all of the above
 6) potentially the parameters also go into the Environment, so that only 2 things are passed to the engine Template and Environment
 7) profit:)