On Tue, May 1, 2012 at 6:58 AM, jcbollinger <[email protected]> wrote:
>
>> But that requires the files be hosted on the puppet master.
>> What if the conf files are still rdisted out under /rdist/base instead?
>> What does that look like?
>
> It looks exactly like what you are now doing (i.e. no Puppet). How do
> you suppose Puppet is going to recognize that it needs to notify a
> service if it's not managing the file?
That was indeed a major part of the question I have.
I thought it keeps some kind of database of file checksums, etc?
Doesnt puppet support some kind of
(action if file changed), even if it doesnt "manage the file" itself?
>
> I think it would be useful to you to consider what you hope to achieve
> by incorporating Puppet into your infrastructure. Your rdist system
> must be working fairly well because you seem resistant to changing
> it. What, then, do you think Puppet can bring to the table?
A fair question. I thought I had mentioned it, but perhaps not
sufficiently clearly:
I want to change our existing hosttype:/etc/file.conf ->
/rdistbase/conf/file.conf.hosttype symlink methodology, to be more
like
node hosttype {
keep /rdistbase/conf/file.conf.host synced to /etc/file.conf
}
Our existing methodology works well 95% of the time. There are reasons
to keep it in place as is. But I want 100% coverage. symlinks break
patches, and a few other things.. The only way to extend things in
that direction that I can see, is have puppet manage the duplication
on a per-host basis.
Yes, I understand the "normal puppet way" of doing things, is to have
those conf files inside the puppet tree, but it is more maintainable
*for us*, to have all multi-host related stuff, in the single rdist
directory tree.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
