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 dig...@stanford.edu 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] Re: Parameterized classes vs defined-types
- Original Message - On Aug 23, 1:00 pm, Digant C Kasundra dig...@stanford.edu wrote: Out of curiosity, how are people using parameterized classes in a way that is distinct from defined-types? snarkI am _using_ defined types, that's how./snark 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 dig...@stanford.edu 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 dig...@stanford.edu 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 dig...@stanford.edu 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 antonym...@yahoo.com 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) {
some action
} else {
another action
}
}
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 dig...@stanford.edu
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. tony...@gmail.com 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 .
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 .
--
Tony
-- 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 dig...@stanford.edu
Technical Lead, ITS Unix Systems and Applications, Stanford University
--
You received
[Puppet Users] Re: Looking for ideas on how to get details of managed resources on the puppet client.
- Trevor Vaughan peiriann...@gmail.com 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: 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 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 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 ja...@lovedthanlost.net 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 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 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 r...@devco.net wrote: 'lo, - Julian Simpson simpsonjul...@gmail.com 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 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 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 peter.me...@immerda.ch 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 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 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 e.lann...@gmail.com 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
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] 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
* 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 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 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 p...@tertiusfamily.net 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 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 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 t...@reductivelabs.com 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 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 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 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 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 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 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 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: 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. snip 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: 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] 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 -~--~~~~--~~--~--~---
