On 11/12/13 11:59, Randall Burt wrote:
On Dec 10, 2013, at 3:46 PM, Zane Bitter <[email protected]> wrote:
On 10/12/13 15:10, Randall Burt wrote:
On Dec 10, 2013, at 1:27 PM, Zane Bitter <[email protected]>
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
Yeah, that makes a lot of sense from a "I want to calculate what this stack is going to cost
me" use case. My only concern is that a given service provider may have different ideas as to
what's "important" WRT a stack's value, but we could always extend this with something in
the global environment similar to how we discussed resource support status in those reviews.
True in theory, though in practice I suspect this will mostly happen
only when the operator is plugging in a different resource
implementation anyway. Probably best to assume YAGNI for now, but keep
this idea in mind and see if a use for it comes up.
So it sounds to me like we just need to add a field to the property schema that says
"this property is important to the preview call".
Sold. I updated the blueprint to depend on the
property-schema-conversion bp I am currently working on, otherwise the
conflicts will be epic :D
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
