Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700: > On 24/10/13 11:54 +0200, Patrick Petit wrote: > >Hi Clint, > >Thank you! I have few replies/questions in-line. > >Cheers, > >Patrick > >On 10/23/13 8:36 PM, Clint Byrum wrote: > >>I think this fits into something that I want for optimizing > >>os-collect-config as well (our in-instance Heat-aware agent). That is > >>a way for us to wait for notification of changes to Metadata without > >>polling. > >Interesting... If I understand correctly that's kinda replacement of > >cfn-hup... Do you have a blueprint pointer or something more > >specific? While I see the benefits of it, in-instance notifications > >is not really what we are looking for. We are looking for a > >notification service that exposes an API whereby listeners can > >register for Heat notifications. AWS Alarming / CloudFormation has > >that. Why not Ceilometer / Heat? That would be extremely valuable for > >those who build PaaS-like solutions above Heat. To say it bluntly, > >I'd like to suggest we explore ways to integrate Heat with Marconi. > > Yeah, I am trying to do a PoC of this now. I'll let you know how > it goes. > > I am trying to implement the following: > > heat_template_version: 2013-05-23 > parameters: > key_name: > type: String > flavor: > type: String > default: m1.small > image: > type: String > default: fedora-19-i386-heat-cfntools > resources: > config_server: > type: OS::Marconi::QueueServer > properties: > image: {get_param: image} > flavor: {get_param: flavor} > key_name: {get_param: key_name} > > configA: > type: OS::Heat::OrderedConfig > properties: > marconi_server: {get_attr: [config_server, url]} > hosted_on: {get_resource: serv1} > script: | > #!/bin/bash > logger "1. hello from marconi" > > configB: > type: OS::Heat::OrderedConfig > properties: > marconi_server: {get_attr: [config_server, url]} > hosted_on: {get_resource: serv1} > depends_on: {get_resource: configA} > script: | > #!/bin/bash > logger "2. hello from marconi" > > serv1: > type: OS::Nova::Server > properties: > image: {get_param: image} > flavor: {get_param: flavor} > key_name: {get_param: key_name} > user_data: | > #!/bin/sh > # poll <marconi url>/v1/queues/{hostname}/messages > # apply config > # post a response message with any outputs > # delete request message >
If I may diverge this a bit, I'd like to consider the impact of hosted_on on reusability in templates. hosted_on feels like an anti-pattern, and I've never seen anything quite like it. It feels wrong for a well contained component to then reach out and push itself onto something else which has no mention of it. I'll rewrite your template as I envision it working: resources: config_server: type: OS::Marconi::QueueServer properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} configA: type: OS::Heat::OrderedConfig properties: marconi_server: {get_attr: [config_server, url]} script: | #!/bin/bash logger "1. hello from marconi" configB: type: OS::Heat::OrderedConfig properties: marconi_server: {get_attr: [config_server, url]} depends_on: {get_resource: configA} script: | #!/bin/bash logger "2. hello from marconi" serv1: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} components: - configA - configB user_data: | #!/bin/sh # poll <marconi url>/v1/queues/{hostname}/messages # apply config # post a response message with any outputs # delete request message This only becomes obvious why it is important when you want to do this: configC: type: OS::Heat::OrderedConfig properties: script: | #!/bin/bash logger "?. I can race with A, no dependency needed" serv2: type: OS::Nova::Server properties: ... components: - configA - configC This is proper composition, where the caller defines the components, not the callee. Now you can re-use configA with a different component in the same template. As we get smarter we can have these configs separate from the template and reusable across templates. Anyway, I'd like to see us stop talking about hosted_on, and if it has been implemented, that it be deprecated and eventually removed, as it is just plain confusing. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev