Open Stack

----- Original Message -----
> From: "Clint Byrum" <clint at fewbar.com>
> To: openstack-dev at 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, cbjchen at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>