Puppet users - Feb 2008 - Yumrepo and managing the contents of /etc/yum.repos.d directory...

Puppet version: 0.22.4
facterversion => 1.3.7
rubyversion => 1.8.5

Given the following:

file { yum_repo_d:
  path    => "/etc/yum.repos.d",
  ensure  => directory,
  recurse => true,
  purge   => true
}

yumrepo { pkg_repo:
  descr     =>  "Packages Repository",
  enabled   =>  1,
  baseurl   =>  "http://Some/path/",
  gpgcheck  =>  0,
  require   =>  File[yum_repo_d]
}

Every time I run pcheck now, the file is deleted and recreated and pcheck
gripes about the file being there and needing to be deleted.  The workaround,
of course, is to use templates but that''s broken.

verbose noop gives the following notice every time:

notice:
//workstation/base/yum_base/File[/etc/yum.repos.d/scea_pkg_repo.repo]/ensure:
//is file, should be absent (noop)


Is anyone else seeing this?

--Robert

On Fri, 2008-02-22 at 11:40 -0800, Robert Nickel wrote:
> file { yum_repo_d:
>   path    => "/etc/yum.repos.d",
>   ensure  => directory,
>   recurse => true,
>   purge   => true
> }
Try without the purge .. puppet doesn''t think of yumrepo resources as
files, and therefore doesn''t know that the yumrepo you defined goes
into
a file that should be excluded from the purge.
> notice:
//workstation/base/yum_base/File[/etc/yum.repos.d/scea_pkg_repo.repo]/ensure:
> //is file, should be absent (noop)
Is that a typo in the log output ? The yumrepo resource doesn''t create
a
''scea_pkg_repo.repo'' - not sure where the scea_ prefix comes
from. Do
you have another file resource in your manifest somewhere ?

David

On 2008.02.22 14:47:02 +0000, David Lutterkort wrote:
> On Fri, 2008-02-22 at 11:40 -0800, Robert Nickel wrote:
> > file { yum_repo_d:
> >   path    => "/etc/yum.repos.d",
> >   ensure  => directory,
> >   recurse => true,
> >   purge   => true
> > }
> 
> Try without the purge .. puppet doesn''t think of yumrepo resources
as
> files, and therefore doesn''t know that the yumrepo you defined
goes into
> a file that should be excluded from the purge.
I was afraid of that.

The purge is required to be there so that we don''t have unknown yum
repositories in place from our users.
> > notice:
//workstation/base/yum_base/File[/etc/yum.repos.d/scea_pkg_repo.repo]/ensure:
> > //is file, should be absent (noop)
> 
> Is that a typo in the log output ? The yumrepo resource doesn''t
create a
> ''scea_pkg_repo.repo'' - not sure where the scea_ prefix
comes from. Do
> you have another file resource in your manifest somewhere ?
No.  It''s just the name of the file before I altered the configs for
public
digestion.

I think I''m just going to switch back to managing the directory by hand
unless
there''s another way to ensure that the repository directory is empty
save
repos defined by puppet.

Thanks,
--Robert

Hi

There was once the discussion on the list that puppet doesn''t see
yumrepo as a file and therefore the holding directory can''t be purged:
>> file { yum_repo_d:
>>   path    => "/etc/yum.repos.d",
>>   ensure  => directory,
>>   recurse => true,
>>   purge   => true
>> }
> 
> Try without the purge .. puppet doesn''t think of yumrepo resources
as
> files, and therefore doesn''t know that the yumrepo you defined
goes into
> a file that should be excluded from the purge.
am I right to assume that this is the same with the new nagios types?

as I see this might be related to bug #949 [1] which is open already I
while.
I can Imagine that this might be quite a lot to change and therefore not
that easy. However is there currently work toward to fix this problem,
or what is the current best practise to fix this issue?

A solution which just popups right now while writing my mind is to make
for each puppet-nagios_cmd-target-file (for example
/etc/nagios/nagios_command.cfg,) a "dummy" file resource:

file{"/etc/nagios/nagios_command.cfg":
   ensure => file,
   replace => false,
   mode => 0644, owner => root, group => 0;
}

to ensure that they''re not purged. would this work?

and might this also be a solution for the yumrepo problem? so for each
yum_repo and additional "dummy" file (with a define as wrapper this
might be easy)?

as this idea was just popping up I''m going to test it now :)

