Jira (PUP-9748) Puppet Device doesn't honor ENC-set Environment in 5.5.10 or later
Title: Message Title Adam Gardner updated an issue Puppet / PUP-9748 Puppet Device doesn't honor ENC-set Environment in 5.5.10 or later Change By: Adam Gardner *Puppet Version: 5.5.10 - 5.5.14 (5.5.8 works correctly)* *Puppet Server Version: 5.3.6* *OS Name/Version: Centos 7* ** Note that this probably affects at least some versions of Puppet 6.x, though I don't have the setup to verify that personally.*Steps to reproduce:* # Install Puppet Agent 5.5.10 or later # Configure a Device node in devices.conf and set up a certificate for it # Configure the ENC on the Master to supply an environment other than production for the device node # Run `puppet device --target --verbose`*Desired Behavior:*The application switches to the ENC-supplied environment before performing a plugin sync. This behavior can be observed under 5.5.8; the logs show "Notice: Local environment 'production' doesn't match server specified node environment 'foo', switching agent to 'foo'." prior to "Retrieving pluginfacts".*Actual Behavior:*The application remains in the production environment during pluginsync (and possibly after) unless a `–environment` flag is explicitly passed. No environment-switching occurs. If the module containing the device transport code is not present in the production environment, then the device transport files will be removed and the subsequent run will fail.*Notes* This seems likely to be related to PUP-8766, which changed the way that the puppet device application handles environments, and was incorporated into 5.5.10 as well as 6.0.5. Prior to PUP-8766, _only_ ENC-supplied environments were honored by the Puppet Device application, and the --environment flag did not function; now, the reverse situation is true. Add Comment
Jira (PUP-9748) Puppet Device doesn't honor ENC-set Environment in 5.5.10 or later
Title: Message Title Adam Gardner created an issue Puppet / PUP-9748 Puppet Device doesn't honor ENC-set Environment in 5.5.10 or later Issue Type: Bug Affects Versions: PUP 5.5.14, PUP 5.5.13, PUP 5.5.12, PUP 5.5.10 Assignee: Unassigned Created: 2019/06/11 7:46 PM Environment: Centos 7 Puppetserver 5.3.6 Puppet Agent 5.5.x (5.5.8 and earlier works, 5.5.10 through 5.5.14 does not). Priority: Normal Reporter: Adam Gardner Puppet Version: 5.5.10 - 5.5.14 (5.5.8 works correctly) Puppet Server Version: 5.3.6 OS Name/Version: Centos 7 **Note that this probably affects at least some versions of Puppet 6.x, though I don't have the setup to verify that personally. Steps to reproduce: Install Puppet Agent 5.5.10 or later Configure a Device node in devices.conf and set up a certificate for it Configure the ENC on the Master to supply an environment other than production for the device node Run `puppet device --target --verbose` Desired Behavior: The application switches to the ENC-supplied environment before performing a plugin sync. This behavior can be observed under 5.5.8; the logs show "Notice: Local environment 'production' doesn't match server specified node environment 'foo', switching agent to 'foo'." prior to "Retrieving pluginfacts". Actual Behavior: The application remains in the production environment during pluginsync (and possibly after) unless a `–environment` flag is explicitly passed. No
Jira (PUP-8774) puppet device does not use locking
Title: Message Title Adam Gardner commented on PUP-8774 Re: puppet device does not use locking I think this should be revisited. While it certainly does not make sense for puppet device to be locked across all targets, it makes a lot of sense to try and protect against a single proxy running puppet device against the same target multiple times simultaneously. Just like each device target has its own cache, it should have its own lock file: /opt/puppetlabs/puppet/cache/devices//state/device_catalog_run.lock, most likely. 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-8947) Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters
Title: Message Title
Adam Gardner commented on PUP-8947
Re: Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters
I think an ideal implementation would also be able to automatically handle sensitive conversions in cases like
type Example = Struct[{
username => String,
password => Sensitive[String],
}]
class profile::example(
Array[Example] $foo,
){
...
}
Obviously, if you start introducing complex types including things like `Variant[String,Sensitive[String]]` those wouldn't be converted because the original string also matches.
Jira (PUP-8946) Return all eyaml encrypted values from hiera as Sensitive
Title: Message Title Adam Gardner commented on PUP-8946 Re: Return all eyaml encrypted values from hiera as Sensitive I know this has been marked "Accepted" already, but please consider implementing PUP-8947 instead, it seems much friendlier, and provides a much easier transition for existing codebases. 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-8947) Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters
Title: Message Title Adam Gardner commented on PUP-8947 Re: Automatically cast ACPL results to Sensitive for Sensitive-typed class parameters I have to say I view this option (8947) as markedly superior to the suggestion in PUP-8946. PUP-8946 would require us to update our entire codebase in one giant update or everything would break - depending on implementation, it may actually not be feasible at all for us. 8947, on the other hand, feels like exactly what is needed - it's what I came here to suggest myself, actually. 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-9112) :undef still shows up in types and providers
Title: Message Title
Adam Gardner updated an issue
Puppet / PUP-9112
:undef still shows up in types and providers
Change By:
Adam Gardner
*Puppet Version:* 5.5.6 *Puppet Server Version:* N/A *OS Name/Version:* Centos 7, same on Windows 10Per the discussion in PUP-1467, all Ruby code in Types and Providers is supposed to receive {{undef}} values as {{nil}}. However, in at least some circumstances, I am receiving the Symbol {{:undef}} instead.For example, given the following resource declaration: {code:java}foo { 'bar': baz => {quux => undef, },}{code} *Desired Behavior:*Inside the provider, {{resource[:baz]}} evaluates to {{ \ {'quux' => nil \ }}}*Actual Behavior:*Inside the provider, {{resource[:baz]}} evaluates to {{ \ {'quux' => :undef \ }}}*Additional Context*Besides behaving contrary to the discussions in PUP-1467 (which is the closest I could find to documentation on {{:undef}} vs {{nil}}, this is also problematic when the provider is constructing JSON, perhaps to communicate with an API; the desired JSON string would be {{ \ {"quux": null \ }}}, but instead you end up with {{ \ {"quux": "undef" \ }}}.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9112) :undef still shows up in types and providers
Title: Message Title
Adam Gardner created an issue
Puppet / PUP-9112
:undef still shows up in types and providers
Issue Type:
Bug
Affects Versions:
PUP 5.5.6
Assignee:
Unassigned
Components:
Types and Providers
Created:
2018/09/06 4:16 PM
Priority:
Minor
Reporter:
Adam Gardner
Puppet Version: 5.5.6 Puppet Server Version: N/A OS Name/Version: Centos 7, same on Windows 10 Per the discussion in PUP-1467, all Ruby code in Types and Providers is supposed to receive undef values as nil. However, in at least some circumstances, I am receiving the Symbol :undef instead. For example, given the following resource declaration:
foo { 'bar':
baz => {
quux => undef,
},
Jira (PUP-7935) Prefetching custom types not possible if namevar is not "name"
Title: Message Title Adam Gardner commented on PUP-7935 Re: Prefetching custom types not possible if namevar is not "name" Is there any intent to address this at some point? 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-8700) --extra cli option is nonfunctional
Title: Message Title
Adam Gardner created an issue
Puppet / PUP-8700
--extra cli option is nonfunctional
Issue Type:
Bug
Assignee:
Unassigned
Created:
2018/05/04 4:52 PM
Labels:
commandline
Priority:
Minor
Reporter:
Adam Gardner
Puppet Version: 5.5.1 Puppet Server Version: N/A OS Name/Version: Centos 7.4.1708 Many `puppet` applications such as `puppet facts` and `puppet catalog` take a `–terminus` option to specify what indirector to use. These applications generally also specify a `–extra` argument, like so: `--extra HASH - Extra arguments to pass to the indirection request` As far as I can determine, this argument is not actually possible to use, since any argument supplied to the `–extra` option is treated by Ruby as a String. For example, `puppet facts --terminus network_device --extra '{target => "example-device"}'` results in `Error: Could not call 'find' on 'facts': undefined method `inject' for "{target => \"example-device\"}":String` The same results are had when trying other hash-ish syntaxes such as JSON or key-value pairs. If there's some existing syntax that will actually work here, it should be documented. But I had a look through the source code, and I don't think any such syntax exists. Describe steps to reproduce… `puppet facts --terminus network_device --extra ` Desired Behavior: **The `–extra` argument should function, or should be removed. Actual Behavior: ``` $ sudo puppet facts --terminus network_device --extra '{target => "example-device"}' --trace Error: Could not call 'find' on 'facts': undefined method `inject' for "{target => \"example-device\"}":String Did you mean? inspect /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/request.rb:68:in `initialize' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:115:in `new' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:115:in `request'
Jira (PUP-8699) puppet device application should support outputting facts
Title: Message Title Adam Gardner created an issue Puppet / PUP-8699 puppet device application should support outputting facts Issue Type: New Feature Assignee: Unassigned Created: 2018/05/04 2:51 PM Priority: Normal Reporter: Adam Gardner Much like `puppet device --resource` roughly provides the behavior of `puppet resource` for network devices, there should be a `puppet device --facts` command that provides a feature analogous to `puppet facts`, but for network devices. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (FACT-1849) Allow overriding Facter config (specifically external facts dir) when calling Puppet
Title: Message Title Adam Gardner created an issue Facter / FACT-1849 Allow overriding Facter config (specifically external facts dir) when calling Puppet Issue Type: Improvement Assignee: Unassigned Created: 2018/04/26 12:39 PM Priority: Normal Reporter: Adam Gardner Currently when calling puppet (e.g `puppet facts`) you can override the directory from which custom facts in ruby are loaded (using the `--factdir` flag or the FACTERLIB environment variable), however it does not appear to be possible to customize the location from which external facts are loaded other than by editing facter.conf. When calling `facter` directly as a command line tool, you can of course specify the `--external-dir` flag at the command line, but there is no equivalent flag when calling `puppet facts` (or `puppet agent`, `puppet catalog`, etc), nor is there an environment variable you can set to achieve this end. Add Comment
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title Adam Gardner commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax I'd like to point out, the absence of exported resources in Puppet Forge modules seems like a pretty big red herring; I suspect (obviously I can't prove) that exported resources are most often created and consumed by organization-specific Puppet code that never gets published to forge.puppet.com. Certainly, that's how we're using them. That's not to say I'm not in favor of eventually deprecating these features, and the idea of being able to use PuppetDB as a key-value store without having to create dummy types (either instead of or in addition to collecting resources) has a lot of appeal. But for the moment I agree with Sean, John, etc, the current alternatives aren't quite there yet. At the very least, if you're going to deprecate these features, add functions to query PuppetDB into stdlib. 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.
