help-cfengine
[Top][All Lists]
Advanced

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

Re: processing order, preprocessing, etc.


From: Luke A. Kanies
Subject: Re: processing order, preprocessing, etc.
Date: Sun, 22 Dec 2002 11:27:23 -0600 (CST)

On Sun, 22 Dec 2002 address@hidden wrote:

> 
> > 
> > and a "shellcommands" section which uses that variable:
> > 
> > shellcommands:
> >     "/bin/echo $(variable) > /tmp/testing"
> > 
> > What happens if I later reassign that variable?  (Can I only assign
> 
> 
> Sounds like you are starting down the usual path of trying to
> think of cfengine as an imperative language like perl or shell.
> Order does not matter very much in cfengine.
> 
> Don't mean to fob you off, but there is really no substitute
> for reading the tutorial and FAQs at www.cfengine.org

No, actually, that is not what I am trying to do.  The initial example of
what I am trying is this:

I have 70 servers, 100 or so packages, and multiple versions of each
package.  I want to define some way to configure the correct version of
the correct packags on every host.  I'd prefer to do it based on some kind
of classing; I always want the most recent version of ssh, but I can't
always just upgrade Oracle or whatever.

I am trying to figure out a way to store all of the information I am
working with (default package versions, package installation methods, and
which hosts have which packages) in cfengine configs, and let cfengine do
the installing.

So no, I am not trying to do this declaratively.  But what I am _am_
trying to do is reduce duplication in my configs, and hopefully be able to
split the different types of information into different places, e.g., I'd
like to store the default versions of all of my packages in one place, the
package installation methods in another place, and then the host to
package correlation in yet another place.

Because I can't make complex data structures in cfengine, like
$pkg->version, but I also don't appear to be able to use symbolic
references, like $( $(pkg)->version ), I can't figure out a way to store
this information for each package and then retreive it in an scripted
fashion.  In other words, if I have 100 packages, I do _not_ want to have
100 install methods set up.

This is what I would like to see:

# package config

control:
        name = ( "MyPkg" )
        defaultversion = ( 1.0 )
        requires = ( openssl ncurses )
        isinstalled = ( ExecResult("do stuff") )
        location = (
                $fileserver/packages/$vendor/$osrelease/$package/$version
        )

# package installation

shellcommands:
        !isinstalled::
                "/bin/pkginstall $pkg $version $vendor"


# host configuration

groups:
        webserver = ( host1 host2 host3 )
        ftpserver = ( anotherhost another )
        dbone = ( host5 )
        dbtwo = ( host6 )

control:
        any::
                pkglist = ( ssh perl )
        webserver::
                pkglist = ( httpd mod_perl mod_php )
        ftpserver::
                pkglist = ( wuftpd )
        dbone::
                pkglist = ( mysql )
                version = ( 1.0 )
        dbtwo::
                pkglist = ( mysql )
                version = ( 1.2)

Now, this is obviously just all made up, and isn't really a valid config
at all, but hopefully you can get the point.  For instance, in the db
server configs, how can I specify that one group of servers get one
version of the app, and another group gets a different version of the same
app?  This is not an imperative question; I'm not trying to set up a
relatively complicated state. However, I definitely do not want to have to
set up a situation where I cannot a) cannot reuse my install methods, b)
define a package list in one place and then essentially iterate over that
package list, c) define different versions for different apps and have the
"right thing" get done, and d) have package lists with every host class,
such that when the package list is complete I just iterate over it making
sure everything is installed.

If you still consider this imperative, and thus something that shouldn't
be tried with cfengine, then how would you solve this?  I can certainly
see how I would set something up like this:

control:
        mysqlversion = ( 1.0 )
        mysqlrequires = ( openssl ncurses )
        sshversion = ( 3.5 )
        sshrequires = ( openssl )

        actionsequence = ( shellcommands )

        sshinstalled = (
                ExecResult("pkgtest -pkg ssh -version $sshversion")
        )

        mysqlinstalled = (
                ExecResult("pkgtest -pkg mysql -vers $mysqlversion")
        )

shellcommands:
        !mysqlinstalled::
                "pkginstall -pkg mysql -version $mysqlversion"
        !sshinstalled::
                "pkginstall -pkg ssh -version $sshversion"

I _hate_ that.  Hate, hate, hate, hate, hate.  I definitely don't want to
do that for all 100 packages that I have, because what happens when I
change my pkginstall method?  Or anything else in that chain?  Or what
happens when I want to install different versions of the same app?  I have
to create "sshversion4 = ( 4.0 )", which is a bit silly.

In other words, this has nothing to do with being an imperative language,
but it is entirely related to namespace.  Normally I would define a
namespace for each package, usually a hash in perl, or an object in some
other language, and then I would iterate over the hashes or objects, and
if the package is not installed correctly cfengine will install it, just
like the ssh example in the docs.

However, since cfengine seems to only have one namespace, I can't do that.
So, I was thinking I can maybe create multiple effective namespaces using
time; if I can somehow get cfengine to 1) get the list of packages based
on classes, 2) iterate over that list defining the standard variables, and
then 3) import the _exact_ same method configs that do the work, then
maybe I can avoid this level of repetition.

I am trying to completely separate the list of packages, the methods used
to install the packages, and the metadata surrounding the package, and
cfengine doesn't seem to allow me to do that in a repeatable way.

Please advise, as the docs do not seem to cover this.  How are other
people installing their 100 packages, or are other people not using
cfengine to install packages?

Luke

-- 
Is life worth living?  That is a question for an embryo, not a man.
                --Samuel Butler





reply via email to

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