On 05/16/2011 12:47 AM, Scott Seago wrote:
> 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).
This is fair. I'd like to not lose sight of this topic, but I think
you're absolutely right in that it has to be looked at holistically and
not just for script storage.
> 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.
My overall concern here is specific to the user that has an existing
configuration engine library. It looks to me like we're asking the user
to import their config engine library and store a copy with us.
If we can guide the user down a path that does not end up with them
having to edit their configuration engine library in two places (their
original storage location, and Cloud Engine's storage location), then
I'm fine.
> 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
You're right...my bad. I misread the model.
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?
I think the params are intrinsically tied to the scripts already. In
the case of puppet, they're going to represent variables in the puppet
classes, or replacement variables in erb templates.
Still, pushing them up the model to services allows them to filter back
down to the actual scripts.
> 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.
Really, all I meant here was that if we _are_ going to prepackage a
bunch of services with Cloud Engine, then my points are largely moot;
since, we'll have complete control over the organization and content of
the scripts associated with those services.
However, I don't assume that we have the resources or ability to define
all the various scripts required for each installation. Hence the
assumption that we're not going to prepackage services with Cloud Engine
(except for demo purposes?).
Scott
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel