It seems to me we have been discussing a proposal whose write-up 
intertwines two ideas: (1) making software components look like resources, 
and (2) using nested stacks and environments to achieve the pattern of 
definitions and uses.  The ideas are separable, and I think the discussion 
has sort of revealed that.  There are issues with both.  Regarding the 
first, I think Clint has been pursuing the critical issue.

Clint Byrum <cl...@fewbar.com> wrote on 11/12/2013 07:34:34 PM:
> ...
> > >I have implementation questions about both of these approaches 
though,
> > >as it appears they'd have to reach backward in the graph to insert
> > >their configuration, or have a generic bucket for all configuration
> > 
> > Yeah, it does depend on the implementation. If we use Mistral the
> > agent will need to ask Mistral for the tasks that apply to the server.
> > 
> > $ mistral task-consume \
> >   --tags=instance_id=$(my_instance_id);stack_id=$(stack_id)
> > 
> 
> Actually that makes perfect sense. Thanks. If we have a hidden work-flow
> handle for any resources that have need of it passed in much the same
> way we pass in the cfn-metadata-server now, that would allow us to write
> our work-flow afterward. The image can decide when it wants to start
> doing work-flows and can decide to just spin until the work-flow exists
> and is enabled. For the tiny-work-flow case of one task it works the
> same as the complicated work-flow, so I think this sounds like a
> workable plan.. assuming a work-flow service. :)

If I understand correctly, Clint is dismayed at the idea of a heat engine 
plugin "reaching backward" to find the software configs needed to apply to 
a server, but is OK with a task in a taskflow doing that.  It seems like a 
double standard to me.  And it makes the software config stuff depend on 
an essentially independent big change, which is dismaying to those of us 
eager to make progress on software config.  How about allowing a Heat 
plugin to query for dependents in the graph?

Regarding issue (2), look at where we are going.  If I write a template 
that I want to share with you, and that template exercises the 
definition/use distinction, I have to give you: (i) the templates that 
comprise my definitions, (ii) my template that has my uses, and (iii) a 
*fragment* of environment that binds the templates in (i) to the names 
used for them in (ii).  This is a pretty ragged assembly of stuff.

Regards,
Mike
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to