From: Mark McLoughlin markmc@redhat.com Date: Fri, 13 May 2011 14:22:47 +0100
On Fri, 2011-05-13 at 08:39 -0400, John R. Dunning wrote: > From: Mark McLoughlin markmc@redhat.com > Date: Fri, 13 May 2011 09:43:39 +0100 > > Hey, > > Just to clarify some subtleties in what I sent yesterday > > I'm pretty sure I'm seeing the subtleties, but let me try to say it > explicitly and get a confirm or deny: > > It sounds like what you're saying is that we should be striving for a > model where most or all services, at least of the RH-supported sort, > have a common way of enabling/disabling, and a common place where the > top of the puppet stuff lives. > > I infer, but didn't see explicitly stated, that we are still talking > about a scrap of xml-ish stuff as the descriptor, ie a thing with > semantics "I'm describing service foo. To implement me, you'll need > packages foo-underlying, foo-control, and foo-puppet-scripts. To > launch me, you'll need to supply parameters foo-tcp-port, foo-peer-ip, > and foo-color".
I'm taking the template authors viewpoint - how does a template author describe and implement optional services (and their parameters) provided by the template so that they show up as options in the UI when the user is adding an instantiation of the template to a deployable?
I'm suggesting a set of conventions for describing such services in a puppet manifest.
Hmmm. What we said in a pile of previous discussions was that there were little snippets of descriptor, not part of a template (yet), which talked about services, including what were its parameters, what packages were implied by it, what scripts (puppet or otherwise) would be driven by it at launch time, etc.
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. I don't want to tell them they are forced to adopt this tool they don't like, when all they really wanted was to get some parameters handed to them at launch time, for them to use as they see fit.
The template's XML descriptor provided by the template author would just have something like:
<template> ... <services> <service> <puppet manifest="my_postfix.pp"/> </service> </services> </template>
When the template descriptor is registered with Conductor, it would need to extract the name, parameters and documentation from the manifest so that they can be shown in the UI and passed to config server.
That's partly why I like the separate descriptor. Nothing needs to be extracted, it's all explicit.
When Conductor extracts the details, it could be stored internally in the template XML but template authors wouldn't be required to specify them both in the puppet manifest and the XML. Keeping it DRY as Ruby folks would say.
> Where said scrap would nominally be provided by pulp.
Hmm, pulp? You'll need to elaborate on how pulp comes in to it.
Is Todd Sanders listening? We had a long discussion 2-3 weeks ago about how pulp was the place where the service descriptor snippets live.
I could imagine having conventions for storing template XML descriptors and puppet manifests in pulp repositories so that they can be distributed by template authors. Is that what you mean?
Yes, essentially. Though we took it a step further, and hypothesized one or more special channels, whose explicit purpose was to present the service metadata I've been talking about.
> If that is indeed a fair summary of what you're talking about, that > sounds pretty sensible to me. > > Re the part of the discussion about doing service inclusion > dynamically, schemes of this sort don't, I believe preclude any of > that, though there would likely need to be more infrastructure at > launch time to pull together all the pieces. > > I still hope and advocate that we can avoid being totally > puppet-centric with services, IOW the service descriptors allow for > other-than-puppet underpinnings to deal with the launch-time stuff.
Yep, I could see us coming up with similar conventions for implementing services using Chef recipes or arbitrary config scripts.
Right.
To my mind, the single most important piece of the implementation of services at launch time, is the API between the set of stuff coming down from confserv and the stuff which picks it up in the booting instance. If that's solid, and *isn't* explicitly puppet-centric, that leaves the door open for people to pick up and run with those parameters in their instance, using whatever tools they prefer.
Another tidbit, which may have gotten lost in the noise, is that we hypothesize the need for a smallish tool to aid "somebody" in creating these service descriptor snippets. A plausible way for such a thing to work would be
1. import conf files (and maybe other bits) from some app or rpm 2. run augeous (or other parser of your choice) to extract the relevant configurables. 3. Present user with lists of same, allow for selecting the ones which want to be settable as part of this new service we're defining. include default values etc. 4. wrap the results up into the above-mentioned service metadata snippet.
In the fullness of time, one can easily imagine this tool getting rather more comprehensive, smarter/bigger etc.
Whether said tool would be part of conductor or something else, I don't much care. It seems to me it would be useful to make it standalone, but somebody should think through who's doing that task, and when.