Jira (PUP-7526) no pip2 package provider when pip3 is system default
Title: Message Title Andrey Galkin commented on PUP-7526 Re: no pip2 package provider when pip3 is system default Confirm the problem on pip installed into "/usr/local/bin" - not through system packages. Actual "/usr/local/bin/pip" is undefined as it depends on order of installation/update of Python 2 vs 3 version. Solution is as simple as copy of "pip3.rb" to "pip2.rb" with dumb replacement of "pip3" with "pip2" string. That would ensure fine control of which Python version to use. 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-8547) MRI and JRuby Yaml parsers not compliant with spec wrt. errors
Title: Message Title Andrey Galkin commented on PUP-8547 Re: MRI and JRuby Yaml parsers not compliant with spec wrt. errors Looked at code, psych uses event emitter when parsing. It just ends the document and ignores another document. Here the issue reported back in 2015: https://github.com/ruby/psych/issues/239 I believe, PuppetLabs can influence/help the issue to resolve. 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-8547) MRI and JRuby Yaml parsers not compliant with spec wrt. errors
Title: Message Title Andrey Galkin commented on PUP-8547 Re: MRI and JRuby Yaml parsers not compliant with spec wrt. errors I believe, the main problem is PuppetServer which runs in JRuby. So, it seems "snakeyaml" should be used internally by "psych" wrapper. I've tried a quick test of Java version and immediately found that it DOES properly handle invalid documents. Exception in thread "main" expected '', but found BlockMappingStart in 'reader', line 5, column 1: somevar: 3 ^ at org.yaml.snakeyaml.parser.ParserImpl$ParseDocumentStart.produce(ParserImpl.java:225) at org.yaml.snakeyaml.parser.ParserImpl.peekEvent(ParserImpl.java:157) at org.yaml.snakeyaml.parser.ParserImpl.checkEvent(ParserImpl.java:147) at org.yaml.snakeyaml.composer.Composer.getSingleNode(Composer.java:108) at org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:120) at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:450)
Jira (PUP-8541) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin commented on PUP-8541 Re: Hiera lookup must hard fail on invalid YAML > created PUP-8547 for the upstream problems Looks good. 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 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-8541) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin commented on PUP-8541 Re: Hiera lookup must hard fail on invalid YAML > The best practice is to use a validator for YAML that gives the appropriate errors/warnings. Not sure it is desirable to do this at runtime as it would increase the cost of reading YAML quite dramatically. The performance problem is solvable by proper YAML parser instead of definitely broken Ruby's default one. There is not need to introduces linter overhead. And in any case, you can do Hiera static file caching the same way you do catalog or ruby file caching. It should even increase performance overall at minor cost of extra memory used. 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-8541) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin commented on PUP-8541 Re: Hiera lookup must hard fail on invalid YAML Guys, I believe you fix is incomplete as it does not protect from another case below. I would still open this ticket blocked by a feature request: strict YAML validation. It's definitely not resolved. --- #someobj: a: 1 b: 2 somevar: 1 Ruby results in: --- a: 1 b: 2 Add Comment
Jira (PUP-8541) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin commented on PUP-8541 Re: Hiera lookup must hard fail on invalid YAML I see you pain with broken YAML loading in Ruby. In other implementations, the original YAML snippet from description fails to load. The problem can be reported to upstream. However, some validation in Puppet is desired. Log entry is not really enough. Broken YAML should fail the same way as invalid Puppet manifest would fail. 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 (HI-597) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin commented on HI-597 Re: Hiera lookup must hard fail on invalid YAML I would say the behavior should be controlled by configuration option: ignore, warn and enforce. Puppet 5 may just warn about the problem, but Puppet 6 must hard fail by default. 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 (HI-597) Hiera lookup must hard fail on invalid YAML
Title: Message Title Andrey Galkin created an issue Hiera / HI-597 Hiera lookup must hard fail on invalid YAML Issue Type: Bug Affects Versions: HI 3.4.2 Assignee: Unassigned Components: Community, PE Created: 2018/03/11 11:13 AM Priority: Normal Reporter: Andrey Galkin PuppetServer/Hiera just ignores broken YAML files instead of hard failing on them. The consequences can be as serious as compromised system and/or lost network access to host. I would consider that critical based on experience with the problem. Below is broken sample from hierarchy for tests: --- #classes: - cls1 - cls2
Jira (PUP-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters Hi Moses Mendoza. At the moment, I see the second master in lab environment is missing routes.yaml. So, only the primary master has one. I believe the situation was the same in the original testing as puppetdb-termini apparently does not install one automatically. Sorry for the misleading previous comment. 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-7383) Puppet with openssl 1.1 fails
Title: Message Title Andrey Galkin commented on PUP-7383 Re: Puppet with openssl 1.1 fails I guess Puppet team looks at this item as not important, but this leads to puppet gem not being usable for module developers on newer systems. The fix seems to be as trivial enough as adding a simple "if". The issue may eventually spread to other OSes like Fedora 26+: https://bugzilla.redhat.com/show_bug.cgi?id=1440710 Please consider proactively adding this one-line fix to next patch release. 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters Moses Mendoza Regarding 'settings' error, I switched to use unlimited environment_timeout & API calls for refresh during deployment. So, did not pay much attention. Regarding routes.yaml - yes, it it used exactly as in the example. Do you suggest to remove one? 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-7217) Add "premessage" metaparameter for better user experience
Title: Message Title Andrey Galkin created an issue Puppet / PUP-7217 Add "premessage" metaparameter for better user experience Issue Type: Improvement Affects Versions: PUP 4.9.1 Assignee: Unassigned Components: Types and Providers Created: 2017/02/14 2:55 AM Priority: Minor Reporter: Andrey Galkin Some resource creation may take a long time, especially if compilation or other heavy processing is involved. Some users may think that deployment goes wrong and cancel it. For better user experience, there should be some way to notify user right before resource is created. It's not possible to use "notify" type for conditional message. Instead of metaparameter, as normal parameter can be added only to "exec", "package" and some other types. Of course, this is easily achievable with custom providers, but some DSL-level support is desired.
Jira (PUP-7207) New Puppet functions and type aliases are searched only in direct dependencies
Title: Message Title Andrey Galkin updated an issue Puppet / PUP-7207 New Puppet functions and type aliases are searched only in direct dependencies Change By: Andrey Galkin Summary: New Puppet functions and type aliases are search searched only in direct dependencies 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-7208) Add Struct-extending Params[] and ParamsHash[] data types
Title: Message Title Andrey Galkin created an issue Puppet / PUP-7208 Add Struct-extending Params[] and ParamsHash[] data types Issue Type: New Feature Affects Versions: PUP 4.9.0 Assignee: Unassigned Components: Language Created: 2017/02/11 5:30 AM Priority: Normal Reporter: Andrey Galkin There is a common idiom with Hiera data and module writing. Example: define mymodule::mytype( /*... a long list of params ... */
Jira (PUP-7207) New Puppet functions and type aliases are search only in direct dependencies
Title: Message Title
Andrey Galkin created an issue
Puppet / PUP-7207
New Puppet functions and type aliases are search only in direct dependencies
Issue Type:
Bug
Affects Versions:
PUP 4.9.0
Assignee:
Unassigned
Components:
Language
Created:
2017/02/11 5:15 AM
Priority:
Minor
Reporter:
Andrey Galkin
This is not critical, but absolutely not intuitively understandable compared to legacy "parser" functions.
1. create moduleA and define new-style Ruby functions under {module}/lib/puppet/functions/{module_name} and/or PP type aliases under {module}
/types Example: moduleA::some_func, moduleA::Sometype 2. create moduleB -> metadata.json depends on moduleA 3. create moduleC -> metadata.json depends on moduleB 4. Call moduleA::some_func or use moduleA::Sometype from moduleC 5. Observe very not intuitive failure of unknown function/resource type 6. add moduleC metadata.json dependency on moduleA 7. everything works
The behavior is not consistent with search manifests/ or legacy "parser" functions.
Rational: sometimes, a larger functionality can be split into many modules released together. In this case, it's much easier to control "sub-modules" dependency versions in
Jira (PUP-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters ... and definitely, timestamps should not come to play when we generate a new catalog. It's obvious that agent provided data is the actual state. 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters In my testing, all nodes are synced through ntpdate initially and then through constantly running ntpd against the same source. Time drift is no more than 0.01 seconds. Each puppet agent run takes way much time. Regarding timestamp, also related: #PDB-3248 IMO, it does not look right at all to compare timestamps. I understand, it can be a sort of mitigation for highly available PuppetDB setup, but it would obviously be much safer to have UUID of agent + counter (generation) of facts/resources. 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters Guys, it's a race condition, I am quite sure for that: I put delay (breakpoint + wait 10 seconds + continue) between extract_facts_from_request_facts() and node_from_request() in Puppet::Resource::Catalog::Compiler then everything works as expected. /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/catalog/compiler.rb:51 Now, I wonder if that can be reproduced on single server instance as well... 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters Some more info: I did restart of both PuppetServer and PuppetDB. The issue remains. It seems obvious that by some reason, PuppetServer uses old facts for compilation, but then submits new facts to YAML cache and database. I've specially checked that both PostgreSQL and YAML cache at /opt/puppetlabs/server/data/puppetserver/yaml/facts/cacheissue.example.com.yaml contain value which is not present anywhere on agent's host. So, every run switches the values. Current fact from client goes to database, but PuppetServer uses the previous value for compilation. All packages come from PuppetLabs OpenSource repo. 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title Andrey Galkin commented on PUP-7198 Re: Puppet Server uses facts from the previous run (n-1) after agent switches masters I've extended the test to shutdown PuppetServer & Puppet DB on primary master and PostgreSQL replica on secondary. The result is the same. I can provide scripts for complete setup of vagrant environment from scratch with a few clicks and around 10 minutes for processing. 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-7198) Puppet Server uses facts from the previous run (n-1) after agent switches masters
Title: Message Title
Andrey Galkin updated an issue
Puppet / PUP-7198
Puppet Server uses facts from the previous run (n-1) after agent switches masters
Change By:
Andrey Galkin
I couldn't believe that, but I could finally reliably reproduce the problem in minimal sample. I've observed that episodically and believe this is a long standing issue - the reason I do not put Critical to this.Ruby fact plugin:{code:ruby}Facter.add('fact_cache_issue') dosetcode dobeginFile.read('/etc/fact_cache_issue')rescueendendend{code}Puppet code:{code:puppet}class factcacheissue {$value = $::facts['fact_cache_issue'] ? {undef => generate('/usr/bin/openssl', 'rand', '-hex', '8'),default => $::facts['fact_cache_issue']}file { '/etc/fact_cache_issue':content => $value,}}node cacheissue.example.com {include factcacheissuefile {'/etc/puppetlabs/puppet/puppet.conf':mode=> '0644',content => '[main]client = falsecertname = cacheissue.example.comserver = puppetback.example.comca_server = puppet.example.comenvironment = productionsrv_domain = example.comuse_srv_records = false',}}{code}1. Setup puppet-agent 1.9.0 package2. Run against CA server puppet.example.com3. During the first initialization, openssl generator is called and puppet server is changed to secondary master (puppetback.example.com)4. Second run goes to secondary master. Master stores facts PuppetDB, but Master does not see new facts during catalog compilations => calls openssl generator again .5. Each next run uses fact set from run #n-1 - *that's very weird*, and produces resource value switch to previous run.6. If puppet server is not switched then everything is correct.Command line output:{noformat}Setting up puppet-agent (1.9.0-1jessie) ...Configuration file '/etc/puppetlabs/puppet/puppet.conf' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. ==> Using current old file as you requested.Created symlink from /etc/systemd/system/multi-user.target.wants/puppet.service to /lib/systemd/system/puppet.service.Created symlink from /etc/systemd/system/multi-user.target.wants/mcollective.service to /lib/systemd/system/mcollective.service.Created symlink from /etc/systemd/system/multi-user.target.wants/pxp-agent.service to /lib/systemd/system/pxp-agent.service.Removed symlink /etc/systemd/system/multi-user.target.wants/pxp-agent.service.+ PUPPET=/opt/puppetlabs/bin/puppet+ /opt/puppetlabs/bin/puppet resource service puppet ensure=false enable=false provider=systemdNotice: /Service[puppet]/enable: enable changed 'true' to 'false'service { 'puppet': ensure => 'stopped', enable => 'false',}+ systemctl mask puppetCreated symlink from /etc/systemd/system/puppet.service to /dev/null.+ host maint.example.com+ /opt/puppetlabs/bin/puppet agent --test --traceInfo: Creating a new SSL key for cacheissue.example.comInfo: Caching certificate for caInfo: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yamlInfo: Creating a new SSL certificate request for cacheissue.example.comInfo: Certificate Request fingerprint (SHA256): DA:8A:E9:2C:01:A4:2B:B4:DA:28:66:89:8D:91:9B:4F:76:DF:62:4F:EA:A5:28:68:03:0B:20:92:03:01:70:01Info: Caching
Jira (PDB-3248) PuppetDB stops updating catalogs after time correction
Title: Message Title Andrey Galkin commented on PDB-3248 Re: PuppetDB stops updating catalogs after time correction No problem, please update the ticket to better fit the task. 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 (PDB-3248) PuppetDB stops updating catalogs after time correction
Title: Message Title Andrey Galkin commented on PDB-3248 Re: PuppetDB stops updating catalogs after time correction This particular one came with vagrant VMs in testing. However, some time ago, I saw a similar issue in production with Xen & old kernel & ntpd failure - it was solved by manual psql queries and was not reported here. I am not sure how it assists with replication [of PostgreSQL?]. Perhaps, some special use cases of async report injection? I would recommend to add an option to control if PuppetDB should reject "outdated" reports at least. 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 (PDB-3248) PuppetDB stops updating catalogs after time correction
Title: Message Title
Andrey Galkin created an issue
PuppetDB / PDB-3248
PuppetDB stops updating catalogs after time correction
Issue Type:
Bug
Affects Versions:
PDB 4.3.0
Assignee:
Unassigned
Components:
PuppetDB
Created:
2017/01/10 12:28 PM
Priority:
Normal
Reporter:
Andrey Galkin
Sometimes, it happens that system clock becomes too much desynced. Case 1: virtualization with known bugs and lagging NTPd Case 2: mutli-master setup with desynced clock
If time runs into future and then gets synchronized by NTPd Puppet DB stops updating actual catalogs with the following warning in logs: "Not replacing catalog for certname {0}
because local data is newer."
The consequences is invalid instantiation of exported resources (old versions) and obviously outdated results of node/fact/resource queries.
The issues comes from: https://github.com/puppetlabs/puppetdb/blob/master/src/puppetlabs/puppetdb/scf/storage.clj#L763
Jira (PUP-6804) Change from symlink to regular file produces strange results
Title: Message Title Andrey Galkin commented on PUP-6804 Re: Change from symlink to regular file produces strange results links => follow, Doesn't help, BTW. 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-6804) Change from symlink to regular file produces strange results
Title: Message Title Andrey Galkin updated an issue Puppet / PUP-6804 Change from symlink to regular file produces strange results Change By: Andrey Galkin Summary: Changed Change from symlink to regular file produces strange results 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-6804) Changed from symlink to regular file produces strange results
Title: Message Title Andrey Galkin created an issue Puppet / PUP-6804 Changed from symlink to regular file produces strange results Issue Type: Bug Affects Versions: PUP 4.7.0 Assignee: Unassigned Components: Language Created: 2016/10/08 9:08 AM Environment: Debian Jessie + Puppet 4.7.0 Priority: Normal Reporter: Andrey Galkin If existing file is a symlink it fails to be changed to regular file and symlink target is very strangely processed. If file is removed first then everything is OK. root@maint:~# cat puppet_symlink_to_file.pp
Jira (PUP-6804) Changed from symlink to regular file produces strange results
Title: Message Title
Andrey Galkin updated an issue
Puppet / PUP-6804
Changed from symlink to regular file produces strange results
Change By:
Andrey Galkin
If existing file is a symlink it fails to be changed to regular file and symlink target is very strangely processed. If file is removed first then everything is OK.{code: java puppet }root@maint:~# cat puppet_symlink_to_file.pp node default {$f = '/etc/localtime.test'$fo = "/usr/share/zoneinfo/Etc/UTC"exec {"/bin/ln -sfn $fo $f": } ->file { $f:ensure => file,mode => '0644',source => $fo,}}root@maint:~# puppet apply puppet_symlink_to_file.pp Notice: Compiled catalog for maint.example.com in environment production in 0.19 secondsNotice: /Stage[main]/Main/Node[default]/Exec[/bin/ln -sfn /usr/share/zoneinfo/Etc/UTC /etc/localtime.test]/returns: executed successfullyNotice: /Stage[main]/Main/Node[default]/File[/etc/localtime.test]/target: target changed '/usr/share/zoneinfo/Etc/UTC' to '../UTC'Notice: Applied catalog in 0.13 secondsroot@maint:~# puppet --version4.7.0root@maint:~# uname -aLinux maint.example.com 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linuxroot@maint:~# puppet apply cat puppet_symlink_to_file.pp node default {$f = '/etc/localtime.test'$fo = "/usr/share/zoneinfo/Etc/UTC"#exec {"/bin/ln -sfn $fo $f": } ->exec {"/bin/rm -f $f": } ->file { $f:ensure => file,mode => '0644',source => $fo,}}root@maint:~# puppet apply puppet_symlink_to_file.pp Notice: Compiled catalog for maint.example.com in environment production in 0.17 secondsNotice: /Stage[main]/Main/Node[default]/Exec[/bin/rm -f /etc/localtime.test]/returns: executed successfullyNotice: /Stage[main]/Main/Node[default]/File[/etc/localtime.test]/ensure: createdNotice: Applied catalog in 0.16 seconds{code}
Add Comment
This message was sent by Atlassian
Jira (PUP-4464) 4.x syntax error in '=>' in hash following another expression
Title: Message Title
Andrey Galkin commented on PUP-4464
Re: 4.x syntax error in '=>' in hash following another _expression_
Just a hint for anyone running into the problem. Adding round brackets around Hash should help.
Example (not tested).
$result = $rows.map |$row| {
$temp_val = $row['col']
({ a=> $temp_val })
}
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
Jira (PUP-6606) Regression with inherited variables lookup
Title: Message Title Andrey Galkin commented on PUP-6606 Re: Regression with inherited variables lookup OK, I got your idea. It seems order of evaluation has changed and that's why not completely valid code worked previously. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6606) Regression with inherited variables lookup
Title: Message Title Andrey Galkin updated an issue Puppet / PUP-6606 Regression with inherited variables lookup Change By: Andrey Galkin Priority: Major Minor Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6606) Regression with inherited variables lookup
Title: Message Title
Andrey Galkin commented on PUP-6606
Re: Regression with inherited variables lookup
Just in case
class regtest::params {
$var = 'value'
}
class regtest inherits regtest::params {
}
define regtest::other (
$var = $::regtest::var
) {
}
Jira (PUP-6606) Regression with inherited variables lookup
Title: Message Title Andrey Galkin created an issue Puppet / PUP-6606 Regression with inherited variables lookup Issue Type: Bug Affects Versions: PUP 4.6.0 Assignee: Unassigned Components: Language Created: 2016/08/11 1:34 PM Environment: A simple case with puppetlabs-apt and use of apt::key Priority: Major Reporter: Andrey Galkin The problem appeared right after upgrade to 4.6.0 Error message: "Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Unknown variable: '::apt::keyserver'. at /etc/puppetlabs/code/environments/production/modules/apt/manifests/key.pp:7:18" Investigation: 1. `apt::key` has the following line
Jira (PDB-2842) PDB should grant read-only access to different [read-database] user
Title: Message Title Andrey Galkin created an issue PuppetDB / PDB-2842 PDB should grant read-only access to different [read-database] user Issue Type: Bug Affects Versions: PDB 4.1.2 Assignee: Unassigned Created: 2016/06/24 2:37 PM Priority: Normal Reporter: Andrey Galkin SITUATION: 1. [read-database] has different PostgreSQL user than in [database] section 2. The read-only user is allowed to connect to DB, but fails to query objects created by read-write user 3. Example output: WARN [o.e.j.s.HttpChannel] /pdb/query/v4/facts?query=[%22extract%22,[%22certname%22,%22name%22,%22value%22],[%22and%22,[%22in%22,%22certname%22,[%22extract%22,%22certname%22,[%22select_resources%22,[%22and%22,[%22=%22,%22type%22,%22Class %22],[%22=%22,%22title%22,%22Cftotalcontrol%22],[%22=%22,%22exported%22,false],[%22or%22,[%22=%22,%22name%22,%22cf_totalcontrol_key%22],[%22=%22,%22name%22,%22cf_totalcontrol_scope_keys%22
Jira (PDB-2841) Twice as much maximum-pool-size connections
Title: Message Title Andrey Galkin commented on PDB-2841 Re: Twice as much maximum-pool-size connections It did cause a problem until I realized where the excessive connections were coming from. Now, I know how to workaround that. It would be good to update the documentation with clear note of such behavior at least. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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 (PDB-2841) Twice as much maximum-pool-size connections
Title: Message Title Andrey Galkin created an issue PuppetDB / PDB-2841 Twice as much maximum-pool-size connections Issue Type: Bug Affects Versions: PDB 4.1.2 Assignee: Unassigned Components: PuppetDB Created: 2016/06/24 1:36 PM Priority: Normal Reporter: Andrey Galkin STEP 1: 1. [database] maximum-pool-size is set to 10 2. [read-database] is not set See 20 connections are created. STEP 2: 1. [database] maximum-pool-size is set to 10 2. [read-database] is configured the same, but with different host and/or port See 10 connections created to [database] instance and 10 other connections for [read-database] instance CLUE: perhaps, if [read-database] is missing then [database] is simply copied what leads to duplicated amount of connections. PROPOSED SOLUTION: make sure a single pool is used, if [read-database] is missing.
Jira (PUP-6358) Set strict_variables = true, if strict = error is set
Title: Message Title Andrey Galkin created an issue Puppet / PUP-6358 Set strict_variables = true, if strict = error is set Issue Type: Bug Affects Versions: PUP 4.5.0 Assignee: Unassigned Components: Platform Created: 2016/05/25 3:51 PM Environment: Please see details from MODULES-3414 Priority: Normal Reporter: Andrey Galkin As there is a new overlapping configuration option, for backward compatibility, please force strict_variables = true, if strict = error is set. For forward compatibility, please make the vice-versa. Please set strict = ignore/error, if strict_variables = false/true is set respectively.
Jira (PUP-6070) Serious regression with exception in reduce() & others after change from Enumerable to Iterable
Title: Message Title Andrey Galkin updated an issue Puppet / PUP-6070 Serious regression with exception in reduce() & others after change from Enumerable to Iterable Change By: Andrey Galkin Environment: Debian Jessie AMD64 with latest Puppet 4.4.0 from the official repoOpenJDK 7 & 8 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6070) Serious regression with exception in reduce() & others after change from Enumerable to Iterable
Title: Message Title Andrey Galkin created an issue Puppet / PUP-6070 Serious regression with exception in reduce() & others after change from Enumerable to Iterable Issue Type: Bug Affects Versions: PUP 4.4.0 Assignee: Unassigned Attachments: puppet_exception_reduce.txt Components: Language, Puppet Server Created: 2016/03/17 5:08 PM Environment: Debian Jessie AMD64 with latest Puppet 4.4.0 from the official repo OpenJDK 7 Priority: Major Reporter: Andrey Galkin The behavior is not stable. There is no exception with `puppet apply` & Ruby , the
Jira (PUP-6070) Serious regression with exception in reduce() & others after change from Enumerable to Iterable
Title: Message Title
Andrey Galkin updated an issue
Puppet / PUP-6070
Serious regression with exception in reduce() & others after change from Enumerable to Iterable
Change By:
Andrey Galkin
The behavior is not stable. +There is no exception with `puppet apply` & Ruby+, the exception is triggered only on JRuby when invoked through Puppet Server.It may be one of already solved JRuby bugs => bundled JRuby update may be required.The same data with small modifications work without issues, I tried to reduce example as possible until the exception is still triggered. *In the example below try to remove "keyname4" entry and no exception is triggered.*This has worked on Puppet 4.3.2 and started to fail with upgrade to 4.4.0.As with previous Hiera issue, I can expect that some third-party module may have polluted Puppet type system, but see no evidence so far.Here's example data in Puppet code:{code}$data = [{"certname"=>"x.some.domain","parameters"=>{"admin_auth_keys"=>{"keyname1"=>{"key"=>"ABCDEF","options"=>["from=\"10.0.0.0/8\""]},"keyname2"=>{"key"=>"ABCDEF",},"keyname3"=>{"key"=>"ABCDEF","options"=>["from=\"10.0.0.0/8\""],"type"=>"ssh-xxx"},"keyname4"=>{"key"=>"ABCDEF","options"=>["from=\"10.0.0.0/8\""]}},"admin_user"=>"ertxa","admin_hosts"=>["1.2.3.4","1.2.3.4","1.2.3.4"],"admin_password"=>"ABCDEF","sshd_ports"=>[22,22, 24],"sudo_no_password_all"=>false,"sudo_no_password_commands"=>[],"sshd_config_template"=>"cfauth/sshd_config.epp","sudo_env_keep"=>[]},"exported"=>false},]$data_reduced = $data.reduce({}) |$m, $r|{$cn = $r['certname']merge($m, { $cn => $r['parameters'] })}fail($data_reduced){code}Exception thrown:{noformat}Error while evaluating a Method call, bignum too big to convert into `long'{noformat}Tip of backtrace on exception:{noformat}org/jruby/RubyArray.java:689:in `hash'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/types/types.rb:1230:in `hash'org/jruby/RubyArray.java:3241:in `uniq'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/types/types.rb:1796:in `initialize'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/types/iterable.rb:57:in `on'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/types/iterable.rb:23:in `asserted_iterable'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/loader/../../../puppet/functions/reduce.rb:118:in `reduce_with_memo'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/functions/dispatch.rb:45:in `invoke'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/functions/dispatcher.rb:35:in `dispatch'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/functions/function.rb:44:in `call'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/pops/evaluator/runtime3_support.rb:272:in `call_function'...{noformat}String dump of "types" argument to PVariantType::initialize() {noformat}[#, @value_type=#
Jira (PUP-6014) Default resource parameters are not stored in PuppetDB - not usable in collector
Title: Message Title Andrey Galkin commented on PUP-6014 Re: Default resource parameters are not stored in PuppetDB - not usable in collector Actually, it is important to save original defaults as they may be based on facts or other type of dynamic calculation. For me, this item is not critical as I prefer to hide all export/import logic inside other types. However, other users may get not expected results. 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6014) Default resource parameters are not stored in PuppetDB - not usable in collector
Title: Message Title Andrey Galkin created an issue Puppet / PUP-6014 Default resource parameters are not stored in PuppetDB - not usable in collector Issue Type: Bug Affects Versions: PUP 4.3.2 Assignee: Unassigned Components: Language Created: 2016/03/06 9:55 PM Priority: Normal Reporter: Andrey Galkin It seems PUP-1045 is not directly related, not sure. Apply the following code: define test_exported_resource ( $required_param,
Jira (PUP-5983) Environment Data Provider has different from Hiera alias interpolation behavior
Title: Message Title Andrey Galkin created an issue Puppet / PUP-5983 Environment Data Provider has different from Hiera alias interpolation behavior Issue Type: Bug Affects Versions: PUP 4.3.2 Assignee: Unassigned Components: Puppet Server Created: 2016/02/26 8:58 PM Priority: Normal Reporter: Andrey Galkin I haven't found duplicate reports of this. YAML Sample: --- somevar:
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment OK, it's cache folder related. It seems some of the forge modules is poisoning Hiera. It does not seems to be directly puppet related. Sorry, for taking your time. 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment A little clue, notice the difference in vagrant user vs superuser: Meanwhile, I am stepping through in debugger. vagrant@puppet:~$ sudo /opt/puppetlabs/bin/puppet lookup --confdir=/vagrant/pup_5952/etc/puppet --merge unique --explain classes Merge strategy unique Data Binding "hiera" Found key: "classes" value: nil Data Provider "Hiera Data Provider, version 4" ConfigurationPath "/vagrant/pup_5952/etc/code/environments/production/hiera.yaml" Data Provider "common" Path "/vagrant/pup_5952/etc/code/environments/production/data/common.yaml" Original path: "common"
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment That's more than strange as I have specially recreated VMs from scratch for testing and still saw the problem before providing the instruction. I'll try to debug the problem deeper a bit later. Could it be that environment variables affect Puppet/Hiera somehow as I see "WARN" related to environment variables passed through SSH from your client machine? 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment I use only YAML. 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment Henrik Lindberg, is there any way I can tell that? I install PuppetServer from official PuppetLabs PC1 APT repository for Debian Jessie The test configuration is exactly the way you have provided. No changes or other backends. Does the official Hiera gem 3.0.6 have correct behavior? I am sure that default Debian package is not installed. It is a heavy way, but you can reproduce that by doing the following (the latest Vagrant is assumed to be installed): 1. git clone https://github.com/codingfuture/puppet-test.git pup_5952_reprod 2. cd pup_5952_reprod 3. git checkout reproduce_PUP_5952 4. vagrant up puppet it takes some long time 5. vagrant ssh puppet 6. sudo /opt/puppetlabs/bin/puppet lookup --confdir=/vagrant/pup_5952/etc/puppet --merge unique --explain classes Note: I have not changed provisioning to use pupppetlabs/postgresql module yet, but it should not be the case 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment Just a clue. Can it be that you are testing against hiera code beyond 3.0.6 release. Officially available gem is 3.0.6 and there are some changes: https://github.com/puppetlabs/hiera/compare/3.0.6...master https://github.com/puppetlabs/hiera/compare/3.0.6...stable 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment Could it be that something outside of --confdir affects configuration? Can simply installed deep_merge gem affect it somehow? Any way, the results: root@puppet:~# puppet lookup --confdir=/vagrant/pup_5952/etc/puppet --merge unique --explain classes Merge strategy unique Data Binding "hiera" Found key: "classes" value: nil Data Provider "Hiera Data Provider, version 4" ConfigurationPath "/vagrant/pup_5952/etc/code/environments/production/hiera.yaml"
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin commented on PUP-5952 Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment Actually, I was moving to lookup() from hiera_classes() and spotted the problem. 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title
Andrey Galkin commented on PUP-5952
Re: Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
That's interesting. I have taken exactly your example with no modification and got the following results:
"target": "Notify['[, someclass]']"
The empty element, I guess is Undef. Please tell me how I can help you to reproduce the problem.
Full output:
{
"tags": ["settings","default","node"],
"name": "default",
"version": 1456183739,
"code_id": null,
"environment": "production",
"resources": [
{
"type": "Stage",
Jira (PUP-5952) Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment
Title: Message Title Andrey Galkin created an issue Puppet / PUP-5952 Lookup in global Hiera injects Undef/nil with unique merge strategy, if key exists only in environment Issue Type: Bug Affects Versions: PUP 4.3.2 Assignee: Unassigned Components: Puppet Server Created: 2016/02/21 6:38 AM Priority: Normal Reporter: Andrey Galkin It seems, this issue has not been reported before. It affects general variable lookup. If merge strategy is first, then environment's data is ignored. If merge strategy is unique then Undef/nil is inserted as first argument That breaks class parameter lookup as well. Steps to reproduce: 1. Global hiera.yaml datadir points to /etc/puppetlabs/code/hieradata/ and only entry "global" in the hierarchy. 2. There is /etc/puppetlabs/code/hieradata/global.yaml ---
Jira (PUP-5899) Empty hiera data in modules causes whole lookup to fail
Title: Message Title
Andrey Galkin updated an issue
Puppet / PUP-5899
Empty hiera data in modules causes whole lookup to fail
Change By:
Andrey Galkin
Situation:1. Module has "data_provider: 'hiera'" in metadata.json2. Module has simple hiera.yaml version 4 pointing to 'data/common.yaml'2. Module's data/common.yaml is empty with only three dashes:{code:yaml}---{code}4. "puppet lookup" or "puppet agent -t" leads to error below.5. The error is easily fixed by changing common.yaml content to:{code:yaml}---{}{code}{code}rror: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, undefined method `[]' for nil:NilClass at /etc/puppetlabs/code/environments/production/modules/cffirehol/manifests/init.pp:12:5 on node cfpuppet . codingfuture . net . /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:207:in `is_http_200?'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/rest.rb:105:in `find'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/indirector/indirection.rb:194:in `find'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:299:in `block in retrieve_new_catalog'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:292:in `block in thinmark'/opt/puppetlabs/puppet/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:291:in `thinmark'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:298:in `retrieve_new_catalog'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:59:in `retrieve_catalog'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:104:in `prepare_and_retrieve_catalog'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:206:in `run_internal'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:134:in `block in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/context.rb:65:in `override'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:240:in `override'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/configurer.rb:133:in `run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (4 levels) in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent/locker.rb:21:in `lock'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:45:in `block (3 levels) in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:98:in `with_client'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:42:in `block (2 levels) in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:65:in `run_in_fork'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:179:in `controlled_run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/agent.rb:39:in `run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/agent.rb:353:in `onetime'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application/agent.rb:331:in `run_command'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:344:in `block in run'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:446:in
Jira (PUP-5899) Empty hiera data in modules causes whole lookup to fail
Title: Message Title Andrey Galkin created an issue Puppet / PUP-5899 Empty hiera data in modules causes whole lookup to fail Issue Type: Bug Affects Versions: PUP 4.3.2 Assignee: Unassigned Components: Modules, Puppet Server Created: 2016/02/14 4:04 PM Priority: Normal Reporter: Andrey Galkin Situation: 1. Module has "data_provider: 'hiera'" in metadata.json 2. Module has simple hiera.yaml version 4 pointing to 'data/common.yaml' 2. Module's data/common.yaml is empty with only three dashes: ---
