Jira (PUP-10679) Unable to install Ruby gem on Windows with ensure and version range
Title: Message Title Matt Dainty commented on PUP-10679 Re: Unable to install Ruby gem on Windows with ensure and version range Here's a summary of tests with and without a space between the operator and the version: Ensure 5.5.21 PUP-6563 reverted Comment ~>2.2.0 Windows seems to intercept the >2.2.0 and Gem only sees the ~ as a version ~> 2.2.0 =>2.2.0 Gem requires a space regardless => 2.2.0 There seems to be some secret Windows shell expansions that I'm not familiar with at play here.
Jira (PUP-10679) Unable to install Ruby gem on Windows with ensure and version range
Title: Message Title Matt Dainty commented on PUP-10679 Re: Unable to install Ruby gem on Windows with ensure and version range Mihai Buzgau if I remove the space, I get this: Error: Could not update: Execution of 'C:\opt\sensu\embedded\bin\gem.bat install -v "=>2.2.0" --no-document sensu-plugins-puppet' returned 1: ERROR: While executing gem ... (Gem::Requirement::BadRequirementError) Illformed requirement ["=>2.2.0"] C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/requirement.rb:105:in `parse' C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/requirement.rb:135:in `block in initialize' C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/requirement.rb:135:in `map!' C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/requirement.rb:135:in `initialize' C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/version_option.rb:55:in `new' C:/opt/sensu/embedded/lib/ruby/site_ruby/2.4.0/rubygems/version_option.rb:55:in `block in add_version_option' C:/opt/sensu/embedded/lib/ruby/2.4.0/optparse.rb:548:in `conv_arg' C:/opt/sensu/embedded/lib/ruby/2.4.0/optparse.rb:676:in `parse' C:/opt/sensu/embedded/lib/ruby/2.4.0/optparse.rb:1581:in `block in parse_in_order'
Jira (PUP-10679) Unable to install Ruby gem on Windows with ensure and version range
Title: Message Title Matt Dainty commented on PUP-10679 Re: Unable to install Ruby gem on Windows with ensure and version range If I change my example to use '~> 2.2.0' for the ensure value as per PUP-6563 then that also explodes in the same way. If I revert the changes made by PUP-6563 then both the example in that ticket and my example start working. This leads me to suspect that the way this command was issued on Windows has changed and the quoting is now no longer needed. It makes sense therefore to revert this change, so I'll file a PR. 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.373310.160130644.44300.1601309100177%40Atlassian.JIRA.
Jira (PUP-10679) Unable to install Ruby gem on Windows with ensure and version range
Title: Message Title
Matt Dainty commented on PUP-10679
Re: Unable to install Ruby gem on Windows with ensure and version range
It's this block that is causing the problem:
if Puppet.features.microsoft_windows?
version = resource[:ensure]
command_options << "-v" << %Q["#{version}"] if (! resource[:ensure].is_a? Symbol) and useversion
else
command_options << "-v" << resource[:ensure] if (! resource[:ensure].is_a? Symbol) and useversion
end
For some reason the version string is treated differently on Windows and explicitly quoted. If I change the code to just use the same code as !Windows my test case works. This change looks like it was introduced by PUP-6563.
Add Comment
Jira (PUP-10679) Unable to install Ruby gem on Windows with ensure and version range
Title: Message Title
Matt Dainty created an issue
Puppet / PUP-10679
Unable to install Ruby gem on Windows with ensure and version range
Issue Type:
Bug
Affects Versions:
PUP 5.5.21
Assignee:
Unassigned
Components:
Types and Providers
Created:
2020/09/28 8:20 AM
Priority:
Normal
Reporter:
Matt Dainty
Puppet Version: 5.5.21 Puppet Server Version: n/a OS Name/Version: Windows 2012R2 The following example on Windows doesn't work:
package { 'sensu-plugins-puppet':
ensure => '>= 2.2.0',
provider => gem,
command => 'C:\\opt\\sensu\\embedded\\bin\\gem.cmd',
}
Jira (PDB-4710) PuppetDB 5.2.14 won't start
Title: Message Title Matt Dainty created an issue PuppetDB / PDB-4710 PuppetDB 5.2.14 won't start Issue Type: Bug Affects Versions: PDB 5.2.14 Assignee: Unassigned Components: PuppetDB Created: 2020/05/04 2:49 AM Priority: Normal Reporter: Matt Dainty Our PuppetDB installation was upgraded from 5.2.13 to 5.2.14. As soon as this happened PuppetDB wouldn't start and was throwing this error continuously: 2020-05-02 18:25:14,326 INFO [o.e.j.u.log] Logging initialized @21674ms to org.eclipse.jetty.util.log.Slf4jLog 2020-05-02 18:25:16,717 INFO [p.t.s.w.jetty9-service] Initializing web server(s). 2020-05-02 18:25:16,788 INFO [p.p.pdb-routing] Starting PuppetDB, entering maintenance mode 2020-05-02 18:25:16,835 INFO [p.t.s.s.status-service] Registering status callback function for service 'puppetdb-status',
Jira (PDB-4709) PuppetDB 6.10 schema migration failed
Title: Message Title Matt Dainty commented on PDB-4709 Re: PuppetDB 6.10 schema migration failed I noticed a similar error when PuppetDB was upgraded from 5.2.13 to 5.2.14 over the weekend, I saw the same "Your PuppetDB database contains a schema migration numbered 1, but..." error message and PuppetDB wouldn't start. Downgrading back to 5.2.13 got things working again. I am going to investigate and see if I can see anything in the logs. 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.357582.1588581307000.53656.1588584660038%40Atlassian.JIRA.
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title Matt Dainty commented on PUP-9792 Re: Merge of lookup_options not working https://github.com/puppetlabs/puppet/pull/7726 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.313541.1561115342000.101139.1568732040166%40Atlassian.JIRA.
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title Matt Dainty commented on PUP-9792 Re: Merge of lookup_options not working Eventually I managed to unpick the multiple levels of caching and the following crude diff fixes the behaviour: diff --git a/lib/puppet/pops/lookup/lookup_adapter.rb b/lib/puppet/pops/lookup/lookup_adapter.rb index 4014aea..d531705 100644 --- a/lib/puppet/pops/lookup/lookup_adapter.rb +++ b/lib/puppet/pops/lookup/lookup_adapter.rb @@ -233,12 +233,12 @@ class LookupAdapter < DataAdapter module_name = key.module_name # Retrieve the options for the module. We use nil as a key in case we have no module -if !@lookup_options.include?(module_name) +#if !@lookup_options.include?(module_name) options = retrieve_lookup_options(module_name, lookup_invocation, MergeStrategy.strategy(HASH)) - @lookup_options[module_name] = options -else - options = @lookup_options[module_name]
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title
Matt Dainty commented on PUP-9792
Re: Merge of lookup_options not working
I've managed to get my example to work by changing manifests/site.pp to just the following:
$bar = 'bar'
notice(lookup('foo'))
Basically by ensuring the top scope variable is set before any lookup() is called, it gets the correct merge behaviour. This does suggest that lookup_options is getting cached for the lifetime of the compile. I'm trying to find where in the code this caching is done but I'm not having much luck so far.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title Matt Dainty commented on PUP-9792 Re: Merge of lookup_options not working There's no such option, (on 5.5.16 at least): Error: Could not parse application options: invalid option: --evaluate I'm already using --compile as part of my tests, however I don't get the correct answer with the puppet lookup CLI, nor within a normal catalog compile. Your first comment suggested a lack of cache eviction, my example does suggest the lookup options aren't re-evaluated once the top scope variables are set. 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.313541.1561115342000.99263.1568643240423%40Atlassian.JIRA.
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title
Matt Dainty commented on PUP-9792
Re: Merge of lookup_options not working
Sorry, I didn't see your comments. I think I've managed to reduce this down to the following contrived example: hiera.yaml
---
version: 5
defaults:
datadir: data
data_hash: yaml_data
hierarchy:
- name: YAML
paths:
- "%{bar}.yaml"
- "common.yaml"
data/common.yaml
---
lookup_options:
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title
Matt Dainty updated an issue
Puppet / PUP-9792
Merge of lookup_options not working
Change By:
Matt Dainty
*Puppet Version: 5.5.14* *Puppet Server Version: 5.3.8* *OS Name/Version: RHEL 7.x*In our Hiera data, we have made use of lookup_options to control the merge behaviour, so in our catch-all common.yaml there are entries such as:{noformat} ---lookup_options: profile::autofs::mounts:merge: hash {noformat}This works as desired. However we have some exceptions where we want to override this on a per-role basis back to the original "first" behaviour, so as we have a higher priority role level, I added the following in a role/foo.yaml:{noformat} ---lookup_options: profile::autofs::mounts:merge: first {noformat}If I use the "puppet lookup" command against the correct host, this appears to work as desired, using `--explain-options` I get the following result:{noformat} Merged result: {"profile::autofs::mounts" => { "merge" => "first"} }{noformat}For any other hosts I still get the behaviour defined at the common level:{noformat} Merged result: {"profile::autofs::mounts" => { "merge" => "hash"} } {noformat}All good. However this doesn't seem to actually apply to the lookup itself:{noformat} Using merge options from "lookup_options" hashSearching for "profile::autofs::mounts" Merge strategy hash ... {noformat}It only ever picks up the behaviour defined at the common level.*Desired Behavior:*I would expect to see:{noformat} Using merge options from "lookup_options" first hash Searching for "profile::autofs::mounts" ... {noformat} i.e. (no merge strategy displayed here) *Actual Behavior:*One bit of information that might be relevant is that in order for our lookups to work from the CLI, I have to use the --compile option, so basically something like:{noformat} puppet lookup --compile --environment --node profile::autofs::mounts --explain(-options){noformat}We have multiple backends/levels configured in Hiera, a mix of YAML/eYAML and using the HTTP backend too. I noticed there was PUP-7037 which was raised for similar behaviour but was ultimately traced to a typo. I'm confident this isn't down to a typo. Edit: After a bit more experimenting, I was a bit confused about where "hash" should be printed vs other merge strategies, the 'Using merge options from "lookup_options" hash' is pretty much a fixed string, it's the presence/lack of "Merge strategy ..." that is the identifier.
Jira (PUP-9792) Merge of lookup_options not working
Title: Message Title Matt Dainty created an issue Puppet / PUP-9792 Merge of lookup_options not working Issue Type: Bug Affects Versions: PUP 5.5.14 Assignee: Unassigned Components: Hiera & Lookup Created: 2019/06/21 4:09 AM Priority: Normal Reporter: Matt Dainty Puppet Version: 5.5.14 Puppet Server Version: 5.3.8 OS Name/Version: RHEL 7.x In our Hiera data, we have made use of lookup_options to control the merge behaviour, so in our catch-all common.yaml there are entries such as: --- lookup_options: profile::autofs::mounts: merge: hash This works
Jira (PUP-9046) How to turn off the Hiera global level
Title: Message Title Matt Dainty created an issue Puppet / PUP-9046 How to turn off the Hiera global level Issue Type: Bug Affects Versions: PUP 5.5.3 Assignee: Thomas Hallgren Components: Hiera & Lookup Created: 2018/08/08 3:56 AM Priority: Normal Reporter: Matt Dainty Puppet Version: 5.5.3 Puppet Server Version: 5.3.3 OS Name/Version: EL 7.5 I've just completed a migration to move Hiera from v3 to v5 and I would like to now completely disable the global level (/etc/puppetlabs/code/hiera.yaml) leaving just the environment and per-module levels. According to PUP-7641 I need to just have an empty zero-bytes hiera.yaml however with that, I still see with `puppet lookup --explain ...`: Warning: /etc/puppetlabs/code/hiera.yaml: File exists but does not contain a valid YAML hash. Falling back to Hiera version 3 default config Warning: /etc/puppetlabs/code/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5 (file: /etc/puppetlabs/code/hiera.yaml)
Jira (PUP-6723) collector_transformer: add support for 'in' operator to facilitate 'not in'
Title: Message Title Matt Dainty commented on PUP-6723 Re: collector_transformer: add support for 'in' operator to facilitate 'not in' I just caught myself typing something like `Yumrepo <||> ~> Exec['yum clean all'] -> Package <| tag != "foo" and tag != "bar" |>` and remembering some nagging doubt in my head that it didn't work the last time I tried to do that and searching for this ticket. I agree with the sentiment that even if it's considered a breaking change nobody actually uses it this way as it's unusable Adding some form of "in" and "not in" operators would be useful. 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-8773) Logging as JSON broken
Title: Message Title Matt Dainty commented on PUP-8773 Re: Logging as JSON broken Please see https://github.com/puppetlabs/puppet/pull/6852 for a PR that fixes this. 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-8773) Logging as JSON broken
Title: Message Title
Matt Dainty updated an issue
Puppet / PUP-8773
Logging as JSON broken
Change By:
Matt Dainty
Affects Version/s:
PUP 5.5.0
*Puppet Version: 5.5.1* *Puppet Server Version: n/a* *OS Name/Version: RHEL 7.x*Running the puppet agent with the --logdest option pointing at a JSON target file causes a Ruby backtrace.*Desired Behavior:*Puppet should log as JSON.*Actual Behavior:* Example output:{noformat} # puppet agent -t --noop --logdest /tmp/foo.json/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:130:in `current_adapter': undefined method `[]' for # (NoMethodError)from /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:139:in `dump'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/json.rb:70:in `dump'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log/destinations.rb:112:in `handle'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:191:in `block in newmessage'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `each'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `newmessage'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:308:in `initialize'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `new'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `create'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:11:in `send_log'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:20:in `block (2 levels) in 'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:69:in `log_exception'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:673:in `rescue in exit_on_fail'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:660:in `exit_on_fail'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:366:in `run'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:137:in `run'from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:73:in `execute'from /opt/puppetlabs/puppet/bin/puppet:5:in `'{noformat}Change the log destination to /tmp/foo.txt and it doesn't error. It looks like this bug was introduced in 5.5.0, 5.4.0 still works as expected, possibly related to PUP-8501.
Jira (PUP-8773) Logging as JSON broken
Title: Message Title Matt Dainty created an issue Puppet / PUP-8773 Logging as JSON broken Issue Type: Bug Affects Versions: PUP 5.5.1 Assignee: Unassigned Created: 2018/05/23 4:36 AM Priority: Normal Reporter: Matt Dainty Puppet Version: 5.5.1 Puppet Server Version: n/a OS Name/Version: RHEL 7.x Running the puppet agent with the --logdest option pointing at a JSON target file causes a Ruby backtrace. Desired Behavior: Puppet should log as JSON. Actual Behavior: Example output: # puppet agent -t --noop --logdest /tmp/foo.json /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:130:in `current_adapter': undefined method `[]' for # (NoMethodError) from /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:139:in `dump' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/json.rb:70:in `dump'
Jira (PUP-7744) Puppet CA's CRL is prone to duplicate entries
Title: Message Title Matt Dainty commented on PUP-7744 Re: Puppet CA's CRL is prone to duplicate entries Yes, just run into this via SERVER-115 and " doesn't always revoke what you expect" class="issue-link" data-issue-key="PUP-2569" style="color: #3b73af; text-decoration: none"> PUP-2569 and associates. I now have a 8.5 MB CRL that contains ~ 180,000 individual revocations and as many as ~ 500 duplicate revocations for specific certificate serial numbers. I've used puppet cert reinventory to clean down inventory.txt so most of the old certificate serials are forgotten. Is it possible to rebuild the CRL and de-dupe it to just contain one of each serial number as I'm continually hitting the problem documented in SERVER-115 whereby any time I perform a puppet node clean it triggers a CRL rebuild that causes issues for any other connecting client(s), the size of the CRL can't not be contributing to this so the smaller I can make it the better. 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 (PDB-3698) Build up of orphaned rows in edges and facts tables
Title: Message Title Matt Dainty commented on PDB-3698 Re: Build up of orphaned rows in edges and facts tables Thanks for the response. I'll have to try and sort out getting the servers and agents upgraded to 5.x first before I can try the newer PDB out. 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-3698) Build up of orphaned rows in edges and facts tables
Title: Message Title Matt Dainty created an issue PuppetDB / PDB-3698 Build up of orphaned rows in edges and facts tables Issue Type: Bug Affects Versions: PDB 4.4.0 Assignee: Unassigned Components: PuppetDB Created: 2017/10/10 6:49 AM Priority: Normal Reporter: Matt Dainty I've noticed in the PuppetDB PostgreSQL database that there seems to be a build up of what seem to be orphaned rows in both the edges and facts tables. For example: puppetdb=# SELECT COUNT(*) FROM edges WHERE certname NOT IN (SELECT certname FROM certnames); count
Jira (PUP-7179) Type aliases defined across multiple levels of modules
Title: Message Title
Matt Dainty updated an issue
Puppet / PUP-7179
Type aliases defined across multiple levels of modules
Change By:
Matt Dainty
I have three modules; A, B and C.# Module C defines some type aliases.# Module B lists module C in `metadata.json` and defines some type aliases in terms of the ones in C, (`Variant`, `Array`, etc.).# Module A lists module B in `metadata.json` and uses the type aliases defined in B for parameter types.When I try and use module A I get errors similar to:{noformat}Class[A]: parameter 'myparam' references an unresolved type 'C::MyType'{noformat} `myparam` is defined in the class of type 'B::SomeType'. The workaround is to also add module C to module A's `metadata.json` even though it is installed on the host by virtue of installing module B. I would argue it should just work without this as I'm not explicitly using any of C's resources; it's a dependency of B's and that module is free to change it's dependencies as it sees fit.
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-7179) Type aliases defined across multiple levels of modules
Title: Message Title Matt Dainty created an issue Puppet / PUP-7179 Type aliases defined across multiple levels of modules Issue Type: Bug Affects Versions: PUP 4.9.0 Assignee: Unassigned Created: 2017/02/04 9:56 AM Priority: Normal Reporter: Matt Dainty I have three modules; A, B and C. Module C defines some type aliases. Module B lists module C in `metadata.json` and defines some type aliases in terms of the ones in C, (`Variant`, `Array`, etc.). Module A lists module B in `metadata.json` and uses the type aliases defined in B for parameter types. When I try and use module A I get errors similar to: Class[A]: parameter 'myparam' references an unresolved type 'C::MyType'
Jira (PUP-6648) Puppet 4.6.x breaks catalog.apply in unit tests
Title: Message Title Matt Dainty commented on PUP-6648 Re: Puppet 4.6.x breaks catalog.apply in unit tests Thanks for the response, I'll try and apply a similar workaround. I agree this is something that puppetlabs-spec_helper should ideally handle as that gets pulled in by all of my modules. 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-6648) Puppet 4.6.x breaks catalog.apply in unit tests
Title: Message Title
Matt Dainty updated an issue
Puppet / PUP-6648
Puppet 4.6.x breaks catalog.apply in unit tests
Change By:
Matt Dainty
I have the following automated test as part of my module:{ { code:ruby} require 'spec_helper'provider_class = Puppet::Type.type(:avahi_host).provider(:augeas)describe provider_class do before :each doPuppet::Type.type(:avahi_host).stubs(:defaultprovider).returns described_classFileTest.stubs(:exist?).returns falseFileTest.stubs(:exist?).with('/etc/avahi/hosts').returns true end context 'with empty file' dolet(:tmptarget) { aug_fixture('empty') }let(:target) { tmptarget.path }it 'should create simple new entry' do apply!(Puppet::Type.type(:avahi_host).new(:name => 'router.local',:ip => '192.0.2.1',:target => target,:provider => 'augeas', )) aug_open(target, 'Hosts.lns') do |aug|expect(aug.get("*[canonical = 'router.local']/ipaddr")).to eq('192.0.2.1') endend endend {code } } This works fine on any Puppet version I've tested with prior to 4.6.0 but with that or 4.6.1 I get the following error: { { code} Failures: 1) Puppet::Type::Avahi_host::ProviderAugeas with empty file should create simple new entry Failure/Error: catalog.apply Errno::ENOTDIR: Not a directory @ dir_s_mkdir - /dev/null/state/transactionstore.yaml20160824-21390-1gzxywg.lock # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:182:in `mkdir' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:182:in `mkdir' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:175:in `locking' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:38:in `block in initialize' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:134:in `create_tmpname' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/file_system/uniquefile.rb:28:in `initialize' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/util.rb:453:in `new' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/util.rb:453:in `replace_file' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/util/yaml.rb:32:in `dump' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/transaction/persistence.rb:82:in `save' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/transaction.rb:148:in `block in evaluate' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/graph/relationship_graph.rb:147:in `call' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/graph/relationship_graph.rb:147:in `traverse' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/transaction.rb:154:in `evaluate' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/resource/catalog.rb:222:in `block in apply' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/util/log.rb:159:in `with_destination' # /home/travis/.rvm/gems/ruby-2.1.6/gems/puppet-4.6.1/lib/puppet/transaction/report.rb:137:in `as_logging_destination' #
Jira (PUP-6648) Puppet 4.6.x breaks catalog.apply in unit tests
Title: Message Title
Matt Dainty created an issue
Puppet / PUP-6648
Puppet 4.6.x breaks catalog.apply in unit tests
Issue Type:
Bug
Affects Versions:
PUP 4.6.0, PUP 4.6.1
Assignee:
Unassigned
Created:
2016/08/24 5:47 AM
Environment:
I've seen this both with Puppet gems locally on OS X and on Travis CI testing my module.
Priority:
Normal
Reporter:
Matt Dainty
I have the following automated test as part of my module:
{{require 'spec_helper'
provider_class = Puppet::Type.type(:avahi_host).provider(:augeas)
describe provider_class do
before :each do Puppet::Type.type(:avahi_host).stubs(:defaultprovider).returns described_class FileTest.stubs(:exist?).returns false FileTest.stubs(:exist?).with('/etc/avahi/hosts').returns true end
context 'with empty file' do let(:tmptarget) { aug_fixture('empty') }
let(:target) { tmptarget.path }
it 'should create simple new entry' do apply!(Puppet::Type.type(:avahi_host).new( :name => 'router.local', :ip => '192.0.2.1', :target => target, :provider => 'augeas', ))
Jira (FACT-704) Docker support for virtual and is_virtual broken by systemd slices
Title: Message Title Matt Dainty commented on FACT-704 Re: Docker support for virtual and is_virtual broken by systemd slices So for the benefit of the ticket the bug is reproduced by running Docker on top of at least CentOS 7 or possibly other systemd-based Linux distros. As systemd utilises cgroups they are already present when a docker container is launched thus creating its own cgroups as children of the systemd ones. This broke the facter detection logic which expected the docker-created cgroups to be the root of the cgroup hierarchy, the facter logic would then fall through and detect either the physical machine or virtualisation used for the Docker host as applicable. The Linux distro running inside Docker doesn't have to be systemd-based, I reproduced the problem with both CentOS 6 and 7. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 (FACT-704) Docker support for virtual and is_virtual broken by systemd slices
Title: Message Title Matt Dainty commented on FACT-704 Re: Docker support for virtual and is_virtual broken by systemd slices I've created PR's for facter and cfacter that should fix this. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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 (FACT-236) Facter RPM should not require virt-what
Title: Message Title Matt Dainty commented on an issue Re: Facter RPM should not require virt-what I've been wandering around trying to find out why facter is not giving me ec2 facts on EC2, (it turns out this is due to them being in a VPC and the MAC-based detection logic doesn't work). For virt-what not working, I think all you're missing is this: mount -t xenfs none /proc/xen With that, /proc/xen is populated and virt-what correctly reports I'm in a domU and therefore facter too. I just include a mount resource if virtual reports xen or xenu to enforce this. Add Comment Facter / FACT-236 Facter RPM should not require virt-what There is a bug in virt-what that causes facter to behave incorrectly. https://bugzilla.redhat.com/show_bug.cgi?id=973663 http://projects.puppetlabs.com/issues/7559#note-71 I'm currently in the process of updating my automation to install facter (and thus puppet) as gems instead of RPM's due to the fact that the RPM (after v1.6.10) requires the virt-w... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