greets Pete

[1] http://reductivelabs.com/trac/puppet/ticket/949

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

On Apr 24, 2008, at 2:15 PM, Peter Meier wrote:
> A solution which just popups right now while writing my mind is to  
> make
> for each puppet-nagios_cmd-target-file (for example
> /etc/nagios/nagios_command.cfg,) a "dummy" file resource:
>
> file{"/etc/nagios/nagios_command.cfg":
>   ensure => file,
>   replace => false,
>   mode => 0644, owner => root, group => 0;
> }
>
> to ensure that they''re not purged. would this work?
Yes, this should work well -- files that are mentioned in your catalog  
are never purged.

-- 
We are here on Earth to do good to others. What the others are here
for, I don''t know. -- W. H. Auden
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
>> A solution which just popups right now while writing my mind is to  
>> make
>> for each puppet-nagios_cmd-target-file (for example
>> /etc/nagios/nagios_command.cfg,) a "dummy" file resource:
>>
>> file{"/etc/nagios/nagios_command.cfg":
>>   ensure => file,
>>   replace => false,
>>   mode => 0644, owner => root, group => 0;
>> }
>>
>> to ensure that they''re not purged. would this work?
> 
> Yes, this should work well -- files that are mentioned in your catalog  
> are never purged.
this works perfectly! :)

for people who are yurious how that looks like:

yum with wrapper define for repos:
https://git.puppet.immerda.ch/?p=module-yum;a=blob_plain;f=manifests/init.pp;hb=HEAD

nagios with dummy files for the native natios_cmds:
https://git.puppet.immerda.ch/?p=module-nagios;a=blob_plain;f=manifests/init.pp;hb=HEAD

greets pete



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

A personal note about using yumrepo types (and the general approach to
puppet management):

What are the pros and cons of this:

    yum::managed_yumrepo {extras:
        descr => ''CentOS-$releasever - Extras'',
        mirrorlist =>
''http://mirrorlist.centos.org/?release$releasever&arch=$basearch&repo=extras'',
        enabled => 1,
        gpgcheck => 1,
        gpgkey =>
''file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5'',
        priority => 1,
    }

compared to something like this:
	                        file {
 	                                "/etc/yum.repos.d/CentOS-
Extra.repo":
 	                                        mode => 644, owner => root,
group => root,
 	                                        backup => local,
 	                                        ensure => present,
 	                                        source => "puppet://
$servername/repo/CentOS-Extra.repo",
	                        }
(with the file CentOS-Extra.repo placed in $modulesdir/repo/files/ ),

or, more generally, why overruse puppet declarations and templates
instead of placing the right file on the right place?

Absolutely do not consider this as a polemic or a "my solution is
better than yours" post, I just would like to better understand all
the positions and motivations behind a choice.
For my point of view, puppet should be a tool which eases a sysadmin
life.
Sysadmins know their stuff but don''t generally know puppet or
puppet''s
modules logic,  they are used to plain configuration files, placing
the usual config file in the module files dir (with a cp or cut&paste)
for me is easier and less error prone than defining variables or fill
with correct values (more cut and pastes) a yumrepo definition (or
whatever).
This is now always true, of course, templates and custom or specific
types can be very useful and give better flexibility, but at times I
feel like there''s the tendency to make plain and easy things over
complicated / structured.

My 1.5 cents
al
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Al @ Lab42 wrote:
> A personal note about using yumrepo types (and the general approach to
> puppet management):
> 
> What are the pros and cons of this:
> 
>     yum::managed_yumrepo {extras:
>         descr => ''CentOS-$releasever - Extras'',
>         mirrorlist =>
''http://mirrorlist.centos.org/?release>
$releasever&arch=$basearch&repo=extras'',
>         enabled => 1,
>         gpgcheck => 1,
>         gpgkey =>
''file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5'',
>         priority => 1,
>     }
> 
> compared to something like this:
> 	                        file {
>  	                                "/etc/yum.repos.d/CentOS-
> Extra.repo":
>  	                                        mode => 644, owner => root,
> group => root,
>  	                                        backup => local,
>  	                                        ensure => present,
>  	                                        source => "puppet://
> $servername/repo/CentOS-Extra.repo",
> 	                        }
> (with the file CentOS-Extra.repo placed in $modulesdir/repo/files/ ),
(Speaking not as a puppet developer or anything, just as a relatively new and
quite satisfied user...)

