The error scenario you describe, Ben Ford, arises in part from no such separation having been performed, so that collectors still perform multiple largely unrelated functions. The manifold module's capabilities look interesting, but they don't solve that problem themselves. Supposing that you recognize that, I guess you are suggesting that manifold, or something substantially similar, be incorporated into core puppet in conjunction with collectors being made unacceptable operands for the chain operators. I think that would be the wrong direction. I would rather see collectors continue to work with the chain operators and for resource parameter overrides, but cease to (automatically) realize virtual resources or collect external resources, even though the latter are the original functions of the constructs. I think it makes sense for the language to have a general-purpose syntax to represent a set of resources. Collectors serve that purpose reasonably well, but manifolds not so much. It looks like manifolds do fine, within their limitations, as a stand-in for collectors for resource relationship purposes, but there remains collectors' usage for resource parameter overrides, and there may well be future applications, too. For example, once upon a time I suggested that collectors be allowed as property values, so that they could be used with the relationship metaparameters (the chain operators were introduced instead). Moreover, if we accept that a such a general-purpose group-selection syntax is sensible, then voila! it provides its own natural solution to the problem. Take away the automatic realization / collection function, and introduce instead explicit realization of resources matched by collectors. One might use the realize keyword to accomplish that, for example. Thus, one might be obliged to write ... realize Host<<| |>> realize User<| tag == 'x' |> ... instead of just ... Host<<| |>> User<| tag == 'x' |> ... if one wanted not only to collect resources that are otherwise in the catalog but also to add matching known / discoverable resources to the catalog. And one could make such realize expressions work in chain expressions and parameter override specifications, so that converting old code would just be a matter of adding one keyword in those places where it is wanted.
As an aside: it does not appear that the present implementation of manifolds is as flexible as collectors with regard to specifying member resources. Collectors allow multiple criteria to be combined via logical operators, and they support search values of several non-string types, notably including resource references and undef, but it does not appear that manifolds do the same. I'm sure that's a solvable problem, but I'm uncertain what the costs of building and maintaining a solution would be.
|
