Hi all, I''m sure you''re all wondering what the heck is going on with development and why there are so many open tickets. Hopefully this email will answer those questions for you. REST Development =====================First, I''ve found the REST work to be significantly more complicated than I''d feared. The plumbing is nearly all done and the majority of the functionality is now available, but there''s still the painful and lengthy process of converting the internals from using the old xmlrpc- style classes to the newer and much cleaner REST-style classes. Release Status ================Given how long I''ve been out in the wilderness on this, the fact that I don''t know how long this conversion will take, and the rate at which tickets have been piling up, I''ve decided to put off this conversion and do a release instead. Starting today, I''m refocusing on getting 0.24.0 out the door as soon as possible. I''ll have a more complete idea of what''ll be in it by next week, but at this point it''ll include the environment work I did a while back plus as many tickets as I can reasonably fix in the next week or two. This will be the misspiggy release, so by around Monday you should have some idea of what tickets I''m planning on fixing in this release. I''ll probably also create another intermediate release and start assigning tickets to that, which will also include the REST work when I finally get it done. I was initially planning on rolling back to the last known-good state, but in assessing the current state, I don''t think that''s necessary. We''ve mostly gotten plumbing done without hooking it into anything, which means that we would just be releasing the old functionality along-side the new plumbing, which shouldn''t have any affect at all, other than making my life easier. I *really* hope to get this release out in less than two weeks: One week of ticket-closing, and one week of testing. Apparently the git repo is kinda hosed right now, but it''ll be working again by Monday. If you''re in a position to help test, please start testing on Monday. Ticket Management ================I''ve mentioned this a few times, but I''m still looking for help from the community to manage tickets. I appear to have really let the open tickets pile up, and I''m having a hard time keeping on top of the list of unreviewed tickets. If anyone is interested in helping out, this would be a great place to start, and there are tickets ranging from trivially easy to fantastically complicated, so we can find the right challenge for just about anyone. I''ve also been considering putting a bounty on some of the tickets. I''m a bit broke at the moment, but some of the tickets have the right combination of annoyance and simplicity that it might be worth some money to get rid of them. Is anyone interested in this? If so, please email me personally, and, I guess, let me know what it would actually take to get you interested. Would others be interested in putting their own bounty on tickets? Do you have a feature request or bug that''s just killing you that you''d be willing to pay a little or a lot of money to have fixed? Hopefully the same bounty system would work for you. Errata =======This is more Reductive Labs than Puppet, but it''s at least worth pointing out. I''ve recently been joined by two partners, Andrew Shafer and Shane Olson. Neither of them is at the company full time, but hopefully I''ll be able to afford to bring them on full-time soon. My big hope is that their help will allow me to make the product even better for all of you and to develop both Puppet and the tools around it, like PuppetShow and Runnels, with a little more vigour. Conclusion ==============The summary here, of course, is that REST is delayed for a while, but I''m hoping to get a release out relatively soon with the features I''ve already developed (including support for multiple environments) along with any critical open tickets. I''m also still looking for community help in managing tickets, and I''d love someone to help document features as I add them (James Turnbull has been doing a great job of picking my brain and documenting the results, as an example). I should be posting more in the coming days, covering functionality you should expect to see in this release. Feel free to contact me directly if you have any concerns. -- I object to doing things that computers can do. --Olin Shivers --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 25 October 2007, Luke Kanies wrote:> I *really* hope to get this release out in less than two weeks: One > week of ticket-closing, and one week of testing. Apparently the git > repo is kinda hosed right now, but it''ll be working again by Monday. > If you''re in a position to help test, please start testing on Monday.That''s good to hear! My regular tests are already running again on http://puppettests.black.co.at/ The testresults are put into a directory named after the time the test ran. I run the following tests: * rake test, output in /rake_tests * puppetmaster + puppetd on a empty site.pp. config, output and vardir in /minimal * puppetmaster + puppetd on my full configuration. config, output and vardir in /trunk These tests are currently run 06:30 UTC+2, which should be around the end of your workday? Please tell me if you''d like them run more often or at a different time. I even whipped up a little munin plugin which tracks rake test results. http://www.edv-bus.at/munin/black.co.at/git-test.black.co.at-puppettests.html As you said, the git repo currently is a bit off track. Also the tests are run within a vserver container, so some tests (e.g. the mount stuff) will always fail due to missing permissions. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHIZbr/Pp1N6Uzh0URAv4/AJ9whXj1cEqv5f3SW0qNqrYnV1w+hACgoD5F IBj5bLiTWnf8eGc/h8+kI6Y=KveR -----END PGP SIGNATURE-----
On Oct 26, 2007, at 2:27 AM, David Schmitt wrote:> > That''s good to hear! My regular tests are already running again on > > http://puppettests.black.co.at/ > > The testresults are put into a directory named after the time the > test ran. > I run the following tests: > > * rake test, output in /rake_testsYou''re definitely getting failures I''m not getting, at least on Debian. I''ve only got one failure on Debian and none on OS X; I''m about to test my other OSes.> * puppetmaster + puppetd on a empty site.pp. config, output and vardir > in /minimal > > * puppetmaster + puppetd on my full configuration. config, output > and vardir > in /trunkCan we work at getting these tests, at least the minimal one, into the test framework? Otherwise it''s difficult for me to work at reproducing them.> These tests are currently run 06:30 UTC+2, which should be around > the end of > your workday? Please tell me if you''d like them run more often or at a > different time.The time is fine. Now we just need a script that emails failures to puppet-dev (preferably only if the failures are different than the day before). Care to take responsibility for that?> I even whipped up a little munin plugin which tracks rake test > results. > http://www.edv-bus.at/munin/black.co.at/git-test.black.co.at- > puppettests.htmlThat''s pretty darn slick. We really need to set up some kind of autobuild system, preferably backed by multiple OS instances. Maybe something on EC2, with a community member taking responsible for each instance? E.g., have a Solaris image maintained by someone familiar with it, same for Debian, Ubuntu, etc. Anyone want to volunteer to head up this effort? Anyone know much about autobuild systems, especially those that will generate nice graphs like this?> As you said, the git repo currently is a bit off track. Also the > tests are run > within a vserver container, so some tests (e.g. the mount stuff) > will always > fail due to missing permissions.We need to get the tests to the point where they always pass on all systems. If you''ve got tests that never pass, then the tests need to be fixed so they pass or they need to be changed so they aren''t run. Are you in a position to take a crack at your consistently-failing tests? -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [cross-posting/moving to -dev] On Friday 26 October 2007, Luke Kanies wrote:> On Oct 26, 2007, at 2:27 AM, David Schmitt wrote: > > That''s good to hear! My regular tests are already running again on > > > > http://puppettests.black.co.at/ > > > > The testresults are put into a directory named after the time the > > test ran. > > I run the following tests: > > > > * rake test, output in /rake_tests > > You''re definitely getting failures I''m not getting, at least on Debian. > > I''ve only got one failure on Debian and none on OS X; I''m about to > test my other OSes.Hmm. This is running on a pretty clean etch VServer, with only my default configs applied. Actually, its configuration comes from my puppet repo: http://git.black.co.at/?p=manifests.git;a=blob;f=manifests/site.pp;h=d7a265ea397b98b4a9e57de9d960ce4d6ccaf8cd;hb=HEAD#l397 397 node ''git-test.black.co.at'' { 398 399 $mta = ssmtp 400 $nagios_parent = "ic.black.co.at" 401 402 include dbp 403 include puppet::test_from_git::on_debian 404 405 } The class on #403 coming from the module at http://git.black.co.at/?p=manifests.git;a=tree;f=modules/puppet;hb=HEAD I would discourage its use on valueable installations though, it''s pretty rough to all things ruby and puppet when running the tests as well as the rake tests which are not very restrained either. Which already brings me to my first problem when testing from git: I get conflicts with the system''s puppet version: | root@git-test:/tests/puppet-trunk/test# rake test | (in /tests/puppet-trunk/test) | [...] | Could not | autoload "/usr/lib/ruby/1.8/puppet/parser/ast/resourceoverride.rb": | superclass mismatch for class ResourceOverride The testscript thus removes before puppet for the time of the testing. The script runs from cron which cleans most of the environment. running rake test from a shell fixed the cron failure: ./ral/types/cron.rb:467:in `test_default_user'' ENV["USER"] is used, which is empty under cron. I used the Etc.getpwuid function instead. ./ral/providers/service.rb uses "hddtemp" as example service, which is not installed on this host. I changed these tests to use "sysklogd with a pattern. ./ral/types/mount.rb assumes that /etc/fstab contains some mounts. Since mounts cannot be changed from within a vserver, it''d make sense to not run these tests at all on this host. One way to check this would be a non-zero XID: root@git-test:/tests/puppet-trunk# cat /proc/$$/vinfo XID: 5 I could just subtract 3 from the error count too ;) ./executables/puppetd.rb is missing a --no-daemonize With the changes as published in http://git.black.co.at/?p=puppet-testsuite-fixes;a=summary or git://git.black.co.at/puppet-testsuite-fixes the failure count goes down to: 940 tests, 10240 assertions, 3 failures, 0 errors two of which were mount errors and the third: test_period_by_number(TestSchedule) [./ral/types/schedule.rb:218:in `test_period_by_number'' /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in `__send__'' /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in `run'']: matched minus an hour. <false> is not true. which happens probably because local time is 00:40.> > * puppetmaster + puppetd on a empty site.pp. config, output and vardir > > in /minimal > > > > * puppetmaster + puppetd on my full configuration. config, output > > and vardir > > in /trunk > > Can we work at getting these tests, at least the minimal one, into > the test framework? Otherwise it''s difficult for me to work at > reproducing them.I believe the minimal one is a subset of executable/puppetd.rb only run from the command line and implemented in shell.> > These tests are currently run 06:30 UTC+2, which should be around > > the end of > > your workday? Please tell me if you''d like them run more often or at a > > different time. > > The time is fine. Now we just need a script that emails failures to > puppet-dev (preferably only if the failures are different than the > day before). Care to take responsibility for that?Sure. There is currently a full testrun in the works, so I get the output with my fixes to the website. I''ll use that as a testcase. For starters I''ll just use a plain diff and we can work on from there.> > I even whipped up a little munin plugin which tracks rake test > > results. > > http://www.edv-bus.at/munin/black.co.at/git-test.black.co.at- > > puppettests.html > > That''s pretty darn slick.Yeah, munin really rules for this kind of stuff. See http://git.black.co.at/?p=manifests.git;a=blob;f=modules/puppet/files/munin.puppettest for the plugin''s code.> We really need to set up some kind of autobuild system, preferably > backed by multiple OS instances. Maybe something on EC2, with a > community member taking responsible for each instance? E.g., have a > Solaris image maintained by someone familiar with it, same for > Debian, Ubuntu, etc. > > Anyone want to volunteer to head up this effort? Anyone know much > about autobuild systems, especially those that will generate nice > graphs like this?''cuse me, what do you mean by autobuilding? Which functionality/report are you missing? What additional metrics would you like to see? I could try for the runtime of the tests, but that will have a high variance, since there are other services on this machine too ... Just for fun I added lines of code for lib/ and test/ subdirectories to the munin plugin.> > As you said, the git repo currently is a bit off track. Also the > > tests are run > > within a vserver container, so some tests (e.g. the mount stuff) > > will always > > fail due to missing permissions. > > We need to get the tests to the point where they always pass on all > systems. If you''ve got tests that never pass, then the tests need to > be fixed so they pass or they need to be changed so they aren''t run. > > Are you in a position to take a crack at your consistently-failing > tests?The only two still failing due to external reasons are the mount tests, and I''m not really sure how they should be handled. Please advise! Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHInj2/Pp1N6Uzh0URAhFdAJ9fn6yzge2CHBs+4cQB2maMl+bIywCgobJH +f5VPqSXPhd7vTA2H1J0ces=776p -----END PGP SIGNATURE-----
On Oct 26, 2007, at 6:32 PM, David Schmitt wrote:> > Hmm. This is running on a pretty clean etch VServer, with only my > default > configs applied. Actually, its configuration comes from my puppet > repo: > > http://git.black.co.at/?p=manifests.git;a=blob;f=manifests/ > site.pp;h=d7a265ea397b98b4a9e57de9d960ce4d6ccaf8cd;hb=HEAD#l397 > > 397 node ''git-test.black.co.at'' { > 398 > 399 $mta = ssmtp > 400 $nagios_parent = "ic.black.co.at" > 401 > 402 include dbp > 403 include puppet::test_from_git::on_debian > 404 > 405 } > > > The class on #403 coming from the module at > http://git.black.co.at/?p=manifests.git;a=tree;f=modules/ > puppet;hb=HEADI just don''t think I can go through that and figure out what''s broken. I should, but... How can we figure out what the problems are without me poring over your configs?> I would discourage its use on valueable installations though, it''s > pretty > rough to all things ruby and puppet when running the tests as well > as the > rake tests which are not very restrained either. > > Which already brings me to my first problem when testing from git: > I get > conflicts with the system''s puppet version: > > | root@git-test:/tests/puppet-trunk/test# rake test > | (in /tests/puppet-trunk/test) > | [...] > | Could not > | autoload "/usr/lib/ruby/1.8/puppet/parser/ast/resourceoverride.rb": > | superclass mismatch for class ResourceOverride > > The testscript thus removes before puppet for the time of the testing.Didn''t we discuss this? You had an old copy or something?> The script runs from cron which cleans most of the environment. > running rake > test from a shell fixed the cron failure: > > ./ral/types/cron.rb:467:in `test_default_user'' ENV["USER"] is used, > which is > empty under cron. I used the Etc.getpwuid function instead. > > ./ral/providers/service.rb uses "hddtemp" as example service, which > is not > installed on this host. I changed these tests to use "sysklogd with a > pattern. > > ./ral/types/mount.rb assumes that /etc/fstab contains some mounts. > Since > mounts cannot be changed from within a vserver, it''d make sense to > not run > these tests at all on this host.Can you file these as bugs? In general, if a test fails on your system because it''s a bad test, that''s a bug. Please file it, in the ''tests'' component.> One way to check this would be a non-zero XID: > root@git-test:/tests/puppet-trunk# cat /proc/$$/vinfo > XID: 5 > > I could just subtract 3 from the error count too ;) > > > ./executables/puppetd.rb is missing a --no-daemonize--verbose implies it.> With the changes as published in > http://git.black.co.at/?p=puppet-testsuite-fixes;a=summary or > git://git.black.co.at/puppet-testsuite-fixes the failure count goes > down to: > > 940 tests, 10240 assertions, 3 failures, 0 errors > > two of which were mount errors and the third: > > test_period_by_number(TestSchedule) > [./ral/types/schedule.rb:218:in `test_period_by_number'' > /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in > `__send__'' > /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in > `run'']: > matched minus an hour. > <false> is not true. > > which happens probably because local time is 00:40.This is a bad test that I need to fix, and I now know how to using mocks.>> We really need to set up some kind of autobuild system, preferably >> backed by multiple OS instances. Maybe something on EC2, with a >> community member taking responsible for each instance? E.g., have a >> Solaris image maintained by someone familiar with it, same for >> Debian, Ubuntu, etc. >> >> Anyone want to volunteer to head up this effort? Anyone know much >> about autobuild systems, especially those that will generate nice >> graphs like this? > > ''cuse me, what do you mean by autobuilding? Which functionality/ > report are you > missing? What additional metrics would you like to see? I could try > for the > runtime of the tests, but that will have a high variance, since > there are > other services on this machine too ...By autobuilding I really mean autotesting, but across lots of platforms. There are already about 7 platforms that Puppet "supports", and that number is only going to increase. I''d love to have a central reporting server that anyone can report to, and then have most of those platforms running under EC2 or something so that people who aren''t me could maintain an image for testing and have it run the Puppet tests once a day, sending the report to the central server. I''ve got a bunch of vmware images, but I don''t maintain them very well because I don''t really use any of those OSes which means that I don''t know much about best practice on them. I''d really like a platform advocate to take responsibility for at least automated testing on their platform.> Just for fun I added lines of code for lib/ and test/ > subdirectories to the > munin plugin.Cool. Can you publish a link to your stuff on the wiki somewhere?> The only two still failing due to external reasons are the mount > tests, and > I''m not really sure how they should be handled. Please advise!These should be fixed now. -- DOS is the _only_ operating system -- and I''m using that term loosely -- which [exhibits this behavior]. --Aeleen Frisch, "Essential System Administration" --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Nov 9, 2007 9:15 AM, Luke Kanies <luke@madstop.com> wrote:> On Oct 26, 2007, at 6:32 PM, David Schmitt wrote: > > ./executables/puppetd.rb is missing a --no-daemonize > > --verbose implies it.As you need to not daemonize with launchd on Mac clients, it would be nice to have the option to be able to no-daemonize without increasing verbosity. I keep meaning to try and look at writing a patch for this, but am still busy planning the 0.22 to 0.23 upgrade here. -- Nigel Kersten MacOps @ Google "Two kinds of Kool-Aid" _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
This is done in http://reductivelabs.com/trac/puppet/ticket/832, currently marked for the misspiggy release On Nov 9, 2007 9:34 AM, Nigel Kersten <nigelk@google.com> wrote:> > > > On Nov 9, 2007 9:15 AM, Luke Kanies <luke@madstop.com> wrote: > > > > > > On Oct 26, 2007, at 6:32 PM, David Schmitt wrote: > > > > > ./executables/puppetd.rb is missing a --no-daemonize > > > > --verbose implies it. > > As you need to not daemonize with launchd on Mac clients, it would be nice > to have the option to be able to no-daemonize without increasing verbosity. > I keep meaning to try and look at writing a patch for this, but am still > busy planning the 0.22 to 0.23 upgrade here. > > > -- > Nigel Kersten > MacOps @ Google > "Two kinds of Kool-Aid" > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users > >
On Nov 9, 2007, at 11:34 AM, Nigel Kersten wrote:> As you need to not daemonize with launchd on Mac clients, it would > be nice to have the option to be able to no-daemonize without > increasing verbosity. I keep meaning to try and look at writing a > patch for this, but am still busy planning the 0.22 to 0.23 upgrade > here.The current code base actually does this -- it completely decouples verbosity and backgrounding. It''s a behaviour change, in that you specifically need to specify -- no-daemonize even when using --verbose or --debug, but at least it''s there. If people think a behaviour change is bad, speak up now. -- I used to get high on life but lately I''ve built up a resistance. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Just a note For this change the following wiki pages will need to be changed, they specify to use --verbose to keep the daemon in the foreground: http://reductivelabs.com/trac/puppet/wiki/SimplestPuppetInstallRecipe http://reductivelabs.com/trac/puppet/wiki/BranchTesting http://reductivelabs.com/trac/puppet/wiki/PuppetWithLaunchd The following pages don''t explicitly say that --verbose puts the daemon in the foreground but seem to to desire that result: http://reductivelabs.com/trac/puppet/wiki/TestingGuide http://reductivelabs.com/trac/puppet/wiki/InstallationGuide I''ll be happy to make these changes once the release is out. Thanks Brian On Nov 9, 2007 9:43 AM, Luke Kanies <luke@madstop.com> wrote:> On Nov 9, 2007, at 11:34 AM, Nigel Kersten wrote: > > > As you need to not daemonize with launchd on Mac clients, it would > > be nice to have the option to be able to no-daemonize without > > increasing verbosity. I keep meaning to try and look at writing a > > patch for this, but am still busy planning the 0.22 to 0.23 upgrade > > here. > > The current code base actually does this -- it completely decouples > verbosity and backgrounding. > > It''s a behaviour change, in that you specifically need to specify -- > no-daemonize even when using --verbose or --debug, but at least it''s > there. > > If people think a behaviour change is bad, speak up now. > > -- > I used to get high on life but lately I''ve built up a resistance. > > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 November 2007, Luke Kanies wrote:> On Oct 26, 2007, at 6:32 PM, David Schmitt wrote: > > Hmm. This is running on a pretty clean etch VServer, with only my > > default > > configs applied. Actually, its configuration comes from my puppet > > repo: > > > > http://git.black.co.at/?p=manifests.git;a=blob;f=manifests/ > > site.pp;h=d7a265ea397b98b4a9e57de9d960ce4d6ccaf8cd;hb=HEAD#l397 > > > > 397 node ''git-test.black.co.at'' { > > 398 > > 399 $mta = ssmtp > > 400 $nagios_parent = "ic.black.co.at" > > 401 > > 402 include dbp > > 403 include puppet::test_from_git::on_debian > > 404 > > 405 } > > > > > > The class on #403 coming from the module at > > http://git.black.co.at/?p=manifests.git;a=tree;f=modules/ > > puppet;hb=HEAD > > I just don''t think I can go through that and figure out what''s > broken. I should, but... > > How can we figure out what the problems are without me poring over > your configs?It was more a reference than an invitation ;)> > I would discourage its use on valueable installations though, it''s > > pretty > > rough to all things ruby and puppet when running the tests as well > > as the > > rake tests which are not very restrained either. > > > > Which already brings me to my first problem when testing from git: > > I get > > > > conflicts with the system''s puppet version: > > | root@git-test:/tests/puppet-trunk/test# rake test > > | (in /tests/puppet-trunk/test) > > | [...] > > | Could not > > | autoload "/usr/lib/ruby/1.8/puppet/parser/ast/resourceoverride.rb": > > | superclass mismatch for class ResourceOverride > > > > The testscript thus removes before puppet for the time of the testing. > > Didn''t we discuss this? You had an old copy or something?I don''t think we explicitely talked about it, but this is the System installation, I use to manage this VServer. So currently my test scripts do "dpkg --remove puppetmaster puppet" as the first thing and "apt-get install puppet" as the last thing. It seems that this is a bit brittle in reality as the vserver is more often broken than not.> > The script runs from cron which cleans most of the environment. > > running rake > > test from a shell fixed the cron failure: > > > > ./ral/types/cron.rb:467:in `test_default_user'' ENV["USER"] is used, > > which is > > empty under cron. I used the Etc.getpwuid function instead. > > > > ./ral/providers/service.rb uses "hddtemp" as example service, which > > is not > > installed on this host. I changed these tests to use "sysklogd with a > > pattern. > > > > ./ral/types/mount.rb assumes that /etc/fstab contains some mounts. > > Since > > mounts cannot be changed from within a vserver, it''d make sense to > > not run > > these tests at all on this host. > > Can you file these as bugs? > > In general, if a test fails on your system because it''s a bad test, > that''s a bug. Please file it, in the ''tests'' component.Yes, I will file thos as bugs and put the patches into the puppet-bugfixes repo.> > ./executables/puppetd.rb is missing a --no-daemonize > --verbose implies it.Judging from the replies to this, it is already fixed.> > test_period_by_number(TestSchedule) > > [./ral/types/schedule.rb:218:in `test_period_by_number'' > > /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in > > `__send__'' > > /tests/puppet-trunk/test/lib/mocha/test_case_adapter.rb:19:in > > `run'']: > > matched minus an hour. > > <false> is not true. > > > > which happens probably because local time is 00:40. > > This is a bad test that I need to fix, and I now know how to using > mocks.You''ll need a bug report for that too?> >> We really need to set up some kind of autobuild system, preferably > >> backed by multiple OS instances. Maybe something on EC2, with a > >> community member taking responsible for each instance? E.g., have a > >> Solaris image maintained by someone familiar with it, same for > >> Debian, Ubuntu, etc. > >> > >> Anyone want to volunteer to head up this effort? Anyone know much > >> about autobuild systems, especially those that will generate nice > >> graphs like this? > > > > ''cuse me, what do you mean by autobuilding? Which functionality/ > > report are you > > missing? What additional metrics would you like to see? I could try > > for the > > runtime of the tests, but that will have a high variance, since > > there are > > other services on this machine too ... > > By autobuilding I really mean autotesting, but across lots of > platforms. There are already about 7 platforms that Puppet > "supports", and that number is only going to increase. I''d love to > have a central reporting server that anyone can report to, and then > have most of those platforms running under EC2 or something so that > people who aren''t me could maintain an image for testing and have it > run the Puppet tests once a day, sending the report to the central > server. > > I''ve got a bunch of vmware images, but I don''t maintain them very > well because I don''t really use any of those OSes which means that I > don''t know much about best practice on them. I''d really like a > platform advocate to take responsibility for at least automated > testing on their platform.Yes, regular automated tests are very important. I think though that most platforms would benefit from having some kind "platform angel" who is responsible for maintaining the test setup ... To reduce the truck nomber of such a setup, the needed setup modules could be managed somewhere centrally, like a git repo un reductivelabs.com.> > Just for fun I added lines of code for lib/ and test/ > > subdirectories to the > > munin plugin. > > Cool. > > Can you publish a link to your stuff on the wiki somewhere?Yeah, it''s a shame that many people looking at the wiki don''t find their way to my repo. I''m listed on WhosUsingPuppet, but that''s not very notable. Any suggestions? I''d really like to make some kind of formal release of my manifests once my hosting setup is complete, but I kinda get the feeling that "complete" in IT _really_ always means "never" :-/ Suggestions welcome here too...> > The only two still failing due to external reasons are the mount > > tests, and > > I''m not really sure how they should be handled. Please advise! > > These should be fixed now.I''ll check my test vserver again .. seems like it keeled over somehow. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNKBJ/Pp1N6Uzh0URAgUNAKCVteL+iKW5in3jxkQeYXVlrLg2eQCfR55X qbM9XWGKboJUPUpN7jIKKx4=xA0z -----END PGP SIGNATURE-----
On Nov 9, 2007, at 12:00 PM, David Schmitt wrote:>> I''ve got a bunch of vmware images, but I don''t maintain them very >> well because I don''t really use any of those OSes which means that I >> don''t know much about best practice on them. I''d really like a >> platform advocate to take responsibility for at least automated >> testing on their platform. > > Yes, regular automated tests are very important. I think though > that most > platforms would benefit from having some kind "platform angel" who is > responsible for maintaining the test setup ... To reduce the truck > nomber of > such a setup, the needed setup modules could be managed somewhere > centrally, > like a git repo un reductivelabs.com.That''s what I meant by a platform advocate.> Yeah, it''s a shame that many people looking at the wiki don''t find > their way > to my repo. I''m listed on WhosUsingPuppet, but that''s not very > notable. Any > suggestions? I''d really like to make some kind of formal release of my > manifests once my hosting setup is complete, but I kinda get the > feeling > that "complete" in IT _really_ always means "never" :-/ Suggestions > welcome > here too...Feel free to add it to the ToC -- it''s clearly the main example people use. -- Yesterday upon the stair I met a man who wasn''t there. He wasn''t there again today -- I think he''s from the CIA. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Nov 9, 2007, at 11:58 AM, Brian Finney wrote:> Just a note > > For this change the following wiki pages will need to be changed, they > specify to use --verbose to keep the daemon in the foreground: > > http://reductivelabs.com/trac/puppet/wiki/SimplestPuppetInstallRecipe > http://reductivelabs.com/trac/puppet/wiki/BranchTesting > http://reductivelabs.com/trac/puppet/wiki/PuppetWithLaunchd > > The following pages don''t explicitly say that --verbose puts the > daemon in the foreground but seem to to desire that result: > > http://reductivelabs.com/trac/puppet/wiki/TestingGuide > http://reductivelabs.com/trac/puppet/wiki/InstallationGuide > > I''ll be happy to make these changes once the release is out.That''d be great; thanks for tracking this down. So everyone''s ok with the change? -- Ninety-eight percent of the adults in this country are decent, hard-working, honest Americans. It''s the other lousy two percent that get all the publicity. But then--we elected them. --Lily Tomlin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Nov 9, 2007 9:43 AM, Luke Kanies <luke@madstop.com> wrote:> The current code base actually does this -- it completely decouples > verbosity and backgrounding. > > It''s a behaviour change, in that you specifically need to specify -- > no-daemonize even when using --verbose or --debug, but at least it''s > there. > > If people think a behaviour change is bad, speak up now.Decoupling is an excellent idea, and I heartily approve. -- Nigel Kersten MacOps @ Google "Two kinds of Kool-Aid" _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 November 2007, Luke Kanies wrote:> On Nov 9, 2007, at 11:58 AM, Brian Finney wrote: > > Just a note > > > > For this change the following wiki pages will need to be changed, they > > specify to use --verbose to keep the daemon in the foreground: > > > > http://reductivelabs.com/trac/puppet/wiki/SimplestPuppetInstallRecipe > > http://reductivelabs.com/trac/puppet/wiki/BranchTesting > > http://reductivelabs.com/trac/puppet/wiki/PuppetWithLaunchd > > > > The following pages don''t explicitly say that --verbose puts the > > daemon in the foreground but seem to to desire that result: > > > > http://reductivelabs.com/trac/puppet/wiki/TestingGuide > > http://reductivelabs.com/trac/puppet/wiki/InstallationGuide > > > > I''ll be happy to make these changes once the release is out. > > That''d be great; thanks for tracking this down. > > So everyone''s ok with the change?It''ll probably hurt someone somewhere. But the change is neccessary nevertheless, so I''m ok with it. And it''s not like it won''t be obvious what happened. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNK/Q/Pp1N6Uzh0URAoQzAJ9y5DWVvwn1a7Erssq1QyIxtkvt+QCbB11N 937UBbeDfib7Xkq/DcLQSDc=ZHa5 -----END PGP SIGNATURE-----
> So everyone''s ok with the change?As one who''s griped pretty loudly in the past when command line switches and configuration variables change... I''m completely for it. -- Jeff McCune Systems Manager The Ohio State University Department of Mathematics
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 09 November 2007, Luke Kanies wrote:> On Nov 9, 2007, at 12:00 PM, David Schmitt wrote: > >> I''ve got a bunch of vmware images, but I don''t maintain them very > >> well because I don''t really use any of those OSes which means that I > >> don''t know much about best practice on them. I''d really like a > >> platform advocate to take responsibility for at least automated > >> testing on their platform. > > > > Yes, regular automated tests are very important. I think though > > that most > > platforms would benefit from having some kind "platform angel" who is > > responsible for maintaining the test setup ... To reduce the truck > > nomber of > > such a setup, the needed setup modules could be managed somewhere > > centrally, > > like a git repo un reductivelabs.com. > > That''s what I meant by a platform advocate. > > > Yeah, it''s a shame that many people looking at the wiki don''t find > > their way > > to my repo. I''m listed on WhosUsingPuppet, but that''s not very > > notable. Any > > suggestions? I''d really like to make some kind of formal release of my > > manifests once my hosting setup is complete, but I kinda get the > > feeling > > that "complete" in IT _really_ always means "never" :-/ Suggestions > > welcome > > here too... > > Feel free to add it to the ToC -- it''s clearly the main example > people use.Thanks, I did that and added CompleteConfiguration[1] with a list of all my modules and a few code samples. Regards, David [1] http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHNMre/Pp1N6Uzh0URApyvAKCPbcTycDlfIY2xwTU1R0PbbvVmiACdEimb zrjupW8SzuNp0sWFbcKaYio=tvu2 -----END PGP SIGNATURE-----