In short - the more puppet is able to understand a given file (or any other
configuration entity), the better is able to intelligently manage it.

Take the yumrepo example you have.  Assume you have two different hosts, both
of which you want to point at the same repo, but one of which is behind a
highly restrictive firewall, requiring use of a proxy to get through.

With native yumrepo types, it is very straightforward to set up the repo once,
and then add the proxy parameter in the puppet config for the server that
needs it (or it a child class, if you want to do it for multiple servers).  If
you were using a simple file, you''d have to either maintain two copies
of the
file (one with the proxy and one without), or create a template and manually
turn the proxy on or off in there.

Using native types also allows puppet to only manage the settings it''s
told
about, rather than forcing itself on the entire file.  Take managing user
accounts in a heterogeneous environment.  Even if all of the systems use
exactly the same passwd/shadow file format, it''s likely that from one
to the
next, there will be different system accounts that are required for normal
operations.  By using the native user type instead of just pushing out a
passwd and shadow file, you can safely ignore those additional OS specific
accounts without worrying about accidentally blowing them away.

The general file and exec types are certainly necessary, as there will always
be plenty of corner cases that aren''t covered by native types, no
matter how
easy they are to write.  But in the long run, the more you can get away with
just using native types instead of manually creating lots of templates, the
easier and more effective puppet gets.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

--~--~---------~--~----~------------~-------~--~----~
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
> What are the pros and cons of this:
> 
>     yum::managed_yumrepo {extras:
>         descr => ''CentOS-$releasever - Extras'',
>         mirrorlist =>
''http://mirrorlist.centos.org/?release>
$releasever&arch=$basearch&repo=extras'',
>         enabled => 1,
>         gpgcheck => 1,
>         gpgkey =>
''file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5'',
>         priority => 1,
>     }
> 
> compared to something like this:
> 	                        file {
>  	                                "/etc/yum.repos.d/CentOS-
> Extra.repo":
>  	                                        mode => 644, owner => root,
> group => root,
>  	                                        backup => local,
>  	                                        ensure => present,
>  	                                        source => "puppet://
> $servername/repo/CentOS-Extra.repo",
> 	                        }
> (with the file CentOS-Extra.repo placed in $modulesdir/repo/files/ ),
> 
> or, more generally, why overruse puppet declarations and templates
> instead of placing the right file on the right place?
> 
> Absolutely do not consider this as a polemic or a "my solution is
> better than yours" post, I just would like to better understand all
> the positions and motivations behind a choice.
> For my point of view, puppet should be a tool which eases a sysadmin
> life.
> Sysadmins know their stuff but don''t generally know puppet or
puppet''s
> modules logic,  they are used to plain configuration files, placing
> the usual config file in the module files dir (with a cp or cut&paste)
> for me is easier and less error prone than defining variables or fill
> with correct values (more cut and pastes) a yumrepo definition (or
> whatever).
> This is now always true, of course, templates and custom or specific
> types can be very useful and give better flexibility, but at times I
> feel like there''s the tendency to make plain and easy things over
> complicated / structured.

pros:

- it uses native puppet types
- enables to have repositories in an inheritance chain and let easily
overwrite or disable them:

class yumrepo_internal inherits yumrepo_standard {
	Managed_yumrepo[foobar_only_needed_exernal]{
		enabled => false,
	}

	Managed_yumrepo[standard_repo]{
		baseurl =>
''$use_internal_yum_repo_mirror_to_save_bandwidth''
	}

	Managed_yumrepo[testing_repo_what_we_use_internal]{
		priority =>
''$higher_than_external_so_we_use_the_testrepo_internally''
	}
	etc.
}
- look at the the puppet-manifests and know what they do, you don''t
have
to look at some configfiles
- go away from deploying config-files to rather managing them, otherwise
we could simply use some (advanced) scp scripts to ensure the
deployement of plain textfiles and we wouldn''t need puppet.
- go away from your typical sysadmin jobs and hacking scripts together
and move forward to a system architecture designer

- cons:

none, or maybe a bit of more engineering work, which however enables you
the pros from above.

I didn''t really see any cons from your site except that you might see
this as a bit of overengeenering. However you see that you then have
none of the pros I mentioned above.

My personal interest in puppet is to go away from traditional hacking of
some textfiles together to a more engineering like approach and to
design the environment which I want.

