Open Stack

On 10/12/13 15:10, Randall Burt wrote:
> On Dec 10, 2013, at 1:27 PM, Zane Bitter <zbitter at redhat.com>
>   wrote:
>
>> On 10/12/13 12:46, Richard Lee wrote:
>>> Hey all,
>>>
>>> We're working on a blueprint
>>> <https://blueprints.launchpad.net/heat/+spec/preview-stack> that adds
>>> the ability to preview what a given template+parameters would create in
>>> terms of resources.  We think this would provide significant value for
>>> blueprint authors and for other heat users that want to see what
>>> someone's template would create before actually launching resources (and
>>> possibly having to pay for them).
>>
>> +1 for this use case.
>>
>> BTW AWS supports something similar, which we never bothered to implement in the compatibility API. You might want to do some research on that as a starting point:
>>
>> http://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_EstimateTemplateCost.html
>>
>> However the fact that we have pluggable resource types would make it very difficult for us to do cost calculations inside Heat (and, in fact, CloudFormation doesn't do that either, it just spits out a URL for their separate calculator) - e.g. it's very hard to know which resources will create, say, a Nova server unless they are all annotated in some way.
>>
>> Are you thinking the API will simply return a list of resource types and counts? e.g.:
>>
>> {
>>    "OS::Nova::Server": 2,
>>    "OS::Cinder::Volume": 1,
>>    "OS::Neutron::FloatingIP: 1
>> }
>>
>> If so, +1 for that implementation too. Don't forget that you will have to recurse through provider templates, which may not contain what they say on the tin.
>
> That sounds more than reasonable to me. I don't think we could begin to do any sort of meaningful "cost" calculation without having to mostly punt to the service provider anyway.

Yeah, exactly.

Although it occurs to me that we may want more detail than I originally 
thought... e.g. knowing the flavor of any Nova servers is probably quite 
important. Any ideas?

The first thing that comes to mind is that we could annotate resource 
types with the list of parameters we want to group by. That would enable 
something like:

{
   "OS::Nova::Server":
     [{config: {"flavor": m1.small}, count: 1},
      {config: {"flavor": m3.large}, count: 1}],
   "OS::Cinder::Volume":
     [{config: {"size": 10}, count: 1}],
   "OS::Neutron::FloatingIP":
     [{config: {}, count: 1}],
}

- ZB