On May 13, 2011, at 9:22 AM, Mark McLoughlin wrote:
On Fri, 2011-05-13 at 08:39 -0400, John R. Dunning wrote:
From: Mark McLoughlinmarkmc@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?
Does this imply that the template author can flag services as either "required" or "optional"? "Required" meaning: the user adding an instantiation of this template to a deployable would not be able to turn the service on or off. "Optional" meaning: the user can decide if they want that service turned on or off.
I'm not sure we really need the required/optional bit on the template itself. The deployable author is already configuring services for each template/assembly in the deployable, and this user is probably the one in the best position to decide what's really required for each included template. In this case, it's not a question of on/off checkboxes. Rather it's a question of looking at a list of available services (i.e. included in the template/build) for each template and choosing which ones to configure (and, consequently to enable).
Remember this still isn't launch time. A deployable is merely a reusable collection of templates/assemblies with services configured. The next step is for an end user (possibly the same user that created the deployable and/or templates, but likely not) to launch. At some point we will need to also allow launching users to override service parameters defined in the deployable, but I don't think there's any hard requirement to do this now.
Is it safe to assume that if there are "required services" the user can't turn off when adding an instantiation of the template to a deployable, the user would still need to configure those services?
For any services enabled in a deployable, the deployable author must configure them. Once configured, they'll be enabled in all deployments launched from this deployable.
Scott