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. 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.
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.
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?
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.
Cheers, Mark.