On Fri, 2011-05-13 at 10:11 -0400, John R. Dunning wrote:
I don't like the idea of joining services and puppet at the hip, mostly because I think it's important to be able to talk about services in slightly more abstract terms. I care about the semantics, not the underpinnings. And more pragmatically, there are lots of people in the world for whom puppet is a big and wrongly-shaped hammer.
There's two slightly different issues at play here: (1) the config server we use to support our tooling (2) the config server that users use to do their bidding.
Clearly, for (2), users will use whatever they have and feel comfortable with; for (1) we should use whatever we can make work.
Given this discussion, there's no doubt that (1) will have to be reasonably close in functionality to puppet that we might as well use it. With what we are trying to do with templates/assemblies/deployables, we are way beyond a package list and a few ancillary knobs.
The question then becomes: what do we need to build to provide useful external interfaces for (1) ? The biggest need I can see so far is, in puppet speak, given a set of classes and facts, produce a catalog. In plain English: if I know that I want to build something that realizes the mysql-server profile and the php-webapp profile, what are the ingredients that go into it ? The puppetmaster can be made to spit that out as a YAML file that talks about packages, services, files etc. That output (maybe transformed to XML or whatnot) should be enough fr our tooling to determine things like packages to stick into an image, or to send to the user's config mechanism for further processing.
David