my point of view. ;)

greets pete

--~--~---------~--~----~------------~-------~--~----~
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
>> [...]
> (Speaking not as a puppet developer or anything, just as a relatively new
and
> quite satisfied user...)
> 
> In short - the more puppet is able to understand a given file (or any other
> configuration entity), the better is able to intelligently manage it.
> 
> Take the yumrepo example you have.  Assume you have two different hosts,
both
> of which you want to point at the same repo, but one of which is behind a
> highly restrictive firewall, requiring use of a proxy to get through.
> 
> With native yumrepo types, it is very straightforward to set up the repo
once,
> and then add the proxy parameter in the puppet config for the server that
> needs it (or it a child class, if you want to do it for multiple servers). 
If
> you were using a simple file, you''d have to either maintain two
copies of the
> file (one with the proxy and one without), or create a template and
manually
> turn the proxy on or off in there.
> 
> Using native types also allows puppet to only manage the settings
it''s told
> about, rather than forcing itself on the entire file.  Take managing user
> accounts in a heterogeneous environment.  Even if all of the systems use
> exactly the same passwd/shadow file format, it''s likely that from
one to the
> next, there will be different system accounts that are required for normal
> operations.  By using the native user type instead of just pushing out a
> passwd and shadow file, you can safely ignore those additional OS specific
> accounts without worrying about accidentally blowing them away.
> 
> The general file and exec types are certainly necessary, as there will
always
> be plenty of corner cases that aren''t covered by native types, no
matter how
> easy they are to write.  But in the long run, the more you can get away
with
> just using native types instead of manually creating lots of templates, the
> easier and more effective puppet gets.
> 
I can sign all of your words. :) Maybe you explained it even better than me.

greets pete

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

Thank you for the feedback, guys.
Let me focus on some points of the discussion:

On 3 Mag, 18:45, Peter Meier <peter.me...@immerda.ch>
wrote:
> Hi
>
>
>
> > What are the pros and cons of this:
>
> >     yum::managed_yumrepo {extras:
> >         descr => ''CentOS-$releasever - Extras'',
> >         mirrorlist =>
''http://mirrorlist.centos.org/?release> >
$releasever&arch=$basearch&repo=extras'',
> >         enabled => 1,
> >         gpgcheck => 1,
> >         gpgkey =>
''file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5'',
> >         priority => 1,
> >     }
>
> > compared to something like this:
> >                            file {
> >                                    "/etc/yum.repos.d/CentOS-
> > Extra.repo":
> >                                            mode => 644, owner =>
root,
> > group => root,
> >                                            backup => local,
> >                                            ensure => present,
> >                                            source =>
"puppet://
> > $servername/repo/CentOS-Extra.repo",
> >                            }
> > (with the file CentOS-Extra.repo placed in $modulesdir/repo/files/ ),
>
> > or, more generally, why overruse puppet declarations and templates
> > instead of placing the right file on the right place?
>
> > Absolutely do not consider this as a polemic or a "my solution is
> > better than yours" post, I just would like to better understand
all
> > the positions and motivations behind a choice.
> > For my point of view, puppet should be a tool which eases a sysadmin
> > life.
> > Sysadmins know their stuff but don''t generally know puppet or
puppet''s
> > modules logic,  they are used to plain configuration files, placing
> > the usual config file in the module files dir (with a cp or
cut&paste)
> > for me is easier and less error prone than defining variables or fill
> > with correct values (more cut and pastes) a yumrepo definition (or
> > whatever).
> > This is now always true, of course, templates and custom or specific
> > types can be very useful and give better flexibility, but at times I
> > feel like there''s the tendency to make plain and easy things
over
> > complicated / structured.
>
> pros:
>
> - it uses native puppet types
> - enables to have repositories in an inheritance chain and let easily
> overwrite or disable them:
>
> class yumrepo_internal inherits yumrepo_standard {
>         Managed_yumrepo[foobar_only_needed_exernal]{
>                 enabled => false,
>         }
>
>         Managed_yumrepo[standard_repo]{
>                 baseurl =>
''$use_internal_yum_repo_mirror_to_save_bandwidth''
>         }
>
>         Managed_yumrepo[testing_repo_what_we_use_internal]{
>                 priority =>
''$higher_than_external_so_we_use_the_testrepo_internally''
>         }
>         etc.}
>
> - look at the the puppet-manifests and know what they do, you
don''t have
> to look at some configfiles
> - go away from deploying config-files to rather managing them, otherwise
> we could simply use some (advanced) scp scripts to ensure the
> deployement of plain textfiles and we wouldn''t need puppet.
> - go away from your typical sysadmin jobs and hacking scripts together
> and move forward to a system architecture designer
>
> - cons:
>
> none, or maybe a bit of more engineering work, which however enables you
> the pros from above.
>
> I didn''t really see any cons from your site except that you might
see
> this as a bit of overengeenering. However you see that you then have
> none of the pros I mentioned above.
>
> My personal interest in puppet is to go away from traditional hacking of
> some textfiles together to a more engineering like approach and to
> design the environment which I want.
>
> my point of view. ;)
I agree on some and give a different weight to others:
>- it uses native puppet types
Ok, nice, but also somehow a limit: to use new native puppet types
(for example the repo or nagios ones) you must have a new version of
Puppet, and this could not aways be possible or comfortable on
existing production architectures.
If you use basic, well tested types (as files) you have a code that is
probably more puppet version independent and well tested.
>- enables to have repositories in an inheritance chain and let easily
overwrite or disable them:

