I had some questions come up today during the Puppet demo here: 1. Is there any way to apply different intervals to different classes? For example, we might want a security baseline manifest to run once a month, package installation files once/day, etc. Since we''re a brokerage, we also don''t want ANY system changes during trading hours. I guess we could cron killing the puppetmaster at open of trading and starting it up at end of day, but that seems clunky - especially for reporting purposes. IOW, if we use Puppet to ensure reporting tools are there 24/7, we need the clients runnings... we just don''t want every module class applied during trading hours. Anyone else done something like this? 2. Wildcards in case and if statements ? Answer seems no - write a fact - but wanted to check? 3. Multiple puppetmasters for point solutions. For example, our Tools team liked this for managing Nagios, but want to manage the manfiests themselves on their own puppetmaster. Security Eng might want to manage the baseline and other manifests on their own puppetmaster... etc. Since the client only supports a single homed connection - how about a multi-homed feature in the client, OR ? 4. Is there any randomness to the interval time ? like MS''s group Policy Object? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jun 12, 2008 at 4:17 PM, Jeff Leggett <jeffrey.leggett@etrade.com> wrote:> > I had some questions come up today during the Puppet demo here: > > 1. Is there any way to apply different intervals to different > classes? For example, we might want a security baseline manifest to > run once a month, package installation files once/day, etc. Since > we''re a brokerage, we also don''t want ANY system changes during > trading hours. I guess we could cron killing the puppetmaster at open > of trading and starting it up at end of day, but that seems clunky - > especially for reporting purposes. IOW, if we use Puppet to ensure > reporting tools are there 24/7, we need the clients runnings... we > just don''t want every module class applied during trading hours. > Anyone else done something like this?http://reductivelabs.com/trac/puppet/wiki/TypeReference#id177> 2. Wildcards in case and if statements ? Answer seems no - write a > fact - but wanted to check?Not yet. You might use a fact, or use a function that munges a fact in the proper way.> 3. Multiple puppetmasters for point solutions. For example, our Tools > team liked this for managing Nagios, but want to manage the manfiests > themselves on their own puppetmaster. Security Eng might want to > manage the baseline and other manifests on their own puppetmaster... > etc. Since the client only supports a single homed connection - how > about a multi-homed feature in the client, OR ?As in having each client speak to multiple masters? That''s nuts, dude. Each group could have their own master, but there should only be one master per client.> 4. Is there any randomness to the interval time ? like MS''s group > Policy Object?http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference#splay --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Jun 12, 2008 at 4:17 PM, Jeff Leggett <jeffrey.leggett@etrade.com> wrote:> 3. Multiple puppetmasters for point solutions. For example, our Tools > team liked this for managing Nagios, but want to manage the manfiests > themselves on their own puppetmaster. Security Eng might want to > manage the baseline and other manifests on their own puppetmaster... > etc. Since the client only supports a single homed connection - how > about a multi-homed feature in the client, OR ?Use process to manage who has commit access to different parts of the manifest. It will be simpler to keep everything in one place (version control) than it would be to have a single client contact multiple masters for different parts of the configuration. (Not to mention the failure conditions, which would be many and nasty.) Regards, Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> >> 3. Multiple puppetmasters for point solutions. For example, our >> Tools >> team liked this for managing Nagios, but want to manage the manfiests >> themselves on their own puppetmaster. Security Eng might want to >> manage the baseline and other manifests on their own puppetmaster... >> etc. Since the client only supports a single homed connection - how >> about a multi-homed feature in the client, OR ? > > As in having each client speak to multiple masters? That''s nuts, dude. > Each group could have their own master, but there should only be one > master per client.I think your guys are missing the point of ''centrally managed''. Theoretically, if you did manage to hack this setup, what prevents your groups from overwriting each other? Version control is your friend. Each group could have their own version controlled modules with appropriate write access which are then included in a central manifest. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
That''s what I told them pretty much too. On Jun 12, 7:44 pm, Andrew Shafer <and...@reductivelabs.com> wrote:> > I think your guys are missing the point of ''centrally managed''. > Theoretically, if you did manage to hack this setup, what prevents > your groups from overwriting each other? > > Version control is your friend. Each group could have their own > version controlled modules with appropriate write access which are > then included in a central manifest.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jun 12, 2008, at 4:17 PM, Jeff Leggett wrote:> > I had some questions come up today during the Puppet demo here: > > 1. Is there any way to apply different intervals to different > classes? For example, we might want a security baseline manifest to > run once a month, package installation files once/day, etc. Since > we''re a brokerage, we also don''t want ANY system changes during > trading hours. I guess we could cron killing the puppetmaster at open > of trading and starting it up at end of day, but that seems clunky - > especially for reporting purposes. IOW, if we use Puppet to ensure > reporting tools are there 24/7, we need the clients runnings... we > just don''t want every module class applied during trading hours. > Anyone else done something like this?I didn''t see anyone else answer this one. You can use Schedules for this: http://reductivelabs.com/trac/puppet/wiki/TypeReference#id177 You can then have resources require specific schedules. -Blake --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---