Jira (PUP-1079) Exported resources is exporting to the database with --noop flag
Title: Message Title Sean Millichamp commented on PUP-1079 Re: Exported resources is exporting to the database with --noop flag I just noticed this issue and wanted to chime in and say I can see value in either behavior. In general, I would prefer -noop runs to not affect the active catalog in PuppetDB for a given node as that is a surprising effect for most users. However, I also frequently use the current behavior of updating the catalog so I can use puppet query to dig through the catalog in PuppetDB to validate that the catalog looks how I would expect (especially in terms of exported resource generation). I suppose I could, as an alternate approach, look at the client's on-disk copy of the catalog on a -noop run instead but the client's copy is typically harder for me to access than the PuppetDB one. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.21413.1387220582000.1424.1673971620023%40Atlassian.JIRA.
Jira (PUP-11685) Total number of fact warning not counting array elements
Title: Message Title Sean Millichamp created an issue Puppet / PUP-11685 Total number of fact warning not counting array elements Issue Type: Bug Affects Versions: PUP 7.20.0 Assignee: Unassigned Created: 2022/12/05 7:18 AM Priority: Normal Reporter: Sean Millichamp The "Total number of facts exceeds" warning generated from https://github.com/puppetlabs/puppet/blob/main/lib/puppet/configurer.rb#L190 seems to incorrectly count the total number of facts. A fact which returns a Hash containing hashes (Hash[String, Hash]) will result in each hash entry being counted. A fact which returns an Array of Hashes, say (Array[Hash[String, Scalar]), will result in each element in the array being counted. However, an array consisting of scalar entries (Array[Scalar]) will only count as one fact entry. This behavior seems inconsistent, a bit confusing and nowhere have I found clear documentation on exactly what should count toward the maximum fact count nor the optimal data structure to use if we just can't avoid returning a very large number of structured elements (e.g. is it an Array[Hash], a Hash[String, Hash], something else? or maybe there is no significant difference?) If the fact check is either overcounting (Hashes in Arrays) or undercounting (Scalars in Arrays) then it should be corrected. If the current behavior is correct then it would be great to get some documentation on what is "good" and what is "bad" for very large facts. Thanks!
Jira (PUP-11666) Resources type should be marked as "apply_to_all"
Title: Message Title Sean Millichamp commented on PUP-11666 Re: Resources type should be marked as "apply_to_all" I put up a PR for this: https://github.com/puppetlabs/puppet/pull/8941 Thanks! Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.473621.1666963942000.53762.1666964040033%40Atlassian.JIRA.
Jira (PUP-11666) Resources type should be marked as "apply_to_all"
Title: Message Title Sean Millichamp created an issue Puppet / PUP-11666 Resources type should be marked as "apply_to_all" Issue Type: Improvement Affects Versions: PUP 7.20.0 Assignee: Unassigned Components: Types and Providers Created: 2022/10/28 6:32 AM Priority: Normal Reporter: Sean Millichamp The resources resource type works as is in both host and device mode, but right now it can't be used to manage device resources because it hasn't been marked as "apply_to_all". Marking it as "apply_to_all" enables it to be used to purge device resources without troubles. Add Comment
Jira (PUP-11663) max/min core functions are incorrect for Semver types
Title: Message Title Sean Millichamp created an issue Puppet / PUP-11663 max/min core functions are incorrect for Semver types Issue Type: Improvement Affects Versions: PUP 7.20.0 Assignee: Henrik Lindberg Components: Functions Created: 2022/10/25 11:39 AM Priority: Normal Reporter: Sean Millichamp The Puppet max/min functions do not handle Semver types correctly. The "Any" data type function signature matches, they are converted to strings, compare as strings, and are often incorrect. Based on the spec tests for max/min it looks to be explicitly called out behavior, which I assume it means that it can't change until a new major Puppet version: https://github.com/puppetlabs/puppet/blob/main/spec/unit/functions/max_spec.rb#L77 It would be great if min/max would support all the applicable data types in their native/correct fashion. At least Semver, Timestamp, and Timespan should all be added and the deprecated Any behavior removed. Add Comment
Jira (PUP-11446) Facts returning nil are converted to empty string
Title: Message Title
Sean Millichamp commented on PUP-11446
Re: Facts returning nil are converted to empty string
josh To be clear, what I observed and reported doesn't seem to be a facter issue. In fact, interestingly, facter by itself seem to have the inverse behavior as to what I saw versus when the facts are presented in Puppet. Given two Ruby facts, one simple fact which returns "nil" and one which returns a hash containing a single key with a nil value you get these results with the facter CLI:
facter --version 3.14.17 (commit ce1f2bb4a91a1ac4ae5852091c96ae6ee3712e23)
facter -p --json mysimplefact mystructuredfact { "mysimplefact": "", "mystructuredfact": { "mykey": null } }
Facter does the correct thing with the structured fact, but turns the simple fact nil value into a string. Now, those same Facts as presented by Puppet: Notice: mystructuredfact: {"mykey":""} Notice: mysimplefact: null Notice: mysimplefact is key in facts hash: false The value of the structured fact key is now the empty string, the simple fact value is now null, and on top of that the fact doesn't even get added to the $facts hash. The behavior I think we should have is that the data types returned by Facter should be preserved when used in Puppet. I think that a fact which returns nil as its only value should continue to not be present in the facts hash. At the very least, the behavior should be consistent between Puppet and Facter. You can see the quick module I put together for the above testing here: https://github.com/seanmil/facttest As an aside to this issue, Puppet type system support in facts would be awesome!
Add Comment
This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d)
Jira (PUP-11446) Facts returning nil are converted to empty string
Title: Message Title Sean Millichamp created an issue Puppet / PUP-11446 Facts returning nil are converted to empty string Issue Type: Bug Assignee: Unassigned Created: 2022/02/02 12:15 PM Priority: Normal Reporter: Sean Millichamp In sanitize_facts null fact results are not preserved. With the modern data type support Puppet can and should properly preserve null values returned in fact data OR, at least, remove the fact from the data entirely so a reference to it, as an undefined key, returns undef. I understand that this would likely need to be done on a major version change, but I just wasted hours trying to figure out why my undef-expecting code was not behaving as intended. Add Comment This
Jira (PUP-4647) Yum provider uses rpm -e to uninstall packages
Title: Message Title Sean Millichamp commented on PUP-4647 Re: Yum provider uses rpm -e to uninstall packages I just came across this ticket and I wanted to add the the documentation specific to the yum provider documents (and has for years) that ensure => absent will not remove dependent packages. For better or for worse, this is a behavior that I have come to rely on as a default for safety reasons, opting to use ensure => purged only when I have done more extensive testing to validate that it is safe and necessary for a particular package. Latest yum provider docs: https://puppet.com/docs/puppet/7/types/package.html#package-provider-yum All the way back to 5.5: https://puppet.com/docs/puppet/5.5/types/package.html I would very much like if Puppet was able to batch up a series of packages and run an "rpm -e" with the whole set, but I realize the current resource/provider design makes that challenging. When I need to remove a cyclical dependency then I opt into ensure => purged or, if I don't want to risk unknown/unexpected dependencies from being also removed, I'll use an exec. Not the most elegant, but it suffices. If this behavior does change, I'm not exactly opposed, but it definitely would need to be on a major version as I'd have to reassess every package resource in my environment where I might use absent so I could explicitly specify the rpm provider. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to
Jira (PUP-8373) Lookup CLI should use RBAC token if available for PuppetDB
Title: Message Title Sean Millichamp commented on PUP-8373 Re: Lookup CLI should use RBAC token if available for PuppetDB I saw a flurry of `puppet lookup` related ticket updates and went to look to see if there was an issue in for this, only to find out that I had put one in! To Michael Smith's suggestion for a new gem opportunity, Voxpupuli has puppetdb gem (to which I added token support quite a which back). It consults `/etc/puppetlabs/client-tools/puppetdb.conf` and `/.puppetlabs/client-tools/puppetdb.conf` to find the path to the CA cert and `/.puppetlabs/token` for the PE RBAC token. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.231894.1516392104000.40944.1587125760091%40Atlassian.JIRA.
Jira (PUP-7428) Implement knockout prefix for unique lookups
Title: Message Title Sean Millichamp commented on PUP-7428 Re: Implement knockout prefix for unique lookups I just encountered the brokenness with knockout_prefix in Hiera's deep merge. I understand that might be a tricky problem to fix, but adding knockout_prefix to Hiera's unique lookup would be relatively easy code. Since Eric Sorenson asked for use-cases above, I was trying to implement a "feature_flag" Hiera setting, implemented as an array of strings. I wanted to be able to list the feature flags but also to negate them as an earlier (more specific) Hiera level, in this case to opt out a small set of customers (who are currently in an extended change freeze) from what would be an otherwise global change on a particular platform type. The deep merge knockout_prefix appeared to work in simple testing, but it is a good thing I did a final full-catalog compile test with octocatalog-diff and caught the problem or I would have ended up violating the customers' change freezes. I ended up whipping up a quick Ruby function applied in the module after Hiera APL that still allowed me to use Hiera's unique merge and get the knockout feature flag behavior for the final set of enabled feature flags, but it would be much cleaner if it were just an option in Hiera's unique merge itself. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PUP-9407) Don't backup to the local filebucket by default
Title: Message Title Sean Millichamp commented on PUP-9407 Re: Don't backup to the local filebucket by default Chris Denneen I would say it is most definitely not okay to remove until/unless there is a suitable replacement. I'm fine having it disabled by default, but our ops folks depend on being able to quickly see/recover files overwritten by Puppet. I'll grant it isn't super easy to use (with the checksums, etc.) but in this case something is better than nothing. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.291105.154707498.24048.1573217820192%40Atlassian.JIRA.
Jira (PDOC-295) Add support for @enum tag
Title: Message Title Sean Millichamp commented on PDOC-295 Re: Add support for @enum tag A PR which I believe implements this correctly is up here for consideration: https://github.com/puppetlabs/puppet-strings/pull/215 Thanks! Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.330991.1571580412000.8564.1571580540040%40Atlassian.JIRA.
Jira (PDOC-295) Add support for @enum tag
Title: Message Title Sean Millichamp created an issue Puppet Strings / PDOC-295 Add support for @enum tag Issue Type: New Feature Assignee: Unassigned Created: 2019/10/20 7:06 AM Priority: Normal Reporter: Sean Millichamp Puppet Strings currently supports, via YARD, the ability to add extended documentation to a parameter which expects a hash to document the various keys expected using the @option tag. This is quite useful. Parameters that are of the Puppet Enum type would also benefit from this type of extended option documentation. However, the @option tag is not suitable as it expects a data type to be provided, which makes no sense in the context of an Enum. You can put an arbitrary value as the datatype, but it results in a poor user experience for both the person documenting and the person reading the documentation. Instead I propose adding a new tag, @enum, that behaves similarly to @option but does not expect a data type to be passed and renders the results accordingly (but otherwise similarly to @option). Add Comment
Jira (FACT-2004) cloud fact does not detect Azure with NetworkManager
Title: Message Title Sean Millichamp created an issue Facter / FACT-2004 cloud fact does not detect Azure with NetworkManager Issue Type: Bug Assignee: Unassigned Created: 2019/08/29 5:35 AM Priority: Normal Reporter: Sean Millichamp EL7 using NetworkManager on Azure does not report the cloud fact, even though it should. On EL7 platforms using NetworkManager the dhclient lease file is not in the location where Facter is looking for it /var/lib/dhcp/dhclient.eth0.leases from https://github.com/puppetlabs/facter/blob/master/lib/inc/internal/facts/linux/virtualization_resolver.hpp#L37 If NetworkManager is in use the file instead needs to be looked for in /var/lib/NetworkManager/dhclient--eth0.lease. The code would need to search both locations for matches similarly to here: https://github.com/puppetlabs/facter/blob/master/lib/src/facts/bsd/networking_resolver.cc#L136-L169 Thank you. Add Comment
Jira (PUP-9943) User type has custom retrieve() with non-standard return values
Title: Message Title Sean Millichamp commented on PUP-9943 Re: User type has custom retrieve() with non-standard return values I have put up a proposed PR to address this issue: https://github.com/puppetlabs/puppet/pull/7664 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.320115.1565272699000.48529.1565292180100%40Atlassian.JIRA.
Jira (PUP-9943) User type has custom retrieve() with non-standard return values
Title: Message Title Sean Millichamp commented on PUP-9943 Re: User type has custom retrieve() with non-standard return values As an additional note: It appears that the Puppet::Type.retrieve_resource() method was perhaps designed as a work-around to this particular problem. However, it is marked as a private API. https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L1122-L1136 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.320115.1565272699000.48039.1565277060102%40Atlassian.JIRA.
Jira (PUP-9943) User type has custom retrieve() with non-standard return values
Title: Message Title Sean Millichamp created an issue Puppet / PUP-9943 User type has custom retrieve() with non-standard return values Issue Type: Bug Affects Versions: PUP 6.7.2, PUP 5.5.16 Assignee: Unassigned Components: Types and Providers Created: 2019/08/08 6:58 AM Priority: Normal Reporter: Sean Millichamp The core user type has a custom retrieve() method which returns a Hash that is inconsistent with the data type returned by the common method in Puppet::Type.retrieve(). As a result, mechanisms expecting to use retrieve() will have problems with user resources. Here is the offending code in the user type: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/user.rb#L496-L513 I think it may be safe and desirable to just remove the user type's retrieve block and let the standard one take effect. The existing retrieve method seems to be 10+ years old and may just be an artifact of a much earlier time in Puppet's life. Regardless if the method is needed or not, it should have a return value consistent with the expected return value from the standard Puppet::Type.retrieve() method.
Jira (PUP-9647) Pip package provider does not handle pip executable paths with spaces
Title: Message Title Sean Millichamp updated an issue Puppet / PUP-9647 Pip package provider does not handle pip executable paths with spaces Change By: Sean Millichamp Summary: Pip package provider should use execute for Windows compatibility does not handle pip executable paths with spaces Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.305257.133562000.63270.1561638780375%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9647) Pip package provider should use execute for Windows compatibility
Title: Message Title
Sean Millichamp commented on PUP-9647
Re: Pip package provider should use execute for Windows compatibility
I dig a bit more digging around. I believe this is the output I'm getting which is causing the version match to fail: 'C:/Program' is not recognized as an internal or external command, {{ operable program or batch file.}} The actual path (as returned by Puppet::Util.which('pip.exe')) is "C:/Program Files/Python35/Scripts/pip.exe" It looks like the command returned needs to have double-quotes around it for it to work properly on Windows, and the double quotes don't seem to negatively affect running it on Linux.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.305257.133562000.63034.1561595400293%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1412) 'script run' CLI silently ignores arguments containing equal signs
Title: Message Title Sean Millichamp created an issue Puppet Task Runner / BOLT-1412 'script run' CLI silently ignores arguments containing equal signs Issue Type: Bug Affects Versions: BOLT 1.23.0 Assignee: Unassigned Components: CLI Created: 2019/06/20 6:35 AM Priority: Normal Reporter: Sean Millichamp When trying to run an adhoc script I discovered that the Bolt CLI seems to silently consume and ignore arguments passed intended to be used with a "script run". These should be valid arguments to pass. In this case, I was trying to pass a LDAP DN, which had a number of equal signs. You can see the CLI option vanish when running bolt in debug mode: bolt script run myscript.sh string1 a=b string2 -n testnode ... Starting: script myscript.sh on testnode Running script myscript.sh with '["string1", "string2"]' on ["testnode"] ... Displaying the contents of ARGV confirms the argument with the equal sign was never received by the script. Invoking the run_script function from within a Bolt plan does not suffer from the same issue, leading me to believe it is a problem with the CLI parsing somewhere. Thanks!
Jira (PDOC-254) @hiera section for putting example hiera
Title: Message Title Sean Millichamp commented on PDOC-254 Re: @hiera section for putting example hiera In my perfect world I'd like @lookup (and yes, you're right, a much better name than @hiera) to look and work more or less exactly like @param, near/in the param section. But maybe just auto-tagged with a "Not available as a class parameter" type message. I don't like the re-including all the @param docs again, it seems unnecessarily verbose bordering on confusing for a class with a very large set of parameters. Even with a @lookup tag, I still feel that there is a need for an additional @example-style tag for YAML-syntax highlighted groups of keys for specific use cases and complex behaviors requiring setting multiple keys to achieve specific results. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.252028.1526935563000.34851.1559738400478%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-280) Rake Task for coverage
Title: Message Title Sean Millichamp commented on PDOC-280 Re: Rake Task for coverage I think this would be great, but I'd like to suggest that it to flag puppet-strings warnings of any kind, not just coverage. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.311289.1559727679000.34801.1559733420204%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-254) @hiera section for putting example hiera
Title: Message Title Sean Millichamp commented on PDOC-254 Re: @hiera section for putting example hiera I like the idea of a @hiera tag. Though making the example syntax style configurable might be more flexible. I actually think that there may be two Hiera-related opportunities here: 1) Documenting keys which are used in lookup() calls which aren't class parameters similar to the style of "@param". Maybe the data type could even be sussed out of the lookup() call parameters, if listed. 2) Documenting example Hiera YAML blocks as they would look in the file. This would be more in keeping with the @example tag. To Henrik Lindberg's question, I'd like to think the value of #1 is self-evident. From a user standpoint "lookup()" only based keys are still parameters which are part of the interface. For #2 most of my day-to-day user base is very familiar with making changes in Hiera/YAML, but they are not as familiar (in some cases, not at all) with Puppet class syntax and examples shown in Puppet class parameter declaration style wouldn't be nearly as meaningful/useful to them. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit
Jira (PUP-9647) Pip package provider should use execute for Windows compatibility
Title: Message Title Sean Millichamp commented on PUP-9647 Re: Pip package provider should use execute for Windows compatibility I have pushed a rebase required due to recent changes in the provider to https://github.com/puppetlabs/puppet/pull/7488 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.305257.133562000.31062.1559395800566%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9647) Pip package provider should use execute for Windows compatibility
Title: Message Title Sean Millichamp commented on PUP-9647 Re: Pip package provider should use execute for Windows compatibility I have created two PRs which seem to resolve the issue: against master: https://github.com/puppetlabs/puppet/pull/7487 against 5.5.x: https://github.com/puppetlabs/puppet/pull/7488 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9647) Pip package provider should use execute for Windows compatibility
Title: Message Title Sean Millichamp created an issue Puppet / PUP-9647 Pip package provider should use execute for Windows compatibility Issue Type: Bug Affects Versions: PUP 6.4.0, PUP 5.5.10 Assignee: Unassigned Components: Types and Providers Created: 2019/04/17 1:39 PM Priority: Normal Reporter: Sean Millichamp The package pip provider has some suggestion of Windows support. However, it uses "execpipe" to invoke commands, which puts a shell redirection of "2>&1" into the final command which is not compatible with Windows. On a Windows system with Python installed when the "pip_version" method is called it results in an error: "Cannot collect packages for Puppet::Type::Package::ProviderPip3 provider; undefined method `[]' for nil:NilClass" Reworking this in terms of execute allows the pip provider to work on Windows as well. Add Comment
Jira (BOLT-126) Support WinRM with Kerberos
Title: Message Title Sean Millichamp commented on BOLT-126 Re: Support WinRM with Kerberos Sorry forgot to include the link, the new PR is here: https://github.com/puppetlabs/bolt/pull/950 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-126) Support WinRM with Kerberos
Title: Message Title Sean Millichamp commented on BOLT-126 Re: Support WinRM with Kerberos I put up a new PR based on Michael Smith's PR from January 2018 adjusted for the latest Bolt. It allows me to use a locally obtained Kerberos ticket on Linux to connect via WinRM with Kerberos to a target Windows system. I can confirm the inconsistent run results Michael Smith reported, I did a few sets of 100 runs and got approximately 10% failure. I understand the desire to not want to merge this when the behavior isn't consistent, but 10% failure is better than 100% failure. Also, I spent a while looking at this today and I believe it to be likely some error with the Kerberos decryption in WinRM. It seems to be similar to or the same as the issue here: https://github.com/WinRb/WinRM/issues/161 Open question: are we trying to enable transparent login from Windows nodes in a domain to other Windows nodes in that domain, or users getting a Kerberos ticket and using it to login to Windows domain nodes from heterogeneous sources? Those are going to be completely separate to implement. Our use case is we have a large number of completely disconnected domains with systems we need to WinRM into. Each domain has its own security policy and some of them only allow WinRM using Kerberos. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this
Jira (PUP-9561) puppet language functions are 11,350x slower than ruby functions
Title: Message Title Sean Millichamp commented on PUP-9561 Re: puppet language functions are 11,350x slower than ruby functions Thanks for the suggestions. Given that I can't use group_by yet (on 5.5) I'll probably stick with the Ruby I'm using, but Henrik's suggestions were clever and interesting to read. Would you mind clarifying what part of the original is responsible for the exponential running time? Is it the last line in the reduce that merges the results? Is that because each time through the loop requires allocating a new hash and copying all of the elements in the previous hash, before doing the merge? I believe that is a fairly common pattern I use in reduce, often to manipulate a data structure I can't otherwise modify (such as in an each construct, for example) because of immutable variables. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-864) Always upload code from bolt when running a task via Orchestrator
Title: Message Title Sean Millichamp commented on BOLT-864 Re: Always upload code from bolt when running a task via Orchestrator Please don't make this an "always" behavior. It should be an option, definitely. I have use cases where users can run tasks on certain targets, but only if those tasks have been peer-approved, tagged, and released to production. Just because they have restrictions from a compliance standpoint doesn't mean they don't want to be able to use the Bolt CLI. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9390) Static catalogs match multiple environment paths incorrectly
Title: Message Title Sean Millichamp created an issue Puppet / PUP-9390 Static catalogs match multiple environment paths incorrectly Issue Type: Bug Affects Versions: PUP 6.1.0, PUP 5.5.8 Assignee: Unassigned Components: Compiler Created: 2019/01/02 7:22 AM Priority: Normal Reporter: Sean Millichamp When using an environmentpath setting with multiple colon-separated paths specified, static catalog compilation does not correctly identify the environment path of the environment being compiled and therefore incorrectly concludes that no file is ever eligible for inlined metadata. See https://github.com/puppetlabs/puppet/blob/master/lib/puppet/indirector/catalog/compiler.rb#L173 and, from 5.5.x, the same line here: https://github.com/puppetlabs/puppet/blob/5.5.x/lib/puppet/indirector/catalog/compiler.rb#L173 The line in question assumes that there will only ever be a single environmentpath specified. Instead it should use the environmentpath entry which is associated with the environment name being compiled (which was presumably determined considerably earlier in the compilation).
Jira (PUP-9254) Agent Functions - add eval() function
Title: Message Title Sean Millichamp commented on PUP-9254 Re: Agent Functions - add eval() function Eric Sorenson I was one of the users in one of the chats Henrik Lindberg had about this. I haven't started using Deferred yet (since we're on 2018) so I don't currently have something blocking waiting on eval, but I believe one of the discussions basically led to eval() as the best solution (sorry, I can't recall the particulars). Regardless, I like having options and having access to more than just string return values seems like something that should definitely be possible. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9305) Built-in unique function behaves differently with undef
Title: Message Title Sean Millichamp commented on PUP-9305 Re: Built-in unique function behaves differently with undef Just wanted to add my $0.02: I wish more of the stdlib functions handled types more strictly than they have and I think the behavior of the core unique makes a lot more sense. If I call unique on something I expect that it will be an array. If it is not an array then I probably haven't handled something correctly earlier in the code (either a bug or failed to validate input correctly) and I would want it to raise an error. Please don't change the core unique behavior as added in Puppet 5. It is the right direction for the language/platform. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9304) Puppet::Util::Execution.execute does not have binary-safe stdinfile support
Title: Message Title Sean Millichamp created an issue Puppet / PUP-9304 Puppet::Util::Execution.execute does not have binary-safe stdinfile support Issue Type: Bug Assignee: Unassigned Created: 2018/11/07 10:56 AM Priority: Normal Reporter: Sean Millichamp While working on a patch to address SERVER-2167 I was trying to pass binary data on stdin to a command (gpg) run by Puppet::Util::Execution.execute using the stdinfile option. GPG was returning errors indicating the input data was corrupted so I did some digging. I believe that the 'r' in this line https://github.com/puppetlabs/puppet/blob/d4348e02c5eba0222d400ab0883f53cc8e2a086f/lib/puppet/util/execution.rb#L199 should be 'rb' to indicate to Ruby that the encoding should be treated as ASCII-8BIT instead of the default (in my environment UTF-8). It should be safe to pass binary data in via execute's stdinfile option and if the current behavior cannot be changed then there should be an option which indicates that stdinfile should be treated as binary data. In this instance, I was able to work around the issue by passing the file directly to gpg as a command line argument instead of using stdinfile (and it worked), but it may not be possible to do that in every use case. My testing was within Puppetserver in PE 2018.1.3. Add Comment
Jira (PUP-8002) "Attempt to redefine entity" caused by using a resource collector
Title: Message Title Sean Millichamp commented on PUP-8002 Re: "Attempt to redefine entity" caused by using a resource collector Eric Sorenson I tried your patch in the above PR on a single compile master and I went from a consistent average of around 10 "Puppet Could not autoload" error messages per hour to zero over the last 90 minutes it was running. I think it is a safe bet to say that your patch has fixed the issue. Now, what is the chance we could get that also backported into Puppet 5.x for an upcoming LTS PE release? Thank you! Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8002) "Attempt to redefine entity" caused by using a resource collector
Title: Message Title Sean Millichamp commented on PUP-8002 Re: "Attempt to redefine entity" caused by using a resource collector Attaching generated pcore file for ini_setting.ppper Eric Sorenson's request. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8002) "Attempt to redefine entity" caused by using a resource collector
Title: Message Title Sean Millichamp updated an issue Puppet / PUP-8002 "Attempt to redefine entity" caused by using a resource collector Change By: Sean Millichamp Attachment: ini_setting.pp Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-266) Getting "unexpected construct regexp_literal" when using resource API title_patterns
Title: Message Title Sean Millichamp commented on PDOC-266 Re: Getting "unexpected construct regexp_literal" when using resource API title_patterns No reason I have. Here is a PR: https://github.com/puppetlabs/puppet-strings/pull/189 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-266) Getting "unexpected construct regexp_literal" when using resource API title_patterns
Title: Message Title Sean Millichamp commented on PDOC-266 Re: Getting "unexpected construct regexp_literal" when using resource API title_patterns Sure, here it is: https://github.com/seanmil/puppet-strings/commit/c0165422d677d0f861d6e889e3cc27f8cb109978 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-266) Getting "unexpected construct regexp_literal" when using resource API title_patterns
Title: Message Title Sean Millichamp commented on PDOC-266 Re: Getting "unexpected construct regexp_literal" when using resource API title_patterns It breaks doc generation for the type containing title_patterns - nothing is generated. The other types generate okay. In order to try to ensure comprehensive documentation on everything that we release we do default our pipeline to prohibiting anything though where Strings reports any warnings or any missing coverage (classes, parameters, etc.), but we also have a toggle to enable docs with failures to continue though so I can work around that. I did fiddle around with Strings enough to get a patch that has it continue without any warning, but I wasn't sure if it was a valid approach or not so I stopped working on it. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDOC-266) Getting "unexpected construct regexp_literal" when using resource API title_patterns
Title: Message Title Sean Millichamp created an issue Puppet Strings / PDOC-266 Getting "unexpected construct regexp_literal" when using resource API title_patterns Issue Type: Bug Assignee: Unassigned Created: 2018/09/12 2:26 PM Priority: Normal Reporter: Sean Millichamp When running Puppet Strings against a type/provider that uses the `title_parameters` option in the Resource API I get this message: [warn]: in PuppetStrings::Yard::Handlers::Ruby::RsapiHandler: Undocumentable unexpected construct regexp_literal at lib/puppet/type/mytype.rb:5 I've narrowed it down to not liking the `title_patterns` parameter and, in particular, the regex value in it. Add Comment This message was sent by
Jira (PUP-9077) Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Title: Message Title Sean Millichamp commented on PUP-9077 Re: Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function Sorry, I don't mean to be a pain here but I feel like I'm reading two different things here. "Functions such as to_yaml, and to_json etc. must deal with the idiosyncrasies of 3.x and must understand what to do with Ruby symbol :undef." and "3.x functions are not well documented and there is no real specification." Even if both of those are true, they can't be entirely mutually exclusive. Even if the only idiosyncrasy of 3.x that 4.x functions have to deal with is :undef would that alone not be worth documenting in the document as something 4.x function writers must handle (or at least be aware of) ? How is someone coming at this new to the ecosystem, but having to deal with output from all the 3.x functions still out there (there are still many in stdlib, if nothing else) supposed to know the rules of engagement here? And there are at least some known 3.x behaviors, even if there isn't a formal specification, such as: undef passed in as a top-level scalar will be converted to '' undef passed in as a value in a Hash or Array will be converted to :undef :undef returned to Puppet will be correctly treated as Puppet undef, but also passed as :undef to any later 4.x functions. Which feel like they would be prudent to document in the 3.x section, and then also a mention in the 4.x section about the possibility of handling :undef incoming - and any other known possible weirdness that could be incoming from 3.x functions. So far :undef is the only one I've encountered (that I know of). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9077) Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Title: Message Title Sean Millichamp commented on PUP-9077 Re: Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function Thanks for the quick reply. Disappointing, but understandable. That said, I've been writing Puppet functions for many years, and it came as a surprise to me that :undef from 3.x functions would be correctly handled by Puppet but wouldn't be automatically handled as nil inputs to 4.x functions. As far as I can see, the documentation makes no mention of that anywhere (I'm referring to the docs at https://puppet.com/docs/puppet/5.5/functions_ruby_overview.html ). In fact, those docs specifically state that undef will be handled as nil on the Ruby side. The legacy 3.x function docs seem to gloss-over data types entirely. If we are going to have to continue to handle the 3.x function baggage even when working within 4.x functions then could we get the docs updated with comprehensive coverage in both the legacy and 4.x function documentation sections clearly outlining the expectations in terms of inputs/outputs and what needs to be handled? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9077) Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Title: Message Title Sean Millichamp commented on PUP-9077 Re: Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function I have just attached a reproducer. It should be run with a recent stdlib in the module path. I was using 4.25.1. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9077) Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Title: Message Title Sean Millichamp updated an issue Puppet / PUP-9077 Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function Change By: Sean Millichamp Attachment: pup_9077.tar.gz Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9077) Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Title: Message Title
Sean Millichamp created an issue
Puppet / PUP-9077
Inconsistent undef value received by 4.x API Ruby functions after touched by 3.x Ruby function
Issue Type:
Bug
Affects Versions:
PUP 5.5.3
Assignee:
Unassigned
Created:
2018/08/21 7:31 AM
Priority:
Normal
Reporter:
Sean Millichamp
While trying to use the Stdlib function to_yaml() I believe I have discovered a bug in how Puppet handles data returned from Ruby 3.x API functions versions when passed into 4.x Ruby functions. It is easiest to explain with a reproducer. Give this code, where func3() and func4() are just Ruby API 3.x and 4.x functions respectively that each just return the value they were passed:
$orig_hash = {
'mykey'=> undef,
'otherkey' => 'test',
}
Jira (FACT-1874) Environment variable-supplied facts should be resolved prior to confines
Title: Message Title Sean Millichamp created an issue Facter / FACT-1874 Environment variable-supplied facts should be resolved prior to confines Issue Type: Improvement Affects Versions: FACT 3.11.3 Assignee: Unassigned Created: 2018/08/10 2:13 PM Priority: Normal Reporter: Sean Millichamp When testing another issue I discovered that facts supplied as environment variables are evaluated after confines, and therefore can't be used to override/supply a value for a confine based on a fact. Given a fact in envfact/myfact.rb: Facter.add(:myfact) do confine matchfact: 'matches' setcode do "fact results" end
Jira (FACT-1873) Custom facts that aren't suitable should not override built-in facts
Title: Message Title
Sean Millichamp created an issue
Facter / FACT-1873
Custom facts that aren't suitable should not override built-in facts
Issue Type:
Improvement
Affects Versions:
FACT 3.11.3
Assignee:
Unassigned
Created:
2018/08/10 1:59 PM
Priority:
Normal
Reporter:
Sean Millichamp
As a user of Facter, I would expect that a custom fact, with weight > 0, and with confines which have it result in being not suitable for the current system should not replace the built-in fact with an empty result. Or, put more generally, I would expect facter to pick the highest weighted fact available from the set of facts where the confines return success. Example with a fact in myfacts/custom.rb:
Facter.add(:timezone) do
has_weight 10
confine { File.exist?('/tmp/fact_trigger') }
setcode do
Jira (FACT-1872) dmi.product.uuid should return the system UUID on Windows
Title: Message Title Sean Millichamp created an issue Facter / FACT-1872 dmi.product.uuid should return the system UUID on Windows Issue Type: Improvement Affects Versions: FACT 3.11.3 Assignee: Unassigned Created: 2018/08/07 2:31 PM Priority: Normal Reporter: Sean Millichamp On Linux the dmi.product.uuid fact returns a UUID of the system. This value is not provided by Facter for Windows systems, but it is available and should be returned as it is often an important unique identifier for the system. It is available as the 'UUID' property on the WMI ComputerSystemProduct class (which is already accessed for retrieving the dmi.product.name fact). Add Comment
Jira (PUP-8373) Lookup CLI should use RBAC token if available for PuppetDB
Title: Message Title Sean Millichamp commented on PUP-8373 Re: Lookup CLI should use RBAC token if available for PuppetDB In my implementation I'm reading the global puppet-query configuration file as well as the per-user configuration file (/.puppetlabs/client-tools/puppetdb.conf) and I'm currently only using the per-user token file in /.puppetlabs/token, though I can't rule out that I might want to use something in, say, a CI job where I'd want to pass a token path somehow. But I'm not tackling that for this first version I'm working on. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8373) Lookup CLI should use RBAC token if available for PuppetDB
Title: Message Title Sean Millichamp commented on PUP-8373 Re: Lookup CLI should use RBAC token if available for PuppetDB I am in the process of implementing a custom internal facts indirector for PuppetDB with RBAC along with a custom version of "lookup" to basically solve this for our site and as part of this there are a couple of more aspects to it that I hadn't considered originally. My overarching outcome from getting this ticket implemented as I originally outlined was so that any non-root user could invoke "puppet lookup" with a RBAC token granting them access to PuppetDB (which as a non-root user they of course otherwise wouldn't have even on a Puppetmaster due to lack of permissions on the node's private key), pointed to an environment with a hiera configuration they could read so that the values would be correctly interpolated and resolved as they would during a root-based "puppet lookup". However, in addition to the token I found that I needed a PuppetDB configuration as well. As a non-root user it was trying to read my configurations from ~/.puppetlabs/etc/puppet. In my setup I have ended up looking for and reading the same configuration files that the pe-client-tools uses. Setting configuration per-user in ~/.puppetlabs/etc/puppet and leveraging the normal Puppet PuppetDB indirector configuration was a non-starter, the command needed to just work for an arbitrary user on the system with a token. While just implementing support for the PE RBAC token would be a step in the right direction, I'm not sure how it would be useful without also providing support for more of the whole end-to-end I've described. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-8556) environment.conf modulepath should accept globs
Title: Message Title Sean Millichamp commented on PUP-8556 Re: environment.conf modulepath should accept globs The scenario we have is a set of modules that are organized on the filesystem like so: groups//modules In our scenario, "" happens to be customer, but I could see something similar using other groupings depending on organizational need. Today we solve this problem by jamming symlink creation into the end of our Puppetfile that collects all the module names (using Dir.glob) and puts symlinks to them from a single, otherwise empty, directory (which is specified in environment.conf). We've been doing this for 5+ years but there are a couple of problems with it: Every time users create a new module in this area in their "live" testing environments, they have to remember to manually create the symlinks (something which is otherwise done automatically for them when the testing environment is spun up). Since they don't do it all the time, it is frequently a source of confusion. The symlinks to/through directories do not work with the Code Manager / Static Catalogs combination. Access to file resources (e.g. with source => 'puppet:///modules/modulename') in these modules is not possible with static catalogs enabled - so despite our efforts to enable them we have been unable to use them so far. There are some organizational reasons why the above directory structure has some considerable advantages for us, and why having to know and list all the possible group/customer directories in environment.conf is a non-starter - unless we started generating environment.conf as part of our Puppetfile instead of generating symlinks, but then we still have the user awareness issue when creating new customer module areas. Though I can't see it, I'm told that PE-20305 contains information about the symlink / code manager / static catalogs bug and support cases #25081 and #28894 contain maybe a bit more detail about our particular use case. Add Comment
Jira (PUP-8556) environment.conf modulepath should accept globs
Title: Message Title Sean Millichamp commented on PUP-8556 Re: environment.conf modulepath should accept globs I have posted a PR which I believe addresses this issue. https://github.com/puppetlabs/puppet/pull/6746 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8556) environment.conf modulepath should accept globs
Title: Message Title Sean Millichamp created an issue Puppet / PUP-8556 environment.conf modulepath should accept globs Issue Type: Improvement Assignee: Unassigned Components: Platform Created: 2018/03/16 11:35 AM Priority: Normal Reporter: Sean Millichamp The "modulepath" parameter in environment.conf should support the use of globs in the path specification, but currently does not. The use of globs allows somewhat elegant solutions to problems not found in environments which require something more complex than a standard Puppet environment layout and workflow. Add Comment
Jira (PDOC-91) Strings should be able to document an environment
Title: Message Title Sean Millichamp commented on PDOC-91 Re: Strings should be able to document an environment We use strings to generate whole-environment documentation as part of a CI job when we release updates to environments and serve it out via GitLab pages from our internal GitLab instance. It works fairly well, but there are some improvements that would make it a lot better (particularly for our Puppet "end-users" that work mostly with Hiera data and not the code). Independent per-module docs are far less useful for us. Key improvements that would directly and noticeably improve the end user experience in my environment (with regards to documentation): Ability to handle any README.md optionally found in each module, and somehow make them available/visible in the whole-environment view. Possibly related to the above, a module-level/centric search/list view in the left pane. Documentation support for custom data types. Links from custom data types used in parameter documentation to the place where the custom data type is documented. Documentation for facts The ability to distinguish a fact as having a stable "API" vs. an unstable one (or, "public" vs. "private"). While all facts are obviously always visible and usable from a technology standpoint, it would be good to clearly communicate expectations around whether the fact was intended for broader consumption (e.g. in external reporting) or only was intended for internal use in the module. A type of "index page" where all class parameters are all collected and shown in one place so people can look to see if options are exposed to do something, even if they might not be familiar with what module it would found in or exactly what it would be called. I know some of these require some more fundamental things to be addressed in Strings (e.g. fact documentation) but I wanted to not only be clear that there is definitely a valid use case for this but also some of the key things that feel lacking to make it a more complete end-user experience. That said, the Strings documentation we do enjoy now is great, far better than what we ever had with the old rdoc system (when it worked) and still provides a lot of value to our end users, so thank you for the work thus far on it.
Jira (PUP-8373) Lookup CLI should use RBAC token if available for PuppetDB
Title: Message Title Sean Millichamp commented on PUP-8373 Re: Lookup CLI should use RBAC token if available for PuppetDB It would be super great if the location of the token file could be specified. I looked for a puppet.conf option for it, but of course there wasn't one. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8373) Lookup CLI should use RBAC token if available for PuppetDB
Title: Message Title Sean Millichamp created an issue Puppet / PUP-8373 Lookup CLI should use RBAC token if available for PuppetDB Issue Type: Bug Assignee: Thomas Hallgren Components: Hiera & Lookup, PuppetDB Created: 2018/01/19 12:01 PM Priority: Normal Reporter: Sean Millichamp In order to facilitate use of the CLI puppet lookup by non-root users who want to perform a lookup in terms of a particular node without having to have a fully-trusted and PuppetDB-whitelisted certificate, it would be great if lookup would look for and use any PE RBAC tokens to obtain access when getting the facts from PuppetDB. Add Comment
Jira (PUP-8341) Lookup interpolation on alias to missing key should return not found
Title: Message Title Sean Millichamp commented on PUP-8341 Re: Lookup interpolation on alias to missing key should return not found I understand the concerns about preserving backwards compatible behavior, but it is certainly surprising behavior for someone using the function for the first time. The documentation at https://puppet.com/docs/puppet/5.3/hiera_merging.html#alias doesn't outright address the issue of missing keys but certainly leaves one with the impression that the alias function will basically provide a 1:1 key name remap behavior. If you don't want to change the behavior of alias I'd like to suggest that the documentation be clarified as to the behavior with missing keys. Also, I'd like to suggest that a similar function (maybe remap_key) be supplied at part of Puppet that does preserve identical behavior, and if not part of Puppet then it seems reasonable for inclusion in stdlib. I have put up a PR with a clarifying note here: https://github.com/puppetlabs/puppet-docs/pull/832 I certainly can create my own function to do this, but it feels like a common enough pattern to want to remap key names that having a standard function people can use that doesn't have any surprising behaviors in it would be beneficial. Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8341) Lookup interpolation on alias to missing key should return not found
Title: Message Title Sean Millichamp created an issue Puppet / PUP-8341 Lookup interpolation on alias to missing key should return not found Issue Type: Bug Affects Versions: PUP 5.3.3 Assignee: Thomas Hallgren Components: Hiera & Lookup Created: 2018/01/10 11:55 AM Priority: Normal Reporter: Sean Millichamp The Hiera interpolation function alias returns an empty string if the key referenced for lookup is not found. In order to preserve the intent of alias and its usefulness in re-mapping key names in lookups it should return a not found condition like a direct lookup of a missing Hiera key would, and not an empty string. For example, given: ---
Jira (FACT-1782) Facter.flush not working as expected in Facter 3.x
Title: Message Title Sean Millichamp created an issue Facter / FACT-1782 Facter.flush not working as expected in Facter 3.x Issue Type: Bug Affects Versions: FACT 3.6.6 Assignee: Unassigned Created: 2017/10/19 9:12 AM Priority: Normal Reporter: Sean Millichamp Calling Facter.flush to clear out resolved values during unit testing does not seem to work in Facter 3.6. Facter.clear does, but then affects the ability to get correct coverage reports from tools like SimpleCov, as Facter.clear reloads the entire fact, not just clearing the value. I have put a very simple reproducer here: https://github.com/seanmil/facter_flush_reproducer If you run it initially with Facter 3.6.6 two of the tests fail, due to Facter.flush not clearing out a previously resolved value from the prior test run. If you then uncomment gem 'facter' from the Gemfile and re-run it with Facter 2.5.1 available all tests pass, showing Facter.flush working as expected. Add Comment
Jira (PUP-7761) New users with null passwords not created correctly
Title: Message Title Sean Millichamp commented on PUP-7761 Re: New users with null passwords not created correctly I have a PR to address this: https://github.com/puppetlabs/puppet/pull/6053 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7761) New users with null passwords not created correctly
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7761 New users with null passwords not created correctly Issue Type: Bug Affects Versions: PUP 4.10.4 Assignee: Unassigned Components: Types and Providers Created: 2017/07/07 5:50 AM Environment: Platforms using the useradd and libuser providers. Priority: Minor Reporter: Sean Millichamp When using Puppet in a Beaker acceptance test to configure a user with a null password (in order to later test to ensure that null passwords would not be permitted to authenticate) I discovered a bug in Puppet when creating users with null passwords. Given a manifest like:
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title Sean Millichamp commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Erik Dalén Sean Millichamp when compiling the catalog on a host you essentially only have the facts for that host as input, and those same facts can be queried from another host using some puppetdb query function. I've reviewed our code exploring the idea of using only non-exported resources data from PuppetDB to generate and I don't think we could use just node facts for ANY of our use cases. All of them are also influenced in some small or large part by input from Hiera (again, in the context of the node exporting the resource). Now, you could take that data, write it out as facts, and then read it that way when those facts are then read in on the next run. But that introduces a whole new set of problems: you are now trusting the facts the client reports (which in some use cases may not be sufficient), you are making data available on the system and in PuppetDB fact queries which may not be information you want generally available, and - worst of all - it now takes two client runs to get the data in PuppetDB for use. Henrik Lindberg's idea of a key/value store as a substitute/replacement for exported resources would probably be workable. In fact, you can approximate the requirements with exported resources as they are now. If you create a defined type which has parameters but no code and export it you have essentially a basic data export/import process suitable for retrieval and import-side processing with puppetdbquery functions. Whatever key/value store was implemented to replace exported resources would still have to follow the basic rule that it was not committed to the store (presumably this would be PuppetDB) unless the catalog compile was successful. If this store also allowed you to - during the same catalog compile - read back any values already stored into it (even though they hadn't been committed yet) then this would also allow you to replace much of the virtual resource workflow too. The one scenario which sticks out in my mind that this hypothetical key/value store would not let you do is replicate the virtual resource use case where you can realize resources which haven't been processed by the compiler yet. I know there is this feeling that you should be able to wave your hands and fix ordering issues - and in theory I agree. However, in a complex environment with a lot of profile-level code that is being provided to uses who - by and large - don't maintain it, don't read it, and don't particularly want to dig into it, adding additional ordering requirements does ratchet up the required knowledge level on those users as to rules on how to interact with that code. The property of virtual resources where the order in which you realize it does not matter versus where you declare the resource is quite valuable to smooth and ease the user experience in larger and complex environments where you have a wide range of Puppet skill levels involved. As far as using APL/lookup as the way to import the resources / key/value store data. This might be a convenient approach in some cases, but I would certainly still want a way to retrieve from that key/value store in a fashion that wasn't able to be overridden from the normal hierarchy resolution structure by users of that data. And to Henrik Lindberg's assertion that the problem is that exported resources work on resources I have actually always seen that has generally a good thing.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title Sean Millichamp commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Eric Sorenson To Erik Dalén's point, it is possible to work around a removal of the exported resource feature by digging through the facts for a host and performing all of the logic on the "collection" side of the compile using the facts from the host that you would have done on the "export" side, and then do all of that logic in terms of the results of the fact query - but why? We already have a context in which code and data are evaluated in terms of the "export" side - the Puppet compile of the agent which would have exported it! For very simple cases of logic perhaps it doesn't matter too much, but when you are dealing with many layers of conditionals and complex logic to arrive at what would be the exported resource I think it is far more cleaner and sensible to do those operations in the actual compiling context of the system the resource is being generated for. In terms of introspection into your environment, I think there is value in being able to ask "show me all of the resources associated with node foo". In some cases, I'm not quite as interested as where those resources are being applied as I am in seeing which node they are related to. True, this could probably be solved with tagging - but the current system is quite elegant in this regard. In terms of error handling: consider the scenario where you have some bad input or some other conditional occurring for which you might fail the catalog compile. In terms of a single node, a catalog compile is unfortunate, but only impacts that node. If all of that logic is moved to the device/node where the resources are acted upon now you are left with the choice of failing the whole catalog - thus impacting every single node relying on that catalog run - or opting for some soft failure condition which might include leaving out the resource (and who knows what the impact of that might be?) Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You
Jira (PUP-4806) Add a variable with the chosen environmentpath
Title: Message Title Sean Millichamp commented on PUP-4806 Re: Add a variable with the chosen environmentpath I had opened the now closed-as-duplicate PUP-3041 requesting the same thing. I also have some code which tries to ascertain which of multiple different path entries in environmentpath the currently compiling environment ended up coming from. Just a suggestion that perhaps having a name of environmentdir as an exposed value when there is already a Puppet setting called environmentpath might be a touch confusing. Maybe call it something like current_environment_dir ? For as little as it is likely to be used in code it might make sense to be a bit wordier for clarity. Otherwise, sounds good. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7541) Remove export / collect / virtual / realize syntax
Title: Message Title Sean Millichamp commented on PUP-7541 Re: Remove export / collect / virtual / realize syntax This raises a lot of alarm / concern for me as a customer/user. As it stands, I'm not a big fan of this idea - though I'm willing to be convinced. How would we declare the equivalent of exported resources on host A that should never be on host A but are only intended for some other host where they are realized? We use that pattern quite a bit. Or, put another way, how would we get resources into PuppetDB without having them declared on the host without the exported resources syntax? I'll agree that the use-case that Henrik brought up with the virtual collect is less needed these days, but it still can be quite useful. Consider having to adhere to a particular security policy that says "/path/to/file" has to be 0600 instead of 0644 and the mode is buried in some module - or not set at all. Right now tweaking that value is a pretty trivial operation at the end of the compile. We also use the virtual resources quite a bit to allow resources to be essentially conditionally declared in various spots around our code and then decide in one spot if and how those resources will be realized. These may seem like with better design you could avoid needing them - and that may be true - but unfortunately things aren't always able to be that tidy. Not a fan of this plan. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7485) Top-scope Puppet function behavior is inconsistent with documentation
Title: Message Title Sean Millichamp updated an issue Puppet / PUP-7485 Top-scope Puppet function behavior is inconsistent with documentation I have attached a simple test case which can be run from the directory it was uncompressed in with: puppet apply pup-7485/mytest.pp --modulepath pup-7485/modules/ Change By: Sean Millichamp Attachment: pup-7485-testcase.tar.gz Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7485) Top-scope Puppet function behavior is inconsistent with documentation
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7485 Top-scope Puppet function behavior is inconsistent with documentation Issue Type: Bug Affects Versions: PUP 4.10.0 Assignee: Unassigned Components: Language Created: 2017/04/30 6:48 AM Priority: Normal Reporter: Sean Millichamp Per https://docs.puppet.com/puppet/4.10/lang_write_functions_in_puppet.html it is possible to write Puppet-language functions in the main manifest (top-scope). The warning in the documentation indicates that the behavior, as with other top-scope items, would be to have the function accessible to all modules. However, if you define a function in the main manifest and then try to call it from a module you will receive an error such as: "Error: Evaluation Error: Unknown function: 'testfunc'". It works fine when called from the main manifest. Calling it with the leading "::" indicating top-scope has no change in behavior. The expected behavior is that top-scope Puppet language functions would work per the documentation and similarly to their Ruby counterparts.
Jira (PUP-7401) Aliased types are not indistinguishable from the original type
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7401 Aliased types are not indistinguishable from the original type Issue Type: Bug Affects Versions: PUP 5.0.0 Assignee: Unassigned Components: Language Created: 2017/03/28 5:58 AM Priority: Normal Reporter: Sean Millichamp I stumbled across a behavior relating to aliased data types which seems inconsistent with the documentation / specification. Per https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md#type-aliases "An aliased type is indistinguishable from the original type." I believe I have found at least one instance where that is not so. Example 1: enum.pp
Jira (PUP-7201) Additional certificate attributes should be exposed in trusted hash
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7201 Additional certificate attributes should be exposed in trusted hash Issue Type: New Feature Assignee: Unassigned Components: Platform Created: 2017/02/10 8:43 AM Priority: Normal Reporter: Sean Millichamp The $trusted hash should contain additional certificate attributes. At a minimum 'not_after' and 'not_before' but others such as 'serial' and 'signature_algorithm' might also be useful. Possible use cases for 'not_before' and 'not_after': Examine the 'not_before' date and generate warnings or failures during catalog compilation if required trusted certificate extensions are not present. This allows adding checks for hard extension requirements while allowing backwards compatibility / support for certificates issued prior to a certain time. Examine the 'not_after' date and generate warnings to the user during a Puppet run about an impending client certificate expiration. The times should be stored in something easily machine-consumable or convertable (such as integer values in Unix time).
Jira (PUP-7181) Add function support to defined()
Title: Message Title Sean Millichamp commented on PUP-7181 Re: Add function support to defined() A "find_function" approach would be great too. Good point about function signatures. For my purpose I was assuming that the signatures would not be an issue. The motivation is that we have some early manifest bootstrapping logic which can (and does) vary per customer. Traditionally we have baked that all into one massive case statement in a single class that is the first thing we load. This had the downside of being difficult to maintain, test, manage, and certainly not nimble enough for others (less familiar with the code) to contribute new logic for new customers in a timely manner. I am currently reworking this logic to instead allow a Puppet language function to be written outside of the core module and then have which function gets called (via `call`) using a configurable setting (typically via a lookup in Hiera). This would permit the team to craft and deploy a custom function for a new customer in a rush situation outside of the change control process our core (versioned) code is required to follow. My thinking here was to check for the existence of the requested function and, if not found, either soft-fail (allow the catalog run to complete, raise an error via Notify, but skip most of the processing) or hard fail with an error that would provide additional help/site-specific direction to the user. Definitely in the "nice to have" category rather than required for this use case. Also, in my situation the most likely spot where these functions would appear won't be in versioned modules (either via git tag or a metadata.json-supplied version) so in this case I actually couldn't check for either. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving
Jira (PUP-7181) Add function support to defined()
Title: Message Title
Sean Millichamp created an issue
Puppet / PUP-7181
Add function support to defined()
Issue Type:
New Feature
Assignee:
Unassigned
Components:
Language
Created:
2017/02/06 4:24 AM
Priority:
Normal
Reporter:
Sean Millichamp
The defined() function should be able to see if a given function name is defined for both Ruby and Puppet Language functions.
Example:
defined('digest()')
defined('mod::func()')
Jira (PUP-7174) Add a 'call' function to Puppet built-in functions
Title: Message Title Sean Millichamp commented on PUP-7174 Re: Add a 'call' function to Puppet built-in functions I have submitted a PR at https://github.com/puppetlabs/puppet/pull/5609 which implements much of this functionality. However, note that there is one spec test failing because it can't find / call Puppet language functions. I believe that this is perhaps a bug in call_function, but wasn't sure how to diagnose it further. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7174) Add a 'call' function to Puppet built-in functions
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7174 Add a 'call' function to Puppet built-in functions Issue Type: New Feature Affects Versions: PUP 5.0.0 Assignee: Unassigned Components: Language Created: 2017/02/03 10:17 AM Priority: Normal Reporter: Sean Millichamp The Puppet built-in functions should include a 'call' function, allowing both native Ruby functions and Puppet language functions to be invoked with a variable reference. Example: $a = 'notice' call($a, 'a message')
Jira (PUP-7127) metadata.json specification provides no allowance for proprietary modules
Title: Message Title Sean Millichamp created an issue Puppet / PUP-7127 metadata.json specification provides no allowance for proprietary modules Issue Type: Bug Assignee: Unassigned Components: Modules Created: 2017/01/23 4:23 AM Priority: Normal Reporter: Sean Millichamp Per the documentation at https://docs.puppet.com/puppet/latest/modules_metadata.html, which is the most formal specification I could find for metadata.json, the "license" key is required and should match a license at "SPDX". However, limiting options to the SPDX list provides no ability to note a module as "Proprietary" or "Commercial" or some other form of non-open source license. In the past, this wasn't so important when metadata.json was really only used by the Forge - proprietary modules wouldn't be published there. However, with the addition of "data_provider" this file now has a functional impact within the code base. Given the specification at the link above, the linting tool metadata-json-lint correctly produces an error when either the "license" key is not specified or when the "license" key is specified but not specified with a value matching one of the licenses at spdx.org. The "license" key should either be made optional OR (preferably) expanded to include a value such as "Proprietary", "Commercial", "Restricted", or something similar as allowable in addition to the spdx.org values. Thank you.
Jira (HI-547) Unable to use 'nil' in backend to force default
Title: Message Title
Sean Millichamp updated an issue
Hiera / HI-547
Unable to use 'nil' in backend to force default
Change By:
Sean Millichamp
In older versions of Hiera you could use a nil in the backend to force the Hiera default to be selected.For example, given the simple Hierarchy:{code}---:hierarchy: - 'data/host' - 'data/common'{code}And data/common with:{{my_var: 'global val'}}You could use in data/host :{{my_var: ~}}And Hiera would return the specified default value back to Puppet. This would allow the intentional "unsetting" of a particular key in Hiera for a small set of hosts that otherwise received more global Hiera-based settings.This used to work in Hiera and was usable from Puppet with {{hiera('my_key', 'a default')}}Now, Hiera (arguably more correctly) returns the found value nil, but Puppet doesn't fall back to the default, it instead raises an error and aborts the catalog compilation.This breaks a small but important bit of flexibility in Hiera.
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (HI-547) Unable to use 'nil' in backend to force default
Title: Message Title Sean Millichamp created an issue Hiera / HI-547 Unable to use 'nil' in backend to force default Issue Type: Bug Affects Versions: HI 3.2.1 Assignee: Unassigned Created: 2016/12/13 10:50 AM Priority: Normal Reporter: Sean Millichamp In older versions of Hiera you could use a nil in the backend to force the Hiera default to be selected. For example, given the simple Hierarchy: --- :hierarchy: - 'data/host'
Jira (PUP-1913) Puppet user resource should respect the forcelocal option
Title: Message Title Sean Millichamp commented on PUP-1913 Re: Puppet user resource should respect the forcelocal option Unless I am misunderstanding something, user enumeration via the provider instances method (used by the resource type for purging, for example) is invoked at a point where the forcelocal option won't be seen/honored, even if set as a global resource default. So, focusing on forcelocal really misses a large part of this. The real fix needs to be in instances and how the users are enumerated. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4370) Formalize Types and Providers API
Title: Message Title Sean Millichamp commented on PUP-4370 Re: Formalize Types and Providers API I like what I've read so far and agree with Trevor's suggestions. Here are some additional items: Preserve the generate function I mention this because it isn't often used, but very useful and hadn't seen it mentioned yet. Support provider-level configuration options Example: the user LDAP provider has puppet.conf-level config options, it would be nice to have these types of options specifiable directly in the DSL (perhaps in a fashion similar to resource defaults) and defined within the type and/or provider that needs them. This would be particularly useful to be able to specify the file/path used in the instances method to support the resource type's purging behavior of non-default paths Provide hooks for initialize/finalize methods to be called once before and once after all resource instances are synchronized. To enable provider-wide one time preparation / cleanup actions. Also just off the top of my head from some of the pain I've had in the past. I'll give it some additional thought. Add Comment
Jira (PUP-3041) Expose actual environment path to scope in DSL
Title: Message Title Sean Millichamp created an issue Puppet / PUP-3041 Expose actual environment path to scope in DSL Issue Type: Improvement Affects Versions: 3.6.2 Assignee: Andy Parker Components: Server Created: 09/Aug/14 3:17 PM Priority: Normal Reporter: Sean Millichamp The new directory environment support is slick BUT one big problem is that there is no really good way to discover from within a catalog compile what the base path to the environment you are in is. It would be great if there was something akin to $settings::my_environment_path exposed into the scope available to the DSL which adjusted to the root of whatever environment was currently being compiled. This would be useful for things like the extdata() and file() functions, and possibly even in use as a crutch in hiera.yaml until per-environment Hiera configuration files are properly supported. For old-style environments I think it would be fair to return 'undef' since the idea of an environment root didn't really exist. Thanks!
Jira (PDB-16) Store status for reports
Title: Message Title Sean Millichamp updated an issue PuppetDB / PDB-16 Store status for reports Change By: Sean Millichamp Werecentlylearnedthatwhenapuppetrunfailsduetocatalogcompilationerrororcatalogtimeout,theagentwillsubmitareportwithastatusof`failed`,butwithoutanyevents.BecausethecurrentimplementationofreportstorageinPuppetDBreliesentirelyoneventstoindicatesuccess/failure,thereisnowaytolookatthePuppetDBdataanddeterminewhetherornotthesereportsrepresentsuccessesorfailures.Toalleviatethis,wewillprobablyneedtoextendtheschemaforthereportstabletoincludeastatusfield.Myproposalisthatweaddtwonewcolumnswhicharebothbasicallyenums:1.`status`:success/failure2.`failure_cause`:catalog/resource/...?(ThisiscoveredbyPDB-36)Burgundyneedsawaytoqueryforfailuresthatwerespecificallycausedbycatalogissues.Wediscussedtheideaofjustaddingasingle`status`column,andhavingtheenumerationthereinencapsulatethedifferencebetweenthevarioustypesoffailures...however,itseemsmoregenerallyusefultome(forthird-partyintegrators/OSSusers)toallowthestatus(success/failure)andthefailurecause(catalogvsresource)tobequeriedindependently. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-536) Create endpoint for enumerating environments
Title: Message Title Sean Millichamp commented on an issue Re: Create endpoint for enumerating environments So, I know there has been lots of discussion on this, but we have a dynamic environments use case that is perhaps a little more sophisticated than some I've seen discussed out in the wild and I thought I'd share. In both cases the problem can (currently) be solved with a bunch of symlink work in the various check-out and management scripts. Two things I'd love to see are: 1) Specifying a multiple environment base search path (like you can do today with modulepath). We have two distinct types of environment: fully managed via git checkouts (via an internal librarian-puppet/r10k type script) and adhoc (created on a developer whim to quickly mock something up and then be destroyed). In order to accomodate Puppet's dynamic environment implementation today we make them appear at one place via a bunch of symlinks into a common directory but that seems gross and needless and, when developers manually remove their adhoc environment without the toolset we've provided to do so it leaves broken symlinks. Again, we could have a script that looks for and removes them, but an environment base search path seems so much cleaner. 2) The ability not only to specify a module search path external to the environment (e.g.: /opt/puppet/share/puppet/modules) but also a module search path internal to the environment. I mention this because it wasn't clear to me if all of the discussed approaches would support that. This is, of course, possible today but it wasn't clear to me if/how a directory-based environment design would support that. We have two major categories of modules. Our managed modules are designed, reviewed, tested, versioned by the Puppet team. Each gets its own Git repo and has reasonably high standards. The others can be more or less created by our Puppet users (the OS engineers), committed, and become live with no Puppet team involvement - the use case is primarily for deploying things that are one-off and particular for a given customer that we don't intend to reuse OR which have to go from nothing to deployed rapidly. This gives a modulepath of: modulepath=/path/to/environmentbase/$environment/coremodules:/opt/puppet/share/puppet/modules:/path/to/environmentbase/$environment/modules The nice thing with this configuration is that we get to determine what the precedence order is and ensure that the core and PE-provided modules never get accidentally overridden with one of the one-off modules. The symlink approach makes it work, but removes the ability to ensure that at the Puppet layer. As an aside, what I'd really like to be able to do is manipulate the module search path at run time early in the DSL. I know that would likely impact things like pluginsync and so it is non-trivial or near impossible to do (though I'd be okay with losing plugin sync for any path dynamically included). I think I recall seeing an ARM about that which seemed promising. Thanks!
Jira (PUP-1118) Support an $environmentsdir setting
Title: Message Title
Sean Millichamp commented on an issue
Re: Support an $environmentsdir setting
Hi, I just saw this ticket... in regards to the question you posed about the master's modulepath I would say that given those two choices I would prefer the modules directory path to be pre-pended to master section's modulepath vs. the symlinks.
Our environment checkout and management scripts do a bunch of symlink work to support our dynamic environment use-case already, and adding one more step to look for the modules in /opt/puppet/share/puppet/modules (or wherever) and symlink those in would be pretty trivial, but I do like that right now all of the symlinks are entirely self-contained within the environment itself.
In the end both approaches seem workable, and it is probably a matter of style as much as anything.
Add Comment
Puppet / PUP-1118
Support an $environmentsdir setting
Puppet needs to read environment specific manifests and modules from directories that reside in a location specified by an {{environmentsdir}} setting. The name of the environment is the name of the directory that will be used for that environment. Each environment directory contains 2 directories (both optional) * manifests * modules The {{...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
