Puppet users - Nov 2010 - Propagating local config changes from a client to the puppetmaster

Hi,

I''m using puppet with a centralized puppetmaster pushing config to
many client nodes.  Most of the configuration files that puppet
manages are static and served via the puppet fileserver (running on
the puppetmaster).  I often find myself making changes to a node''s
config file, testing those changes, and then manually adding those
changes to the corresponding file on the puppetmaster.  Is there any
way for me to cut out this last step?  That is, does puppet have any
support for propagating config changes from a client node back to the
puppetmaster?  In the case of static files, it seems that puppet has
enough information to determine which client config files should be
pushed back to the puppetmaster, so this seems at least theoretically
possible.

Thanks,

Greg

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

On Tuesday 30 Nov 2010 12:58:33 gdb wrote:
> Hi,
> 
> I''m using puppet with a centralized puppetmaster pushing config to
> many client nodes.  Most of the configuration files that puppet
> manages are static and served via the puppet fileserver (running on
> the puppetmaster).  I often find myself making changes to a node''s
> config file, testing those changes, and then manually adding those
> changes to the corresponding file on the puppetmaster.  Is there any
> way for me to cut out this last step?  That is, does puppet have any
> support for propagating config changes from a client node back to the
> puppetmaster?  In the case of static files, it seems that puppet has
> enough information to determine which client config files should be
> pushed back to the puppetmaster, so this seems at least theoretically
> possible.
> 
> Thanks,
> 
> Greg
We use git.

Make all the changes locally, test them in a VM, push the changes to GIT, pull 
the repos onto the pupptermaster.

I''m not too sure the scenario you''ve just described is
possible...

M.

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

gdb <greg@gregbrockman.com> writes:
> I''m using puppet with a centralized puppetmaster pushing config to
many
> client nodes.  Most of the configuration files that puppet manages are
> static and served via the puppet fileserver (running on the puppetmaster).
> I often find myself making changes to a node''s config file,
testing those
> changes, and then manually adding those changes to the corresponding file
on
> the puppetmaster.  Is there any way for me to cut out this last step?
Not really at this point, no.  You can use a filebucket to collect them
automatically to the server, but it won''t update your changes into
puppet.
> That is, does puppet have any support for propagating config changes from a
> client node back to the puppetmaster?  In the case of static files, it
seems
> that puppet has enough information to determine which client config files
> should be pushed back to the puppetmaster, so this seems at least
> theoretically possible.
Theoretically.  OTOH, in the puppet model copying files is a sign that we
don''t have sufficient rich types available yet, so it isn''t
exactly a
focus... :)


That said, in my experience most folks are way, way better off investing the
time to have the ability to spin up a new VM and test your changes in there
*before* you even think about touching a production system.

        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

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

On Nov 30, 6:58 am, gdb <g...@gregbrockman.com>
wrote:
> That is, does puppet have any
> support for propagating config changes from a client node back to the
> puppetmaster?
You mean so that the updated files will subsequently be served out to
clients?  No, Puppet does not support that, and personally, I don''t
find the idea very appealing.  In fact, I would find Puppet itself
slightly less appealing if it offered such a feature, as I would then
have to worry that some bug in one of my manifests or in Puppet itself
might cause the feature to actually turn on.  I WANT there to be at
least a nominal barrier to overcome in order to change the
configuration that my Puppetmaster pushes out.
>  In the case of static files, it seems that puppet has
> enough information to determine which client config files should be
> pushed back to the puppetmaster, so this seems at least theoretically
> possible.
Puppet definitely has enough information to determine that a file is
different on the client than on the Puppetmaster.  It specifically
checks that to determine whether it needs to sync the file on the
client (unless the File is declared with replace => false).

It would be a bit trickier, however, for Puppet to manage collecting
potentially conflicting change sets from multiple clients and then
merging them into its master copy.  Moreover, doing so would turn the
Puppet model on its head: the master is (now) the golden source
against which clients are measured.  Clients are managed, not
managers.

As Daniel wrote, test first, then put your files into production.  If
you really need only tiny tweaks, and you are confident about them,
then perform them on the Puppetmaster''s copy and use Puppet to push
them out.


Regards,

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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

The issue becomes that while it would offer you a time saver in the
short term, it would give you headaches later with security and as you
try to expand out your puppet infrastructure, which you will have to
do once you reach at the very least 50 hosts. The best solution that I
could offer is you would want to publish files to a source control
repository and basically have the puppetmaster populate the working
copy from the copy in source control. This offers a bit of control
when you try to only push out production changes to production
systems, and also ensure that if you have multiple puppet masters that
they will have the correct file.

On Tue, Nov 30, 2010 at 7:58 AM, gdb <greg@gregbrockman.com>
wrote:
> Hi,
>
> I''m using puppet with a centralized puppetmaster pushing config to
> many client nodes.  Most of the configuration files that puppet
> manages are static and served via the puppet fileserver (running on
> the puppetmaster).  I often find myself making changes to a node''s
> config file, testing those changes, and then manually adding those
> changes to the corresponding file on the puppetmaster.  Is there any
> way for me to cut out this last step?  That is, does puppet have any
> support for propagating config changes from a client node back to the
> puppetmaster?  In the case of static files, it seems that puppet has
> enough information to determine which client config files should be
> pushed back to the puppetmaster, so this seems at least theoretically
> possible.
>
> Thanks,
>
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks all for the responses.  Sounds like basically the answer is
"you don''t actually want the thing you are asking for", which
after
hearing the reasoning I''m convinced is correct.  I''m basically
just
building out my puppet infrastructure now, which is why I was
interested in a feature like this, but I think I''m actually rather
glad it doesn''t exist :).

Best,

Grge

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

Still trying to sort out whether this use-case even makes sense, but what if 
I were to use Puppet to standardize development environments?

It may be the case that someone makes a change or sets themselves up with a 
tool/configuration that allows them to work more efficiently. I can imagine 
a scenario where, after selling the benefit of these changes to a project 
lead, we''d want to push that change back to the puppet master so that
every
dev system would get them without developers having do it manually. Now 
everyone''s on the same page and working with the same tools.

Any thoughts? I like the Git idea, and might pursue that, but wondering if 
anyone has input :)

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

On Wednesday, March 2, 2011 at 5:52 PM, Patrick Connolly wrote:
Still trying to sort out whether this use-case even makes sense, but what if I
were to use Puppet to standardize development
environments?
> 
> It may be the case that someone makes a change or sets themselves up with a
tool/configuration that allows them to work more efficiently. I can imagine a
scenario where, after selling the benefit of these changes to a project lead,
we''d want to push that change back to the puppet master so that every
dev system would get them without developers having do it manually. Now
everyone''s on the same page and working with the same tools.
> 
> Any thoughts? I like the Git idea, and might pursue that, but wondering if
anyone has input :)
I use DevStructure''s (full disclosure: I''m the CTO) Blueprint
tool to promote configurations from development to production. Blueprint figures
out what I did to my development server and then I commit the Puppet code it
generates to Git.

http://devstructure.com/tutorial.html
http://devstructure.github.com/blueprint/



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

On Mar 2, 5:52 pm, Patrick Connolly <patrick.c.conno...@gmail.com>
wrote:
> Any thoughts? I like the Git idea, and might pursue that, but wondering if
> anyone has input :)
If you''re on EL you may want to look at cft[1]. I thought I saw
mention of work to bring ti to Deb based distros as well. I haven''t
actually used it, but looks like the poor cousin of DevStructure
Blueprint.


[1] http://cft.et.redhat.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-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.