Modules, yum repo's & best practices

[Matthew Barr]

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: mb...@snap-interactive.com
AIM: matthewbarr1
c:  (646) 727-0535

[Dan White]

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)

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

[Matthew Barr]

:(

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 <yg...@comcast.net> 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.

[Matthew Barr]

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 :)

[Jason Slagle]

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

[jcbollinger]

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

[Ryan Coleman]

On Mon, Dec 31, 2012 at 12:18 PM, Matthew Barr <mb...@snap-interactive.com> 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. 

[Jakov Sosic]

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?

[Johan De Wit]

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
_______________________________________________________