Yes, that''s fine.
Actually you can achieve the same  using different repo files (or
adding, removing them) properly sourced in relevant defines or
classes, even if I admit it''s surely less elegant.
> - look at the the puppet-manifests and know what they do, you
don''t have
> to look at some configfiles
That''s true, even if all the info I need is the same module directory.
Maybe we could discuss if it''s more readable/manageable a simple
manifest + sourced files or a single more complex manifest, but this
mostly depends on simgles'' points of view and operation methods.

In an IT environment where different sysadmins co-work, we can also
discuss if it''s more error prone if in order to change puppet
configuration you have to edit manifests or configuration files, but
that always depends.
> - go away from deploying config-files to rather managing them, otherwise
> we could simply use some (advanced) scp scripts to ensure the
> deployement of plain textfiles and we wouldn''t need puppet.
> - go away from your typical sysadmin jobs and hacking scripts together
> and move forward to a system architecture designer
Uhm, on this point probably I have different opinions of how to use
puppet.
It should help me design and manage a *nix infrastructure, based on
more or less well known software that I already know how to configure.
Why should I need to learn how puppet configures it?
I find this an unnecessary overhead.
Do we need another tool to configure application specific stuff?
I find also long term cons on this: how would you manage configuration
items/options of future versions of software for which there are not
updated puppet native types?
In the case of repo types, how would you manage eventually new
configuration options of repo files?
Have to wait for the patch/version of puppet that would handle them?
I still think that placing that usual / well known repo file in the
files dir, and managing alternative with proper classes and
alternative repo files with different urls is more comfortable (even
if I understand the drawbacks of partial data replication).
You know exactly what you deploy on your servers, otherwise you leave
puppet build configurations in a way you can''t fully control.
> - cons:
> none, or maybe a bit of more engineering work, which however enables you
> the pros from above.
So at least we agree in the over engineering... even if we give
different weight to it.

Also the post of Frank gives good points:
>Using native types also allows puppet to only manage the settings
it''s told
>about, rather than forcing itself on the entire file.  Take managing user
>accounts in a heterogeneous environment.  Even if all of the systems use
>exactly the same passwd/shadow file format, it''s likely that from
one to the
>next, there will be different system accounts that are required for normal
>operations.  By using the native user type instead of just pushing out a
>passwd and shadow file, you can safely ignore those additional OS specific
>accounts without worrying about accidentally blowing them away.
I do agree on this.
Probably after all it could be a matter of context and situations.
User native types are useful, I agree,
Nagios types are ok because for monitoring purposes is nice to move
configuration items inside puppet logic rather than in separated files
(even if there can be issues on long term  compatibility, as pointed
above),
repo types according to me are not so useful.


In any case, I''m grateful for the good hints and points of view,
I''m
considering them even if I still haven''t changed fully my idea (for
example on how to manage yum repos :-)
the point for me is not only how to obtain what you need (we see here
that it mostly depend on personal preferences and approaches ) bout
how to make different approaches work together.


