----- Original Message -----
> From: "Clint Byrum" <cl...@fewbar.com>
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, 27 June, 2013 3:55:17 AM
> Subject: Re: [openstack-dev] [Heat] re: discussion about passing metadata
> into provider stacks as parameters
>
> On 2013-06-20 22:49, Angus Salkeld wrote:
> > On 20/06/13 22:19 -0400, cbjc...@linux.vnet.ibm.com wrote:
> >>
> >> So anyway, let's get back to the topic this thread was discussing
> >> about - "passing meta data into provider stacks".
> >>
> >> It seems that we have all reached an agreement that deletepolicy and
> >> updatepolicy will be passed as params, and metadata will be exposed to
> >> provider templates through a function
> >>
> >> In terms of implemetation,
> >>
> >> MetaData:
> >>
> >> - add a resolve method to template.py to handle
> >> {'Fn::ProvidedResource': 'Metadata'}
> >
> > I think the name needs a little thought, how about:
> >
> > {'Fn::ResourceFacade': 'Metadata'}
> >
>
> <user>
> What the heck is a resource facade?
> </user>
This is for the provider-template feature:
- user writes a template that will fill in for a resource (the resource is the
facade).
- when they are writing their template they need to access the metadata from
the original/facade/owning resource - ga please feel free to come up with a
better name.
Just to clarify this:
top level template (top.yaml):
resources:
my_server:
type: OS::Compute::Server
metadata:
key: value
some: more stuff
provider_template (my_actual_server.yaml)
resources:
_actual_server_:
type: OS::Compute::Server
metadata: {Fn::PleaseGet_my_server's_metadata ;)}
my environment (env.yaml):
resource_registry:
resources:
my_server:
"OS::Compute::Server": my_actual_server.yaml
heat stack-create -f top.yaml -e env.yaml
So the idea was to define a way to get at the "facade" resource from
the actual provider implementation template.
I'd prefer a Function over a magic parameter for implementation reasons and
as I don't think it makes any difference to the understanding of what it does,
but if you can come up with a better name then that is great.
-Angus
>
> Can we perhaps take a step back from being developers and consider the
> user experience for a second?
>
> This function name may make sense from an implementation standpoint,
> but for users, I don't think they're going to be grasping what design
> patterns we've applied to our internals.
>
> Can somebody, in plain english, explain why these can't work in a
> similar manner cloudformation pseudo parameters like AWS::StackName and
> AWS::Region?
>
> _______________________________________________
> 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
