Re: [openstack-dev] [heat] Heat API v2 - Removal of template_url?
On Fri, Dec 06, 2013 at 11:38:03AM +1100, Angus Salkeld wrote: On 05/12/13 17:00 +, Steven Hardy wrote: On Thu, Dec 05, 2013 at 04:11:37PM +, ELISHA, Moshe (Moshe) wrote: Hey, I really liked the v2 Heat API (as proposed in Create a new v2 Heat APIhttps://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. Sure, that sounds like a good idea, when the template service exists. That's kinda orthogonal from this issue though, which is removing arbitrary user-provided URLs; I'm perfectly happy if we add template_id in future. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] Heat API v2 - Removal of template_url?
Hey, I really liked the v2 Heat API (as proposed in Create a new v2 Heat APIhttps://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? 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. Will the template_url be removed and if so how will the template contain the YAML template? Thanks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Heat API v2 - Removal of template_url?
On 05/12/13 16:11, 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? 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. Will the “template_url” be removed and if so how will the “template” contain the YAML template? Oh, that would be sad indeed. We're just looking at this pattern in AWS: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-stack.html And using that in heat as well would be very welcome. Cheers, -- Stephen Gran Senior Systems Integrator - theguardian.com Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Heat API v2 - Removal of template_url?
On Thu, Dec 05, 2013 at 04:11:37PM +, ELISHA, Moshe (Moshe) wrote: Hey, I really liked the v2 Heat API (as proposed in Create a new v2 Heat APIhttps://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 OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Heat API v2 - Removal of template_url?
On 05/12/13 17:00 +, Steven Hardy wrote: On Thu, Dec 05, 2013 at 04:11:37PM +, ELISHA, Moshe (Moshe) wrote: Hey, I really liked the v2 Heat API (as proposed in Create a new v2 Heat APIhttps://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
