thr3ads.net - Puppet users - [Puppet Users] Modules, yum repo''s & best practices [Dec 2012]

If this information is useful, please help other people find it:
Share via:

Matthew Barr

2012-Dec-31 18:40 UTC

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

Dan White

2012-Dec-31 18:56 UTC

head link

Re: [Puppet Users] Modules, yum repo''s & best practices

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

2012-Dec-31 19:26 UTC

head link

Re: [Puppet Users] Modules, yum repo''s & best practices

:(

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

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

2012-Dec-31 20:18 UTC

head link

[Puppet Users] Re: Modules, yum repo''s & best practices

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 <mbarr@snap-interactive.com>
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

2012-Dec-31 22:18 UTC

head link

Re: [Puppet Users] Re: Modules, yum repo''s & best practices

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.

jcbollinger

2013-Jan-02 17:14 UTC

head link

[Puppet Users] Re: Modules, yum repo''s & best practices

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.

Ryan Coleman

2013-Jan-02 17:42 UTC

head link

Re: [Puppet Users] Re: Modules, yum repo''s & best practices

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

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

Jakov Sosic

2013-Apr-17 10:56 UTC

head link

Re: [Puppet Users] Modules, yum repo''s & best practices

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

2013-Apr-17 11:07 UTC

head link

Re: [Puppet Users] Modules, yum repo''s & best practices

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.

Puppet users - Dec 2012 - Modules, yum repo's & best practices

[Puppet Users] Modules, yum repo''s & best practices

Re: [Puppet Users] Modules, yum repo''s & best practices

Re: [Puppet Users] Modules, yum repo''s & best practices

[Puppet Users] Re: Modules, yum repo''s & best practices

Re: [Puppet Users] Re: Modules, yum repo''s & best practices

[Puppet Users] Re: Modules, yum repo''s & best practices

Re: [Puppet Users] Re: Modules, yum repo''s & best practices

Re: [Puppet Users] Modules, yum repo''s & best practices

Re: [Puppet Users] Modules, yum repo''s & best practices