gmane.comp.configuration-management.users

Suggestion: config-mgmt sponsorship of an annual CM survey

Summary: I've recently been talking with owners/developers of a few of
the different configuration management systems, and I would like to
suggest that this group work together to build an annual survey that
can then be advertised and used across the different communities, with
the input process for the survey being open, and the results being
open as well.

Background: I've noticed that many of the CM developers are doing
surveys within their own communities; however, many of the questions
are actually applicable across all CM communities.  Since there are
overlapping (competing, even) surveys, it's not realistic to have the
survey being done by ABC go out to the XYZ community, even though much
of the data would be usefully shared across the larger CM community.

Proposal: whomever is interested form a group to work on a generic
survey to be distributed annually that CM product owners could opt-in
to use in their communities.  The CM product owners who opt-in could
still do their own product-specific surveys within their own
communities, of course, to help with their own prioritize directions
for their products, but the generic survey would be cross-product,
with resulting data available to everyone.

Do people think that's a good idea, and who is interested in
participating in helping construct the survey?

Thanks,
Steven Jenkins
End Point Corporation
http://www.endpoint.com/

(Continue reading)

headers

John P. Rouillard | 16 Jan 23:49

DACS - YACCMS version 2.0 released


Hi Folks:

Well the much promised version 2.0 of the 'Config' computer
configuration management system renamed DACS is finally released.

The home page is:

  http://www.cs.umb.edu/~rouilj/DACS

This page includes the manula in pdf and html forms as well as a tar
bundle with a starter DACS master tree.

A quick blurb from the home page:

DACS, the Distribution and Configuration System, is a tool for
maintaining system configuration on multiple computers. It is similar
to other CCM (computer configuration management) tools such as bcfg2,
lcfg, puppet and the well known cfengine. However, it has some unique
features, it integrates:

    * a host "database"
    * a version control system
    * an optional file generation system
    * a file distribution and remote command execution mechanism

The other systems I looked at in 2005 had minimal (or absent) support
for the key things I wanted in a configuration system:

    * a database of information about systems that can be queried

(Continue reading)

headers

John P. Rouillard | 2 Dec 05:09

Looking for editors for DACS CCM documentation

Hi all:

During the last LISA conference I had a few people ask me about the
availiability of the next generation of the Config CCM (computer
configuration mangement) tool called DACS.

I have taken this week off from work to get a running start on getting
the documentation and release done and I am looking for some
editors/reviewers for the documentation.

I have one prior DACS user who is looking at deploying it at another
job. I would like at least one reviewer who is using/has used a CCM system,
bcfg2, puppet, cfengine etc doesn't matter. Also I would like a
reviewer who hasn't deployed or used a CCM and is considering it.

I am afraid I can't provide anything except mention in the document
(unless you would rather I omit your name ).

I am looking for a release by 1 Jan, so the editing and comments would
have to be done by then.

I have the following sections at the moment:

  Intro
  Database
  Version Control System
  Build system
  Distribution
  Examples/Case Studies
  Advanced topics

(Continue reading)

headers

Paul Anderson | 6 Oct 09:24

Re: Configuration files


On 4 Oct 2008, at 20:00, Narayan Desai <desai@...> wrote:

>   Paul> I think this is going in the right direction, but I still  
> think that
>   Paul> dealing with "files" as opaque objects is misleading - a  
> "file" is
>   Paul> rather an arbitrary unit - it is just a convenient way of  
> bundling
>   Paul> together some information - which may, or may not be  
> conceptually
>   Paul> related in configuration terms.
>
> I disagree. While I certainly agree that configuration files are a
> historical artifact, as opposed to some sort of platonic ideal, there
> are some really useful properties that configuration file-based
> statistics have that have not yet (to my knowledge) been implemented
> with a parameter-based statistics mechanisms (for lack of a better  
> term).
>
> Like it or not, configuration files are a unique formulation; this  
> means
> that a given change (or state) can be represented in a unique
> fashion.

