On 05/12/13 17:00 +0000, Steven Hardy wrote:
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.
Given the talks about Heater/appstore/glance-templates it would be
good to be able to pass a references to one of those systems so
the user doesn't have to upload to glance, then send a copy to heat.
so just pass a template_id like how nova.boot() takes an image_id.
-Angus
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
