From: Mark McLoughlin <markmc(a)redhat.com>
Date: Tue, 24 May 2011 17:11:05 +0100
[...]
Services are a separate concept - scripts that are specified by the
assembly to be pulled from the config server at boot time. The also have
parameters.
So, there's pretty much no change here apart from a terminology change
(i.e. not using the service term for config scripts included in a
template, since the conflation was causing confusion) and a realization
that images just expose a set of parameters.
[...]
Supporting services at the template level is starting to make some sense
to me but, in terms of prioritization, I think the order would be:
1) A single template configuration script with parameters and returns,
similar to kickstart %post - people can run multiple scripts from
here if they like
2) A single service script per assembly
3) Multiple service scripts per assembly
4) Services scripts at the template level
So, I think I've just dropped (4) from my immediate thinking rather than
saying it will never make sense
[...]
> The thing that I'm not convinced on in here is the
services vs scripts
> thing. Perhaps some more elucidation on why that distinction exists?
It basically comes down to:
- I think templates need the concept of a %post script, independent
of services
- Services make sense in deployables and justify the existence of
assemblies
- We can support services in templates down the road
Ok, I think I have a better handle on what you're after. And I
appreciate and sympathize with the desire to simplify. I'm still not
buying that reasoning.
Couple of reasons:
First, by removing the service grouping, you're preventing any kind of
namespacing, or separation of all the myriad tasks which need to
happen at boot/init time. I'll grant that for a hacker type who wants
to get the bits all over his fingers, there's no great loss of
generality there, but I have to believe that the sweet spot of who we
want to use this thing is not people like us. It's people who will
want to partition the problem up into parts.
Second, I think that part of the semantic we're trying to express is
"I'm an image which supplies or requires service(s) called foo, bar,
baz" etc. For instance, if I build a lamp stack, where the mysql
server is some other machine, I want to be able to have the metadata
for that image say "At launch time, I need somebody to provide mysql
service, and the parameters I need are ip-addr and user-cred". Or if
I build a hail server image, I want his metadata to be able to say "I
supply service block-storage, subtype s3, parameters ip-address and
base-url". The way we've been talking about expressing those ideas is
with service entries. Now granted, you *could* claim that all that
could go in the assembly. But another part of what you're doing is
decoupling assemblies from templates. Which to me says that it's even
more important to keep the semantic information you care about tightly
connected to the place where it matters, ie the place with the code.
Third, by institutionalizing parameters outside services as distinct
from parameters which are part of services, it seems to me you're
making an artificial distinction and separate paths through the code.
Ie, increasing complexity rather than reducing it. We already know we
need parameters tied to services. I think we should just use those,
instead of creating a new kind of parameters.
Ok, that was three, I can't count :-)
I don't disagree about templates needing other kinds of escape
clauses, for instance %post-like things. We probably will need more
escape clauses at build time, as well as run time. But the existence
of %post things or other escape clauses, to me, doesn't imply that we
can skip service descriptors.