You are picking a completely arbitrary level by talking about files. Why
not talk about bits on the disk if you want to use this argument -  
the same
is true there, and that actually makes a much better starting point  
if you

(Continue reading)

headers

Paul Anderson | 3 Oct 13:48

Re: Config-mgmt Digest, Vol 32, Issue 2

On 2 Oct 2008, at 20:00, John Rouillard <rouilj@...> wrote:

> I am not claiming that a file is the ultimate end all, but it does
> provide a level of granularity that can be measured.

I guess I'm just not sure what you are measuring by doing this  
though ...
It doesn't really relate to the effort required to make the change,  
or the potential
disruption, or .... (anything useful?)

>> Who cares how
>> many low-level operations (file replacements, file edits, database
>> inserts, process restarts) the configuration management system needs
>> to perform?
>
> Well the goal is to get a configuration change deployed. If you are
> waiting for an hour for the CM system to run through it's file
> generation, update, restart to impose a configuration then it is a big
> deal as it contributes to waiting time which is a type of waste under
> a LEAN framework.

Um. I'm still don't get this. Isn't it like saying that you are going  
to write
raw machine code because you can't be bothered to wait for the
compiler .. .. ? Usually, having it correct is more important than fast.

> Then you may have to do it a couple of times if you didn't get the
> config right the first time. Right now depending on how well the

(Continue reading)

headers

Paul Anderson | 1 Oct 08:42

Re: Config-mgmt Digest, Vol 31, Issue 6


On 30 Sep 2008, at 20:00, Lamont Granquist <lamont@...>  
wrote:

> if you want to measure a useful statistic, measure the complexity  
> of the configuration state when it comes to deltas between boxes.
> as an example:
>
> if you have 30,000 servers with the same sshd_config file that is  
> highly compressible information and is a very low amount of state.
>
> if you have 30,000 servers with the same sshd_config file except  
> one group of boxes which have a different sshd_config file then  
> that is only slightly less compressible, but it roughly doubles the  
> compressed state (considering the sshd_config files to be opaque).
>
> if you have 30,000 servers with most having the same sshd_config  
> file except you've got 10 unique groups but those groups all share  
> the same slightly different sshd_config file, then that is even  
> less compressible.
>
> if you have 30,000 servers and have a standarized default, but 10  
> different groups have 10 differently unique sshd_config files then  
> you've degraded your compressibility even more.
>
> if you have 30,000 servers and have 10 different sshd_configs, but  
> have 6,000 different groups of servers and have no sane default and  
> each server group gets one of the 10 different config files, then  
> you've got a huge amount of config state (equivalent to 6,000  
> individual servers with each server having one of 10 different

(Continue reading)

headers

Paul Anderson | 29 Sep 09:30

Useful stats from a CM system (John Rouillard)

On 28 Sep 2008, at 20:00, John Rouillard <rouilj@...> wrote:

>> I'd be interested in a very simple
>> classification of the reasons - eg. software upgrade, hardware
>> upgrade, configuration bug fix, etc. etc.
>
> Interesting idea. Do you have an exhaustive list of categories
> that you would like to see?

No - I had these "starters", but I thought we'd need to try it out  
for real
and add new ones when people came to make a change that didn't fit
any of the existing categories. I'd *really* like to see some figures on
this, but you need the buy-in from the people actually making the
changes to make this worthwhile ....

>  The
> amount of work the user has to do is reduced by 1/(multiplier) since
> the user touches one file rather than say the 10 files that really
> have to be updated.

Yes. Again, its not just the amount of work though - its the improved  
chance
of getting it consistent and correct ....

>> (*) "How do you tell whether your config management system is making
>> things better?". It would be very interesting to do some kind of
>> formal study on this
>

(Continue reading)

headers

Paul Anderson | 24 Sep 12:07

Re: Useful stats from a CM system

On 23 Sep 2008, at 17:25, John Rouillard <rouilj@...> wrote:

> In my first musings I talked about using a version control system to
> determine how efficient your CM system is ....

Hi John ...

This is all very interesting indeed. I'll try and summarised the  
issues that it
raised for me ...

