[Puppet-dev] How to run tests on custom report parser
I am new to ruby development and want to integrate my report parser with TravisCI. I have read articles and blog posts on how to integrate Puppet modules with rspec, puppet-lint, and travisci but those are not directly applicable to modules that do nothing but provide lib instances (facts, report parsers, etc.) Here is a link to my code on github https://github.com/tracyde/puppet-influxdb-reporter and my puppet forge link https://forge.puppetlabs.com/tracyde/influxdb_reporter The module submits metrics from puppet reports to an InfluxDB database. -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7856672a-bbde-4a4b-af41-99d49f50d4ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: The string to number torture never stops
On 2014-03-11 18:19, John Bollinger wrote: On Friday, October 31, 2014 8:22:36 PM UTC-5, henrik lindberg wrote: [...] Yet again someone was bit by the automatic String to Numeric conversion that is in Puppet (and also in --parser future). I must confess to a certain dark amusement at Puppet struggling with its weak-typing legacy and moving more and more in the direction of strong typing. Not that I am in any way happy about these difficulties, but I'm an old-school dinosaur, and weak typing has never seemed like such a great idea to me. It is never a great idea to have weak / no typing. It is an even worse idea to have all types represented as strings... [...] We fixed PUP-3602 by not converting strings that are floating point 0 with exponential part and we also do not convert values that are floating point infinite in Ruby (e.g. 4e999 and such). This is a crutch though, and it is only a matter of time until someone stumbles over the next SURPRISE ! Indeed so. If you rely on heuristics to choose behavior then you have to accept that sometimes the wrong behavior will be chosen. In this case, it is purely a guess that a string starting with 0e[digit] is not meant to be interpreted as a number. Yes, this was a bit of a panic fix. It really sucks. The best cure is naturally to never do String to numeric conversion. What about numeric to string conversion? I guess Puppet doesn't do that automatically now, so maybe this isn't the time to start, but that /is/ an alternative approach to mixed string/number comparison. True, 4.0.0 will not do numeric to string automatically (because of radix, precision and floating point formatting). I do not see that coming back. And we wonder what people feel about that. Should we go for this in Puppet 4.0.0 (and have a 3.7.4 release as the last of the 3x series where this behavior is implemented when using --parser future). I think avoiding automatic string to numeric conversion is consistent with forbidding bare strings starting with a digit.. Good point. It would be a lot better, though, if in the context of the manifest it were clearer which expressions are strings and which are numeric. That's no problem for literals, of course, but none of this is interesting in the case where all the values involved are literals. I (think I) understand that with the P4 parser and evaluator it will be possible to declare types specifically enough to address that issue, but it is also my understanding that expressions won't /necessarily/ have formal types specific enough for that. It is a bit difficult since operators are overloaded on type. The good part is that if we stop transforming strings to numbers there will be errors for arithmetic expressions. The bad part is that ==, != cannot raise errors (since a string is simply not equal to a number). Currently comparisons order all numbers to be smaller than all strings. We could change those to instead error if the types are not comparable to each other. It is highly desirable to give manifest authors sufficient control over conversions to avoid unwanted ones, but it is not altogether clear to me whether the best approach is to nix all automatic string-to-number conversions. A lot of existing manifests rely on such conversions, since they used to be the only alternative. P4 is at liberty to break backward compatibility, but maybe a little less breakage would be wiser? While I am not so worried about the logic in the manifests themselves. There has not been that many problems reported with respect to the conversion in the other direction. For resource attributes however the situation is worse since there are many types out there where it is unknown how they deal with data types, what sort of munging / processing they do of strings/numbers etc. This would be the primary reason (IMO) to not do this until resource types can type their parameters. (Since typed parameters direct serialization, and there is no longer a question if a serialized 42 should be a number or a string). * Add === operator to compare both type and value. This is a slippery slope since we probably want Integer and Float to compare equal - say 0.0 and 0. It adds yet another operator, and we have to decide what case, selector and in should use since there is no way to specify if one or the other should be used. I agree that as proposed, the '===' operator would be troublesome. There is always the alternative, though, of keeping '==' as it is, and making '===' simply perform a comparison without string/number conversion. I think 'case', selector, and 'in' behavior are collectively a red herring, though: if '===' were adopted in any form then 'case', selector, and 'in' behavior would still be whatever is specified for them, whether that's their current behavior or a variant one based on '==='. There is no requirement that that
Re: [Puppet-dev] Re: The string to number torture never stops
On 11/04/2014 09:46 AM, Henrik Lindberg wrote: It is a bit difficult since operators are overloaded on type. The good part is that if we stop transforming strings to numbers there will be errors for arithmetic expressions. The bad part is that ==, != cannot raise errors (since a string is simply not equal to a number). Currently comparisons order all numbers to be smaller than all strings. We could change those to instead error if the types are not comparable to each other. I think raising an exception when the types of operands to a comparison operator are different is the least surprising behavior absent automatic type conversion. It would also provide at lot more confidence that a manifest is 4x safe if it passes `puppet parser validate`. Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. -Josh -- -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54590CCE.1030305%40cpan.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: The string to number torture never stops
Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. This x 1000. This is an absolute MUST for the release of 4.0 lest we silently alter every system out there (terrifying). Trevor On Tue, Nov 4, 2014 at 5:28 PM, Joshua Hoblitt jhobl...@cpan.org wrote: On 11/04/2014 09:46 AM, Henrik Lindberg wrote: It is a bit difficult since operators are overloaded on type. The good part is that if we stop transforming strings to numbers there will be errors for arithmetic expressions. The bad part is that ==, != cannot raise errors (since a string is simply not equal to a number). Currently comparisons order all numbers to be smaller than all strings. We could change those to instead error if the types are not comparable to each other. I think raising an exception when the types of operands to a comparison operator are different is the least surprising behavior absent automatic type conversion. It would also provide at lot more confidence that a manifest is 4x safe if it passes `puppet parser validate`. Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. -Josh -- -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54590CCE.1030305%40cpan.org. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUGjC%3Dg_Qm%3DQUUtAvuuz4MP7owM4M645P%3DVEmJrhdB34w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] How to run tests on custom report parser
On 4 November 2014 14:32, tracyde trac...@gmail.com wrote: I am new to ruby development and want to integrate my report parser with TravisCI. I have read articles and blog posts on how to integrate Puppet modules with rspec, puppet-lint, and travisci but those are not directly applicable to modules that do nothing but provide lib instances (facts, report parsers, etc.) Here is a link to my code on github https://github.com/tracyde/puppet-influxdb-reporter and my puppet forge link https://forge.puppetlabs.com/tracyde/influxdb_reporter The module submits metrics from puppet reports to an InfluxDB database. Good idea, I'm also pretty interested in InfluxDB. Regarding testing things in lib, ultimately it's just ruby code which is good and bad, in that any rspec tutorial will be useful, but bad in the sense that most won't be specific to Puppet. Hopefully the following is useful. This is a small module of mine (alas not a report processor) that has a test suite: https://github.com/garethr/garethr-digitalocean/tree/master/spec/unit If the InfluxDB client is using HTTP then you can likely do something similar to this with webmock. Gareth -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7856672a-bbde-4a4b-af41-99d49f50d4ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAFi_6yLrh9%2BKQShvgDcCO1EPJpsx-CEbbWJR8Y68Y-jagFF2xg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: The string to number torture never stops
On Tue, Nov 4, 2014 at 9:28 AM, Joshua Hoblitt jhobl...@cpan.org wrote: On 11/04/2014 09:46 AM, Henrik Lindberg wrote: It is a bit difficult since operators are overloaded on type. The good part is that if we stop transforming strings to numbers there will be errors for arithmetic expressions. The bad part is that ==, != cannot raise errors (since a string is simply not equal to a number). Currently comparisons order all numbers to be smaller than all strings. We could change those to instead error if the types are not comparable to each other. I think raising an exception when the types of operands to a comparison operator are different is the least surprising behavior absent automatic type conversion. It would also provide at lot more confidence that a manifest is 4x safe if it passes `puppet parser validate`. Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. The error would have to be at runtime, so puppet parser validate would not uncover these kinds of issues (except perhaps in trivial cases where it could be done). I have an experiment for creating a type inference system, but it is no where near complete enough to be a static type analysis system for puppet 4, and even then it would have to give up in far too many cases without yet more changes to the language. -Josh -- -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54590CCE.1030305%40cpan.org. For more options, visit https://groups.google.com/d/optout. -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - * http://2015.puppetconf.com *Register early to save 40%!* -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXuoq8%2BZW_%2BcqYSsU5cYS7vs%2Be%2B0nxNJZzuU_n%2BHP_p1JA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: The string to number torture never stops
On 2014-04-11 18:28, Joshua Hoblitt wrote: On 11/04/2014 09:46 AM, Henrik Lindberg wrote: It is a bit difficult since operators are overloaded on type. The good part is that if we stop transforming strings to numbers there will be errors for arithmetic expressions. The bad part is that ==, != cannot raise errors (since a string is simply not equal to a number). Currently comparisons order all numbers to be smaller than all strings. We could change those to instead error if the types are not comparable to each other. I think raising an exception when the types of operands to a comparison operator are different is the least surprising behavior absent automatic type conversion. It would also provide at lot more confidence that a manifest is 4x safe if it passes `puppet parser validate`. Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. Remember though, that validation cannot catch results of functions and expressions - since the validation is static, and we cannot really do reasonable quality type inference (at least not yet). - henrik -Josh -- -- Visit my Blog Puppet on the Edge http://puppet-on-the-edge.blogspot.se/ -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/m3bfr7%245j9%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Setting log levels in puppet.conf
Stefan Goethals added the ability to specify puppet's log_level in puppet.conf[1] and it will be available in Puppet 4.0. This was originally redmine ticket #4761, so thank you Stefan for resolving that! I did run into one surprise and wanted to get feedback. If you specify log_level=debug in puppet.conf, and run with `puppet agent --verbose` (or more commonly `puppet agent --test`, which implies `--verbose` and a bunch of other settings), then the agent's log_level will be reset back down to the info level, and you won't get any debug output. To see debug output, you have to execute `puppet agent --test --debug` or specify a lot of the things `--test` implies, but leave out `--verbose`, e.g `puppet agent --no-daemonize --onetime` The problem originates in Puppet::Application#set_log_level if options[:debug] Puppet::Util::Log.level = :debug elsif options[:verbose] Puppet::Util::Log.level = :info end The code assumes that if debug is not specified on the command line, but verbose is, then the log level must be info. If the log level is set to debug in puppet.conf, then this will actually downgrade the logging level to info. We could fix this a few different ways. 1. If --verbose (or --test) is specified, then ensure the log_level is *at least* at the info level 2. Change --test to imply --debug instead of --verbose 3. Something else? Josh [1] https://tickets.puppetlabs.com/browse/PUP-2998 -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/fd36ed20-ad40-433e-81a2-6d419616ddb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Announce: Puppet 3.7.3 available
Puppet 3.7.3 is a bug fix release in the Puppet 3.7 series. It gives Windows users the useful new `$system32` fact (due to packages now pulling in Facter 2.3), and fixes some bugs with directory environments, the `PATH` variable on Windows, and the future parser. It also lays groundwork for some future Puppet Server improvements. To see the Puppet 3.7.3 release page in JIRA: https://tickets.puppetlabs.com/browse/PUP/fixforversion/12001 To follow the list of bugs that are new in this version: https://tickets.puppetlabs.com/issues/?filter=12863 See the release notes for more detail on the changes: http://docs.puppetlabs.com/puppet/3.7/reference/release_notes.html Installation instructions are here: https://docs.puppetlabs.com/guides/install_puppet/pre_install.html Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/B7E96C4B-657D-465B-9023-6B5B50FC6403%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: The string to number torture never stops
On 11/04/2014 01:04 PM, Andy Parker wrote: It would also provide at lot more confidence that a manifest is 4x safe if it passes `puppet parser validate`. Without that you'd have to worry about conditional expressions silently changing their result between 3x and 4x. The error would have to be at runtime, so puppet parser validate would not uncover these kinds of issues (except perhaps in trivial cases where it could be done). I have an experiment for creating a type inference system, but it is no where near complete enough to be a static type analysis system for puppet 4, and even then it would have to give up in far too many cases without yet more changes to the language. Your absolutely right but `puppet master --compile localhost --manifest manifests/role/db.pp` would work. Similarly, rspec-puppet tests would catch an exception from building the catalog even if there isn't coverage of the expression result. Perhaps an option could be added to the parser face to eval expressions? -Josh -- -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5459A314.4000209%40cpan.org. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Setting log levels in puppet.conf
On 2014-11-04 22:46, Josh Cooper wrote: Stefan Goethals added the ability to specify puppet's log_level in puppet.conf[1] and it will be available in Puppet 4.0. This was originally redmine ticket #4761, so thank you Stefan for resolving that! I did run into one surprise and wanted to get feedback. If you specify log_level=debug in puppet.conf, and run with `puppet agent --verbose` (or more commonly `puppet agent --test`, which implies `--verbose` and a bunch of other settings), then the agent's log_level will be reset back down to the info level, and you won't get any debug output. To see debug output, you have to execute `puppet agent --test --debug` or specify a lot of the things `--test` implies, but leave out `--verbose`, e.g `puppet agent --no-daemonize --onetime` The problem originates in Puppet::Application#set_log_level if options[:debug] Puppet::Util::Log.level = :debug elsif options[:verbose] Puppet::Util::Log.level = :info end The code assumes that if debug is not specified on the command line, but verbose is, then the log level must be info. If the log level is set to debug in puppet.conf, then this will actually downgrade the logging level to info. We could fix this a few different ways. 1. If --verbose (or --test) is specified, then ensure the log_level is *at least* at the info level 2. Change --test to imply --debug instead of --verbose 3. Something else? Josh [1] https://tickets.puppetlabs.com/browse/PUP-2998 Commandline options should always trump config file settings for reduced surprise factor. Regards, David -- * Always looking for people I can help with awesome projects * Twitter: @dev_el_ops G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5459C983.1060605%40dasz.at. For more options, visit https://groups.google.com/d/optout.
