On Mon, Mar 22, 2010 at 10:50 PM, John Warburton <jwarbur...@gmail.com> wrote:
> The issue isn't organising puppet, but dealing with a global team of 50
> people who may or may not really understand what they are dealing with
>
> I was thinking that rather than find out too late that someone has tried to
> manage the same file in muliple modules, I was wondering if putting all file
> sunder the same tree might make it a little easier for less adept puppet
> users?

You shouldn't find out until too late though? If you have duplicate
resources in your manifests, they should fail to compile.

Do you use VCS $Id$ tags? I find those make it reasonably clear when a
file has been pushed centrally.



>
> John
>
> On 23 March 2010 13:17, Ohad Levy <ohadl...@gmail.com> wrote:
>>
>> Why not simply using inheritance? or alternativly, have a source search
>> order?
>> e.g. find the first files it find.
>> in moduleA, modubleB, common
>>
>> if you really need to manage different parts of the file in different
>> modules, you might want to look for volcane concat module.
>>
>> cheers,
>> Ohad
>>
>> On Tue, Mar 23, 2010 at 8:23 AM, John Warburton <jwarbur...@gmail.com>
>> wrote:
>>>
>>> Hi All
>>>
>>> I've done a small scale puppet (130 servers) implementation per the book
>>> and had my files hierarchy under each module:
>>>     modules/module1/files
>>>     modules/module2/files
>>>     modules/module3/files
>>>     etc
>>>
>>> This worked fine because we only had a small number of people working on
>>> the project and a small number of files to manage.
>>>
>>> I am now looking at massively upscaling to have puppet run on thousands
>>> of servers, with a global admin staff of about 50, and manage more than 6000
>>> files (variants and unique instances).
>>>
>>> In a previous life, I've used cfengine with a large file hierarchy spread
>>> over multiple modules and had to manage issues where differing modules
>>> wanted to manage the same file. Identifying the issue, and refactoring
>>> modules took a lot of time and effort - and that was with an admin team of 5
>>> all in the same office.
>>>
>>> I am thinking that a monolithic module (call it ALL_FILES) that managed
>>> all files and templates will be the way to go, so that it is more visible if
>>> a file is already being managed, given the size and spread of admins:
>>>     modules/ALL_FILES/files
>>>
>>> Does anyone have any opinion or experiences they wish to share?
>>>
>>> Thanks
>>>
>>> John
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-us...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>
>
>
> --
> John Warburton
> Ph: 0417 299 600
> Email: jwarbur...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Reply via email to