help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Software Package Management


From: Chris (Ducky) Chapin
Subject: Re: Software Package Management
Date: Fri, 9 Aug 2002 11:15:34 -0700 (PDT)

I should expand this a little =)

Our philosophy for host maintenance is a more abstract approach than most
I've heard. Basically, we need the ability to produce a core configuration
infrastructure that can manage a simple host and allow sysadmins closer to
the user base to add configurations. We ended up with a class system where
class membership is defined on the host.

Paul Paradise and I identified some features we believe would make
cfengine more suited to this kind of environment:

- pre-actionsequence modules. We could then be VERY flexible about our
  class memberships and separate it from the cfengine configs that do the
  work.

- iteration in imports. Using modules via the above method, we could
  choose which configs to import.

- option to ignore missing imports. Sometimes class definitions don't have
  corresponding configs, so an option to silently keep going if import
  is told to import a config that's not there.

- back references in iteration. In a copy action, I'd like to be able to
  use the current iteration value on the "dest" side. What it boils down
  to is a need to copy parts of a directory tree. Yeah, tricky, and the
  least important, imo.  But this is to adapt it to our current
  architecture - if we start from scratch, it's not that bad of an
  omition.

So those are some ideas... please pick away. =) I can give some specific
examples if you'd like.

When I get a chance, I'll be taking a whack at coding these up, too.

-Ducky

--

 Christopher 'Ducky' Chapin                        ducky@qualcomm.com
 Unix Systems Administrator - Qualcomm, Inc.           (858) 651-5433
 IT Host Services - AE-209F                                 

On Fri, 9 Aug 2002, Paul Paradise wrote:

> On Fri, Aug 09, 2002 at 12:23:52PM -0500, John Valdes wrote:
> > On Fri, Aug 09, 2002 at 11:06:53AM -0400, Paul Dlug wrote:
> > > In the actionsequence I defined my module as "module:pkgchk $(package)"
> > > and set the package variable above it. However I obviously need to check
> > > multiple packages so I either need a way to rexecute the module with
> > > another package or a way to allow the module to define classes like:
> > > package.emacs-21 so that I can check them without having to list all
> > > possibilities in AddInstallable. Suggestions?
> > 
> > As Paul indicated, you'll want your module to define classes by
> > outputting the list of classes.  Note, btw, that the classes it does
> > define shouldn't contain periods or dashes or colons.  You should
> > instead use underscores, as in:
> > 
> > +package_emacs_21
> > 
> > However, if I'm not mistaken, since these classes get defined at run
> > time and not parse time, you'll still need to list these classes in
> > AddInstallable, unfortunately.  You'll only need to list those for
> > which you've defined other cfengine actions, though, so the list need
> > not include every package installed on your system.
> 
> Chris Chapin (whom I work with here, and has also posted - consult the
> archive) has written a patch (submitted to Mark, I believe) that adds
> a modules: top-level directive that parses the modules in time to make
> them work without using AddInstallable. We felt it was a bug that
> modules didn't appear in time for imports and the like, tweaked the
> execution order to allow something like:
> 
> modules:
>       packages
> 
> import:
>     package_test::
>       package_test.cf
>     package_libc6::
>       package_libc6.cf
> 
> Of course, this still means writing out every package in the import
> stanza, but we got around that by writing a script that does
> that. (Then we needed to define more classes to guard from importing a
> file that doesn't exist - we'd far prefer if cfengine wouldn't
> complain and die when attempting to import a nonexistant file) The
> better solution would be to have a variable listing each file to
> import and iterating over it in the import, but iteration is in many
> ways broken for our needs. (For one thing, we'd love to have
> backreferencing of variable values in any iteration...)
> 
> -- 
> 
> ----------------------------------------------------------------------
>  Paul Paradise                                  paradise@qualcomm.com
>  Interim Engineering Intern, QUALCOMM Incorporated       858.651.6655
>  IT Host Services                                             AE-205C
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]