On 5 Aug 2011, at 12:10, Alessandra Forti wrote:
>> we have been faced with the problem of fabric management for testbeds.
> 
> this is how YAIM came to life and why it was so successful in 
> simplifying everybody's life.

> You know I've always been a fierce YAIM supporter because it is simple 
> and system administrators don't have to wait for the guru to fix it and 
> adapt it as it used to happen before.

Hrm.  We find YAIM to be as much of a problem as a benefit.  That's not down to the actual software itself, but rather the class of software it is.

As a configuration file complier, it's job is to hide configuration complexity.  This has advantages, of course, but it also has it's own disadvantages.  One of the biggest disadvantages in that is that it removes pressure on the software developers to make things easier to configure - rather than removing complexity it can be hidden.  

In the long run, having shorter, fewer and more direct configuration files is a better place to be than slicing, dicing and distributing data.  (e.g. compare configuration of the gLite stack with the Arc stack).

The time when this is most noticeable is when one has to deal with configuration options that are not handled by YAIM. At that point one has to deal with _both_ YAIM _and_ the underlying files - and often use automated on the fly editing to keep YAIM from reverting changes.

In fact, those occasions get complicated by the fact that most of the configuration documentation is now written in terms of YAIM actions - rather than in terms of what the services actually use.  I find that quite the opposite of Alessandra, YAIM means waiting on the developers to suggest things, rather than reading all the configuration documentation to find relevant areas to explore.

There are areas that YAIM doesn't configure (MySQL configs, for example) that mean it needs to be paired with some other configuration management (or be handled manually).  It also doesn't deal with non-grid software, so that needs handled some how - and then we end up having to use two different things instead of one.


I suspect that the way YAIM works by default is fine for many sites, and a sensible 'default configuration' is practically essential for software to be widely used.  However, when one has to go beyond that, it gets exponentially more difficult to use effectively.  Again - that's down to the fundamental nature of the tool - YAIM is by far the best configuration compiler I've ever used; but I do but into the limits of even a theoretically perfect configuration compiler with uncomfortable regularity.

We use cfengine v2, and probably migrating to cfengine v3 at some point.  Puppet ... didn't seem like a better option for us when I last looked at it.
(I'd prefer documentation over executable configuration if there has to be a choice between the two.  Both would, of course, be better).


> On 05/08/2011 11:32, Markus Schulz wrote:
>> Hi Alessandra,
>> 
>> we have been faced with the problem of fabric management for testbeds. For this the two obvious solutions haven't been 100 % suited.
>> 
>> 1) YAIM based manual configuration
>> 2) Quattor based configuration
>> 
>> For 1) the testbeds are too big and too volatile. 2) looked like a bit too much.
>> 
>> After we moved for the testbed to Puppet we thought that we might as well provide the modules to the free world.
>> Given the growing popularity of puppet we wondered how many of our 300+ sites connected have already looked at it.
>> 
>> To answer the question concerning the strategy...... No real strategy behind it. If we see that sites use already puppet we
>> would like to know so that we can share experience.
>> 
>>          markus
>> 
>> 
>> On Aug 5, 2011, at 12:04 PM, Alessandra Forti wrote:
>> 
>>> Hi Andrew,
>>> 
>>> I noticed that DPM has a new puppet 'component'. You now are actually surveying general use of it.
>>> 
>>> What is the strategy behind?
>>> 
>>> We have been using cfengine for the past 5 years.
>>> 
>>> cheers
>>> alessandra
>>> 
>>> 
>>> On 05/08/2011 10:50, Andrew Elwell wrote:
>>>> Hi Folks,
>>>> 
>>>> A quick survey -- how many of you are running some sort of fabric
>>>> management for your clusters?
>>>> 
>>>> if so, which one and why?
>>>> 
>>>> (feel free to respond off-list directly to me if you'd rather)
>>>> 
>>>> background -- trying to see how many sites are using, or thinking of
>>>> using puppet.
>>>> 
>>>> 
>>>> Many thanks
>>>> 
>>>> Andrew