Jira (FACT-2950) Root of structured core facts cannot be overriden by a custom fact
Title: Message Title Gheorghe Popescu updated an issue Facter / FACT-2950 Root of structured core facts cannot be overriden by a custom fact Change By: Gheorghe Popescu Release Notes Summary: Because the top-level fact does not exist, the root of structured core facts could not be overridden by a custom fact. This PR change updates the QueryParser logic to return the root fact, if that present in the loaded facts list, thus allowing completely redefinition of core facts. 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.389257.1614583384000.161834.1615362720030%40Atlassian.JIRA.
Jira (FACT-2950) Root of structured core facts cannot be overriden by a custom fact
Title: Message Title Gheorghe Popescu updated an issue Facter / FACT-2950 Root of structured core facts cannot be overriden by a custom fact Change By: Gheorghe Popescu Release Notes Summary: Because the top-level fact does not exist, the root of structured core facts could not be overridden by a custom fact. This PR updates the QueryParser logic to return the root fact, if that present in the loaded facts list, thus allowing completely redefinition of core facts. 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.389257.1614583384000.161833.1615362660030%40Atlassian.JIRA.
Jira (FACT-2950) Root of structured core facts cannot be overriden by a custom fact
Title: Message Title Gheorghe Popescu updated an issue Facter / FACT-2950 Root of structured core facts cannot be overriden by a custom fact Change By: Gheorghe Popescu Release Notes: Bug Fix 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.389257.1614583384000.161832.1615362540152%40Atlassian.JIRA.
Jira (FACT-2956) Facter should ensure core facts are resolved before loading custom facts
Title: Message Title
Gheorghe Popescu updated an issue
Facter / FACT-2956
Facter should ensure core facts are resolved before loading custom facts
Change By:
Gheorghe Popescu
Facter 4 implements `Facter.value` differently than Facter 3. On Facter 3, search is done in multiple steps, and the next step is executed only if the previous one was not able to resolve the fact: # search in the internal collection # load the `fact_name.rb` from the configured custom directories # load all the core facts, external facts and env facts # load all custom factsCalling `Facter.value(:os)` will: # search for `os` in its internal collection # load `custom_dir/os.rb` # load core, external and env factsCalling `Facter.value(:custom_fact)` will: # search for `custom_fact` in its internal collection # load `custom_dir/custom_fact.rb` # load core, external and env facts # load all custom factsOn Facter 4, when `Facter.value` is called, Facter will load all the core facts and all the custom facts, then will resolve only the facts that match the requested query. Due to this issue, puppet may not be able to manage services, because puppet selects {{base}} as the default service provider instead of {{systemd}}:{noformat}change from 'stopped' to 'running' failed: Services must specify a start command or a binary (corrective){noformat}This issue can be triggered when running {{puppet facts show}}:{noformat}# mkdir -p /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter# cat < /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter/service.rbrequire 'puppet'Puppet::Type.type(:service).new(:name => 'something')END# rm -rf /opt/puppetlabs/puppet/cache/lib/# puppet facts showError: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Facter: error while resolving custom facts in /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter/service.rb Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClass{noformat}If the agent has pluginsynced, then {{facter -p}} will also trigger the issue:{noformat}# facter -p[2021-03-05 20:03:49.595880 ] ERROR Facter - error while resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/service.rb Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClass{noformat}However, {{facter -p }} for an unrelated fact won't trigger it.{noformat}# facter -p os{ architecture => "x86_64", family => "RedHat", hardware
Jira (FACT-2956) Facter should ensure core facts are resolved before loading custom facts
Title: Message Title
Gheorghe Popescu updated an issue
Facter / FACT-2956
Facter should ensure core facts are resolved before loading custom facts
Change By:
Gheorghe Popescu
Facter 4 calls {{Kernel.load}} on all custom ruby facts before core facts have been resolved. If the custom ruby facts has code outside a {{setcode}} block, then it's possible for core facts like {{ implements ` Facter.value (:operatingsystem)}} to return nil, like FACT-2880 ` differently than Facter 3 . It is true that custom facts shouldn't misbehave that way, but a single misbehaving custom fact can prevent PE from managing itself. We also don't have tooling/validation to warn or prevent users from doing this, so there are many examples of it in practice. We should be more defensive about this. One way would be to ensure core facts are resolved before custom facts are loaded. It would still be possible for a custom fact with a higher weight to override the core fact, but at least the core fact would never have a nil value. Facter 3 didn't have this issue because core facts were implemented in C++ and evaluated before loading custom ruby facts. Due to this issue, puppet may not be able to manage services, because puppet selects {{base}} as the default service provider instead of {{systemd}}: {noformat} change from 'stopped' to 'running' failed: Services must specify a start command or a binary (corrective){noformat} This issue can be triggered when running {{puppet facts show}}: {noformat} # mkdir -p /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter# cat < /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter/service.rbrequire 'puppet'Puppet::Type.type(:service).new(:name => 'something')END# rm -rf /opt/puppetlabs/puppet/cache/lib/# puppet facts showError: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClassError: Facter: error while resolving custom facts in /etc/puppetlabs/code/environments/production/modules/badfact/lib/facter/service.rb Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClass{noformat} If the agent has pluginsynced, then {{facter -p}} will also trigger the issue: {noformat} # facter -p[2021-03-05 20:03:49.595880 ] ERROR Facter - error while resolving custom facts in /opt/puppetlabs/puppet/cache/lib/facter/service.rb Could not autoload puppet/type/service: Could not autoload puppet/provider/service/bsd: Could not autoload puppet/provider/service/init: undefined method `downcase' for nil:NilClass{noformat} However, {{facter -p }} for an unrelated
Jira (PUP-10959) Lock loaders using a single central lock
Title: Message Title Maggie Dreyer created an issue Puppet / PUP-10959 Lock loaders using a single central lock Issue Type: Improvement Assignee: Unassigned Created: 2021/03/09 5:10 PM Priority: Normal Reporter: Maggie Dreyer Currently, we lock each individual loader object with its own lock. This can result in deadlocks, when loaders call into other loaders in the process of loading. Instead, we want to try a single, central, high-level lock, perhaps in the base load function, that is tied to the environment/loaders object. So only one thing can be loaded for a given environment at a time. This should avoid deadlocks. We'll probably want to try profiling this a little, but it should avoid the issue that is currently making multithreaded with environment caching unusable. See SERVER-2860 and PE-30479. This solution is an alternative to PUP-10958. Add Comment
Jira (PUP-10947) Revist the exclude_list for puppet facts diff command
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10947 Revist the exclude_list for puppet facts diff command Change By: Josh Cooper Fix Version/s: PUP 6.22.0 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.389694.1614756311000.161409.1615327680034%40Atlassian.JIRA.
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title Josh Cooper commented on FACT-2134 Re: Facter should distinguish between CentOS 8 and CentOS 8 Stream This was merged to main in https://github.com/puppetlabs/facter/commit/37fbb2921c107b03f92d1c26745c24e8c732131a and reverted in main in https://github.com/puppetlabs/facter/commit/96758ba6a68607bd631376eb55798aeb27f951d6 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.336204.1574351826000.161403.1615327200077%40Atlassian.JIRA.
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title Josh Cooper assigned an issue to Unassigned Facter / FACT-2134 Facter should distinguish between CentOS 8 and CentOS 8 Stream Change By: Josh Cooper Assignee: Josh Cooper 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.336204.1574351826000.161400.1615327020528%40Atlassian.JIRA.
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title Josh Cooper assigned an issue to Josh Cooper Facter / FACT-2134 Facter should distinguish between CentOS 8 and CentOS 8 Stream Change By: Josh Cooper Assignee: Josh Cooper 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.336204.1574351826000.161399.1615327020480%40Atlassian.JIRA.
Jira (FACT-1847) Implement "cloud" fact Azure identification for Windows platform
Title: Message Title Josh Cooper updated an issue Facter / FACT-1847 Implement "cloud" fact Azure identification for Windows platform Change By: Josh Cooper Fix Version/s: FACT 3.14.16 Fix Version/s: FACT 3.14.17 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.247441.1524674206000.161385.1615326840094%40Atlassian.JIRA.
Jira (FACT-1847) Implement "cloud" fact Azure identification for Windows platform
Title: Message Title Josh Cooper updated an issue Facter / FACT-1847 Implement "cloud" fact Azure identification for Windows platform Change By: Josh Cooper Fix Version/s: FACT 3.14.16 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.247441.1524674206000.161380.1615326780284%40Atlassian.JIRA.
Jira (FACT-1847) Implement "cloud" fact Azure identification for Windows platform
Title: Message Title Josh Cooper commented on FACT-1847 Re: Implement "cloud" fact Azure identification for Windows platform Merged to 3.x in https://github.com/puppetlabs/facter/commit/bfe625a89f569e97ff9c926cdcb4f58cea291c51, main in https://github.com/puppetlabs/facter/commit/3390419c55070f1a10a695773824ec38b262d747 and passed CI in facter#3390419c5 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.247441.1524674206000.161373.1615326720036%40Atlassian.JIRA.
Jira (FACT-2952) Facter 4 reports lsbmajdistrelease on Ubuntu differently than facter 3
Title: Message Title Josh Cooper commented on FACT-2952 Re: Facter 4 reports lsbmajdistrelease on Ubuntu differently than facter 3 Passed CI in facter#3390419c55070f1a10a695773824ec38b262d747 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.389552.161471215.161370.1615326600335%40Atlassian.JIRA.
Jira (FACT-2950) Root of structured core facts cannot be overriden by a custom fact
Title: Message Title Josh Cooper commented on FACT-2950 Re: Root of structured core facts cannot be overriden by a custom fact Merged to main in https://github.com/puppetlabs/facter/commit/d4266f065cd1dbf8116a2f9188b179453f414033, passed CI in facter#3390419c5 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.389257.1614583384000.161363.1615326540231%40Atlassian.JIRA.
Jira (FACT-2944) During Puppet 7 upgrade from Puppet 6, Puppet Server create another certname
Title: Message Title Josh Cooper commented on FACT-2944 Re: During Puppet 7 upgrade from Puppet 6, Puppet Server create another certname Merged to main in https://github.com/puppetlabs/facter/commit/b56cb31644a17153b13d15b4904d1487630a110b, passed CI in facter#3390419c5 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.387583.1613309929000.161355.1615326360043%40Atlassian.JIRA.
Jira (PUP-10853) When blocking legacy facts in puppet7, puppet agent run fails to fetch 'operatingsystem' fact
Title: Message Title Josh Cooper commented on PUP-10853 Re: When blocking legacy facts in puppet7, puppet agent run fails to fetch 'operatingsystem' fact We're going to need to revert this change until we sort out the dotted name issue in facter (FACT-2958). I'm going to reopen this ticket, so we remember to do that. 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.383136.1610563179000.161345.1615325880141%40Atlassian.JIRA.
Jira (PUP-10948) puppet node find does not honour node_name
Title: Message Title Josh Cooper commented on PUP-10948 Re: puppet node find does not honour node_name Kaushal Kumar The puppet node find will work if you run the command on the puppetserver and you enable puppetserver's node cache. It's disabled by default in puppet6. However, a better way to do this is to query puppetdb. If you have suggestions for documentation, please leave a comment at the bottom of the documentation page. For general questions like this, please reach out in puppet slack. In the meantime, I'm going to close this. 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.389923.1614863878000.161323.1615324620044%40Atlassian.JIRA.
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Josh Cooper commented on PUP-10945 Re: Change the master -> server in Server used http code Passed CI in 8dfa86988b 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.389566.1614715872000.161252.1615321260036%40Atlassian.JIRA.
Jira (PUP-10943) Windows package provider continues to read DisplayVersion key after embedded NULL
Title: Message Title Josh Cooper commented on PUP-10943 Re: Windows package provider continues to read DisplayVersion key after embedded NULL Passed CI in 8dfa86988b 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.388985.1614292739000.161253.1615321260080%40Atlassian.JIRA.
Jira (PUP-10889) Explicitly set default ciphersuites to avoid surprises
Title: Message Title Josh Cooper commented on PUP-10889 Re: Explicitly set default ciphersuites to avoid surprises passed CI in 8dfa86988b 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.386476.1612552318000.161251.1615321200092%40Atlassian.JIRA.
Jira (PUP-10952) Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-10952
Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode
Change By:
Maggie Dreyer
While doing research on new loader architectures for SERVER-2860, I discovered the following:In {{multithreaded}} mode in Puppetserver, we create a new settings object whenever a Puppet setting changes while a JRuby request is being processed. One example is if a Puppet function in a module calls {{Puppet[]=}}. In the process of initializing the new settings object with overrides (for thread safety), we resolve all settings. The {{rich_data}} setting [clears out the environment cache|https://github.com/puppetlabs/puppet/blob/main/lib/puppet/defaults.rb#L2162] when resolved.This means if you are changing any Puppet settings in your catalog, in multithreaded mode environment caching is effectively disabled, because the cache will be invalidated on every compile of the offending environment.The most straightforward fix would be to stop clearing all envs on settings initialization. But we'd need to make sure that won't cause other problems for the {{rich_data}} setting. But a better solution would be to find out why the hook is being called in the first place when [initializing|https://github.com/puppetlabs/puppetserver/blob/9ecd7fb18cd8e02edcfa9e2130c0b2053e0a3209/src/ruby/puppetserver-lib/puppet/server/settings.rb#L25-L31] the threadlocal settings object (we're not altering that setting, and the default hook mode is "on_write_only"), and see if we can avoid it.
Add Comment
Jira (PUP-10952) Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-10952
Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode
Change By:
Maggie Dreyer
While doing research on new loader architectures for SERVER-2860, I discovered the following:In {{multithreaded}} mode in Puppetserver, we create a new settings object whenever a Puppet setting changes while a JRuby request is being processed. One example is if a Puppet function in a module calls {{Puppet[]=}}. In the process of initializing the new settings object with overrides (for thread safety), we resolve all settings. The {{rich_data}} setting [clears out the environment cache|https://github.com/puppetlabs/puppet/blob/main/lib/puppet/defaults.rb#L2162] when resolved.This means if you are changing any Puppet settings in your catalog, in multithreaded mode environment caching is effectively disabled, because the cache will be invalidated on every compile of the offending environment.The most straightforward fix would be to stop clearing all envs on settings initialization. But we'd need to make sure that won't cause other problems for the {{rich_data}} setting. But a better solution would be to find out why the hook is being called in the first place (we're not altering that setting, and the default hook mode is "on_write_only"), and see if we can avoid it.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10952) Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode
Title: Message Title Maggie Dreyer commented on PUP-10952 Re: Changing a Puppet setting in a catalog invalidates the env cache in multithreaded mode On further investigation, it seems like it might be a bug that the rich_data hook is getting called in this context at all. It is not called when the server starts and initializes settings normally, but is called, from here when we create the threadlocal settings object when a setting is updated during a compile. Dunno why yet, but that seems like something we'd rather didn't happen, and fixing that seems better than removing the hook. 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.390083.1614901848000.161245.1615320960035%40Atlassian.JIRA.
Jira (PUP-10958) Load everything in an environment upfront before first compile
Title: Message Title Henrik Lindberg commented on PUP-10958 Re: Load everything in an environment upfront before first compile Did you look into rewriting resource loading for compilation? That was something I wanted to do so that resource types and classes were also loaded with 4x loaders (the agent could continue loading the old way). I believe that would untangle one mess where logic needs to jump through hoops due to the many entry points leading to resource type loading - there must be a representation of it in the 4.x loaders to ensure a resource type isn't overridden with a pcore data type (for example). Thomas struggled with that and as I recall it there was a long tail of bugs related to that. Having a clear separation of what happens during compilation and what the agent does would be very beneficial. 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.390453.1615313252000.161239.1615320240141%40Atlassian.JIRA.
Jira (PDB-5057) Change crypto-policies to DEFAULT in el8 acceptance tests
Title: Message Title Zachary Kent created an issue PuppetDB / PDB-5057 Change crypto-policies to DEFAULT in el8 acceptance tests Issue Type: Bug Assignee: Unassigned Created: 2021/03/09 12:00 PM Priority: Normal Reporter: Zachary Kent In our el8 acceptance test we run update-crypto-policies --set LEGACY in acceptance/pre_suite/15_setup_repos. This was done to work around tlsv1 being used for some of the curl commands in the tests. We should remove this and update our curl calls and make sure that our tests pass with the DEFAULT crypto-policies. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper commented on PUP-10951 Re: The operator '* =>' in a Virtual Query is not supported. Merged to main in https://github.com/puppetlabs/puppet/commit/a91b4d7c147f97d9a71f85387c67ddcc759738fe 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.390019.1614891816000.161145.1615316940122%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Josh Cooper Release Notes: Bug Fix Release Notes Summary: Fixes a regression in 7.x which prevented the splat operator from being used to override resource attributes in a resource collector. 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.390019.1614891816000.161108.1615315140028%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper assigned an issue to Josh Cooper Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Josh Cooper Assignee: Josh Cooper 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.390019.1614891816000.161091.1615314840152%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Josh Cooper Team: Coremunity 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.390019.1614891816000.161093.1615314840244%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper commented on PUP-10951 Re: The operator '* =>' in a Virtual Query is not supported. This was broken in https://github.com/puppetlabs/puppet/commit/8bdaaecdce07c943e9ee0fc3ef3deb717450003f#diff-2fddabb7a8e2dc5edd8ca894974fa5082d2ab3aa0992c5752b07283f757e8278R237-R240. The line acceptor.accept(Issues::UNSUPPORTED_OPERATOR_IN_CONTEXT, p, :operator=>'* =>') should have been removed along with when Model::CapabilityMapping. 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.390019.1614891816000.161090.1615314840108%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Josh Cooper Sprint: Platform Core KANBAN 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.390019.1614891816000.161092.1615314840200%40Atlassian.JIRA.
Jira (PUP-10958) Load everything in an environment upfront before first compile
Title: Message Title Gene Liverman updated an issue Puppet / PUP-10958 Load everything in an environment upfront before first compile Change By: Gene Liverman Labels: customer0 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.390453.1615313252000.161057.1615313520494%40Atlassian.JIRA.
Jira (PUP-10958) Load everything in an environment upfront before first compile
Title: Message Title
Maggie Dreyer updated an issue
Puppet / PUP-10958
Load everything in an environment upfront before first compile
Change By:
Maggie Dreyer
Synchronizing the methods on loaders in multithreaded mode results in deadlocks when environment caching is enabled. In this case, the same set of loaders is being used in multiple threads, and while resolving a value, loaders call into other loaders to see if they have the value. If two mutually-connected loaders are trying to load something, and wind up asking each other at the same time if the other has their value, they can deadlock. See the stack traces [here|https://gist.github.com/Magisus/153a7253b63a01e3d01cf5dd30782a32].Analyzing what would need to be locked to allow safe loading, it doesn't appear that it is possible to avoid this situation. So instead, we want to look into doing loading _everything_ up front when an environment is first used for a compile. We can synchronize this process, and then subsequent compiles against the environment won't need to do any loading, so it's safe to not synchronize the loaders at all. Ideally, this preloading would be fairly contained, so that we could easily opt into it, and use it only when multithreaded and environment caching are both in use. It's a fairly expensive operation that we wouldn't want to run all the time. Investigation doc: https://docs.google.com/document/d/1xVxv4zDcT0eT44dN39Bqr85QwU_I9IsGfBXRnSMdyUc/edit?usp=sharingThe most promising thing I've found so far is that loaders currently implement a {{discover}} method, that can search for and load all examples of a certain class of Puppet object: functions, types, tasks, and plans. Calling these before first compile gets us a good bit of the way, but they don't work for some things, notably resource types. So part of this work might be extending that system, if possible, to support other classes of loadable things.This effort needs more breaking down and better scoping, and might end up needing its own epic.
Add Comment
Jira (PUP-10958) Load everything in an environment upfront before first compile
Title: Message Title Maggie Dreyer created an issue Puppet / PUP-10958 Load everything in an environment upfront before first compile Issue Type: New Feature Assignee: Unassigned Created: 2021/03/09 10:07 AM Priority: Normal Reporter: Maggie Dreyer Synchronizing the methods on loaders in multithreaded mode results in deadlocks when environment caching is enabled. In this case, the same set of loaders is being used in multiple threads, and while resolving a value, loaders call into other loaders to see if they have the value. If two mutually-connected loaders are trying to load something, and wind up asking each other at the same time if the other has their value, they can deadlock. See the stack traces here. Analyzing what would need to be locked to allow safe loading, it doesn't appear that it is possible to avoid this situation. So instead, we want to look into doing loading everything up front when an environment is first used for a compile. We can synchronize this process, and then subsequent compiles against the environment won't need to do any loading, so it's safe to not synchronize the loaders at all. Investigation doc: https://docs.google.com/document/d/1xVxv4zDcT0eT44dN39Bqr85QwU_I9IsGfBXRnSMdyUc/edit?usp=sharing The most promising thing I've found so far is that loaders currently implement a discover method, that can search for and load all examples of a certain class of Puppet object: functions, types, tasks, and plans. Calling these before first compile gets us a good bit of the way, but they don't work for some things, notably resource types. So part of this work might be extending that system, if possible, to support other classes of loadable things. This effort needs more breaking down and better scoping, and might end up needing its own epic.
Jira (PUP-10950) unless should support sensitive data for any type
Title: Message Title Sheena Tharakanparampil commented on PUP-10950 Re: unless should support sensitive data for any type Josh Cooper Thanks alot for the detailed information with examples.Much appreciated. Will incorporate the changes. Thank you. 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.389976.1614881718000.161017.1615312440090%40Atlassian.JIRA.
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title
Josh Cooper commented on PUP-10951
Re: The operator '* =>' in a Virtual Query is not supported.
@file { '/tmp/file':
ensure => file,
}
$permissions = {
"mode" => "0640",
}
File <| title == '/tmp/file' |> {
* => $permissions,
}
$ git bisect bad 7.0.0
$ git bisect good cb8e58ab94
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Josh Cooper updated an issue Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Josh Cooper Fix Version/s: PUP 7.5.0 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.390019.1614891816000.161001.1615311780152%40Atlassian.JIRA.
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title Tom Parker updated an issue Facter / FACT-2924 Facter fails "closed" if the facter.conf file is invalid Change By: Tom Parker Attachment: facter.conf 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.383703.1611082995000.160985.1615311240032%40Atlassian.JIRA.
Jira (FACT-2924) Facter fails "closed" if the facter.conf file is invalid
Title: Message Title
Tom Parker commented on FACT-2924
Re: Facter fails "closed" if the facter.conf file is invalid
This is still not 100% fixed. On puppet-agent.x86_64 0:7.4.1-1.el7 I can't even run a puppet agent --version without a crash. My badly formatted facter.conf (caused by erroneously converting to json unstead of hocon) is: {{{ }} {{ "facts": { }} {{ "blocklist": null, }} {{ "ttls": [ }} {{ { }} {{ "EC2": "1 day" }} {{ } }} {{ ] }} {{ } }} } [LIVE] gredb1 [k: gredb]:~ # puppet agent --version Traceback (most recent call last): 21: from /opt/puppetlabs/puppet/bin/puppet:4:in `' 20: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 19: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 18: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `' 17: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 16: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 15: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet.rb:15:in `' 14: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 13: from /opt/puppetlabs/puppet/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:92:in `require' 12: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:10:in `' 11: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter.rb:13:in `' 10: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options.rb:40:in `init' 9: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:12:in `init' 8: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:24:in `augment_all' 7: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:93:in `augment_facts' 6: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/core/options/config_file_options.rb:93:in `new' 5: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:16:in `initialize' 4: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:83:in `load_facts_ttls' 3: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:83:in `each' 2: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:84:in `block in load_facts_ttls' 1: from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:106:in `ttls_to_seconds' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/facter/framework/config/fact_groups.rb:106:in `*': nil can't be coerced into Integer (TypeError)
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title
Steven Pritchard commented on PUP-10951
Re: The operator '* =>' in a Virtual Query is not supported.
To clarify, in Puppet 5 and 6 at least, using
Service <| title == $key |> {
* => $value,
}
would override parameters of the Service resource. I've attached a module pup_10951.tar.gz with example code and rspec tests that demonstrate the issue. Note that pdk test unit --puppet-version=5 and pdk test unit --puppet-version=6 work fine, but pdk test unit --puppet-version=7 fails with the "The operator '* =>' in a Virtual Query is not supported." error.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10951) The operator '* =>' in a Virtual Query is not supported.
Title: Message Title Steven Pritchard updated an issue Puppet / PUP-10951 The operator '* =>' in a Virtual Query is not supported. Change By: Steven Pritchard Attachment: pup_10951.tar.gz 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.390019.1614891816000.160917.1615307460152%40Atlassian.JIRA.
Jira (PUP-10929) Syntax error in previously valid puppet code due to removal of application orchestration keywords
Title: Message Title Josh Cooper commented on PUP-10929 Re: Syntax error in previously valid puppet code due to removal of application orchestration keywords Merged to main in https://github.com/puppetlabs/puppet/commit/64dcad64c71f8a2c2648ab88262df40bb9622525 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.388276.1614006941000.160830.1615303860024%40Atlassian.JIRA.
Jira (PUP-10957) Support ruby 3
Title: Message Title Breno Fernandes commented on PUP-10957 Re: Support ruby 3 PUP-10247 may fix PUP-10957. 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.390422.161530306.160829.1615303800067%40Atlassian.JIRA.
Jira (PUP-10957) Support ruby 3
Title: Message Title Breno Fernandes created an issue Puppet / PUP-10957 Support ruby 3 Issue Type: Epic Affects Versions: PUP 7.4.1 Assignee: Unassigned Created: 2021/03/09 7:17 AM Priority: Normal Reporter: Breno Fernandes Hi, Fedora 34 ships ruby 3.0. Very soon it will be on Redhat, Centos and Rockylinux. It would be really cool if we could fix what is remaining to make puppet work with ruby 3. Here is what I get when I try to run it on a fedora 34 and ruby 3: ruby --version ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] puppet --version /usr/share/ruby/vendor_ruby/puppet/util.rb:476:in `uri_encode': undefined method `escape' for URI:Module (NoMethodError) from /usr/share/ruby/vendor_ruby/puppet/util.rb:344:in `path_to_uri' from /usr/share/ruby/vendor_ruby/puppet/pops/model/ast.rb:4957:in `register_pcore_types' from /usr/share/ruby/vendor_ruby/puppet/pops.rb:120:in `' from /usr/share/ruby/vendor_ruby/puppet/pops.rb:1:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/parser/compiler.rb:8:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/parser.rb:6:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet.rb:360:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `' from :85:in `require' from :85:in `require' from /usr/bin/puppet:4:in `'
Jira (PUP-10247) Support ruby 2.7
Title: Message Title Breno Fernandes commented on PUP-10247 Re: Support ruby 2.7 Hi, Fedora 34 ships ruby 3.0. It would be really cool if we could fix what is remaining to make puppet work with ruby 3. Here is what I get when I try to run it on a fedora 34 and ruby 3: ruby --version ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux] puppet --version /usr/share/ruby/vendor_ruby/puppet/util.rb:476:in `uri_encode': undefined method `escape' for URI:Module (NoMethodError) from /usr/share/ruby/vendor_ruby/puppet/util.rb:344:in `path_to_uri' from /usr/share/ruby/vendor_ruby/puppet/pops/model/ast.rb:4957:in `register_pcore_types' from /usr/share/ruby/vendor_ruby/puppet/pops.rb:120:in `' from /usr/share/ruby/vendor_ruby/puppet/pops.rb:1:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/parser/compiler.rb:8:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/parser.rb:6:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet.rb:360:in `' from :85:in `require' from :85:in `require' from /usr/share/ruby/vendor_ruby/puppet/util/command_line.rb:12:in `' from :85:in `require' from :85:in `require' from /usr/bin/puppet:4:in `' 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"
Jira (PUP-10956) pkg provider cannot unhold and update package in the same run
Title: Message Title Gabriel Nagy commented on PUP-10956 Re: pkg provider cannot unhold and update package in the same run proposed fix: https://github.com/puppetlabs/puppet/compare/main...GabrielNagy:PUP-10956-poc 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.390409.1615296443000.160786.1615298940028%40Atlassian.JIRA.
Jira (PUP-10956) pkg provider cannot unhold and update package in the same run
Title: Message Title
Gabriel Nagy created an issue
Puppet / PUP-10956
pkg provider cannot unhold and update package in the same run
Issue Type:
Bug
Affects Versions:
PUP 6.13.0, PUP 5.5.19, PUP 7.0.0
Assignee:
Unassigned
Created:
2021/03/09 5:27 AM
Priority:
Normal
Reporter:
Gabriel Nagy
Puppet Version: starting with 5.5.19, 6.13.0 and 7.0.0 Puppet Server Version: n/a OS Name/Version: Solaris 11 Describe your issue in as much detail as possible… After the addition of the mark property, a package cannot pe unheld and updated in the same run. Describe steps to reproduce… Assuming mypkg is installed with version 0.0.2, and held/frozen, apply the following manifest:
package {mypkg : ensure=>"0.0.3", mark=>"none", provider=>"pkg"}
Desired Behavior: The package is unheld/unfrozen, and updated to 0.0.3 Actual Behavior: Puppet attempts to update the package first, which results in:
Debug: Executing: '/usr/bin/pkg update -n mypkg@0.0.3,5.11:20210309T130735Z'
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title Dorin Pleava updated an issue Facter / FACT-2134 Facter should distinguish between CentOS 8 and CentOS 8 Stream Change By: Dorin Pleava Fix Version/s: FACT 4.0.52 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.336204.1574351826000.160752.1615296120028%40Atlassian.JIRA.
Jira (FACT-2936) Facter::Core::Exectuion set $? test is failing on OSX and Solaris
Title: Message Title Dorin Pleava updated an issue Facter / FACT-2936 Facter::Core::Exectuion set $? test is failing on OSX and Solaris Change By: Dorin Pleava Fix Version/s: FACT 4.0.52 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.386034.1612379676000.160747.1615294140029%40Atlassian.JIRA.
Jira (FACT-2926) Ensure all methods have rubydocs
Title: Message Title Dorin Pleava updated an issue Facter / FACT-2926 Ensure all methods have rubydocs Change By: Dorin Pleava Fix Version/s: FACT 4.0.52 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.385100.1611738907000.160746.1615294080108%40Atlassian.JIRA.
Jira (FACT-2915) Break the linux networking resolver into multiple classes
Title: Message Title Dorin Pleava updated an issue Facter / FACT-2915 Break the linux networking resolver into multiple classes Change By: Dorin Pleava Fix Version/s: FACT 4.0.52 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.383060.1610543877000.160745.1615294080051%40Atlassian.JIRA.
Jira (FACT-1847) Implement "cloud" fact Azure identification for Windows platform
Title: Message Title Gabriel Nagy updated an issue Facter / FACT-1847 Implement "cloud" fact Azure identification for Windows platform Change By: Gabriel Nagy Release Notes: Enhancement Release Notes Summary: Implement `cloud.provider` fact for Azure identification on Linux and Windows platforms. 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.247441.1524674206000.160719.1615288620038%40Atlassian.JIRA.
Jira (FACT-1847) Implement "cloud" fact Azure identification for Windows platform
Title: Message Title Gabriel Nagy updated an issue Facter / FACT-1847 Implement "cloud" fact Azure identification for Windows platform Change By: Gabriel Nagy Fix Version/s: FACT 4.0.0 Fix Version/s: FACT 4.0.52 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.247441.1524674206000.160718.1615288560041%40Atlassian.JIRA.