(*) I'm really interested in metrics. I'd certainly be interested in  
sharing some information and
doing some joint analysis on this if it looked like it would be  
useful. I have 5-10 years worth
of configuration change data (in CVS) for 1000+ machines. What I  
don't have is a good
correlation between this and the "why" (tickets). In theory the CVS  
commit comment should
say something useful, but in practice, it often doesn't. I'd be  
interested in a very simple classification
of the reasons - eg. software upgrade, hardware upgrade,  
configuration bug fix, etc. etc.

(*) A "file" is not a good granularity for me - our config system  
(based on LCFG) deals with "resources"
which are a slightly higher level and a single resource change may  
affect multiple files. I'm not sure what
is a good level for a useful metric - but I don't think "file" is the

(Continue reading)

headers

John Rouillard | 23 Sep 01:28

Useful stats from a CM system (part 3) reports

Hi all:

This is my third and last musing on CM stats using the DACS CM tool.

In my first musings I talked about using a version control system to
determine how efficient your CM system is, how may files need to be
changed per ticket, how many time a file has to be changed for a
ticket to get it right etc. In the second musings I discussed how to
determine if the CM system is being used or subverted by looking at
the number of files changed in the wild by the CM system. (This can be
very different from the number of files changed in the version control
system if you generate files.)

(As a funny aside I just calculated those metrics for where I
work. Usually we manage 5300 changes/month from November-2007 through
July-2008. In August we had fewer than 2500 changes with no fewer
tickets completed/updated. Sigh, anyway.)

In this musing I look at the daily report that the CM systems
generate. I equate configuration anomalies with bugs in software. It
is also a measure of how successful the systems are at getting to a
standard foundation on which you can build an efficient environment.

The metrics I am looking at gathering here are:

   1 Number of files not in compliance and not flagged as testing/work
     in progress. Our oncall person is responsible for dealing with
     these reports. There is usually one of three types:

        1 True anomaly - resolve by pushing file from DACS

(Continue reading)

headers

John Rouillard | 15 Aug 00:30

Useful stats from a CM system (part 2) the push

Hi all:

Here are some more musings on stats that may tell you how your CM
system is working.

DACS uses a push model for distribution, but I think the stats are
applicable to push and pull models.

From the distribution system we can get metrics on the number of files
pushed and which files are being pushed.

   1. The "(number of files pushed)/(machine in service)" metric
      should be rising or steady as it is an indication of how many
      changes are occurring. If it drops, and the number of tickets
      being closed remains the same it's an indication that people
      aren't using the CM system to manage new systems. Does anybody
      have any numbers on this for their sites?

      For my company it's running approx 50 files/month-machine
      (I.E. approx 100 machines, 5000 files updated per month). Note
      the number of machines includes any system type that is
      supported by DACS, but isn't managed via DACS. So Cyclades and
      Opengear terminal servers aren't included, but that Centos 5
      virtual machine that isn't updated via DACS is included.

   2. The number of changes/week, month etc. Where a change is a file
      pushed to an end system. We average somewhere around 5000 file
      changes per month. This includes password files, service
      configuration and firewalls changes.

(Continue reading)

headers

John Rouillard | 4 Aug 02:23

Useful stats from a CM system (part 1)

Hello all:

I am currently looking at trying to get some information out of the CM
system for the purpose of:

   * verifying that the system is getting used

   * improving the speed with which changes can be made

   * determining/increasing the first pass success rate (i.e. the
     first time you change the file is the only time you have to
     change the file)

   * looking for problems where training can be provided to reduce
     error rates and eliminate having to redo work.

The system I am analyzing is DACS, it consists of four basic elements:

   * inventory system that maps services and host characteristics
     (e.g. ip address, ethernet address, has particular hardware etc.)
     onto a host.

   * a version control system based on subversion where (the inputs to)
     everything that gets pushed is version controlled allowing
     rollback and re-establishment of a prior state.

   * a build system based on gnu make that can take version controlled
     input files and transform them into files to be pushed to
     machines.

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31