In-line comments. On 10/28/13 5:43 PM, "Steve Baker" <sba...@redhat.com> wrote:
>On 10/26/2013 05:25 AM, Clint Byrum wrote: >> 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. >> >My components proposals had no hosted_on, but I've been thinking about >the implications of implementing software configuration as resources, >and one of the natural consequences might be that hosted_on is the best >way of establishing the relationship with compute and its >configurations. Let me elaborate. > >Lets say that Heat has resource types for software configuration, with >the following behaviours: >* like other resources, a config resource goes into CREATE IN_PROGRESS >as soon as its dependencies are satisfied (these dependencies may be >values signalled from other config resources) >* a config resource goes to state CREATE COMPLETE when it receives a >signal that configuration on the compute resource is complete (by some >mechanism; wait condition, marconi message, whatevs) >* the relationship between config resources and compute resources are >achieved with existing intrinsic functions (get_resource, get_attr) > >This lifecycle behaviour means that a configuration resource can only >run on a single compute resource, and that relationship needs to be >established somehow. Config resources will have a quirk in that they >need to provide 2 sources of configuration data at different times: >1) cloud-init config-data (or other boot-only mechanism), which must be >available when the compute resource goes into CREATE IN_PROGRESS >2) the actual configuration data (oac metadata, puppet manifest, chef >recipe) which the compute resource needs to be able to fetch and execute >whenever it becomes available. > >The data in 1) implies that the compute needs to depend on the config, >but then all concurrency is lost (this won't matter for a >cloud-init-only config resource). Either way, the data for 1) will need >to be available when the config resource is still in state INIT >COMPLETE, which may impose limitations on how that is defined (ie >get_resource, get_attr not allowed). > >So, 2 concrete examples for handling config/compute dependencies: > >hosted_on >--------- >resources: > configA > type: Heat::ScriptConfig > properties: > hosted_on: > get_resource: the_server > script: | > #!/bin/bash > logger "1. hello config A" > configB > type: Heat::ScriptConfig > properties: > hosted_on: > get_resource: the_server > script: | > #!/bin/bash > logger "1. hello config B" > the_server: > type: OS::Nova::Server > >Here, configA and configB go into CREATE IN_PROGRESS as soon as >the_server is CREATE COMPLETE. configA and configB go into CREATE >COMPLETE when heat-engine receives a signal that they are complete. This >signal may include values that other resources depend on to start their >creation. > >OS::Nova::Server config_resources >--------------------------------- >resources: > configA > type: Heat::ScriptConfig > properties: > script: | > #!/bin/bash > logger "1. hello config A" > configB > type: Heat::ScriptConfig > properties: > script: | > #!/bin/bash > logger "1. hello config B" > the_server: > type: OS::Nova::Server > properties: > config_resources: > - {get_resource: configA} > - {get_resource: configB} > >Here there would need to be some bypassing of dependency calculation to >allow configA and configB to be created after the_server, maybe by: >* special treatment of config_resources to prevent dependencies being >created >* a get_resource variant which doesn't create a hard dependency >(get_resource_deferred?) > >Neither the hosted_on nor the config_resources behaviours are ideal, but >I'm leaning towards hosted_on at the moment since it doesn't require any >new soft-dependency mechanism. For what it's worth, I prefer the config_resources method, because I want to reuse configs across multiple servers. In the hosted_on implementation, would there be a way to reuse configA on different servers in the same stack? The logical organization of what software to apply to a server just seems to make more sense to me when I look at the syntax for config_resources. If I can specify multiple "hosted_on" servers for a given config, then I could be ok with hosted_on, but still prefer config_resources for the reason that it seems logical to define what software you want installed on a server than to define what servers you want to install a piece of software on. Nit picky on my part for sure, but food for thought. > >As for composability, what *actually* needs to be composable is the >contents of the script (manifest, recipe) property. Everything else in a >config resource is just stack-specific wiring. There are a couple of >ways this composability could be achieved: >1) resource provider in the user environment which specifies the script >property >2) __include__ or some equivalent client-side inclusion mechanism +1 to the __include__... This would be a useful feature to template writers. What do you all think, should the include substitution logic live in the python-heatclient so that Heat only ever receives the fully composited template? (side note: I originally thought that stack based resource providers worked as #includes... Turns out I was waaay wrong once I understood them :-) > >With either of these options, intrinsic function calls need to be moved >out of the script property and into a variables property. Any >configuration management tool that supports variables passed as inputs >can use them. If a given tool doesn't support variables then heat-engine >could do the substitution when building the configuration data. > >Using resource providers has another interesting possibility. With a >sufficiently advanced software-config base resource type, it should be >possible to write a resource provider which adds support for a >configuration management tool that heat otherwise knows nothing about. A big thank you to all of you proposing ideas here and writing blueprints. This is good stuff! -Keith _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev