i definitely agree we should not mix the two  i think the list syntax makes more sense in this case than it does in capabilities  i previously made comments to this end on that spec  but they got lost in a previous patchset  so i will review it again soon take a simple resource registry resource registry os  tripleo  blockstorage  cinder storage yaml os  tripleo  compute  compute yaml what that is saying is that when a template creates a resource of type blockstorage  it should use the cinder storage yaml file  taking the example from the capabilities requires deployment  puppet resource registry os  tripleo  controller puppet controller yaml  docker controller yaml you  as the template reader maintainer  not as heat programmatically reading it  are no longer able to see what template will be used  that information has moved to the  requires  area plus some additional logic that looks inside the templates themselves  now factor in the alternative in this spec for using a parameter driven approach that s now a third place you need to look to understand which template s  will be used to fulfill a given type  leaving us with the following to understand a set of templates look in the resource registry to see the mapping for a type if the mapping is a list  look at the requires and the contents of each template referenced to see which one will fulfill the requires look through the top level template itself for any resourcechain resources  determine the name of the parameter that is used to convey the list of templates in the chain  then resolve what the current value of that parameter is  imo  this is a rough experience for the user  we ve taken the knowledge of how a stack will be created and spread it over the course of multiple areas and files  by comparison  my argument is that capabilities are not a black box resolution by heat  but rather just metadata the user can ask heat to introspect to determine valid mappings to make in the resource registry chains are communicated inside of the registry itself  that flow leaves the mappings in a single place  the resource registry  it s simpler both for user comprehension and clients that may be layering on top of the templates 