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

Search Discussions

  • Nikola Petrov at Nov 9, 2012 at 4:18 pm

    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 at Nov 9, 2012 at 6:28 pm
    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.
  • Keiran Sweet at Nov 14, 2012 at 7:13 pm
    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.
  • Jakov Sosic at Dec 5, 2012 at 11:11 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedNov 9, '12 at 4:04p
activeDec 5, '12 at 11:11p
posts5
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase