Puppet users - Nov 2012 - Usage of puppet to deploy and configuration manage software patches

I have some questions in terms of how to use puppet of configuration 
management for software patches. My previous approach was it to create a 
puppet module for each patch ... Like Patch1 includes (FileA, FileB, 
FileC), Patch2 includes (FileD, FileE)... So far so good and that works but 
now i have to create a Patch3 with lets say FileF and FileA included. As 
you can see there will be a puppet conflict as i can''t deploy the same 
files within different modules. What is the right architecture and method 
to manage software patches? Is it to use rpms instead of? Or are there 
other ideas how to manage that with puppet.


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/YNceAdQNZr4J.
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 Fri, Nov 09, 2012 at 08:04:44AM -0800, Christian
wrote:
> I have some questions in terms of how to use puppet of configuration 
> management for software patches. My previous approach was it to create a 
> puppet module for each patch ... Like Patch1 includes (FileA, FileB, 
> FileC), Patch2 includes (FileD, FileE)... So far so good and that works but
> now i have to create a Patch3 with lets say FileF and FileA included. As 
> you can see there will be a puppet conflict as i can''t deploy the
same
> files within different modules. What is the right architecture and method 
> to manage software patches? Is it to use rpms instead of? Or are there 
> other ideas how to manage that with puppet.
> 
Hi,

If you should decompose them you can define them as different
classes. That however as you know will lead to an explosion of different
classes which can become pretty unmaintainable with time ...

The question is if you *should* do it this way. I don''t know
so much about your system so I can''t tell. We are mostly updating with
proper package management and build our software for upgrades.

Maybe if you tell us more about your system/setup, we can give you a better
advice?

Best, Nikola
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/YNceAdQNZr4J.
> 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.

Hi,

if your S.O is Centos/Red-hat you can use SpaceWalk, puppet is not good for
this .

Tks


2012/11/9 Nikola Petrov <nikolavp@gmail.com>
> On Fri, Nov 09, 2012 at 08:04:44AM -0800, Christian wrote:
> > I have some questions in terms of how to use puppet of configuration
> > management for software patches. My previous approach was it to create
a
> > puppet module for each patch ... Like Patch1 includes (FileA, FileB,
> > FileC), Patch2 includes (FileD, FileE)... So far so good and that
works
> but
> > now i have to create a Patch3 with lets say FileF and FileA included.
As
> > you can see there will be a puppet conflict as i can''t deploy
the same
> > files within different modules. What is the right architecture and
method
> > to manage software patches? Is it to use rpms instead of? Or are there
> > other ideas how to manage that with puppet.
> >
>
> Hi,
>
> If you should decompose them you can define them as different
> classes. That however as you know will lead to an explosion of different
> classes which can become pretty unmaintainable with time ...
>
> The question is if you *should* do it this way. I don''t know
> so much about your system so I can''t tell. We are mostly updating
with
> proper package management and build our software for upgrades.
>
> Maybe if you tell us more about your system/setup, we can give you a
> better advice?
>
> Best, Nikola
>
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/YNceAdQNZr4J.
> > 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.
>
>

-- 
Douglas Brancaglion
Security Analist

-- 
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.

Hi There,
Looking at your module approach, I think you are heading for quite a bit of 
pain, I''ve found that packaging tools such as RPM are best for this
kind of
task.

In my environment which is all RHEL based I (roughly) do the following:
- I have a number of YUM repositories defined and presented to the network 
via HTTP
- By default, all nodes have the standard production baseline YUM 
repositories enabled by default
- I use top scope variables to enable additional YUM repositories that may 
contain later package versions or testing packages via the yumrepo type
- Once these additional repositories are enabled, I can then use yum update 
to bring hosts up to a specific baseline of the OS or software set.
- Once I am happy with the functionality of this new repo, I can either 
promote it to be the production baseline or something similar.

Here is some puppet logic that operates on the $::enable_testing_repos 
value, and enables the testing repo if it is true for a host, else it is 
left defined, but disabled.

                   yumrepo { $rhelsysupporttestingrepo :
                        baseurl  => $rhelsysupporttestingrepourl,
                        descr    => "TESTING System support
packages",
                        gpgcheck => ''1'',
                        enabled  => $::enable_testing_repos ?   {
                                        ''true''  => 
''1'',
                                        default =>  ''0'',
                                    }
                    }



Re: Spacewalk - I''ve just moved my entire fleet from spacewalk /
satellite
to YUM via HTTP (Apache) with repos created with createrepo, etc and find 
it much faster and flexible.

Hope this is of some use.

Thanks,

K






On Friday, November 9, 2012 4:04:44 PM UTC, Christian
wrote:
>
> I have some questions in terms of how to use puppet of configuration 
> management for software patches. My previous approach was it to create a 
> puppet module for each patch ... Like Patch1 includes (FileA, FileB, 
> FileC), Patch2 includes (FileD, FileE)... So far so good and that works but
> now i have to create a Patch3 with lets say FileF and FileA included. As 
> you can see there will be a puppet conflict as i can''t deploy the
same
> files within different modules. What is the right architecture and method 
> to manage software patches? Is it to use rpms instead of? Or are there 
> other ideas how to manage that with puppet.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/vgJKdu76_VcJ.
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 11/09/2012 05:04 PM, Christian wrote:
> Ihave some questions in terms of how to use puppet of configuration
> management for software patches. My previous approach was it to create a
> puppet module for each patch ... Like Patch1 includes (FileA, FileB,
> FileC), Patch2 includes (FileD, FileE)... So far so good and that works
> but now i have to create a Patch3 with lets say FileF and FileA
> included. As you can see there will be a puppet conflict as i
can''t
> deploy the same files within different modules. What is the right
> architecture and method to manage software patches? Is it to use rpms
> instead of? Or are there other ideas how to manage that with puppet.
You can do it with puppet, but it really isn''t designed to do that.
It''s
declarative nature will make you a lot of trouble trying to implement
procedural tasks. So it would be much better to use technology that is
designed with that specific issue at mind - and that are the packaging
systems. So if you use RHEL/Fedora or derivates, by all means, you
should go with RPM and not stretch the puppet to the limits with ugly
hacks to accomplish things it isn''t supposed to.

-- 
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.