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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
