Re: [Puppet Users] Release Cycle for September
On Wed, Sep 7, 2011 at 6:15 PM, Michael Stahnke stah...@puppetlabs.com wrote: 3. Dashboard has had no commits since 1.2.0, so no RC this month. Dashboard does have commits since 1.2.0 $ git log --oneline --no-merges 1.2.0.. 6b10a5e maint: Move duplicated code to a helper method 02ca4ff maint: Fix node_ids method by not overwriting it with and attr_accessor a2b864d (#8878) Make code more DRY 0075dd9 (#8878) Add ability to add nodes from the group edit/create pages ee59af8 (#8803) A single report page has a header with too much padding -- 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: Announce: Dashboard 1.2.0 is available now
On Tue, Aug 30, 2011 at 8:15 AM, David Thompson dthomp...@waisman.wisc.edu wrote: basically anyone attempting to do anything reasonable with ruby on RHEL 5.x (or any of the free repackaged distributions of RHEL 5.x) knows that 1.8.5 version is just short of useless and has implemented other fixes. Some comments on this thread, and current software development trends in general. Craig, the version of ruby that ships with RHEL 5 was good enough for many things, including dashboard = 1.1. So, while it may have problems and limitations, I think you overstate things to say it is just short of useless. Also, long in the tooth is subjective; RHEL 5 (and the derivative works) are currently supported distributions with significant installed user bases. Many environments, for many different reasons, have decided that EL is the best choice for them. It's important to respect those decisions. As a system administrator, I see people ignore compatibility with the EL distros regularly, and it's unfortunate that many people wave their hands with phrases like 'long in the tooth,' 'next to useless,' or 'any modern linux distribution' (from another project I was asked to install recently), which don't mesh well with the realities of significant parts of the installed linux base. In this case, as was pointed out, there are fairly simple ways to get ruby 1.8.5 onto an EL 5 system. But when someone writes an app against the lastest and greatest libgtk and friends, and uses the most recent versions of everything because that's what's available on their latest ubuntu release, it simply cuts them off from many potential users, for perhaps very little developer gain. Developers should consider carefully the run-time requirements vs. the target audience as part of the development process. I agree with Ramin that a different numbering scheme for ruby versions would have made more sense. A tiny version change (e.g. 1.8.5 to 1.8.7) would be understood in many release contexts to contain bug- fixes only and introduce no higher-level incompatibilities (a very broad simplification, but still true). Version numbers mean something very different to the ruby development team than they do to many other knowledgeable people. All that being said, if the dashboard development folks have decided that 1.8.7 is needed, then 1.8.7 it is. Perhaps pointers to suitable ruby builds could be included in the release notes (or on the download page, etc., etc.) as an aid to those who will need to upgrade. It's not just Dashboard that decided not to support older versions of Ruby, Rails (the framework Dashboard uses) doesn't support older version of Ruby. http://rubyonrails.org/download We recommend Ruby 1.8.7 or Ruby 1.9.2 for use with Rails. Ruby 1.8.6 and earlier are not supported, neither is version 1.9.1. While it's true this statement applies explicitly to Rails 3.x rather than Rails 2.3.x (which Dashboard is still based on), there is nowhere we could find that explicitly says that Rails 2.3.x *supports* Ruby 1.8.5, so there's no guarantee that security fixes (of which there were a few applied recently) will support Ruby 1.8.5. It's probably a good idea to briefly mention a few ways (numerous were mentioned in this thread) to get newer Rubies in the Dashboard manual (http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html#installing-dependencies). I've included our excellent documentation writer on this thread. -- 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] ANNOUNCE: Puppet Dashboard 1.2rc3 available
A race condition issue has been found with DelayedJob report processing. The fix has been committed to the rc branch, so another RC will be necessary. Ticket #8686 commit:e86526f224058d8d049b2f8b93d5fdca57332ad8 On Fri, Jul 22, 2011 at 4:18 PM, Michael Stahnke stah...@puppetlabs.com wrote: This a feature release candidate (number 3) of Puppet Dashboard. If you're wondering what happened to rc2, it was internal only. Our CI system found a few issues before we released it to the public. This release is available for download at: http://downloads.puppetlabs.com/dashboard/ We have included Debian and RPM packages as well as a tarball. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.2rc3 http://projects.puppetlabs.com/projects/dashboard Documentation is available at: http://docs.puppetlabs.com/dashboard/index.html Highlights of RC3: === * Documentation moved primarily away from the included README to website: http://docs.puppetlabs.com/dashboard/index.html * Some minor UI bug fixes Commits for RC3 === 88771ec (#8589) Report events are now ordered by name. 8bd0ffb (#8544) Make empty inspected resources red. d036276 (#8505) Update the default date stringification. bb99ed9 Properly Quote RAILS_ROOT in get_app_version method 08717e1 (#8508) Add delayed job worker script for debian/ubuntu package 2eef4f4 (#8529) Remove unneeded a print statement from sass.rb af8b6e9 (#8500) Replace README with a smaller one dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac 3f0afca (#8484) Nodes for this group heading now appears correctly 1.2 series Highlights Include: * Moved to Apache 2.0 License * LOTS of UI improvements * Updated version of Rails * Now Requires Ruby 1.8.7 * Has Delayed Jobs (puppet-dashboard-workers) for async actions * Several performance improvements More Details === d389d8b (#7568) Relicense to Apache-2.0 License 57d0122 (#8276) Remove MaRuKu dependency a44d9ff (#8262) Show node groups even when node classification is disabled 3996b29 (#8262) Create callbacks for each section of node_classification partial 5dac13a (#8199) Move 'failed' resources to the top when viewing report events 2a3a73c (#7967) Improved user-facing design for delayed job warnings c78b85a (#8266) Back-end logic for splitting read and unread DJ failures. 15bba31 (#8121) Properly generate CSS from SASS in production. a9abf41 (#8101) Updated to new version of Tipsy plugin 9cb5e55 (Maint) More generalized tabbed interface fbe11aa (#8196) Adjust content width based on body classes. e756c25 (#8196) Add a body class describing sidebar state. 23cbef1 (#8196) Clean up body class manipulation. 3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost 81ec3c0 (#8090) Update .gitignore to ignore plugin files 6f117fc (#8022) Don't fail when installing plugin without `public` directory 07a9407 (#8022) Create a hook for plugins to add items to head in layout 64be352 (#7967) Add default value for read column of delayed_job_failures 240c548 (#7967) Infrastructure for displaying background failures. 8038cce (#7389) Don't auto-start DelayedJob workers. 933ae04 (#7389) Cheaper unique filenames for spooled reports. b4384eb (#7398) Support externally managed DelayedJob workers. 184e65b (#7689) Rake task to support parallel report POSTing. 2333c08 (#5947) Rename Destroy button to Delete 2fb0ac1 (#7976) Fixed static debug data in view 393970d (#7976) Node filter links in sidebar work in all cases 4ba3d23 (#7398) Configurable DelayedJob worker count. e839884 (#7938) Delayed import from file, not YAML string. d24c323 (#7973) Refactor colors for changed/unchanged 58c2b52 (#7398) Use DelayedJob for background processing. 6aefc60 (#7938) Add daemons gem to support DelayedJob 7395369 (#7398) Vendor DelayedJob for background tasks. 05040d9 (#7958) Allow plugins to add top level navigation c4d2f26 (#7597) Better integration of node summaries 4ad9cbc (#7913) Upgrade rspec and rspec-rails vendored gems c09b650 (#7913) Fix tap deprecation warning d88da0e (#7913) Update README to say we only support Ruby 1.8.7 acdc31f (#7913) upgrade will_paginate gem to avoid deprecation warnings e935b8d (#7913) vendor newer version of RDoc ce9be98 (#7913) Fix deprecation warning for config.load_paths dd8f277 (#7913) Upgrade vendored haml gem and vendor sass dd88d74 (#7913) vendor json_pure since it was an undocumented dependency 789c1b7 (#7913) Upgrading from Rails 2.3.4 to 2.3.12 060799f (#7597) Reformat node view CSV link 3726771 (#7280) Edit outdated information about the inventory service a02113a (#7597) Change empty tab display, report tab ordering, link expansion b62bf4c (#7597) Add count to pagination link, fix duplicate tags 9f06f58 (#7597) Display only relevant columns
Re: [Puppet-dev] Re: [Puppet Users] ANNOUNCE: Puppet Dashboard 1.2rc3 available
Good catch, I've gone ahead and swapped the column order and merged the change, so we should be ready for another RC tomorrow unless anyone finds more issues. On Thu, Jul 28, 2011 at 4:51 PM, Daniel Hogland dhogl...@puppetlabs.com wrote: Another bug that might want to be fixed (quick fix i'm sure) before cutting a new rc is 8691. Dan On Thu, Jul 28, 2011 at 4:38 PM, Matt Robinson m...@puppetlabs.com wrote: A race condition issue has been found with DelayedJob report processing. The fix has been committed to the rc branch, so another RC will be necessary. Ticket #8686 commit:e86526f224058d8d049b2f8b93d5fdca57332ad8 On Fri, Jul 22, 2011 at 4:18 PM, Michael Stahnke stah...@puppetlabs.com wrote: This a feature release candidate (number 3) of Puppet Dashboard. If you're wondering what happened to rc2, it was internal only. Our CI system found a few issues before we released it to the public. This release is available for download at: http://downloads.puppetlabs.com/dashboard/ We have included Debian and RPM packages as well as a tarball. See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.2rc3 http://projects.puppetlabs.com/projects/dashboard Documentation is available at: http://docs.puppetlabs.com/dashboard/index.html Highlights of RC3: === * Documentation moved primarily away from the included README to website: http://docs.puppetlabs.com/dashboard/index.html * Some minor UI bug fixes Commits for RC3 === 88771ec (#8589) Report events are now ordered by name. 8bd0ffb (#8544) Make empty inspected resources red. d036276 (#8505) Update the default date stringification. bb99ed9 Properly Quote RAILS_ROOT in get_app_version method 08717e1 (#8508) Add delayed job worker script for debian/ubuntu package 2eef4f4 (#8529) Remove unneeded a print statement from sass.rb af8b6e9 (#8500) Replace README with a smaller one dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac 3f0afca (#8484) Nodes for this group heading now appears correctly 1.2 series Highlights Include: * Moved to Apache 2.0 License * LOTS of UI improvements * Updated version of Rails * Now Requires Ruby 1.8.7 * Has Delayed Jobs (puppet-dashboard-workers) for async actions * Several performance improvements More Details === d389d8b (#7568) Relicense to Apache-2.0 License 57d0122 (#8276) Remove MaRuKu dependency a44d9ff (#8262) Show node groups even when node classification is disabled 3996b29 (#8262) Create callbacks for each section of node_classification partial 5dac13a (#8199) Move 'failed' resources to the top when viewing report events 2a3a73c (#7967) Improved user-facing design for delayed job warnings c78b85a (#8266) Back-end logic for splitting read and unread DJ failures. 15bba31 (#8121) Properly generate CSS from SASS in production. a9abf41 (#8101) Updated to new version of Tipsy plugin 9cb5e55 (Maint) More generalized tabbed interface fbe11aa (#8196) Adjust content width based on body classes. e756c25 (#8196) Add a body class describing sidebar state. 23cbef1 (#8196) Clean up body class manipulation. 3670e2b (#8146) Change default DASHBOARD_URL in external_node to localhost 81ec3c0 (#8090) Update .gitignore to ignore plugin files 6f117fc (#8022) Don't fail when installing plugin without `public` directory 07a9407 (#8022) Create a hook for plugins to add items to head in layout 64be352 (#7967) Add default value for read column of delayed_job_failures 240c548 (#7967) Infrastructure for displaying background failures. 8038cce (#7389) Don't auto-start DelayedJob workers. 933ae04 (#7389) Cheaper unique filenames for spooled reports. b4384eb (#7398) Support externally managed DelayedJob workers. 184e65b (#7689) Rake task to support parallel report POSTing. 2333c08 (#5947) Rename Destroy button to Delete 2fb0ac1 (#7976) Fixed static debug data in view 393970d (#7976) Node filter links in sidebar work in all cases 4ba3d23 (#7398) Configurable DelayedJob worker count. e839884 (#7938) Delayed import from file, not YAML string. d24c323 (#7973) Refactor colors for changed/unchanged 58c2b52 (#7398) Use DelayedJob for background processing. 6aefc60 (#7938) Add daemons gem to support DelayedJob 7395369 (#7398) Vendor DelayedJob for background tasks. 05040d9 (#7958) Allow plugins to add top level navigation c4d2f26 (#7597) Better integration of node summaries 4ad9cbc (#7913) Upgrade rspec and rspec-rails vendored gems c09b650 (#7913) Fix tap deprecation warning d88da0e (#7913) Update README to say we only support Ruby 1.8.7 acdc31f (#7913) upgrade will_paginate gem to avoid deprecation warnings e935b8d (#7913) vendor newer version of RDoc ce9be98 (#7913
Re: [Puppet Users] Facter with a gem
require 'rubygems' require 'yourgemname' That should be enough. You're going to have to start giving more info you want more help. At the very least the gem name. Sometimes you think you're requiring the gem correctly based on the gem name, but the thing you need to require might not match the gem name exactly. For example, there's an rspec-core gem, but you don't do require 'rspec-core', you do require 'rspec/core'. This really shouldn't be a facter issue, it's a ruby issue. Try just putting the requires in an empty file and using ruby to run that. If it works there and doesn't in the facter code, paste your code into a gist so that people can see the whole thing. Matt On Fri, May 13, 2011 at 9:49 AM, Pietro Monteiro pie...@deckmonitoring.com wrote: On 05/13/2011 07:55 AM, Patrick wrote: Facter is run on the clients. Does installing that gem on the clients fix the error? Also, require 'rubygems' on the top of the file where you define your facter. -- Pietro Monteiro Senior Developer DECK Monitoring 115 W 8th Ave. Eugene, Oregon 97401 Office: 541-343-0110 www.deckmonitoring.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: allow_duplicate_certs = true not working?
Jake The behavior in 2.7 when running the master with --allow_duplicate_certs set is the same as in 2.6.x in that you can manually (using something like curl or the new 'puppet certificate' face) generate multiple certs with same CN name, but the agent errors the same way regardless of the puppet version. I've updated ticket #3360 with more detail. That ticket is currently closed and should probably stay that way. I opened two new tickets, #7109 and #7110, to address the confusion with how the agent connects to the master when --allow_duplicate_certs is set. We should decide what the desired behavior is with an agent, and improve the error message that comes back. More detail in both those tickets. Thanks for testing out 2.7rc1. Matt On Thu, Apr 14, 2011 at 10:52 AM, Jake - USPS jacob.m.mcc...@usps.gov wrote: Test results posted, you may have posted shortly after I did. ;) We are using SLES 10. I'm not exactly sure what other information you want ... here is some of the relevant packages we have installed: usps-augeas-0.7.4-1.sles10 usps-ruby-gem-test-unit-2.1.2-1.sles10 usps-ruby-augeas-0.3.0-1.sles10 usps-puppet-dashboard-1.1.0.3-1.sles10 usps-ruby-1.8.7-1.sles10 usps-ruby-gem-rake-0.8.7-1.sles10 usps-ruby-gem-rack-1.2.1-1.sles10 usps-ruby-gem-passenger-3.0.2-1.sles10 usps-ruby-gem-sys-admin-1.5.4-1.sles10 usps-ruby-gem-mysql-2.8.1-1.sles10 usps-rubygems-1.4.1-1.sles10 usps-facter-1.5.8-1.sles10 usps-puppetmaster-2.7.0.1-1.sles10 We are running the puppetmaster through passenger, although my tests above are running it as your told me. If you want anything else, just let me know. Thanks for checking this out, Jake On Apr 14, 12:45 pm, Dominic Maraglia domi...@puppetlabs.com wrote: Jake, We are investigating additional uses cases for allow_duplicate_certs functionality; stay tuned for more information on this topic. In the meantime, we'd be very interested in your test results and a bit of information about your platform would be much appreciated at well. Cheers, Dominic On 4/14/11 10:33 AM, Jake - USPS wrote: I can give that a try ... does that mean I wouldn't be able to use passenger like I currently am to get this to work? I'll let you know of my results shortly. Regards, Jake On Apr 14, 11:35 am, Dominic Maragliadomi...@puppetlabs.com wrote: Jake, Can you please try the following step and see if these allows you to use duplicates certs? On your Puppet Master node: - Stop the Puppet Master daemon. - Restart your Puppet Master as follows: puppet master --allow_duplicate_certs --certdnsnames=puppet:$(hostname -s):$(hostname -f) --verbose --noop On a Puppet Agent node: - Generate a cert: puppet certificate generate `hostname` --ca-location remote --server Name_of_Puppet_Master - Generate a second cert : puppet certificate generate `hostname` --ca-location remote --server Name_of_Puppet_Master I would quite interested to know the outcome of these step. Cheers, Dominic Maraglia On 4/14/11 7:37 AM, Jake - USPS wrote: I saw this feature became available in 2.7.0rc1 and wanted to try it out. I entered 'allow_duplicate_certs = true' on both my master and agent systems in the puppet.conf (not sure if its need in both, saw it in genconf for puppetd and puppetmasterd though ...). I also have autosign.conf configured to allow autosigning for our domain (*.domain.com). I had my agent register with the master for the first time, works good (always has ;). Now on my agent I removed the ssl directory. Do another test run, it generates new certs on the agent system and tries to communicate with the master. I then receive the following error on the agent: info: /User[puppet]: Provider useradd does not support features manages_aix_lam; not managing attribute ia_load_module info: /File[/etc/puppet/ssl]: Scheduling refresh of (completed_/etc/ puppet/ssl) notice: /Whit[completed_/etc/puppet/ssl]: Triggered 'refresh' from 1 events info: /File[/etc/puppet/ssl/private]: Scheduling refresh of (completed_/etc/puppet/ssl/private) notice: /Whit[completed_/etc/puppet/ssl/private]: Triggered 'refresh' from 1 events info: /File[/etc/puppet/ssl/certs]: Scheduling refresh of (completed_/ etc/puppet/ssl/certs) info: /File[/etc/puppet/ssl/certificate_requests]: Scheduling refresh of (completed_/etc/puppet/ssl/certificate_requests) notice: /Whit[completed_/etc/puppet/ssl/certificate_requests]: Triggered 'refresh' from 1 events info: /File[/etc/puppet/ssl/private_keys]: Scheduling refresh of (completed_/etc/puppet/ssl/private_keys) notice: /Whit[completed_/etc/puppet/ssl/private_keys]: Triggered 'refresh' from 1 events info: /File[/etc/puppet/ssl/public_keys]: Scheduling refresh of (completed_/etc/puppet/ssl/public_keys) notice: /Whit[completed_/etc/puppet/ssl/public_keys]: Triggered 'refresh' from 1 events notice:
[Puppet Users] ANNOUNCE: Puppet 2.6.8rc1 available!
This release addresses issues with the Puppet 2.6.x series. Bug #4884: Shell exec provider that executes code as a raw shell script Bug #5670: Failed resources don't improperly trigger a refresh Feature #2331: New macports provider You can find the full release notes for Puppet at: https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes This release is available for download at: http://puppetlabs.com/downloads/puppet/puppet-2.6.8rc1.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet Please report feedback via the Puppet Labs Redmine site, using an affected version of 2.6.8rc1: http://projects.puppetlabs.com/projects/puppet/ CHANGELOG: 2.6.8rc1 8b7444d (#2331) Remove darwinports pkg provider, replace with rewritten macports provider 65c4e14 Fixed #7082 - Added system support for groups b7f4ff7 (#7018) Give more context on the service type's assumptions. Wording tweaks. bb19dea (#7018) explain internals better in service provider documentation 23c9663 maint: Fix sqlite3 require to really be optional 4b73d41 maint: Fix sporadic sqlite error 54b9f5d (#6818) Stop from getting Rails 3 named_scope deprecation warning e493f8a (#6856) Copy dangling symlinks with 'links = manage' File resource. 1e4968e (maint) Indentation fixes 99d78f2 (#6490) Add plugin initialization callback system to core 5d1cb02 Fix #4339 - Locally save the last report to $lastrunreport 306aa30 Fix #4339 - Save a last run report summary to $statedir/last_run_summary.yaml 9bb3018 Fixed #3127 - removed legacy debug code d2bacd3 Fixed #3127 - Fixed gem selection regex 1b66c28 (#5437) Invalidate cached TypeCollection when there was an error parsing 0675c9a (#6937) Adjust formatting of recurse's desc 2cdadf9 (#6937) Document the recurse parameter of File type. 647a640 (#6893) Document the cron type in the case of specials. 87ca313 (#5670) Don't trigger refresh from a failed resource f5aabf5 (#5908) Add support for new update-rc.d disable API 37f9ca0 (#6862) Add a default subject for the mail_patches rake task 9a4de12 Fixed #6256 - Creation of rrd directory. 7c60db5 (#5477) Allow watch_file to watch non-existent files, especially site.pp 7761acb (#5221) Add test for fix to fileset with trailing separator 357514c (#5221) Fix fileset path absoluteness checking with trailing slash f8941b8 (#4769) Fix negative timeout support for newer rubies a29c7fd Fixed #6562 - Minor kick documentation fix df20513 (#6658) Propagate ENC connection errors to the agent 08115c0 (#4884) Remove typo from spec test f2c771b (#4884) Modify tests to pass on non-OS X systems ec1aa19 (#4884) Revise new exec tests, add a few more 196294a (4576) - if ENC declares invalid class, it is logged at warning. 0d2d6f3 (#4884) Add an shell provider for execs d2e911a (#4884) Fix Test::Unit exec tests fa0cfc6 (#4884) Break the exec type out to have a posix provider c86a980 (#4884) Add consistent path validation and behavior 77fbf7f (#4884) Add expand_path to requiring the spec_helper 7ec9057 (#4884) Autorequire shared behaviors and method to silence warnings acc99ba (#4884) Fix whitespace 6a4d291 (#4884) Get rid of open3 require since it wasn't being used 3e7ebbb Fixed #6554 - Missing $haveftool if/else conditional in install.rb breaking Ruby 1.9 fddc165 (#5814) Improved cron type specs f2dfee6 (#5814) cron_spec shouldn't depend on cron provider -- 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] ANNOUNCE: Puppet Dashboard v1.1.1rc1
This release addresses some issues issues with Dashboard v1.1.0 #6532 - There is a rake task for generating random sample reports for testing. rake reports:samples:generate CHANGELOG v1.1.1rc1 == f1b2af4 (#7060) Use absolute paths for cert/private key 1a3e607 maint: Document the `rake reports:schematize` upgrade process c02527a Fixed #6980 - Updated DEB packaging for 1.1.0 535b69e Fixed #6980 - Updated RPM spec file for Puppet Dashboard d8374cc maint: Clean sample reports before generating new ones b2e62cc (#6862) Add a default subject for the mail_patches rake task e06e4e7 maint: require 'yaml' should be lowercase, works on macs for some reason 148358c (#6532) Add NUM_REPORTS to reports:samples:generate rake task 75768ae (#6533) Add rake task to generate unresponsive nodes 1e924aa (#6532) Add options to sample generator rake task fd860bf (#6532) Add combination rake task for generating importing samples ff1c087 (#6532) Change report generator to a rake task f0625a9 maint: Print error message when rake:import fails 8d7f875 (#6531) Folded into one file renamed c5056e4 (#6531) Add ability to generate events 9d51f70 Branch with report generation utility e0652ef (#6736) Add require 'thread' to rakefile 062f91c maint: Make sure config/installed_plugins is present before db:migrate bf2d91f (#6684) Sanitize plugin migration names -- 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] ANNOUNCE: Puppet Dashboard 1.1.0rc3
I'm not sure why this would be without more info to reproduce the
problem. I couldn't reproduce it anyway. I'd recommend opening a
ticket that includes at least a sample of the messed up error logs in
addition to the info you provided.
On Mon, Apr 11, 2011 at 7:06 AM, Thomas Bendler
thomas.bend...@gmail.com wrote:
Hi Matt,
2011/4/8 Matt Robinson m...@puppetlabs.com
[...]
We definitely appreciate any help testing RC's and releases, so I look
forward to your feedback.
[...]
Ok, here it is (CentOS 5.6 system). I've changed:
su -s /bin/sh -c ${DASHBOARD_RUBY} ${DASHBOARD_HOME}/script/server -e
${DASHBOARD_ENVIRONMENT} -p ${DASHBOARD_PORT} -b ${DASHBOARD_IFACE}
${DASHBOARD_USER}
to:
su -s /bin/sh -c ${DASHBOARD_RUBY} ${DASHBOARD_HOME}/script/server -e
${DASHBOARD_ENVIRONMENT} -p ${DASHBOARD_PORT} -b ${DASHBOARD_IFACE}
/dev/null 21 ${DASHBOARD_USER}
in /etc/init.d/puppet-dashboard. Otherwise my console is messed up with
error logs and I can't log out without loosing puppet-dashboard. /dev/null
could be replaced by a log file wich should be part of logrotate.
Regards, Thomas
--
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] ANNOUNCE: Puppet Dashboard 1.1.0rc3
Hi Thomas, sorry for the slow reply on this and lack of packages for testing. We messed up and forgot to put packages out with Dashboard for the RC or the release. This should be fixed now for the release, and we've updated our RC checklist to make testing packages for the next time. We definitely appreciate any help testing RC's and releases, so I look forward to your feedback. Matt On Mon, Mar 28, 2011 at 4:34 AM, Thomas Bendler thomas.bend...@gmail.com wrote: Hi Jacob, 2011/3/24 Jacob Helwig ja...@puppetlabs.com [...] This release is available for download at: http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.1.0rc3.tar.gz [...] are there already RPMs available? I would like to help testing but only if RPMs are provided. Kind regards, Thomas -- 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. -- 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-dev] ANNOUNCE: Puppet Dashboard 1.1.0 - Release Candidate 1 available!
There were a few very important changes we forgot to highlight in the Dashboard v1.1.0rc1 release notes. 1. Reports will need to be converted to a new schematized format when upgrading (#5459). Rather than just storing reports as serialized YAML in the database as is currently done in v1.0.4, they are now in a set of tables that allows them to be queried more easily and faster. This conversion can be a slow process if you have a long history of reports, so it's not done as part of `rake db:migrate`. Instead, there is a rake task (#5535) that will do the conversion for you, converting newer reports first and able to be resumed if it's interrupted just by rerunning it. `rake reports:schematize` Also worth noting is the `rake reports:prune` task that can prune older reports that you don't care about, which will make this conversion much faster. Run the rake task without arguments to see documentation for how to specify how far back to prune. 2. The new inventory service portion of Dashboard only works if you're running the newest version of Puppet (2.6.7 which is releasing today). On Wed, Mar 16, 2011 at 5:38 PM, Nick Lewis n...@puppetlabs.com wrote: This release addresses a large number of issues and adds lots of new functionality, including: Inventory Service Lookup - The node view page will now retrieve and display the node's facts from the inventory service. - There is a Custom Query page which will search the inventory service for nodes meeting particular conditions. Preliminary documentation for this feature will be available at: https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/inventory_service.markdown Finalized documentation will be available at release time on the main documentation site: http://docs.puppetlabs.com Settings - Many settings may now be specified in config/settings.yml. Copy the config/settings.yml.example (which provides fallback defaults) to get started. - Changing a setting will currently require a server restart to take effect. Inspect Report Handling - Dashboard can now consume and display inspect reports. Filebucket integration - Dashboard can now display file contents and diffs from a specified Puppet filebucket. Lots of UI and speed improvements Better support for reports - Now supports 2.6 reports and inspect reports Preliminary support for user-made plugins Improved Class/Group/Parameter dependency reporting and handling Log rotation This release is available for download at: http://puppetlabs.com/downloads/dashboard/puppet-dashboard-1.1.0rc1.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.1.0rc1: http://projects.puppetlabs.com/projects/dashboard/ v1.1.0rc1 = 1fcfc01 (#6736) Provide Mutex, avoid an error. 95f97fb maint: Move inventory section lower on the node page 8629962 (#4403) Do timezone arithmetic outside of the DB in the Status model 614655c Remove dead code from Status model 849f2de Validate the user supplied daily_run_history_length 118962b (#6656) Inventory service is no longer experimental. 90e0624 (#6601) Inventory search uses the new inventory URL fb55499 (#5711) Change license from GPLv3 to GPLv2 68b335e (#5234) Source of silk icons attributed, per author's license d3d1528 Maint: Moved logic for identifying inspect reports into a callback. c2fe255 Maint: removed bogus comments from _report.html.haml 81b8a04 Maint: Moved elements of the report show view into callbacks. 2b91838 Maint: Moved elements of the node show view into callbacks. cc95431 Maint: Forbid uninstalled plugins from adding themselves to hooks. 169d275 Maint: Add plug-in install and uninstall rake tasks d4d0b00 Maint: removed db/schema.rb 5f6614d Maint: Removed some private methods in the report model that are part of baseline functionality. db663a5 Maint: remove code that belongs in the baseline module. 5be1f0f maint: Added log dir to version control 93857f0 Maint: Add puppet plugins to .gitignore 1197e8a Bug fix: renamed each_hook and find_first_hook to *_callback cbfde3d Remove some forgotten baseline code 2b4f9eb Add some basic hooks for use by future Dashboard plug-ins. c9ff13e Add a registry for creating hooks and callbacks. a40e6c9 Oops: Remove report baseline functionality fd7f799 Rename baseline-diff-report CSS classes and IDs to be expandable-list 161e0da (#6090) Improved auto-selection of specific baseline. 035aa17 (#6072) Moved baseline inspection link underneath Recent Inspections 613a465 (#6095) Render proper error messages when diffing against a baseline that can't be found ea2368f (#6069) Fixed unique ids in the report group diff view. 3426763 maint: Use new factory_girl syntax to improve a test 1862966 maint: Refresh the vendored gem specifications 79a23c9
[Puppet Users] ANNOUNCE: Facter 1.5.9
Facter 1.5.9 is a maintenance release containing fixes and updates. This release is available for download at: http://puppetlabs.com/downloads/facter/facter-1.5.9rc1.tar.gz See the Verifying Puppet Download section at: http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet#Verifying+Puppet+Downloads Please report feedback via the Puppet Labs Redmine site, using an affected version of 1.5.9rc1: http://projects.puppetlabs.com/projects/facter/ CHANGELOG == 458a22d Incremented release to 1.5.9 4eb64fe Fixed #6719 Typo ffd80ac (#5011) Adds swap statistics for OSX 1207765 (#6719) Restricts virtualization types for zones 8d71db3 Fixed #6616 - Stubbing in VMware tests on Linux aa959df Remove Solaris from the list of confined systems. It won't get the original lsb facts, and it's nonsensical too. d718af4 Fix #6679 - Added Scientific Linux to operatingsystem fact dea6f78 Further fix to #5485 - SELinux facts 6d6d8da (#2721) Merged patch from Brane GraAnar 868e7ba (#5485) Made selinux_mode fact work 214da73 Fixed #5485 - Updated selinux_mode fact ba2601f Fix for #6495 - Updated interface detection 93461d9 Fixed #5950 - Solaris ipaddress incorrect after bonding failure 2e06cdc (#6615) fix missing stub calls in loader specs 3c7841e (#5666) windows support for facter/id.rb dd5d5bf (#4925) - MS Windows doesn't do man pages 52026ee Fixed #5699 - Added processorcount support for S390x 7dd730d Fixed #5699 - Added virtual support for s390x/Zlinux d6ce08a Fixed #6611 - Fixed broken HPVM test and rationalised test structure 84fa3c4 (#6525) change semicolons to 'then' in case statement for ruby 1.9.2 compatibility 3e6217d Fixes #6521 and other Ruby 1.9 issues eb5d6fc Fixed #6525 - Test failures on Ruby 1.9.x cb25119 (#2270) add testing for the new ipaddress6 feature ea29483 (#2270) add IPv6 support to facter core. 77eb512 (#2270) Remove DWIM code from ipaddress on Darwin. f5bf0f5 (#6360) Flush Facter top level cache before every test case. 0d7a2e6 Fix #4755: add support for GNU/kFreeBSD platform where missing. b88a088 (#5510) Facter should load custom fact definitions in filename order. 7a8be16 Refactor #6044 -- use _spec.rb as the pattern for spec tests. b39f892 Refactor #6044 -- require spec_helper with a consistent path. a4fe459 Refactor #6044 -- port testing to rspec2 af9134c (#5086) Try using kstat before falling back to 'who -b' to determine uptime. cbbfe55 Refactor util/uptime.rb tests to reduce duplication using contexts f0cc2c0 (#4575) win32 support for manufacturer, productname, serialnumber c40fc07 (#1423) Memory facts for Solaris 1985528 (#4754) Change is_virtual logic to not enumerate virtual types 739040f (#4754) Add support for Darwin and Parallels VM to virtual fact 9332f8a (#5325) Add tests for SPARC manufacturer and product name 5b561e3 (#5325) Manufacturer and product name on SPARC 9d99079 maint: Fix spec failures caused by having a space in the path to facter's source 89da001 maint: require rubygems so hudson can run the specs 1eef842 Maint: add Local-branch: info to mails sent by rake mail_patches f007a9d (#4989) Add xendomains fact 1fa87a9 JSON support. Works in 1.9.1. Warnings in 1.9.2. LoadError on 1.8.7 for some reason 43e203c (#5040) fact virtual should detect hpvm 7cec60a (#5016) is_virtual should be true on solaris zones f2e66b6 (#5031) Remove redundant puts from RDoc.usage f4da528 maint: Fix merge error d62b013 Issue #4889 Fact values should all be strings 07f186d [#4552] Updating --timing to report in milliseconds instead of seconds 1f387a5 [#4552] Apply patch from Dean Wilson 244d2f1 Better fix for Bug 4569: Uptime Fact is incorrect on Windows 11544c1 [#4289] operatingsystemrelease fact for oel, ovs e6bfdf9 Fix for bug #4569 8c4d0cd (#4558) Fail with message on --help errors 7210429 [#4558] Refactor facter binary using optparse b5c85de [#4563] Add a --trace option to the binary ebcb81b [#4558] Refactor facter binary using optparse b8b7123 (#4567) Remove unnecessary or non-portable redirects 7ecba71 (#4567) Retain detached HEAD state 1125e1e Make sure FreeBSD spec also works on systems that have /proc/cpuinfo. 889e150 Sync rpm spec file from Fedora/EPEL 725dce0 Rename Reductive Labs to Puppet Labs ff473ef Updated signing rake task a85f2b0 [#2865] Fix reporting of virtual facts f67ec05 [#4567] Add ext/facter-diff to compare output of 2 versions 4050acc Removing stupid .DS_Store files :( 016cf03 [#3703] Fix macaddress fact for Darwin -- 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: ANNOUNCE: Facter 1.5.9
On Wed, Mar 16, 2011 at 5:38 PM, Matt Robinson m...@puppetlabs.com wrote: Facter 1.5.9 is a maintenance release containing fixes and updates. That subject and message were supposed to say that this is a release candidate, 1.5.9rc1, not the final release of 1.5.9 -- 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-dev] RFC: Database-backed inventory service plan
On Wed, Feb 23, 2011 at 2:04 PM, Nick Lewis n...@puppetlabs.com wrote: Our current plan for the inventory service is to provide active_record termini for the facts and inventory indirections. This is to support fast look-up of facts, and search of nodes based on their facts. However, there are already tables for facts, used for storeconfigs, along with an active_record terminus for facts. On Fri, Feb 25, 2011 at 1:55 PM, Matt Robinson m...@puppetlabs.com wrote: I propose that we don't share tables, and the inventory service (and any other future service that needs a database backend) has its own set of namespaced tables (servicename_tablename). Thanks to those who gave feedback. The general consensus I've reached talking offline to other devs (Jacob, Nick, Paul) is that we should use separate tables for the inventory service from the ones that storeconfigs currently uses. The question of whether to normalize or denormalize (which I didn't mean to have be the focus of this discussion at all) can be left up to the devs who end up working on the implementation, taking the discussion from this thread into account. Matt -- 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-dev] RFC: Database-backed inventory service plan
On Wed, Feb 23, 2011 at 2:04 PM, Nick Lewis n...@puppetlabs.com wrote: Our current plan for the inventory service is to provide active_record termini for the facts and inventory indirections. This is to support fast look-up of facts, and search of nodes based on their facts. However, there are already tables for facts, used for storeconfigs, along with an active_record terminus for facts. We want to avoid unnecessarily duplicating this behavior, by reusing the existing tables and terminus. This would result in the same fact data being used by both the inventory service and storeconfigs. In principle I don't like the idea of tying the backends of storeconfigs and inventory together by sharing tables, especially since I'm not clear on the future of storeconfigs or a lot of details of how it's currently used, so it makes it harder to change implementation details. As a specific example, I don't like the schema storeconfigs has for storing fact data (explained in more detail below) and would prefer to use a different one. If we share tables this is awkward. I propose that we don't share tables, and the inventory service (and any other future service that needs a database backend) has its own set of namespaced tables (servicename_tablename). Ideally I would like to use separate database schemas entirely, but that would be a bigger, harder to manage change with the current code that relies on the active_record terminus. Currently the storeconfigs tables dealing with facts look something like this (I've removed the columns that are irrelevant to the inventory service): create_table :hosts do |t| t.column :name, :string, :null = false end create_table :fact_names do |t| t.column :name, :string, :null = false end create_table :fact_values do |t| t.column :value, :text, :null = false t.column :fact_name_id, :integer, :null = false t.column :host_id, :integer, :null = false end I propose something more like: create_table :nodes do |t| t.column :name, :string, :null = false t.column :timestamp, :datetime end create_table :facts do |t| t.column :name, :string, :null = false t.column :value, :text, :null = false t.column :node_id, :integer, :null = false end It's less normalized than the storeconfigs schema since fact names will be duplicated per node, but easier to understand and work with, and I think better satisfies the types of queries we will be doing which are of the form select nodes where fact equal to value. The more normalized schema would be better for queries of the form select all values for fact, but I don't think that's something we'll be doing. Correct me if I'm wrong. Other benefits of the proposed schema include the metadata about each fact set being columns on the node table (Nick has also proposed that table be called fact_sets and have a column called node_name) instead of being stored as a fact. Also we tend to use the word host all over our code (in both puppet and dasbhoard) when we really ought to use the word node since host confuses people into thinking the host name is what identifies a node, when by default it's the fqdn and could be anything. Please share any other comments or concerns you may have related to this proposal, particularly if it would interfere with your current use of storeconfigs. Thanks. Questions: Do or will we want historical fact sets? Current understanding is no, that we only store the most recent fact set per node. This makes the database smaller and I can't think of a motivator for wanting historical fact sets, but maybe someone else can. What other metadata do we want to store about facts. Currently the only metadata we're storing is timestamp. -- 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] Puppet Development Lifecycle Documentation - How to contribute to Puppet
The documentation on the wiki for the development lifecycle process has been updated in an effort to make it easier for people to get code into Puppet. The goals were to make it correct and easy to follow, so take a look and let us know if there's anything that could use improvement. http://projects.puppetlabs.com/projects/puppet/wiki/Development_Lifecycle The intent is not to be rigid about following a process to submit code, but the steps outlined in this document hopefully make it easier for everyone to improve Puppet. Once the community has had a chance to comment on this process and documentation, the plan is to move it from the wiki to a more permanent home at: http://docs.puppetlabs.com/guides/development_lifecycle.html. Matt -- 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] Creating tests for the yum package provider
Hi Oliver, Dan Bode emailed me to let me know that he has already looked into this a bit and that he will be on site to work with you this next week. I'll look further into these tests if he doesn't have the time to see this through. Matt On Fri, Sep 3, 2010 at 4:20 PM, Matt Robinson m...@puppetlabs.com wrote: Hi Oliver, Sorry for taking so long to respond on this. We definitely appreciate the help writing some tests for that patch as it looks like something that would definitely help people once it gets merged in. Writing tests for puppet providers can be tricky, as you're finding. I'll take a look and see where you're running into problems. Hopefully I'll have some help for you by the end of Monday. Matt On Mon, Aug 16, 2010 at 4:32 AM, Oliver ohook...@gmail.com wrote: Sorry, but this is a blatant call for help. I'm desperately out of my depth with creating tests due to my lack of experience with just about every component involved. The background is, I'm trying to create the necessary tests to have #2866 accepted. I'm running into problems just getting a basic should specify the package version if one is asked for test running. I've looked through the yum provider code, the other providers, tests for other providers etc but can't seem to come up with something that works. I'm quite certain it is mostly due to lack of knowledge but perhaps also is related to the providers working in slightly different ways. Here is what I have so far: - #!/usr/bin/env ruby require File.dirname(__FILE__) + '/../../../spec_helper' provider = Puppet::Type.type(:package).provider(:yum) describe provider do before do # Create a mock resource �...@resource = stub 'resource' # A catch all; no parameters set �...@resource.stubs(:[]).returns nil # We have to set a name, though �...@resource.stubs(:[]).with(:name).returns mypackage �...@resource.stubs(:[]).with(:ensure).returns :installed �...@resource.stubs(:[]).with(:ensure).returns 1.0 �...@provider = provider.new(@resource) �...@provider.stubs(:resource).returns @resource end it should have an install method do �...@provider.should respond_to(:install) end it should be versionable do provider.should be_versionable end it should use erase to purge do �...@provider.expects(:yum).with(-y, :erase, mypackage) �...@provider.purge end describe when installing do it should specify the package version if one is asked for do �...@resource.expects(:name).with(:ensure).returns 1.0 �...@resource.expects(:name) �...@provider.expects(:yum).with(-d, 0, -e, 0, -y, :install, mypackage-1.0) �...@provider.stubs(:yum).returns yum �...@provider.install end end end - My output is as follows: - Puppet::Type::Package::ProviderYum - should have an install method - should be versionable - should use erase to purge Puppet::Type::Package::ProviderYum when installing - should specify the package version if one is asked for (FAILED - 1) 1) Puppet::Error in 'Puppet::Type::Package::ProviderYum when installing should specify the package version if one is asked for' Could not find package ./spec/unit/provider/package/yum.rb:45: /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:22:in `run' /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `each' /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `run' Finished in 0.160654 seconds 4 examples, 1 failure - I guess that I am not pre-setting the correct information in the mocked provider, so that it thinks the relevant package is available to be installed. I previously did not have the @resource.expects(:name) line in the last test, and it complained about an unexpected invocation to Mock#resource.name() which does not make sense to me but then, not much of this does. Some kind soul helped me out last week on the IRC channel and mentioned there may be bugs in the actual provider, but I cannot comment on that. Any input or flames are welcome. Best Regards, Oliver -- 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. -- 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
Re: [Puppet Users] Creating tests for the yum package provider
Hi Oliver, Sorry for taking so long to respond on this. We definitely appreciate the help writing some tests for that patch as it looks like something that would definitely help people once it gets merged in. Writing tests for puppet providers can be tricky, as you're finding. I'll take a look and see where you're running into problems. Hopefully I'll have some help for you by the end of Monday. (note: this is a duplicate of the email I sent to puppet-dev, which is definitely more frequently read by developers who can help out with this kind of stuff) Matt On Mon, Aug 16, 2010 at 4:32 AM, Oliver ohook...@gmail.com wrote: Sorry, but this is a blatant call for help. I'm desperately out of my depth with creating tests due to my lack of experience with just about every component involved. The background is, I'm trying to create the necessary tests to have #2866 accepted. I'm running into problems just getting a basic should specify the package version if one is asked for test running. I've looked through the yum provider code, the other providers, tests for other providers etc but can't seem to come up with something that works. I'm quite certain it is mostly due to lack of knowledge but perhaps also is related to the providers working in slightly different ways. Here is what I have so far: - #!/usr/bin/env ruby require File.dirname(__FILE__) + '/../../../spec_helper' provider = Puppet::Type.type(:package).provider(:yum) describe provider do before do # Create a mock resource �...@resource = stub 'resource' # A catch all; no parameters set �...@resource.stubs(:[]).returns nil # We have to set a name, though �...@resource.stubs(:[]).with(:name).returns mypackage �...@resource.stubs(:[]).with(:ensure).returns :installed �...@resource.stubs(:[]).with(:ensure).returns 1.0 �...@provider = provider.new(@resource) �...@provider.stubs(:resource).returns @resource end it should have an install method do �...@provider.should respond_to(:install) end it should be versionable do provider.should be_versionable end it should use erase to purge do �...@provider.expects(:yum).with(-y, :erase, mypackage) �...@provider.purge end describe when installing do it should specify the package version if one is asked for do �...@resource.expects(:name).with(:ensure).returns 1.0 �...@resource.expects(:name) �...@provider.expects(:yum).with(-d, 0, -e, 0, -y, :install, mypackage-1.0) �...@provider.stubs(:yum).returns yum �...@provider.install end end end - My output is as follows: - Puppet::Type::Package::ProviderYum - should have an install method - should be versionable - should use erase to purge Puppet::Type::Package::ProviderYum when installing - should specify the package version if one is asked for (FAILED - 1) 1) Puppet::Error in 'Puppet::Type::Package::ProviderYum when installing should specify the package version if one is asked for' Could not find package ./spec/unit/provider/package/yum.rb:45: /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:22:in `run' /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `each' /home/ohookins/work/puppet/spec/monkey_patches/add_confine_and_runnable_to_rspec_dsl.rb:17:in `run' Finished in 0.160654 seconds 4 examples, 1 failure - I guess that I am not pre-setting the correct information in the mocked provider, so that it thinks the relevant package is available to be installed. I previously did not have the @resource.expects(:name) line in the last test, and it complained about an unexpected invocation to Mock#resource.name() which does not make sense to me but then, not much of this does. Some kind soul helped me out last week on the IRC channel and mentioned there may be bugs in the actual provider, but I cannot comment on that. Any input or flames are welcome. Best Regards, Oliver -- 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. -- 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] puppet dashboard takes a long time to display
Steven, Thanks for sharing your findings. I've created ticket #4553 to either add some README documentation about this or somehow setup a default for log size. Matt http://projects.puppetlabs.com/issues/4553 On Mon, Aug 16, 2010 at 3:32 PM, Steven L. Seed slseed1...@gmail.com wrote: I found the root cause of my problem. After running of about 1 month using the development environment my log file grew to over 24GB. I had no idea this log file was even there since it's in a less than standard location (/opt/puppet-dashboard/log/development.log). I switched to using the production environment and that initially helped along with purging about 3GB of my report data from the database, but ultimately, the very large log file was impacting things as well. Igal Koshevoy wrote: On 08/04/2010 01:50 PM, Steven L. Seed wrote: I've been noticing my puppet dashboard is taking longer and longer to load up in my we browser the longer I've used it. I have roughly 1300 nodes being managed by puppet. It's almost as if there is too much data for it to process. I have about 1 month worth of data in my mysql database now. I've recently upgraded to version 1.0.3 but it hasn't improved the performance. It's taking typically around 60 - 90 seconds for the page to load...the browser sits waiting for a response from the server. Some things that you can do to make Dashboard run faster: 1. Run it in `production` mode, which is explained further in application's README. 2. Remove older reports from the database, e.g. keep only the last 15 days: `rake RAILS_ENV=production reports:prune upto=15 unit=day` 3. Run the Dashboard and its database on the same machine, and give them enough CPU cycles and RAM to run comfortably. If these don't help, it's likely that you're running into performance problems with how Dashboard is currently implemented. Resolving these issues is a high priority because it affects sites like yours with many nodes and reports and is on the schedule for the next major release. -igal -- 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. -- 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] puppet-dashboard Explorer 8
We weren't aware as none of us are using Internet Explorer. We'll have to have someone get a copy to test with at some point. Can you file a ticket? http://projects.puppetlabs.com Thanks, Matt On Thu, Aug 12, 2010 at 6:40 AM, ScubaDude brett.ma...@googlemail.com wrote: puppet-dashboard on internet exploder 8: Layout borked and no graphs? I was wondering if you were aware of this? -- 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. -- 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] Puppet + OpenVZ
There's a Google Summer of Code student working on a libvirt module for us right now. It's currently alpha stage and only supports Xen and KVM right now, not OpenVZ, but might be worth following the progress or contributing to the code or providing feedback. http://github.com/carlasouza/puppet-virt Matt On Thu, Aug 5, 2010 at 10:24 PM, Yushu Yao yao.yu...@gmail.com wrote: Hi Matt, That look really cool. Are you planning make something similar for libvirt host node? I think libvirt and OpenVZ share the same structure. If the libvirt one is done, it can control OpenVZ and other VMMs On Aug 5, 2010, at 9:48 PM, Matthew Cluver wrote: Hi Everyone, I just wanted to shoot a quick post out there,hope everyone is doing well. I've been searching for people sharing this type of code, and it seemed to be lacking so I decided to jump in. I'm working on developing what would be an openly available module for puppet, to allow for the development and manipulation of virtual containers on OpenVZ host nodes. Here it is on google code: http://code.google.com/p/puppet-openvz/ If you have been working on the same thing and have any code that you'd like to contribute it would certainly be appreciated! Cheers best regards, Matt -- 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. -- 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. -- 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] Re: standalone puppet file source error Could not evaluate: getaddrinfo: ...
If downgrading to 0.25 fixed this, then the problem probably isn't with facter, and as you say, older versions of facter wouldn't have the bug I mentioned. The patch I suggested would only have fixed things if you were running facter from source. So yes, please file a bug report with the info necessary to reproduce this, which it looks like might all be already in your email. Matt On Tue, Aug 3, 2010 at 3:11 AM, bobics bob...@gmail.com wrote: Matt, thanks for the tip. I'm using the lastest facter 1.5.7 gem, I glanced at the code and it doesn't look like that patch applies. Should I not be using the stable version of facter? Looks like 1.5.7 was last updated in 9/2009? :/ On Aug 2, 6:04 pm, Matt Robinson m...@puppetlabs.com wrote: I was seeing similar problems and it had to do with a bug in facter since it wasn't confining a windows fact to windows. Try this patch on your facter: http://github.com/nicklewis/facter/commit/b2c21145885c15abc43b3641fcf... -- 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. -- 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] Re: standalone puppet file source error Could not evaluate: getaddrinfo: ...
I was seeing similar problems and it had to do with a bug in facter since it wasn't confining a windows fact to windows. Try this patch on your facter: http://github.com/nicklewis/facter/commit/b2c21145885c15abc43b3641fcf903e13a859565 On Mon, Aug 2, 2010 at 5:26 PM, bobics bob...@gmail.com wrote: Why is this even calling getaddrinfo in the first place? Puppet is running totally locally. I was considering a workaround using file paths within 'source' but it doesn't seem to like relative paths either. :( -- 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. -- 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.