There are discussions on other threads on puppet modules standards,
maybe we should focus on a clean way to let cohexist modules with
different approaches for the same applications.
Maybe a sort of common interface or a wrapper, that would let us
choose to decide (according to infrastructures and personal
preference) alternatives between different proposed modules for the
same application.
At this point the usage for example of a repo class based on repo
native types or sourced files or templates becomes a personal "user"
choice among the community alternatives.

My 1.2 cents
al

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

Well Peter,
what can I say.
Having to work back on my yum class and after a comparison on what
you''ve published on your git repo, I found myself agreeding that using
the native type for using yumrepos is actually the best solution.
So I trashed my old repo class, based on files, and started to use,
with minimal modifications, your yum module.
Do you mind if I use it in my modules infrastructure? (yes, ok, it''s
gpl so the answer is obvious, but  I still prefer to inform the
original author).

There''s one thing that I''m noticing in my way to approach a
modular,
reausable, puppet infrastrucure:
- more you  get into puppet more you tend to engineer it with more
elegant solutions and more you use custom code instead of the usual
plain files or templates.
- I started with a sysadmin point of view (I know of files and
configurations not of puppet logic and programming): place plain files
or templates where necessary, without too much overengineering. Now I
find the advantages of a more resource oriented approach (see the
yumrepo case).
- I still haven''t forgotten one thing, though, that the way on how to
organize modules in Puppet should be left to the user, according to
his own infrastructure complexity, tastes, and knowledge of puppet
language and module''s logic.
I''m trying to leverage on this, providing simple essential basic
modules and leaving to users the choice of alternatives.
In order to make a reusable work, not only for me, but for whoever may
be interested, I would like to shape these modules in a "common,
community shared way".
But, hey, is there one? Why don''t we try to define some basic
standards in module''s structure?

Al
--~--~---------~--~----~------------~-------~--~----~
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
> Having to work back on my yum class and after a comparison on what
> you''ve published on your git repo, I found myself agreeding that
using
> the native type for using yumrepos is actually the best solution.
> So I trashed my old repo class, based on files, and started to use,
> with minimal modifications, your yum module.
cool :)
> Do you mind if I use it in my modules infrastructure? (yes, ok,
it''s
> gpl so the answer is obvious, but  I still prefer to inform the
> original author).
thanks. If you think you have some improvements I''m happy to accept
patches. I couldn''t find your changes yet on your trac site. As well:
have you been thinking about sharing the modules in different
submodules? This would make direct reusage and tracking a lot easier.
> There''s one thing that I''m noticing in my way to approach
a modular,
> reausable, puppet infrastrucure:
> - more you  get into puppet more you tend to engineer it with more
> elegant solutions and more you use custom code instead of the usual
> plain files or templates.
agree.
> - I started with a sysadmin point of view (I know of files and
> configurations not of puppet logic and programming): place plain files
> or templates where necessary, without too much overengineering. Now I
> find the advantages of a more resource oriented approach (see the
> yumrepo case).
agree.
> - I still haven''t forgotten one thing, though, that the way on how
to
> organize modules in Puppet should be left to the user, according to
> his own infrastructure complexity, tastes, and knowledge of puppet
> language and module''s logic.
> I''m trying to leverage on this, providing simple essential basic
> modules and leaving to users the choice of alternatives.
> In order to make a reusable work, not only for me, but for whoever may
> be interested, I would like to shape these modules in a "common,
> community shared way".
> But, hey, is there one? Why don''t we try to define some basic
> standards in module''s structure?
and this is where imho the complexity may lay. I mean: You can have a
very general and abstract abstraction in your modules, which will fit
for most cases, but they will often not fit for a specific environment.
So what you then want to do is just little customization for example in
subclasses. However sometimes this simply won''t work and you will have
to make bigger changes. Which sometimes means to rewrite a module. Which
is  kind of bad, however it is often the same with libraries in FOSS.
(my experience.)
I mean: I see the advantages of your way to structure the modules, keep
them simply but still keep them highly configurable. However I think
there are as well other approaches which will have the same advantages,
but are structured in a completely different way. And therefore I''m
currently unsure if it is really a good idea to have some basic
standards in module''s structure.
I mean, my way I learned in the past months is somehow different than
yours, however I claim to have the same advantages as yours. ;) So which
one might be better for a standard? I really don''t know it and there
are
plenty other of different ways outside.
So I don''t know if it is really a good idea to try to nail down basic
standards. On the other side: It would be good to have a common
resource, as well to have a central place for modules.

greets pete

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