Re: processing order, preprocessing, etc.

[Mark . Burgess]

Short answer -- multiple name spaces planned for version 2.1.
In the new year.

M


On 22 Dec, Luke A. Kanies wrote:
> On Sun, 22 Dec 2002 Mark.Burgess@iu.hio.no 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
> 



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mark.Burgess@iu.hio.no
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~