RE: Strategy for "one-off" tasks

[Wheeler, John]

An example of "one-offs" and "roll-out" I have is that I maintain
several products across a dev, qa, stage, and production environments
(example product: http://register.britannica.com). These environments
contain one or more machines. The product is generally 3 tiered. The db
tier is not my concern, so for the web and app tier I define classes
that indicate the machines that are relevant for a given environment and
a given product.

As a developer completes code and checks the resulting product into cvs,
they supply me with information on what is required to deploy the
product. This information is translated into cfengine config files. For
a given release I "roll it out" by using a class to protect the import
of the config files needed for deployment. In some cases the deployments
requires the addition of "one-offs" like the addition of the apache web
server or a local "apache" user. These one-offs stay in my config, for
documentation and completeness, but are never executed again because I
have checks built in to determine if the user "apache" exists.

If a host blows up, or I've discovered an intruder, we can have the
machine and its entire function restored with jumpstart and cfengine in
a matter of hours (never had to do it, but in theory it should work).

I tend to agree with others that have stated there views that, as
painful as it may be to perform a check to determine if you "one-off"
has been performed, it will generally be beneficial down the road.

> -----Original Message-----
> From: Jamie Wilkinson [mailto:jaq@spacepants.org]
> Sent: Monday, July 14, 2003 8:53 PM
> To: Help-cfengine@gnu.org
> Subject: Re: Strategy for "one-off" tasks
> 
> This one time, at band camp, David Douthitt wrote:
> >Controlled update roll-outs are making this more of a necessity.  THe
> >idea is that I can update certain machines now, more machines one
week
> >later, and more machines the week after that, until all are done.
This
> >is related to a one-time-only task in that this sort of thing would
> >only be done periodically.
> 
> Controlled rollouts can be done with selective classes.
> 
> groups:
> 
>     stage1 = ( foo bar baz )
>     stage2 = ( quux )
>     stage3 = ( some other machines )
> 
>     rollout = ( stage1 stage2 )
> 
> editfiles:
> 
>     rollout::
> 
>         ...
> 
> 
> You just add the machines that you want rolled to the class as you go
> along.
> 
> >Installs also come to mind.  There are certain things I don't want
done
> >all the time that are only done during an installation.  If the
> >installation requirements change (that is, a new utility needs to be
> >installed) then I would want to install that utility once only
> >throughout the enterprise.
> 
> I think you're missing the point of convergence.  It's not a
"one-off",
> it's
> "does this need to happen, or doesn't it?".
> 
> Test if the new utility isn't installed, and then install it.  It's a
> "one-off" as long as far as you're concerned, because cfengine is
> converging
> on the wanted configuration of your system.
> 
> 
> --
> jaq@spacepants.org
http://spacepants.org/jaq.gpg
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine