Jira (FACT-1895) Executable and Structured data facts in .txt format to allow Boolean conversion
Title: Message Title Martin Ewings created an issue Facter / FACT-1895 Executable and Structured data facts in .txt format to allow Boolean conversion Issue Type: Improvement Assignee: Unassigned Created: 2018/11/27 5:23 AM Priority: Normal Reporter: Martin Ewings When interpreting a fact in a key Value pair either in a .txt file or in the return from an executable fact, see example: key1=true key2=false key3=true Currently this data type interprets only as a String. "true" and "false" are not identified as being boolean values, as they would in a JSON or YAML Structured data facts The request would be to either, allow for the interpretation of the key value pairs as boolean or to allow JSON or YAML formatted returns from Executable facts
Jira (HI-577) Standalone `hiera` command errors with hiera v5 config file
Title: Message Title
Martin Ewings updated an issue
Hiera / HI-577
Standalone `hiera` command errors with hiera v5 config file
Change By:
Martin Ewings
*Overview*Sometimes you need to use the standalone {{hiera}} command to debug a hierarchy when working with tools such as {{onceover}} or when setting up a whole {{puppet lookup}} environment is impractical.If this is attempted using the {{hiera}} command shipped in puppet-agent-1.10.5-1.el7.x86_64.rpm user will always encounter a confusing error if {{version}} is set to {{> 3}} in the {{hiera.yaml}} file*Expected result*Expect to be able to lookup data item on the command line using {{hiera}} command and hiera v5 config file*Actual result*User receives the error:{noformat} Failed to start Hiera: RuntimeError: v4 hiera.yaml is only to be used inside an environment or a module and cannot be given to the global hiera{noformat} *Steps to reporoduce*1. Hiera.yaml{noformat} ---version: 5defaults: datadir: hieradata data_hash: yaml_datahierarchy: - name: "Common data"path: "common.yaml"{noformat} 2. Lookup data as users:{noformat} hiera -c hiera.yaml ruh::rohFailed to start Hiera: RuntimeError: v4 hiera.yaml is only to be used inside an environment or a module and cannot be given to the global hiera{noformat} *Analysis*The error message seems to indicate that the hiera configuration file uses the old v4 format but it doesn't, its definitely version 5 and works fine with {{puppet lookup}} if dropped into the correct directory. Looking at the sourcecode, versions > 3 will allways encounter this error and Indeed the error can be cleared by declaring {{version: 3}} in the {{hiera.yaml}} file. I didn't check if this 'trick' still lets you work with hiera 5 functionality and wouldn't recommend it.*Workarounds*Setup the system to use {{puppet lookup}} \ (?)*Desired fix*I'm not sure what is supposed to happen here. I understand that hiera is now part of puppet but where does this leave the standalone hiera command? Is it intended to work at all? Is it deprecated in favour of {{puppet lookup}}? Is it only intended to work with {{hiera.yaml}} files v3 and earlier? Would be great to get some clarity around these issues as the error message about v4 configuration files is confusing when file is already in v5 format.
Jira (PUP-8766) puppet device fails with undefined method `loaders' for nil:NilClass when env is not production
Title: Message Title Martin Ewings updated an issue Puppet / PUP-8766 puppet device fails with undefined method `loaders' for nil:NilClass when env is not production Change By: Martin Ewings Method Found: Needs Assessment Customer Feedback 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-8766) puppet device fails with undefined method `loaders' for nil:NilClass when env is not production
Title: Message Title Martin Ewings updated an issue Puppet / PUP-8766 puppet device fails with undefined method `loaders' for nil:NilClass when env is not production Change By: Martin Ewings CS Priority: Needs Priority 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-8660) "puppet apply" should not ignore updated custom facts within the module under test
Title: Message Title Martin Ewings updated an issue Puppet / PUP-8660 "puppet apply" should not ignore updated custom facts within the module under test Change By: Martin Ewings CS Priority: Needs Priority Zendesk Ticket IDs: 29447 Zendesk Ticket Count: 1 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8660) "puppet apply" should not ignore updated custom facts within the module under test
Title: Message Title Martin Ewings updated an issue Puppet / PUP-8660 "puppet apply" should not ignore updated custom facts within the module under test Change By: Martin Ewings Zendesk Ticket IDs: 29447 Zendesk Ticket Count: 1 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8636) Don't prefetch if every resource using a provider is noop'd or no scheduled
Title: Message Title
Martin Ewings updated an issue
Puppet / PUP-8636
Don't prefetch if every resource using a provider is noop'd or no scheduled
Change By:
Martin Ewings
When a Particular Resource provider is defaulting to No-op or is part of a schedule which is not active, Puppet shouldn't prefetch any data relating to that provider in order to speed up compilation, for example: {code:java} schedule { 'narrow': range => '1:01 - 1:02', }Package <| provider == 'pkgutil' |> { schedule => 'narrow', } {code} this works in that the packages are skipped, the background provider tasks are still being completed:{code:java} Prefetching pkgutil resources for packageDebug: Executing: '/opt/csw/bin/pkgutil -a'Debug: Executing: '/opt/csw/bin/pkgutil -c'Debug: /Package[sudo]: Not scheduledDebug: /Package[sudo]: Resource is being skipped, unscheduling all eventsDebug: /Package[name]: Not scheduledDebug: /Package[name]: Resource is being skipped, unscheduling all events{code}
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-8636) Don't prefetch if every resource using a provider is noop'd or no scheduled
Title: Message Title Martin Ewings updated an issue Puppet / PUP-8636 Don't prefetch if every resource using a provider is noop'd or no scheduled Change By: Martin Ewings CS Priority: Needs Priority 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-8636) Don't prefetch if every resource using a provider is noop'd or no scheduled
Title: Message Title
Martin Ewings created an issue
Puppet / PUP-8636
Don't prefetch if every resource using a provider is noop'd or no scheduled
Issue Type:
New Feature
Assignee:
Unassigned
Created:
2018/04/06 7:16 AM
Priority:
Normal
Reporter:
Martin Ewings
When a Particular Resource provider is defaulting to No-op or is part of a schedule which is not active, Puppet shouldn't prefetch any data relating to that provider in order to speed up compilation, for example:
schedule { 'narrow':
range => '1:01 - 1:02',
}
Package <| provider == 'pkgutil' |> {
schedule => 'narrow',
Jira (FACT-1814) Mountpoints Fact available space does not accurately reflect disk usage
Title: Message Title
Martin Ewings updated an issue
Facter / FACT-1814
Mountpoints Fact available space does not accurately reflect disk usage
Change By:
Martin Ewings
PE 2017.2.2 ( facter 3.6.5) RHEL 6.8The customer is using mountpoints.(parition).available_bytes in conditional logic to determine if software should be installed on a system during Puppet Runs.In testing it appears that there is around a 400mb discrepancy between what is reported by facter as available, and what is actually available, which is backed up by df -h.In a test where by continual facter outputs and df outputs where collected during a large file transfer to the target partition, both facter and df -h tracked upwards in consumed disk space, but never agreed with each other, full attachments below, however a snippet can be seen here:{code:java}facter25687531522.39 GiB58.62%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 3.4G 2.1G 62% /varfacter25687531522.39 GiB58.62%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 3.4G 2.1G 62% /varfacter846790656773.65 MiB87.52%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.1G 431M 93% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter421269504401.75 MiB93.21%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 95M 99% /varfacter421269504401.75 MiB93.21%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 95M 99% /var{code}It could be that facter is failing to take into consideration the blocksize for the partition, in which case i have provided the output below: blockdev --getbsz /dev/mapper/vg_root-lv_var 4096 Used space seems also to agree where available does not: used => "5.39 GiB", for facter and 5.4G in df -h
Add Comment
Jira (FACT-1814) Mountpoints Fact available space does not accurately reflect disk usage
Title: Message Title
Martin Ewings updated an issue
Facter / FACT-1814
Mountpoints Fact available space does not accurately reflect disk usage
Change By:
Martin Ewings
PE 2017.2.2 ( facter 3.6.5) RHEL 6.8The customer is using mountpoints.(parition).available_bytes in conditional logging logic to determine if software should be installed on a system during Puppet Runs.In testing it appears that there is around a 400mb discrepancy between what is reported by facter as available, and what is actually available, which is backed up by df -h.In a test where by continual facter outputs and df outputs where collected during a large file transfer to the target partition, both facter and df -h tracked upwards in consumed disk space, but never agreed with each other, full attachments below, however a snippet can be seen here:{code:java}facter25687531522.39 GiB58.62%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 3.4G 2.1G 62% /varfacter25687531522.39 GiB58.62%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 3.4G 2.1G 62% /varfacter846790656773.65 MiB87.52%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.1G 431M 93% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter415592448396.34 MiB93.30%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 90M 99% /varfacter421269504401.75 MiB93.21%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 95M 99% /varfacter421269504401.75 MiB93.21%systemFilesystem Type Size Used Avail Use% Mounted on/dev/mapper/vg_root-lv_var ext4 5.8G 5.4G 95M 99% /var{code}It could be that facter is failing to take into consideration the blocksize for the partition, in which case i have provided the output below: blockdev --getbsz /dev/mapper/vg_root-lv_var 4096
Add Comment
Jira (FACT-1814) Mountpoints Fact available space does not accurately reflect disk usage
Title: Message Title Martin Ewings created an issue Facter / FACT-1814 Mountpoints Fact available space does not accurately reflect disk usage Issue Type: Bug Affects Versions: FACT 3.6.5 Assignee: Unassigned Attachments: output.txt Created: 2018/02/02 6:56 AM Priority: Normal Reporter: Martin Ewings PE 2017.2.2 ( facter 3.6.5) RHEL 6.8 The customer is using mountpoints.(parition).available_bytes in conditional logging to determine if software should be installed on a system during Puppet Runs. In testing it appears that there is around a 400mb discrepancy between what is reported by facter as available, and what is actually available, which is backed up by df -h. In a test where by continual facter outputs and df outputs where collected during a large file transfer to the target partition, both facter and df -h tracked upwards in consumed disk space, but never agreed with each other, full attachments below, however a snippet can be seen here:
Jira (PUP-3963) Error message gives wrong advice for allowed module names
Title: Message Title Martin Ewings commented on PUP-3963 Re: Error message gives wrong advice for allowed module names PR #6425 Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-3963) Error message gives wrong advice for allowed module names
Title: Message Title Martin Ewings assigned an issue to Martin Ewings Puppet / PUP-3963 Error message gives wrong advice for allowed module names Change By: Martin Ewings Assignee: Martin Ewings Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8123) Upper Case in class names is not working correctly
Title: Message Title Martin Ewings commented on PUP-8123 Re: Upper Case in class names is not working correctly Just retested, keeping the classname serVice but change the pp serVice.pp to service.pp seems to make this work, so looks like the case is only an issue in the filenames rather than the class names Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-8123) Upper Case in class names is not working correctly
Title: Message Title
Martin Ewings updated an issue
Puppet / PUP-8123
Upper Case in class names is not working correctly
Change By:
Martin Ewings
Since 4.10, upper case chars have been allowed in classnames so long as they match the following regex:\A[a-z][a-z0-9_]*\Zthe only stipulation on case is that the class must start with a lowercase letter, see the documentation below:https://puppet.com/docs/puppet/4.10/lang_reserved.html#classes-and-defined-resource-typesHowever in testing, i have modified the service class within the puppetlabs-ntp module, including filename and all class calls and declarations to ntp::serVice, when applying the init.pp example in this module i am presented with:{code}Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::ntp::service for hoytrc at /etc/puppetlabs/code/environments/production/modules/ntp/manifests/init.pp:132:3 on node hoytrc{code}note the reference to :ntp::service for line 132 of init.pp which is declared as:{code} contain ntp::serVice{code}it looks like there is some backend downcasing which is in conflict with expected behaviour.tested in PE2017.2.2 and PE2017.3.1 Original case reported from the field:{code} Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Could not find declared class splunk::apps::windows_TA_ad at /var/puppet/svn/env/modules/splunk/manifests/init_search.pp:25:6 on node itu302.acs.kadaster.nl Warning: Not using cache on failed catalog {code} {code} This is a class that defines a Splunk search-node. The last step is the installation of additional Splunk apps. The array $splunk_apps contains the names of Splunk apps to be installed (e.g., [ "unix_app", "sa_nix", "pa_nmon_light", "windows_TA_ad" ]). The apps have corresponding puppet-class. ``` {code} # Class splunk::init_search class splunk::init_search ($splunk_apps=hiera(splunk_server_apps)) {# include the params file so the there defined variables are available throughout the module include splunk::params $ar = prefix( $splunk_apps, 'splunk::apps::' )# flow control anchor{'splunk::init_search::begin':} -> class{'splunk::prereq_storage':} -> class{'splunk::swap':} -> class{'splunk::prereq':} -> class{'splunk::packages':} -> class{'splunk::install_proxy':} -> class{'splunk::search::install':} -> class{'splunk::splunk_nonroot':} -> class{'splunk::install':} -> class{'splunk::install_deplclient':} -> class{'splunk::search::config':} ~> class{'splunk::service':} -> anchor{'splunk::init_search::end':}Anchor['splunk::init_search::begin'] -> Class['splunk::search::config'] -> class{$ar: } -> Anchor['splunk::init_search::end']} {code}
Jira (PUP-8123) Upper Case in class names is not working correctly
Title: Message Title
Martin Ewings updated an issue
Puppet / PUP-8123
Upper Case in class names is not working correctly
Change By:
Martin Ewings
Since 4.10, upper case chars have been allowed in classnames so long as they match the following regex:\A[a-z][a-z0-9_]*\Zthe only stipulation on case is that the class must start with a lowercase letter, see the documentation below:https://puppet.com/docs/puppet/4.10/lang_reserved.html#classes-and-defined-resource-typesHowever in testing, i have modified the service class within the puppetlabs-ntp module, including filename and all class calls and declarations to ntp::serVice, when applying the init.pp example in this module i am presented with:{code}Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::ntp::service for hoytrc at /etc/puppetlabs/code/environments/production/modules/ntp/manifests/init.pp:132:3 on node hoytrc{code}note the reference to :ntp::service for line 132 of init.pp which is declared as:{code} contain ntp::serVice{code}it looks like there is some backend downcasing which is in conflict with expected behaviour.tested in PE2017.2.2 and PE2017.3.1 Original case reported from the field:{code} Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Could not find declared class splunk::apps::windows_TA_ad at /var/puppet/svn/env/modules/splunk/manifests/init_search.pp:25:6 on node itu302.acs.kadaster.nl Warning: Not using cache on failed catalog {code }{code} This is a class that defines a Splunk search-node. The last step is the installation of additional Splunk apps. The array $splunk_apps contains the names of Splunk apps to be installed (e.g., [ "unix_app", "sa_nix", "pa_nmon_light", "windows_TA_ad" ]). The apps have corresponding puppet-class.``` # Class splunk::init_search class splunk::init_search ($splunk_apps=hiera(splunk_server_apps)) {# include the params file so the there defined variables are available throughout the module include splunk::params $ar = prefix( $splunk_apps, 'splunk::apps::' )# flow control anchor{'splunk::init_search::begin':} -> class{'splunk::prereq_storage':} -> class{'splunk::swap':} -> class{'splunk::prereq':} -> class{'splunk::packages':} -> class{'splunk::install_proxy':} -> class{'splunk::search::install':} -> class{'splunk::splunk_nonroot':} -> class{'splunk::install':} -> class{'splunk::install_deplclient':} -> class{'splunk::search::config':} ~> class{'splunk::service':} -> anchor{'splunk::init_search::end':}Anchor['splunk::init_search::begin'] -> Class['splunk::search::config'] -> class{$ar: } -> Anchor['splunk::init_search::end']} {code}
Jira (PUP-8123) Upper Case in class names is not working correctly
Title: Message Title
Martin Ewings updated an issue
Puppet / PUP-8123
Upper Case in class names is not working correctly
Change By:
Martin Ewings
Since 4.10, upper case chars have been allowed in classnames so long as they match the following regex:\A[a-z][a-z0-9_]*\Zthe only stipulation on case is that the class must start with a lowercase letter, see the documentation below:https://puppet.com/docs/puppet/4.10/lang_reserved.html#classes-and-defined-resource-typesHowever in testing, i have modified the service class within the puppetlabs-ntp module, including filename and all class calls and declarations to ntp::serVice, when applying the init.pp example in this module i am presented with:{code}Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::ntp::service for hoytrc at /etc/puppetlabs/code/environments/production/modules/ntp/manifests/init.pp:132:3 on node hoytrc{code}note the reference to :ntp::service for line 132 of init.pp which is declared as:{code} contain ntp::serVice{code}it looks like there is some backend downcasing which is in conflict with expected behaviour.tested in PE2017.2.2 and PE2017.3.1 Original case reported from the field:{code} Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Could not find declared class splunk::apps::windows_TA_ad at /var/puppet/svn/env/modules/splunk/manifests/init_search.pp:25:6 on node itu302.acs.kadaster.nl Warning: Not using cache on failed catalog {code }{code} This is a class that defines a Splunk search-node. The last step is the installation of additional Splunk apps. The array $splunk_apps contains the names of Splunk apps to be installed (e.g., [ "unix_app", "sa_nix", "pa_nmon_light", "windows_TA_ad" ]). The apps have corresponding puppet-class.``` # Class splunk::init_search class splunk::init_search ($splunk_apps=hiera(splunk_server_apps)) {# include the params file so the there defined variables are available throughout the module include splunk::params $ar = prefix( $splunk_apps, 'splunk::apps::' )# flow control anchor{'splunk::init_search::begin':} -> class{'splunk::prereq_storage':} -> class{'splunk::swap':} -> class{'splunk::prereq':} -> class{'splunk::packages':} -> class{'splunk::install_proxy':} -> class{'splunk::search::install':} -> class{'splunk::splunk_nonroot':} -> class{'splunk::install':} -> class{'splunk::install_deplclient':} -> class{'splunk::search::config':} ~> class{'splunk::service':} -> anchor{'splunk::init_search::end':}Anchor['splunk::init_search::begin'] -> Class['splunk::search::config'] -> class{$ar: } -> Anchor['splunk::init_search::end']} {code}
Jira (PUP-8123) Upper Case in class names is not working correctly
Title: Message Title Martin Ewings created an issue Puppet / PUP-8123 Upper Case in class names is not working correctly Issue Type: Bug Affects Versions: PUP 5.3.2, PUP 4.10.0 Assignee: Unassigned Created: 2017/11/03 7:24 AM Priority: Major Reporter: Martin Ewings Since 4.10, upper case chars have been allowed in classnames so long as they match the following regex: \A[a-z][a-z0-9_]*\Z the only stipulation on case is that the class must start with a lowercase letter, see the documentation below: https://puppet.com/docs/puppet/4.10/lang_reserved.html#classes-and-defined-resource-types However in testing, i have modified the service class within the puppetlabs-ntp module, including filename and all class calls and declarations to ntp::serVice, when applying the init.pp example in this module i am presented with: Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::ntp::service for hoytrc at /etc/puppetlabs/code/environments/production/modules/ntp/manifests/init.pp:132:3 on node hoytrc
Jira (PUP-7326) Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts
Title: Message Title Martin Ewings updated an issue Puppet / PUP-7326 Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts Change By: Martin Ewings Zendesk Ticket IDs: 27785 Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7326) Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts
Title: Message Title Martin Ewings updated an issue Puppet / PUP-7326 Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts Change By: Martin Ewings Zendesk Ticket IDs: 27785 Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7326) Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts
Title: Message Title Martin Ewings updated an issue Puppet / PUP-7326 Group resource (with auth_membership) failes if local Winows group contains not resolvable Domain accounts Change By: Martin Ewings Method Found: Customer Feedback 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 (FACT-1782) Facter.flush not working as expected in Facter 3.x
Title: Message Title Martin Ewings updated an issue Facter / FACT-1782 Facter.flush not working as expected in Facter 3.x Change By: Martin Ewings Method Found: Needs Assessment Customer Feedback 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-3684) PDB performance issues with large structured facts
Title: Message Title Martin Ewings updated an issue PuppetDB / PDB-3684 PDB performance issues with large structured facts Change By: Martin Ewings As _emphasized text_As outlined in PDB-2631, PuppetDB encounters severe performance degradation in the presence of large structured facts. In support, we have seen this impact with mountpoint or partitions facts of only 20-30 KiB, which is not terribly uncommon. As noted in that ticket, the expectation is that PDB will be able to handle anything Facter might throw at it.This issue was resolved in PDB-3249, but the fix was removed by PDB-3611. We need a solution that will allow large structured facts to be stored in PDB without causing causing query performance issues. 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-3684) PDB performance issues with large structured facts
Title: Message Title Martin Ewings updated an issue PuppetDB / PDB-3684 PDB performance issues with large structured facts Change By: Martin Ewings _emphasized text_As As outlined in PDB-2631, PuppetDB encounters severe performance degradation in the presence of large structured facts. In support, we have seen this impact with mountpoint or partitions facts of only 20-30 KiB, which is not terribly uncommon. As noted in that ticket, the expectation is that PDB will be able to handle anything Facter might throw at it.This issue was resolved in PDB-3249, but the fix was removed by PDB-3611. We need a solution that will allow large structured facts to be stored in PDB without causing causing query performance issues. 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 (FACT-1767) AIX processor facts return "mismatched processor frequencies found; facter will only report one of them" on every puppet run
Title: Message Title Martin Ewings created an issue Facter / FACT-1767 AIX processor facts return "mismatched processor frequencies found; facter will only report one of them" on every puppet run Issue Type: Bug Assignee: Unassigned Created: 2017/09/29 6:43 AM Priority: Normal Reporter: Martin Ewings On AIX facter reports warnings every puppet run. example: puppet agent --t Notice: Local environment: 'production' doesn't match server specified node environment 'dev', switching agent to 'dev'. Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Warning: Facter: mismatched processor frequencies found; facter will only report one of them Info: Caching catalog for ** Info: Applying configuration version '1506588051' ... Comment related to this message from the project in github: https://github.com/puppetlabs/facter/pull/1112/files#r37475092 ( FACT-970 ) The output from the OS for the CPU in question:
Jira (PUP-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Martin Ewings updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way customer notes that is an annoyance if you have e.g. a forge module and files on some non-default paths for which you need to add fcontext rules. Forge modules normally don't explicitly set selcontext on file resources (or allow to pass the value to use). Either you fixup the module code locally or restart the agent-daemon to complete the "automated" installation. Having setting selinux_ignore_defaults results in getting the selinux fcontext from the parent directory which is also not the correct behaviour. 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-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Martin Ewings updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way Change By: Martin Ewings CS Priority: Normal CS Severity: 2 - Annoyance CS Business Value: 1 - ? CS Frequency: 1 - 1-5% of Customers 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-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Martin Ewings updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way Change By: Martin Ewings Affects Version/s: PUP 4.10.5 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-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Martin Ewings updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way Change By: Martin Ewings Environment: CentOS 7 with Puppet 4.8.2 (puppet-agent 1.8.3)Fedora 25 with Puppet 4.8.2 (puppet-agent 1.8.3)CentOS 6.5 x86_64 Puppet 3.4.3 from Puppetlabs repositoryCentOS 6 with Puppet 3.8.7 from Pupptlabs Repo Rhel 7.3 PE 2016.4.7 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-2169) Not possible to manage SELinux file contexts via puppet in a sane way
Title: Message Title Martin Ewings updated an issue Puppet / PUP-2169 Not possible to manage SELinux file contexts via puppet in a sane way Change By: Martin Ewings Method Found: Customer Feedback 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-3684) PDB performance issues with large structured facts
Title: Message Title Martin Ewings updated an issue PuppetDB / PDB-3684 PDB performance issues with large structured facts Change By: Martin Ewings Method Found: Customer Feedback 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-7749) Puppet to read "X509v3 Extended Key Usage" for trusted facts
Title: Message Title Martin Ewings updated an issue Puppet / PUP-7749 Puppet to read "X509v3 Extended Key Usage" for trusted facts Change By: Martin Ewings h2. RequestRequest for the ability of puppet server to read custom fact extensions from the *strong text* X509v3 Extended Key Usage section of the certificate.h2. ExplanationWhen using and an external CA, it is sometimes not possible to place trusted fact objects in the top-level extension section: X509v3 extensions h2. Example For example, the standard offering from Microsoft facilitates adding data into the "X509v3 Extended Key Usage", which puppet server does not read from. 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-7749) Puppet to read "X509v3 Extended Key Usage" for trusted facts
Title: Message Title Martin Ewings updated an issue Puppet / PUP-7749 Puppet to read "X509v3 Extended Key Usage" for trusted facts Change By: Martin Ewings h2. RequestRequest for the ability of puppet server to read custom fact extensions from the * strong text* X509v3 Extended Key Usage * section of the certificate.h2. ExplanationWhen using and external CA, it is sometimes not possible to place trusted fact objects in the top-level extension section: * X509v3 extensions * h2. Example For example, the standard offering from Microsoft facilitates adding data into the " X*509v3 X509v3 Extended Key Usage * ", which puppet server does not read from. 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-7749) Puppet to read "X509v3 Extended Key Usage" for trusted facts
Title: Message Title Martin Ewings created an issue Puppet / PUP-7749 Puppet to read "X509v3 Extended Key Usage" for trusted facts Issue Type: New Feature Assignee: Unassigned Components: Puppet Server Created: 2017/07/03 7:58 AM Priority: Normal Reporter: Martin Ewings Request Request for the ability of puppet server to read custom fact extensions from the *X509v3 Extended Key Usage *section of the certificate. Explanation When using and external CA, it is sometimes not possible to place trusted fact objects in the top-level extension section: * X509v3 extensions * Example For example, the standard offering from Microsoft facilitates adding data into the " X*509v3 Extended Key Usage*", which puppet server does not read from. Add Comment
Jira (PUP-7580) Change assignment of (NameVar) in exec resources
Title: Message Title Martin Ewings created an issue Puppet / PUP-7580 Change assignment of (NameVar) in exec resources Issue Type: New Feature Assignee: Unassigned Components: Language Created: 2017/05/22 3:00 AM Priority: Normal Reporter: Martin Ewings Currently the namvar attribute of the exec resource is assigned to the command attribute. meaning the name of the resource when printed into resources.txt is the executed parameter. This could be considered a security issue, but also makes it difficult to name resources uniquely. A request for a name attribute or the ability to use the title as the namevar. Add Comment
