A few things about the ServiceConfigScript class:
I'm not sure storing the script_content in the db is a good idea,
because it eliminates the ability to track script revisions, similar to
what would be captured by a decent vcs. You might be able to capture
last modified date and modified by in the db, but you wouldn't be able
to diff to previous versions and figure out the content of the last
working version of the script.
The challenge, of course, is that the rest of the service metadata _is_
stored in the db (name, arch, pacakge list, etc) -- nonetheless this is,
to some degre, an implementation detail that need not concern the image
factory, audrey, etc. -- as long as there's a clear API for importing
this stuff, exporting, etc.
The vcs question gets at another can of worms -- versioning. I'd like to
avoid that in the context of this particular discussion of "what are
services", but the versioning/auditing/diff question is a complex one in
that you have to deal with it across the model. If we do one thing for
puppet scripts (i.e. files in a filesytem), another thing for templates,
etc (i.e. IWHD "versioning"), and yet another thing for the rest of the
conductor model (i.e. audit/archiving functionality on ActiveRecord
models), we'll really have a mess.
So lets handle the audit/archive/diff question separately (and consider
it in the context of the full set of data that Conductor is interacting
with).
Also, I'm a little wary of capturing scripts this way because of
the
implications to the IT shop that already has puppet scripts they want to
reuse. This would seem to require them to either abandon their current
puppet library in favor of what we provide in the db, or require them to
upload their entire library into the db.
Whatever the internal storage mechanism, we've got to work through the
API questions of how are users entering/editing/etc -- and we may need
to provider different interfaces for single-script edits vs. bulk/batch
edits, etc. -- but again that's a UI and/or API question more than a
question of 'how do we define a service', etc.
Finally, I'm not sure we can express all we want for a service in
a
single script. Again, thinking about the IT shop with existing scripts,
a decent puppet script writer is going to apply similar
compartmentalization to their code as any decent programmer would.
They're going to try to employ DRY principles and reuse pieces that
provide common functionality. That implies that there could be multiple
scripts per service. Additionally, you would probably have to call out
that for this particular service, you need to execute (include) N number
of puppet classes to provide the proper configuration for this service.
So there are two points here:
1) a single script is insufficient -- I agree, but if you look at the
model, it already allows for multiple scripts per service
2) a script may be shared across multiple services: This one is _not_
accounted for in the model, but if we decide that we want to support
shared config scripts, we can alter the model accordingly. If we do so,
we'll need to do the same with the configuration parameters. And in
fact, either way, do we want to associated config params withiindividual
config scripts rather than with services at the top level?
This assumes that we're not prepackaging a bunch of services with
Cloud
Engine, and instead expecting the user to define services after installing.
If we define a reasonable API around services (including 'import'
functionality) then we have no such assumption. The installer can
pre-load any number of services if they're included in one of the config
packages. This won't keep users from being able to add/edit services via
the UI post-installation.
Scott