Heat/Providers
Contents
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
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:)