Support configurable template repo URL

Registered by Adrian Otto

Establish a feature in the Heat CLI and Horizon clients that allows a configurable URL to be supplied as a repo for templates. It shall be defaulted to a community repository of well known best practices that the OpenStack user community can contribute to. A one-time repo registration command would save the preference in a local settings file like .heat. This would enable deployment of well known templates by a name, rather than specifying an explicit template file. The example below registers an alternate repo rather than the default OpenStack one, and installs a lamp stack with 2 app servers. If you skip the repo registration step, it just uses the community repo.

$ heat-cli repo http://repos.example.org/
$ heat-cli install lamp --parameters="AppServers=2"

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Angus Salkeld

Related branches

Sprints

Whiteboard

I recognize that the current clo tool is heat-cfn. This blueprint anticipates that we have an OpenStack native tool called heat-cli that uses the new API and DSL that we are working on in this blueprint:

https://blueprints.launchpad.net/heat/+spec/open-api-dsl

See also:

https://blueprints.launchpad.net/heat/+spec/heat-template-repo

(asalkeld) this could be done with environments.
This could be a neat way to solve this problem:
"
template:
 base_url: http://bla.com/...

parameters:
 bla: foo

resources:
 provider: big_cloud
"
This could also mean that any nested stacks could use relative urls.

2013.06.03 - RB: While I agree with the above, I don't think its the intent of this (or https://blueprints.launchpad.net/heat/+spec/heat-template-repo) to implement part of the DSL or template based resources, but rather as a repo for all sorts of stack templates that accomplish common architectural and/or application deployments (best practice Wordpress template, MySQL cluster, etc). While I think its somewhat similar, I think this is proposing a slightly different feature.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.