Re: [Puppet Users] Re: Parameterized classes vs defined-types
- Original Message - > On Aug 23, 1:00 pm, Digant C Kasundra wrote: > > Out of curiosity, how are people using parameterized classes in a > > way that is distinct from defined-types? > > I am _using_ defined types, that's how. > > Although I disfavor parameterized classes and do not use them, the > pattern of my usage of defined types could not be implemented via > parameterized classes. In particular, I typically do not define a > type unless I plan to instantiate it multiple times for the same > node. You cannot do that with parameterized classes. > > If you have an OO background then the words "class" and "type" may > have connotations and implied similarity for you that just don't apply > in Puppet. Puppet classes are not "types" in the type theory sense. > Defined types are closer to that, but it may help to use a fuller name > when you think about them: defined *resource* types. Classes, > parameterized or not, are not resource types; rather, they are > resource _collections_. I agree with you. I think that's why I'm curious. We also overrides on defined types, which is why we prefer them as well. I think while it may be possible to do what we are currently doing with parameterized classes, it would at least involve a lot of restructuring how we think of things in our manifests. -- Digant C Kasundra Infrastructure Systems Software Developer, ITS:IDG, Stanford University -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] 2.7.1 slowness?
- Original Message - > On Tue, 2011-08-23 at 11:00 -0700, Digant C Kasundra wrote: > > Is anyone else noticing slowness with 2.7.1? When I run puppet on my > > 2.6.8 box, it takes 11 seconds. On my second box with exactly the > > same catalog, it takes 35 seconds. > > Is the problem while compiling catalog (ie the master) or when > applying > it (ie puppet agent)? > If the later, can you report what --summarize gives you on both host? > I think it might not even be in the run but might be in some of the post run activities (like reporting maybe?) Here is what I have: A 2.6 puppet client running against a 2.6 puppetmaster: info: Retrieving plugin info: Caching catalog for jimhenson1.stanford.edu info: Applying configuration version '1314209976' notice: Finished catalog run in 9.75 seconds Changes: Events: Resources: Total: 1188 Time: Filebucket: 0.00 Resources: 0.00 K5login: 0.00 Schedule: 0.00 User: 0.02 Service: 0.32 Package: 1.24 Exec: 1.99 Total: 12.92 Last run: 1314209992 File: 3.21 Config retrieval: 6.14 A 2.7 puppet client running against a 2.7 puppetmaster (identical catalog, essentially): info: Retrieving plugin info: Connecting to sqlite3 database: /var/lib/puppet/state/clientconfigs.sqlite3 info: Caching catalog for jimhenson4.stanford.edu info: Applying configuration version '1314209977' notice: Finished catalog run in 37.02 seconds Changes: Events: Resources: Total: 1193 Skipped: 6 Time: Filebucket: 0.00 Resources: 0.00 K5login: 0.00 User: 0.02 Service: 0.40 Package: 0.91 Exec: 1.84 Total: 13.40 Last run: 1314210022 File: 2.85 Config retrieval: 7.38 When I run a 2.6 client against the a 2.6 master and 2.7 master, I don't seem to notice any difference at all, however. Weird. -- Digant C Kasundra Infrastructure Systems Software Developer, ITS:IDG, Stanford University -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] 2.7.1 slowness?
Is anyone else noticing slowness with 2.7.1? When I run puppet on my 2.6.8 box, it takes 11 seconds. On my second box with exactly the same catalog, it takes 35 seconds. -- Digant C Kasundra Infrastructure Systems Software Developer, ITS:IDG, Stanford University -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Parameterized classes vs defined-types
Out of curiosity, how are people using parameterized classes in a way that is distinct from defined-types? -- Digant C Kasundra Infrastructure Systems Software Developer, ITS:IDG, Stanford University -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] variable scoping over and over
Wow, this really makes Puppet look like a programming language, which it isn't.
Have you considered creating classes for each of the roles and then classes
that include those roles and then assigning one of those classes to each node?
We have hundreds of combinations here but that's how we do it and it works fine.
So in your example, your node lamp could just include postgres instead of a
role_postgres and then rely on some other class to do the right thing. It
seems like an inversion of the hierarchy, which is fun in programming but not
in modeling.
But yes, if you insist on doing it this way, it will be painful. :)
- "Antony Mayi" wrote:
> this topic is currently being massively discussed so I just would like
> to share my pain also.
>
>
> my intention was to have an array of node's roles and each included
> role class would just record into the array its role identificator.
> then I could write simple function has_role and then write various
> condition with role checks. imho this would be awesome however
> impossible to implement with variable scoping.
>
>
> individual roles would be defined as classes as follows (this is just
> an example demonstrating the varscope issue so don't try to find a
> workaround for this simple case as I am more interested how to
> implement this whole idea):
>
>
> class root_role {
> $node_roles = []
> }
>
>
> class role_mysql extends root_role {
>
> $node_roles += [ "role_mysql" ]
> include mysql
> }
>
>
>
>
> class role_postgres extends root_role {
> $node_roles += [ "role_postgres" ]
> include mysql
> }
>
>
> class role_basehost {
> if has_role("role_postgres") {
>
> } else {
>
> }
> }
>
>
> node lamp {
> include role_postgres
> include role_basehost
> }
>
>
> obviously this doesn't work. maybe you have now idea to use directly
> the $root_role::node_roles and reference it in all other roles however
> that wouldn't work neither cause the qualified variables from other
> classes are readonly.
>
>
> this is pain, pain and again pain!
> cry with me,
> Antony.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
Digant C Kasundra
Infrastructure Systems Software Developer, ITS:IDG, Stanford University
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Timestamps need to be in sync on all puppetmasters?
This is similar to what I'm talking about. It looks like this resource is
specifically using modified time as the "checksum." Is this something you've
configured or is this a default of those directories as something internal to
puppet.
- "Tony G." wrote:
> I've see this very often but not sure if this is the issue you are
> describing:
>
> Dec 4 03:36:19 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib]/checksum) checksum changed '{mtime}Fri Oct
> 30 11:05:32 -0700 2009' to '{mtime}Fri Oct 30 18:05:50 + 2009'
> Dec 4 03:36:20 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet]/checksum) checksum changed
> '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> + 2009'
> Dec 4 03:36:21 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/type]/checksum) checksum changed
> '{mtime}Fri Oct 30 11:05:49 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> + 2009'
> Dec 4 03:36:24 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/parser]/checksum) checksum changed
> '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30 18:05:50
> + 2009'
> Dec 4 03:36:29 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/parser/functions]/checksum) checksum
> changed '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Fri Oct 30
> 18:05:50 + 2009'
> Dec 4 03:36:29 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider]/checksum) checksum changed
> '{mtime}Fri Oct 30 11:05:33 -0700 2009' to '{mtime}Fri Oct 30 18:05:48
> + 2009'
> Dec 4 03:36:36 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider/package]/checksum) checksum
> changed '{mtime}Fri Oct 30 11:05:35 -0700 2009' to '{mtime}Fri Oct 30
> 18:05:48 + 2009'
> Dec 4 03:37:00 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider/sysctl]/checksum) checksum
> changed '{mtime}Fri Oct 30 11:05:48 -0700 2009' to '{mtime}Fri Oct 30
> 18:05:49 + 2009'
> Dec 4 03:37:01 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider/volumegroup]/checksum)
> checksum changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to
> '{mtime}Fri Oct 30 18:05:35 + 2009'
> Dec 4 03:37:06 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider/logicalvolume]/checksum)
> checksum changed '{mtime}Fri Oct 30 11:05:33 -0700 2009' to
> '{mtime}Fri Oct 30 18:05:34 + 2009'
> Dec 4 03:37:07 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/puppet/provider/physicalvolume]/checksum)
> checksum changed '{mtime}Fri Oct 30 11:05:34 -0700 2009' to
> '{mtime}Fri Oct 30 18:05:34 + 2009'
> Dec 4 03:37:15 puppetclient puppetd[16163]:
> (/File[/var/lib/puppet/lib/facter]/checksum) checksum changed
> '{mtime}Fri Oct 30 11:05:50 -0700 2009' to '{mtime}Tue Nov 03 08:00:05
> + 2009'
> Dec 4 03:37:33 puppetclient puppetd[16163]: Starting catalog run
> Dec 4 03:39:46 puppetclient puppetd[16163]: Finished catalog run in
> 133.44 seconds
>
> I've not been able to look on what is causing it, I belive it's coming
> after we change the environment the puppetclient is pointing to,
> although we use the same puppetmaster to use different
> environments(dev, prod).
>
> Thoughts?
>
> Thanks
>
>
> On Thu, Dec 3, 2009 at 2:31 PM, Digant C Kasundra <
> dig...@stanford.edu > wrote:
>
>
> Hey guys,
>
> We're using multiple puppetmasters and I could have sworn I had
> uncovered an issue once where if a file had a different timestamp on
> two puppetmasters, clients would keep replacing the file depending on
> which puppetmaster they talked to because the clients thought the
> files were changing. But I've been unable to reproduce this problem.
> Is this only an issue in certain situations? We're not using the
> checksum parameter to tell file resources to use timestamps and the
> type references seems to indicate that the default is md5 but I could
> have sworn I uncovered the aforementioned issue before but cannot for
> the life of me replicate it now. Anyone else know what I'm talking
> about?
>
>
> --
> Digant C Kasundra < dig...@stanford.edu >
> Technical Lead, ITS Unix Systems and Applications, Stanford University
>
> --
>
> 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 .
>
[Puppet Users] Timestamps need to be in sync on all puppetmasters?
Hey guys, We're using multiple puppetmasters and I could have sworn I had uncovered an issue once where if a file had a different timestamp on two puppetmasters, clients would keep replacing the file depending on which puppetmaster they talked to because the clients thought the files were changing. But I've been unable to reproduce this problem. Is this only an issue in certain situations? We're not using the checksum parameter to tell file resources to use timestamps and the type references seems to indicate that the default is md5 but I could have sworn I uncovered the aforementioned issue before but cannot for the life of me replicate it now. Anyone else know what I'm talking about? -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Looking for ideas on how to get details of managed resources on the puppet client.
- "Trevor Vaughan" wrote: > All, > > I'm looking for a way to obtain information about the managed > services > on a given client system. > > Basically, some way to know what services have been enabled by Puppet > from the client. > > I'm hoping to implement something like 'purge' for services such that > any service that is not defined is disabled and turned off. > > Any ideas on how to do this would be welcome. If you want to know what services Puppet has managed on a client, you can look at the yaml file, or you can use store configs and poke at the DB. The problem with purging services is do you really want to define everything you know to expect on a server in Puppet? --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Expert Directory
- "lyric" wrote: > Hello Puppet Friends, > > wouldn't it be nice to have a Puppet expert directory with profiles > and services they offer. > > I want to use Puppet but I am not an administration expert, so it > would be nice to be able to contact local Puppet experts (in my case > experts in Germany). > > Also reductivelabs.com, the founder of Puppet, could win from such a > directory by suppling certification and certification-training. > > Thanks for your great tool, > Cyril Consequently, I'll help anyone anywhere in the world for a year for $1million US. :) --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
- "R.I.Pienaar" wrote: > 'lo, > > - "Julian Simpson" wrote: > > > No objections here. I seem to recall that there had a been a > > discussion at PuppetCamp about perhaps moving to a pattens > collection > > instead of set of best practices - not sure if anyone has bandwidth > > to to work on this but it might help to keep it in mind. > > Pattern collections are much better, I'd rather have articles > exploring features that people can learn each feature and then apply > to their environment than a best practice since those are almost > always full of assumptions about local conditions, patterns are > flexible and can be molded to your needs.. That's very true. Different local needs and different levels of complexity and business requirements will definitely drive how things should be done. For instance, if you just want to use puppet to make sure a certain package is installed on all servers, you may not need the complexity of larger instances. We have a practice here (partially represented by the out of date best practices) that works well for a large institution with large amount of classes and large difference and ties to external entities like a CMDB. So well defined patterns can be good, but how to write them and more importantly, how to present them in a common area can be difficult, especially where there are multiple solutions to a given problem. Ideas? -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
- "James Turnbull" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > R.I.Pienaar wrote: > > > Pattern collections are much better, I'd rather have articles > > exploring features that people can learn each feature and then > > apply to their environment than a best practice since those are > > almost always full of assumptions about local conditions, > > patterns are flexible and can be molded to your needs.. > > > > What Arri said. I'd like to see logical, interlinked set of > patterns that can be built into a logical whole rather than a > single, potentially unwieldy document. > I suppose that's true. Though I have to say some of the patterns that developed in the PuppetCommon modules seemed bad, to me. I guess the issue really becomes when patterns are developed by people first exploring Puppet as opposed to people that have done it a while. But certainly, I think institutions tend to develop their own patterns. Stanford was glad to share what our collective wisdom was with the Best Practices and Style Guide but I think it might be time for us to pull our work back in-house so can we preserve these documents since they are still very much part of what our team uses. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
> If anyone feels up to grabbing this document and running with it, > please feel free. As the original author, I suppose I should take over. Can you send me what you had? -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
- "Peter Meier" wrote: > Hi > > so I took again a look a this rather old thread, as I tried to > implement > things as I thought I have understood them. > > >>> good idea! Currently I have all site specific stuff in one big > module, > >>> but like that I might be able to organize it again in modules per > each > >>> site specific module adaptions. Question: Is autoloading looking > in > >>> both module directories? so if it's not found in the module in > one > >>> module directory it's still looking in the other one? I assume so, > but > >>> as I haven't used it yet I better ask... ;) > >> > >> modulepath option must be set in your puppet.conf file. > > > > yeah, that for sure. But so I assume it looks for ssh::client in > every > > ssh module it can find in the different modulepaths. > > After this discussion I thought that modules can be scattered amongst > the various module paths. But this doesn't seem to be the case. At > least > my experience shows that puppet simply respects the classes of a > module > it founds in the first location, all the classes in a second location > get ignored. > > So the best practices would be to have 2 module paths, one with the > public modules and one module path with the site-specific module - > extensions, prefixed with site? so something like: > > modules/public/apache <- public apache module > modules/site/site-apache <- site specific implementations of apache > > To throw up the question: > > Wouldn't it be nicer if puppet would collect a module's classes from > all > module pathes? It would at least make my site specific module changes > look a bit nicer and I still wouldn't have to mix these. However I > see > all the problems coming up with this solution. I'm just curious what > other people think. > I think that would be terrible. Having two different paths for the same namespace is confusing and will easily lead to problems. However, the example you give is correct: you can't have the same module name in two modulepaths and usually want to prefix the classnames to avoid name collisions. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Dealing with timestamps
- "Nigel Kersten" wrote: > On Thu, Aug 20, 2009 at 10:39 AM, Digant C > Kasundra wrote: > > > > Hello everyone, > > > > We're pondering moving to git for our version control system for > Puppet manifests. However, since we have 4 puppetmasters, we're > wondering how to deal with timestamps. Since git doesn't preserve the > timestamps, and instead, sets the current timestamp to every file it > modifies, this will create a problem for us since if a file on each of > puppetmasters has a different timestamp, puppet clients will > continually update that file each time they check in with a different > puppetmaster. How are others dealing with this issue? I hope it isn't > using checksums because we manage a lot of files and that would be a > huge performance impact. > > git checkout to a directory. > > Then use rsync with the -c option to ignore based on checksum, not > mod-time to copy the files into the actual locations your > puppetmasters serve from. > > Or is that what you meant you didn't want to do with "I hope it isn't > using checksums" ? I meant I didn't want to tell puppet to use checksums. It is probably fine with rsync, though it does seem like a duel sync method, but I guess it will have to work. Thanks Nigel! -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Dealing with timestamps
Hello everyone, We're pondering moving to git for our version control system for Puppet manifests. However, since we have 4 puppetmasters, we're wondering how to deal with timestamps. Since git doesn't preserve the timestamps, and instead, sets the current timestamp to every file it modifies, this will create a problem for us since if a file on each of puppetmasters has a different timestamp, puppet clients will continually update that file each time they check in with a different puppetmaster. How are others dealing with this issue? I hope it isn't using checksums because we manage a lot of files and that would be a huge performance impact. -- DK --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
> I sketched a schema describing the use of multiple environments and > git > submodules for Puppet development. > > It's available on the wiki both in both OpenOffice Draw format and > PDF. > > http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg > > http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf > > I'll be glad if it could be useful for the best practices. It > currently > relies heavily on git features, but it's probably doable to sketch > something similar with other versionning tools. I'm not a git expert and can't tell from the diagram if the puppetmaster in this configuration can serve out multiple environments at once? And if so, how does it do that? Does it not rely on different paths per environment? --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Howto understand the error message " Could not find class parent XXXXXXXX"? howto link it?
- "Eric2" wrote:
> Hi,
>
> err: Could not retrieve catalog: Could not find class parent
> apache::package at /home/puppet/modules/apache/manifests/debian.pp:11
> on node ns0.mysite.org
>
> vi /home/puppet/modules/apache/manifests/debian.pp
> ### debian
> class apache::debian inherits apache::package {
> $config_dir = '/etc/apache2/'
>
> file {"$vhosts_dir":
> ensure => '/etc/apache2/sites-enabled/',
> }
> File[default_apache_index] {
> path => '/var/www/index.html',
> }
> } line 11
>
> In the same directory i have found in the file package.pp
> # deploy apache as package
> class apache::package inherits apache::base {
> package { 'apache':
> name => 'apache',
> ensure => present,
> }
> File['vhosts_dir']{
> require => Package[apache],
> }
> File['config_dir']{
> require => Package[apache],
> }
> Service['apache']{
> require => Package[apache],
> }
> File['default_apache_index']{
> require => Package[apache],
> }
> File['modules_dir']{
> require => Package[apache],
> }
> File['web_dir']{
> require => Package[apache],
> }
> File['htpasswd_dir']{
> require => Package[apache],
> }
> }
>
> Something is missing! It should be linked ? Thanks Eric
You don't seem to be using modules. Are you doing an explicit import somewhere
of all files in the manifests directory?
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
> > * Because of complexity of how and when classes are interpreted, > > aren't variables often a tricky thing to play with if you are > > planning to change their values in later scopes? > > With the current tooling, I think the only real chance is to put all > "choosing values for variables which will influence my manifests" > functionality in an external nodes classifier which does proper, > flexible and organisation-specific lookups. > > HAving this, manifests and modules do have a greatly reduced need to > "change values in later scopes". > I agree. > > * Lastly, perhaps this is still my OCD, but I'm still a fan of the > > style guide. Without it, I dont' think our manifests would be as > > clean and legible as they currently are. > > +1 :) -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
> * Environments and the workflow surrounding them > > There is already UsingMultipleEnvironments, which has all the > technical > stuff. Perhaps a few sentences about how to use the production, > testing, > and development environment. I'd love to be able to update that down the line (probably later this year when we move to 0.25 and start using the environment support). We had some very specific ideas in mind for our use of environments with Git which i think may be particularly useful for those institutions such as ours where we have formal change management processes and vetting required from multiple stakeholders in different departments, making fullscale migration difficult. I'll see if i can draft something up. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Best Practices Rewrite - First Draft
- "Paul Lathrop" wrote: > Hi Puppeteers, > > I spent some time tonight making a first pass at what I hope will > eventually be a good replacement for the current "Puppet Best > Practices" page on the wiki. I know this needs *tons of work, but I > hit a good pausing point and decided it was time to ask for feedback > and contributions. The idea here is to provide some overall > guidelines > to help newcomers to Puppet establish good habits as well as get the > most out of Puppet, and especially to highlight some common mistakes > and how to avoid them. > > Please take a look and flame away. I need feedback, both positive and > negative, as well as input as to what the Best Practices actually are > (Volcane, I'm looking at you!). I especially need to flesh out that > final section. I was hoping to redraft this myself when 0.25 came out, but looks like you've beat me to it. Sadly, time doesn't allow me to follow up as closely with the user list as I'd like, (my participation with Puppet as been limited lately to the asynchronous storeconfigs work we've contracted). Here are some comments to consider: * A lot of this does read more like an introduction to Puppet and Puppet concepts, so some of this might need to be broken away elsewhere. * While classes aren't object-oriented, I think treating them as if they are isn't necessarily a bad thing either. Ultimately, when you inherit you are only given yourself permission to override the declared resources, but I also find it to be a good idea to keep this kind of modeling to properly represent what is happening. Ergo, when one class is a derivative of another, I find it better to inherit instead of include, even if I am not overriding a declared resource, simply because modeling shouldn't be a function of what features you are using. * While one shouldn't overuse dependencies, I wouldn't put notify and subscribe in the same boat since they are functionally useful for things besides trying to make Puppet do something in a particular order. I think the intent was just to relate the two parameters to before and require but I would recommend removing it or relocating it so we don't give the impression that using notify or subscribe is a bad idea. * Because of complexity of how and when classes are interpreted, aren't variables often a tricky thing to play with if you are planning to change their values in later scopes? * Lastly, perhaps this is still my OCD, but I'm still a fan of the style guide. Without it, I dont' think our manifests would be as clean and legible as they currently are. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Change Management Practices.
- "Teyo Tyree" wrote: > In the course of training and consulting with Puppet, the question of > change management best practices has come up over and over again. On > the edges, we have small teams that can get away with simply version > controlling their code using an SCM as an incremental backups while > rolling out change in a fairly adhoc fashion and larger teams that > need branches, QA, and DEV environments, and perhaps even separate > repositories for each module. There is also the issues of roll back > and testing. We are curious how the community approaches these > problems in hopes of developing some best practices. So what do you > guys/gals do? We'll be developing extensive practices in this area when we move to 0.25 and start using the environment support (that's why we wanted it, actually: our change management practices are difficult without them). Generally speaking we plan to have all servers pointing to a "stable" environment where only bugfixes or emergency changes are introduced. We will develop in a testing/unstable branch and when we finish our testing, we will tag that as stable and move servers over to using this environment as the departments approve of the change. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Redundant Puppet Master Servers
> > How can the state files be shared between servers? > > DRBD. Considering a load-balanced environment, it seems this might not be optimal. Perhaps the puppetmaster need the ability to store the state information in a database. -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Redundant Puppet Master Servers
> If you want to do failover with puppet servers and you are using > environments, there's a major gotcha that I really should add to that > page... > > > If a puppet client connects to server A, downloads the compiled > manifest, and then starts requesting files via the puppet:/// > protocol, and in the middle of all these short lived requests the > server switches over to Server B, that server doesn't necessarily know > what environment the client should be using, as that is stored in a > file on the server. > > > The only feasible solution is to somehow share those state files > between servers. This may or may not be feasible in your environment > (no pun intended...) How can the state files be shared between servers? -- Digant C Kasundra Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Include class/* picks up backup files
- "dd-b" <[EMAIL PROTECTED]> wrote: > All the examples show just "include class/*", so I was using that > until I started getting errors. I'm curious which examples these are. Best practice is usually to let autoloading take care of loading class pp files. I was just curious if there was an example on the Wiki that we hadn't updated or might want to revisit. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
- "Kenton Brede" <[EMAIL PROTECTED]> wrote: > > With a small operation, it is okay. With something larger, it > doesn't scale well and it doesn't make good use of module grouping. > For instance, when setting up openldap, I want to talk about what I do > (packages I install, conf files I drop in, etc) all in one place so I > can see what I do with openldap as a whole more easily. If it were > broken out into several places based on OS type, it isn't quite as > easy to ensure that each OS type is similar. For instance, on a > debian box and a redhat box, I can look at classes.txt and see that > openssh class is applied, so I know that I'm managing openssh on > debian and redhat boxes, but with the other approach, I wouldn't be > able to see that without digging into the debian.pp and redhat.pp > files. > > > > Hmmm, unless I'm missing something, what you describe is what I'm > doing. If I'm wrong please let me know. > > Currently I have two types of modules: > > Modules based on type (file, cron, etc) that are not tied to a > particular service. For example, a custom script that goes to host > foo, or a group such as rhel5. And modules based on a service > (apache, iptables, etc), which contain any resources that are needed. > > The only time I have a rhel5.pp class, is if it's as sub-module. For > example cron::rhel5.pp, which contains cron jobs for rhel5 servers. > Or apache::rhel5.pp, which contains rhel5 specifics for that group. > I > don't have a single class rhel5.pp where I try to manage all > resources, if that's what you thought I did. > > That is indeed what I thought you were doing. Phew. Yes, what you are doing seems logical. We don't currently break things down into OS. Instead, our apache and apache::foo and whatnot all have internal logic to handle different operating systems with case statements. But what you're doing is something I've seen other people doing and it seems pretty good to. Doesn't quite fit my view of how I organize things in my head but that doesn't necessarily make it "wrong." > >> Could you give a couple examples of what you mean by "action type" > >> and > >> "functional role?" > > > An action type is like sort of like "what you do to a system." So, > things like "install this file" or "install this package." Functional > role is things like "manage openldap" or "ensure these users are > present" which would in turn include actions like installing packages > or files or setting up user preferences. > > > > Thanks for the clarification :) > Kent No problem! -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Common Modules: SSH Proposal
- "Jeroen van Meeuwen" <[EMAIL PROTECTED]> wrote: > Digant C Kasundra wrote: > > There is a lot to digest here but a quick correction on: > > > > # Red Hat / CentOS has puppet-0.24.4 and does not do the import > magic. It could do the imports, but it requires import statements per > file (not exactly making the module any more portable). > > > > I'm not sure what you mean by this as import magic is most certainly > in place (we use it all the time and we actually don't use the word > import anywhere). > > > > Well, it's in the commentary of the actual module... And not as > significant to the proposal as the actual module itself... > > Besides the wiki page can just describe the module as a one file > source, > I find the automagic module imports work, but the subclasses and > defined > types in modules (and/or it's subbclasses) are not automatically > imported. > > Jeroen van Meeuwen > -kanarip That's odd b/c that seems to work for me just fine. Perhaps it is b/c of namespacing? I.e. when I define a subclass of ssh called foo, I would actually declare it as ssh::foo. If I include ssh::foo, puppet looks for foo.pp in the ssh/manifests and if it doesn't find that, it then looks in init.pp in ssh/manifests. Perhaps I'm not understanding what you aren't able to get work. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Common Modules: SSH Proposal
This is an interesting approach and certainly valid and should work. I'm not sure I would use the virtual resources since one could just as easily define those things in the classes they are used in. Virtual resources are better when you wnat to declare something in one place but it could be realized in any number of places (making it impossible to be declared in all of those places b/c if two such classes were included, you'd have an error) I think having the OS specific subclasses override the package name instead of a large case statement in the initial package declaration is spiffy. I can actually seeing both ways being useful. Sometimes, I like to see all the various ways a package (or service) might look in one place, so I sometimes like to see the case statement approach. Other times, I like to see specific changes that are related to an OS or similar logical grouping to be made in an appropriate subclass with the use of overrides. To answer about use-cases, we have in our ssh module some subclasses that are relevent to a particular configuration of ssh server. For instance, ssh::global allows ssh connections from off campus while our regular ssh doesn't. I prefer these as subclasses b/c I like to look at my list of classes to glean what kinds of things my server is setup to do (and when I build an external node tool, rather than messing with variables and blah blah blah, I'll just be adding or dropping classes). - "Jeroen van Meeuwen" <[EMAIL PROTECTED]> wrote: > Hi there, > > I'd like to collect some feedback on a conceptual simple Puppet Common > > Module I want to propose; > > http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH > > I'm thinking about things like; > > - the way virtual resources are used, > - the way operating system specific sub-classes are used, > - use-cases I haven't met (although secondary), > - simple errors I've made (I whipped this up from the top of my head), > > although the best thing is maybe to jump on the Wiki and correct my > error, > - further enhancements in making this a really viable PCM. > > I guess what is not needed (yet) includes (I'm sorry if this sound > harsh); > > - discussions about the indentation I used > > I can live with any form of indentation, and I guess so can you. I > *just > so happen* to use 4 spaces to a tab. > > - the way I aggregate types into resources > > It to me is a habit / matter of convenience, while I'd like to focus > the > discussion on technical arguments instead. > > - namespacing of modules or classes > > again I can live with *any* namespacing, and it's not about setting > the > defacto standard for all Puppet Common Modules, it's about making a > *start* in "code". > > - module or class extensions that everyone uses > > because these often-used extensions should go *in* the module > (upstream, > upstream, upstream is my motto), and such can only be done when there > is > an upstream module to begin with. > > Thanks in advance for review/comments, > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > > -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Pushing data into a CMDB (especially Remedy)
- "Ohad Levy" <[EMAIL PROTECTED]> wrote: > Hi, > > I'm interested, I've already done some basic work on the puppet side. > In our setup we decided not to use storeconfig (due to technical > limitations of having too many puppet masters in different locations), > therefor, we have re implemented many of facts importing and > collecting. > > I would assume it should not be a big deal to push the data forward to > remedy CMDB. > > Cheers, > Ohad Can you talk a little more about what this is. How are you importing and collecting these facts. I'd love to try out this solution here and see how it performs. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Pushing data into a CMDB (especially Remedy)
- "Jeff Leggett" <[EMAIL PROTECTED]> wrote: > Yes, I would be interested in this as well. We posited that Puppet > and facter could make a nice foundation for a CMDB, but you need more > data. It wouldn't be as feature complete as, say BMC's Atrium > product, but in most cases you don't need that... But what you do > need > is the information kept up to date. We use Remedy today to log rack, > row, shelf in our DC's for when resources are installed... BUt we > have > found that it is RAPIDLY out of date as things move, new racks are > added, etc. > > While I don't agree with all of it as being necessary check out the > ITIL v3 CMDB definition for a pretty complete definition. I agree and what I'm looking at is a practical meeting of what I need to know about my systems and indeed what I do know about my systems and what the upper pay grades want (i.e. an ITIL CMDB). I'll likely end up drafting a proposal of the solution and what it might look like and work on the interconnects in an open source, collaborative fashion. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Pushing data into a CMDB (especially Remedy)
> > I was curious if anyone else works at an institution that uses > Remedy, particularly as a CMDB infrastructure. We're planning to do > that and so I've been tasked with writing integration tools so that > Puppet can feed data of interest up into that system. If anyone is > interested in helping (whether you use Remedy or not), I'd be > interested to build a team around this effort. > > > > That's interesting. I had only ever seen Remedy used as a ticket > tracking system. > > Or am I thinking about a different Remedy? Is this to meet an ITIL > standard? If it is the same Remedy, what additional modules would be > used for this. I had been looking at the CMDB part as something that > would need to wrap around puppet and say an asset tracking system. > I thought I replied to this but I can't seem to find the reply in my inbox so I'll reply again just in case. Yes, this is Remedy the ticket tracking system, but it has modules/components for CMDB so that you can tie tickets to "the world view" or some such and do root cause analysis (supposedly) and run nifty reports on which servers had which kind of issues and trouble tickets, blah blah blah. Things I don't necessarily care about but I do know that I'm expected to feed data into it and I don't want to duplicate data I already have based on facter and puppet. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Puppet Common Modules: SSH Proposal
There is a lot to digest here but a quick correction on: # Red Hat / CentOS has puppet-0.24.4 and does not do the import magic. It could do the imports, but it requires import statements per file (not exactly making the module any more portable). I'm not sure what you mean by this as import magic is most certainly in place (we use it all the time and we actually don't use the word import anywhere). - "Jeroen van Meeuwen" <[EMAIL PROTECTED]> wrote: > Hi there, > > I'd like to collect some feedback on a conceptual simple Puppet Common > > Module I want to propose; > > http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH > > I'm thinking about things like; > > - the way virtual resources are used, > - the way operating system specific sub-classes are used, > - use-cases I haven't met (although secondary), > - simple errors I've made (I whipped this up from the top of my head), > > although the best thing is maybe to jump on the Wiki and correct my > error, > - further enhancements in making this a really viable PCM. > > I guess what is not needed (yet) includes (I'm sorry if this sound > harsh); > > - discussions about the indentation I used > > I can live with any form of indentation, and I guess so can you. I > *just > so happen* to use 4 spaces to a tab. > > - the way I aggregate types into resources > > It to me is a habit / matter of convenience, while I'd like to focus > the > discussion on technical arguments instead. > > - namespacing of modules or classes > > again I can live with *any* namespacing, and it's not about setting > the > defacto standard for all Puppet Common Modules, it's about making a > *start* in "code". > > - module or class extensions that everyone uses > > because these often-used extensions should go *in* the module > (upstream, > upstream, upstream is my motto), and such can only be done when there > is > an upstream module to begin with. > > Thanks in advance for review/comments, > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > > -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
- "Kenton Brede" <[EMAIL PROTECTED]> wrote: > My question is, what's wrong with this setup? I ask this realizing > the smallness of our > operation makes me a little myopic. With a small operation, it is okay. With something larger, it doesn't scale well and it doesn't make good use of module grouping. For instance, when setting up openldap, I want to talk about what I do (packages I install, conf files I drop in, etc) all in one place so I can see what I do with openldap as a whole more easily. If it were broken out into several places based on OS type, it isn't quite as easy to ensure that each OS type is similar. For instance, on a debian box and a redhat box, I can look at classes.txt and see that openssh class is applied, so I know that I'm managing openssh on debian and redhat boxes, but with the other approach, I wouldn't be able to see that without digging into the debian.pp and redhat.pp files. And to the scaling point, we manage 2755 files so it would be difficult to manage manifests with all of that in one place. > > > The cfengine community was often hampered by a tendency to organize > by > > action type rather than functional role, so I consider it a kind of > > code smell in Puppet. > > Could you give a couple examples of what you mean by "action type" > and > "functional role?" > Thanks, > Kent An action type is like sort of like "what you do to a system." So, things like "install this file" or "install this package." Functional role is things like "manage openldap" or "ensure these users are present" which would in turn include actions like installing packages or files or setting up user preferences. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
- "Luke Kanies" <[EMAIL PROTECTED]> wrote: > Are your classes really getting that long? > > And does it really make sense to split them based on resource type, > rather than some other organizational criteria? > > The cfengine community was often hampered by a tendency to organize by > > action type rather than functional role, so I consider it a kind of > code smell in Puppet. > To manage Zimbra, we have 790 lines of code in our manifests. That being said, I wholeheartedly agree with you. I'm a staunch advocate of making sure people are doing things "the Puppet way" instead of forcing Puppet to bend to their own will. I'll meet with my team and have them reevaluate their practice and see if there are better functional breaks that can make. The majority of the breaks in Zimbra module are definitely along the times of functional role, like LDAP, mailers, etc. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
- "Al @ Lab42" <[EMAIL PROTECTED]> wrote:
> Hi Digant,
> what's the best place to comment/discuss what is written in:
> http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards ?
>
> I'd like to take part in the discussion about the module standards
> but
> I don't think the wiki is the right places to submit ideas/remarks.
> So for the moment I write here.
I think this is the right place to discuss that.
>
> For example I find point 5 in the Modules Standards section, a bit
> over engineered and not well manageable in the log term:
> I don't find the necessity to introduce a new variable for every
> package and service name (and pathname for almost each file served,
> so
> in some cases you should define a lot of variables for a module).
> I would handle the operating systems differences where is necessary
> with a relevant switch, like here:
>
> class sendmail {
>
> package {
> sendmail:
> name => $operatingsystem ? {
> default => "sendmail",
> },
> ensure => present;
>
> sendmail-cf:
> name => $operatingsystem ? {
> default => "sendmail-cf",
> },
> ensure => present,
> }
>
> service { sendmail:
> name => $operatingsystem ? {
> default => "sendmail",
> },
> ensure => running,
> enable => true,
> hasrestart => true,
> hasstatus => true,
> require => Package[sendmail],
> }
>
> file {
> "sendmail.cf":
> mode => 644, owner => root, group => root,
> require => Package[sendmail],
> ensure => present,
> path => $operatingsystem ?{
> default => "/etc/mail/sendmail.cf",
> },
> }
>
> }
I think the original proposal was due to legibility.
>
> In any case, this is just an example (and, in this case, a solution
> or
> another I guess it's mostly a matter of personal taste).
> Another point quite critical, according to me, is the standardization
> of modules that need to manage objects provided by other modules.
> An example could be a module for a software like mailcanner or amavis
> or whatever: they should handle configuration files and other objects
> of different other programs (for example an MTA like postfix, mail
> filters like spamassassin and clamav and so on).
> How can this be handled in a modular standard way (the mantainer of
> mailscanner module is not necessarily the postfix mantainer)?
> I've thought about different scenarios but they all require some
> tweaks that can be more or less acceptable (for example a conflict
> with other modules).
This is where overrides would come in. The amavis module would have classes
that inherit and override the MTA classes. But how to do so in a manner such
that the MTA in use can be anything and that the amavis module doesn't need to
know about the MTA specifics is a challenge and one that isn't quite clear how
best to handle. Right now, in our case, we just craft everything specific to
the MTA that we use (postfix) so we would not be able to swap out to sendmail
by simply changing the package name in one manifest: we would need to make
additional changes b/c config files are different, etc.
--
Digant C Kasundra <[EMAIL PROTECTED]>
Technical Lead, ITS Unix Systems and Applications, Stanford University
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Pushing data into a CMDB (especially Remedy)
Hello Puppet users, I was curious if anyone else works at an institution that uses Remedy, particularly as a CMDB infrastructure. We're planning to do that and so I've been tasked with writing integration tools so that Puppet can feed data of interest up into that system. If anyone is interested in helping (whether you use Remedy or not), I'd be interested to build a team around this effort. Here is the breakdown: The CMDB wants to know about systems and system facts. This is easy with facter and stored configs and stored facts. We'll just be writing a collector to query these things out of the puppetmaster storage and feed that into the CMDB. The CMDB also wants to know about meta information like who the admin in charge is, who the client is, what the purpose and description of the services are. These meta facts will be provided as either (a) meta resources created as native types in puppet or (b) through an external node tool. That's the basic jist of it. I'd love to hear from interested parties or parties doing something similar. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
When things are fairly small, it isn't an issue and certainly documentation is
key. I'm just very OCD about conventions and naming and I like having things
named in ways that it is explicit to the purpose. Generally, it is fairly easy
to tell that ssh::files would most likely be a class that deals with the files
associated with setting up ssh and not some variation of how ssh is setup.
But, in general, when I see foo::bar, I assume bar is a subclass (ergo
derivative of) foo. But since both fragments and subclasses are useful in
Puppet, for those that so feel inclined (and I think the Puppet community has
expressed interest in consistent style and practice guides to grow the
community closer), I think a naming convention to differentiate is valuable,
even if just for us OCD folks. :)
- Original Message -
From: "Kenton Brede" <[EMAIL PROTECTED]>
To: puppet-users@googlegroups.com
Sent: Tuesday, September 16, 2008 12:40:09 PM GMT -08:00 US/Canada Pacific
Subject: [Puppet Users] Re: Module Standards
2008/9/16 Digant C Kasundra <[EMAIL PROTECTED]>:
> So my proposal is if there is need or want to break up large classes, the
> fragment class (i.e. foo::files) be named specifically in a way that makes it
> clear it is not a complete and functional class but only a fragment. Such a
> naming convention might call for something like foo::_files or
> foo::inc::files. I would like to open this topic up to discussion to the
> greater community (you guys) and see what you think.
>
I guess I could see this if the classes were scattered throughout /manifests/.
I approach module building the same way in terms of breaking the classes
into smaller pieces. I guess I don't see a specific need for a
fragment designation.
I usually create a class named "foo" in init.pp and include the sub
classes there:
class files {
# include files class groups
include files::all
include files::rhel5
# include files class hosts
include files::host1
}
In site.pp I just "include foo." I document all this in the README
and comment the init.pp file. It just seems natural to me that way.
My setup isn't probably as complex as some so maybe I'm missing
something..
Kent
--
Digant C Kasundra <[EMAIL PROTECTED]>
Technical Lead, ITS Unix Systems and Applications, Stanford University
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Module Standards
Hello everyone, My team and I have been mulling over the module standards that were proposed (http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards) Members of our team like to break large classes up into tiny pieces, which isn't covered in this doc. For instance, if a class declares 10 files and 12 packages and 5 services, there is a preference to break these into foo::files, foo::packages, and foo:services and then have foo include these things. My problem with this is that I like to preserve a clear representation that :: denotes that the thing following is a subclass of the thing proceeding (so ssh::server means this is a subclass of ssh, relating specifically to ssh). So my proposal is if there is need or want to break up large classes, the fragment class (i.e. foo::files) be named specifically in a way that makes it clear it is not a complete and functional class but only a fragment. Such a naming convention might call for something like foo::_files or foo::inc::files. I would like to open this topic up to discussion to the greater community (you guys) and see what you think. -- Digant C Kasundra <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
