[openstack-dev] [heat] Heat API v2 - Removal of template_url?

Steven Hardy shardy at redhat.com
Thu Dec 5 17:00:50 UTC 2013


On Thu, Dec 05, 2013 at 04:11:37PM +0000, ELISHA, Moshe (Moshe) wrote:
> Hey,
> 
> I really liked the v2 Heat API (as proposed in Create a new v2 Heat API<https://blueprints.launchpad.net/heat/+spec/v2api>) and I think it makes a lot of sense.
> 
> One of the proposed changes is to "Remove template_url from the request POST", so the template will be passed using the "template" parameter in the request body.
> 
> Could someone please elaborate how exactly Heat Orchestration Templates written in YAML will be embedded in the body?

In exactly the same way they are now, try creating a stack using a HOT yaml
template, with --debug enabled via python heatclient and you'll see what I
mean:

wget https://raw.github.com/openstack/heat-templates/master/hot/F18/WordPress_Native.yaml

heat --debug stack-create -P "key_name=userkey" -f ./WordPress_Native.yaml wp1

This works fine now, so there's nothing to do to support this.

> As I understand the YAML template should be inserted as string otherwise JSON parsers will not be able to parse the JSON body.
> If indeed the template is inserted as string, as far as I know, JSON does not support multiline strings and the available workarounds are not so pretty and require escaping.
> The escaping issue gets more complicated when "UserData" is used in the YAML.

It's just a string, we do the parsing inside the heat-engine, with either
json or yaml parser, depending on the content of the string.

> Will the "template_url" be removed and if so how will the "template" contain the YAML template?

Well, this is a good opportunity to discuss it, since removing it was only
one persons idea (mine ;) and we haven't discussed it much in the team.

My argument for removing it, is:

- We already resolve URLs for environment files in python-heatclient, and
  pass them in the "files" parameter, so lets to the same for the template.

- In real world deployments, assuming the heat-api has access to
  whatever URL you pass may not be reasonable (or secure, ideally we don't
  want the heat hitting random user-provided URLs)

- We are tying up service resources doing a chunked download of a template,
  when this overhead can be in the client, then we just have to check the
  string length provided in the request in the API. When you consider many
  concurrent requests to heat containing template_url, this will probably
  result in a significant performance advantage.

The python CLI/API could be unmodified, if someone passes template_url, we just
download it in the client and pass the result in the POST to the heat API.

So essentially it shouldn't impact users at all, it's just moving the
processing of template_url from heat-api to python-heatclient.

If anyone has some counter-arguments, lets discuss! :)

Steve



More information about the OpenStack-dev mailing list