Grokbase › Groups › Puppet › puppet-users › December 2012
FAQ
I'm working with a forge module that specifies & installs a yum repo before it installs the packages, then goes about it's business.
* package isn't part of a standard repo

We operate on a policy of minimizing the amount of external repo's we use, especially on the edge systems.
* I can sync a repo into the central repo server, though.

I can't imagine we're the only shop that doesn't allow edge servers to talk to the outside world, so how do other folks deal w/ forge modules that expect that?

What's the best practice for the community?

Option 1: Don't change the module itself:
One way to deal with this is to use an internal module to override the repo class, similar to :


class internalJenkins
{
include jenkins::repo

include internalJenkins::repo # Inherits jenkins::repo
}

class internalJenkins::repo inherits jenkins::repo {
yumrepo { "jenkins":
baseurl => "http://localrepo/jenkins",
descr => "Jenkins local repo",
enabled => "1",
gpgcheck => "1",
mirrorlist => absent,
gpgkey => "http://localrepo/jenkins/jenkins-ci.org.key", }
}


Option 2:

modify the module to make the repo optional.
- probably a parameter w/ a default of install.




Matthew Barr
Technical Architect
E: mbarr@snap-interactive.com
AIM: matthewbarr1
c: (646) 727-0535

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

Search Discussions

  • Dan White at Dec 31, 2012 at 6:56 pm ⇧
    Here's what I do on the systems I manage:

    I use Cobbler and Puppet together. Using Cobbler, I make local mirrors of all the repos I want to use. Then, for the third party repositories, I copy/symlink from the local mirror into a hand-maintained local repository. That local repository then is distributed to the servers using a Puppet yumrepo resource. This lets us control exactly what goes into our servers.

    Hope this helps. Holler if you have more questions.

    “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ----- Original Message -----
    From: "Matthew Barr" <mbarr@snap-interactive.com>
    To: puppet-users@googlegroups.com
    Sent: Monday, December 31, 2012 1:40:26 PM
    Subject: [Puppet Users] Modules, yum repo's & best practices

    I'm working with a forge module that specifies & installs a yum repo before it installs the packages, then goes about it's business.
    * package isn't part of a standard repo

    We operate on a policy of minimizing the amount of external repo's we use, especially on the edge systems.
    * I can sync a repo into the central repo server, though.

    I can't imagine we're the only shop that doesn't allow edge servers to talk to the outside world, so how do other folks deal w/ forge modules that expect that?

    What's the best practice for the community?

    Option 1: Don't change the module itself:
    One way to deal with this is to use an internal module to override the repo class, similar to :


    class internalJenkins
    {
    include jenkins::repo


    include internalJenkins ::repo # Inherits jenkins::repo
    }


    class internalJenkins ::repo inherits jenkins::repo {
    yumrepo { "jenkins":
    baseurl => " http://localrepo/jenkins ",
    descr => "Jenkins local repo",
    enabled => "1",
    gpgcheck => "1",
    mirrorlist => absent,
    gpgkey => " http://localrepo/jenkins/jenkins-ci.org.key ", }

    }

    Option 2:


    modify the module to make the repo optional.
    - probably a parameter w/ a default of install.







    Matthew Barr
    Technical Architect
    E: mbarr@snap-interactive.com
    AIM: matthewbarr1
    c: (646) 727-0535



    --
    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.
  • Matthew Barr at Dec 31, 2012 at 7:26 pm ⇧
    :(

    I was really asking after the puppet side of dealing w/ a module that wants to install it's own repo's, vs the below.

    Anyone else have any thoughts from the original post?
    On Dec 31, 2012, at 1:56 PM, Dan White wrote:

    Here's what I do on the systems I manage:

    I use Cobbler and Puppet together. Using Cobbler, I make local mirrors of all the repos I want to use. Then, for the third party repositories, I copy/symlink from the local mirror into a hand-maintained local repository. That local repository then is distributed to the servers using a Puppet yumrepo resource. This lets us control exactly what goes into our servers.

    Hope this helps. Holler if you have more questions.

    We already do those things, slightly differently but the same idea. I'm actually going to look at Pulp in a bit to better manage that.

    BTW- we end up using stages for some of the repos, especially EPEL & Centos Base.



    --
    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.
  • Matthew Barr at Dec 31, 2012 at 8:24 pm ⇧
    Sorry to reply to myself.. but option #1 doesn't work. (It works for resources, but not classes. Silly me.)


    So: should forge modules use repo's explicitly? or is there already a standard design pattern that implements a parameter for repos?

    else… I guess I'll end up writing one :)

    On Dec 31, 2012, at 1:40 PM, Matthew Barr wrote:

    I'm working with a forge module that specifies & installs a yum repo before it installs the packages, then goes about it's business.
    * package isn't part of a standard repo

    We operate on a policy of minimizing the amount of external repo's we use, especially on the edge systems.
    * I can sync a repo into the central repo server, though.

    I can't imagine we're the only shop that doesn't allow edge servers to talk to the outside world, so how do other folks deal w/ forge modules that expect that?

    What's the best practice for the community?

    Option 1: Don't change the module itself:
    One way to deal with this is to use an internal module to override the repo class, similar to :


    class internalJenkins
    {
    include jenkins::repo

    include internalJenkins::repo # Inherits jenkins::repo
    }

    class internalJenkins::repo inherits jenkins::repo {
    yumrepo { "jenkins":
    baseurl => "http://localrepo/jenkins",
    descr => "Jenkins local repo",
    enabled => "1",
    gpgcheck => "1",
    mirrorlist => absent,
    gpgkey => "http://localrepo/jenkins/jenkins-ci.org.key", }
    }


    Option 2:

    modify the module to make the repo optional.
    - probably a parameter w/ a default of install.




    Matthew Barr
    Technical Architect
    E: mbarr@snap-interactive.com
    AIM: matthewbarr1
    c: (646) 727-0535
    --
    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.
  • Jason Slagle at Dec 31, 2012 at 10:26 pm ⇧

    On 12/31/2012 03:18 PM, Matthew Barr wrote:
    Sorry to reply to myself.. but option #1 doesn't work. (It works for
    resources, but not classes. Silly me.)


    So: should forge modules use repo's explicitly? or is there already a
    standard design pattern that implements a parameter for repos?

    else… I guess I'll end up writing one :)
    What I've done is to let the baseurl for the repo optional be passed
    into the class as a parameter - that fixes it from my perspective.

    Jason

    --
    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.
  • Ryan Coleman at Jan 2, 2013 at 5:42 pm ⇧

    On Mon, Dec 31, 2012 at 12:18 PM, Matthew Barr wrote:

    So: should forge modules use repo's explicitly? or is there already a
    standard design pattern that implements a parameter for repos?
    I would like to see Forge modules make the usage of a yumrepo configurable
    via parameterized classes or another mechanism. I'd be happy if the repo
    was enabled by default. If a Puppet Labs module doesn't follow that
    pattern, please point me at the bug report and I'll get it taken care of.

    --
    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.
  • Jcbollinger at Jan 2, 2013 at 5:14 pm ⇧

    On Monday, December 31, 2012 12:40:26 PM UTC-6, Matthew Barr wrote:
    I'm working with a forge module that specifies & installs a yum repo
    before it installs the packages, then goes about it's business.
    * package isn't part of a standard repo

    We operate on a policy of minimizing the amount of external repo's we use,
    especially on the edge systems.
    * I can sync a repo into the central repo server, though.

    I can't imagine we're the only shop that doesn't allow edge servers to
    talk to the outside world, so how do other folks deal w/ forge modules that
    expect that?

    I'd be inclined to reject the module outright unless it provided a
    documented mechanism for avoiding or controlling the configuration of a
    package repo. I am not inspired to confidence in the rest of the module if
    its author doesn't recognize that configuring a new repo on my systems
    might not be something I would readily accept.


    What's the best practice for the community?

    Option 1: Don't change the module itself:
    One way to deal with this is to use an internal module to override the
    repo class, similar to :

    You say in a later post that that doesn't work, but I don't see why not.
    The Yumrepo resource surely is declared by some class, and you should be
    able to create a subclass of that class that overrides its declaration. If
    the class in question is parametrized, then you should be sure that it is
    declared before your subclass.

    I'm not sure that's much better than modifying the module, though, if it
    means digging into the module implementation to find the requisite internal
    class. It's somewhat less likely to break if you update the module, but
    nowhere near as safe as using the module's documented interface.



    Option 2:

    modify the module to make the repo optional.
    - probably a parameter w/ a default of install.

    Or I'm sure you could devise other alterations that would be satisfactory.
    If you are willing to contribute the changes back to the module's project,
    then this is probably the better approach.

    There is also option 3: ask the module author to devise and implement a
    solution instead of changing the module yourself. If you can't contribute
    your own changes back upstream, then getting upstream to make them in the
    first place protects you better against breakage in the event of a module
    upgrade. Also, the person most familiar with the module implementation is
    the one who implements a solution in this case.


    John

    --
    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/-/aXAQVY_ih0sJ.
    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 Apr 17, 2013 at 10:56 am ⇧

    On 12/31/2012 07:40 PM, Matthew Barr wrote:

    class internalJenkins
    {
    include jenkins::repo

    include internalJenkins::repo # Inherits jenkins::repo
    }

    class internalJenkins::repo inherits jenkins::repo {
    yumrepo { "jenkins":
    baseurl => "http://localrepo/jenkins",
    descr => "Jenkins local repo",
    enabled => "1",
    gpgcheck => "1",
    mirrorlist => absent,
    gpgkey => "http://localrepo/jenkins/jenkins-ci.org.key", }
    }
    Why not simply do something like:

    class internalJenkins {
    require yum::repo::jenkins
    }


    And manage all repos in another module?

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Johan De Wit at Apr 17, 2013 at 11:07 am ⇧

    On 04/17/2013 12:56 PM, Jakov Sosic wrote:
    On 12/31/2012 07:40 PM, Matthew Barr wrote:

    class internalJenkins
    {
    include jenkins::repo

    include internalJenkins::repo # Inherits jenkins::repo
    }

    class internalJenkins::repo inherits jenkins::repo {
    yumrepo { "jenkins":
    baseurl => "http://localrepo/jenkins",
    descr => "Jenkins local repo",
    enabled => "1",
    gpgcheck => "1",
    mirrorlist => absent,
    gpgkey => "http://localrepo/jenkins/jenkins-ci.org.key", }
    }
    Why not simply do something like:

    class internalJenkins {
    require yum::repo::jenkins
    }


    And manage all repos in another module?
    Thats how we also do it. All repos are configured in one rep0 module.
    We do have both plain mirrored en own build repo modules. Supporting
    multiple distro and version.

    Maintenance of the packages and updates are done outside of puppet of
    course. Configuration af course with.

    We use a proxy in the dms zone, to gain acces to the repo server, which
    at this moment is hosted internally.

    Grts

    --
    Johan De Wit

    Open Source Consultant
    Red Hat Certified Engineer (805008667232363)
    Puppet Certified Professional 2013 (PCP0000006)
    _________________________________________________________

    Open-Future Phone +32 (0)2/255 70 70
    Zavelstraat 72 Fax +32 (0)2/255 70 71
    3071 KORTENBERG Mobile +32 (0)474/42 40 73
    BELGIUM http://www.open-future.be
    _______________________________________________________

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 31, '12 at 6:40p
activeApr 17, '13 at 11:07a
posts9
users7
websitepuppetlabs.com

7 users in discussion

Matthew Barr: 3 posts Jcbollinger: 1 post Jason Slagle: 1 post Johan De Wit: 1 post Ryan Coleman: 1 post Dan White: 1 post Jakov Sosic: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase