Jira (PUP-4705) RFC: Locally-scoped blocks
Title: Message Title
Greg Larkin created an issue
Puppet / PUP-4705
RFC: Locally-scoped blocks
Issue Type:
New Feature
Assignee:
Unassigned
Components:
Language
Created:
2015/06/05 3:27 PM
Priority:
Normal
Reporter:
Greg Larkin
In C (and other) programming languages, locally-scoped blocks are useful for overriding some behavior in a small area of a source code file, as seen here: http://en.wikibooks.org/wiki/Introduction_to_Programming_Languages/Scoping_with_Blocks
The Puppet DSL does not appear to suppose this construct, and I thought it might be useful for something like this:
class myclass {
# Class-scope resource default
File {
Jira (PUP-4705) RFC: Locally-scoped blocks
Title: Message Title
Greg Larkin updated an issue
Puppet / PUP-4705
RFC: Locally-scoped blocks
Change By:
Greg Larkin
In the C (and other) programming languages, locally-scoped blocks are useful for overriding some behavior in a small area of a source code file, as seen here: http://en.wikibooks.org/wiki/Introduction_to_Programming_Languages/Scoping_with_BlocksThe Puppet DSL does not appear to suppose this construct, and I thought it might be useful for something like this:{code}class myclass { # Class-scope resource default File {ensure => file,mode => '0644', } {# Local-scope resource default - to be combined with class-scope resource defaultFile { owner => 'oracle', group => 'oracle',}# list of file resources to manage files owned by the 'oracle/oracle' user# ...# ... } {# Local-scope resource default - to be combined with class-scope resource defaultFile { owner => 'root', group => 'root',}# list of file resources to manage files owned by the 'root/root' user# ...# ... }}{code}This is just one potential use case, and others would include the use of variables within these arbitrary scope blocks.I'm interested to know if anyone else thinks this would be useful or not.
Add Comment
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this gr
Jira (PUP-4706) Add resource sample usage to output of puppet describe
Title: Message Title Greg Larkin created an issue Puppet / PUP-4706 Add resource sample usage to output of puppet describe Issue Type: New Feature Assignee: Unassigned Created: 2015/06/05 4:28 PM Priority: Normal Reporter: Greg Larkin In a recent Puppet Fundamentals class, a student noted that UNIX man pages often include an example of the command, file format or whatever is documented. He asked for an enhancement to the output of "puppet describe" to show the same thing. I checked a couple of resources (package, file), and they both include examples of usage, but they are interleaved with the attribute descriptions. Is it possible to build another field into the output of the command so an optional example could be displayed at the top? Add Comment
Jira (PUP-4706) Add resource sample usage to output of puppet describe
Title: Message Title Greg Larkin commented on PUP-4706 Re: Add resource sample usage to output of puppet describe Fair enough - thank you, Henrik Lindberg! Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4705) RFC: Locally-scoped blocks
Title: Message Title Greg Larkin commented on PUP-4705 Re: RFC: Locally-scoped blocks Thanks very much for the example code, Henrik Lindberg, I'll keep that in mind for the future! Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1380) Restore --timing option to native facter
Title: Message Title Greg Larkin created an issue Facter / FACT-1380 Restore --timing option to native facter Issue Type: Improvement Assignee: Unassigned Created: 2016/03/30 4:17 PM Priority: Normal Reporter: Greg Larkin A PSE in the field reports that running native Facter on Windows spikes the CPU for a few seconds on each run. The --timing option previously available in facter is no longer present in native facter, making it difficult to determine where the problem is. Restoring the --timing option would make it easier to debug this problem. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6214) Confusing error message displayed when using incorrect value with scheduled_task resource
Title: Message Title
Greg Larkin created an issue
Puppet / PUP-6214
Confusing error message displayed when using incorrect value with scheduled_task resource
Issue Type:
Bug
Assignee:
Unassigned
Components:
DSL
Created:
2016/04/21 11:13 AM
Priority:
Normal
Reporter:
Greg Larkin
I recently used a scheduled_task resource and coded the trigger section incorrectly like so:
scheduled_task { 'defrag C':
ensure => present,
enabled => true,
Jira (PUP-6214) Confusing error message displayed when using incorrect value with scheduled_task resource
Title: Message Title Greg Larkin updated an issue Puppet / PUP-6214 Confusing error message displayed when using incorrect value with scheduled_task resource I guess this isn't really a bug since the documentation is clear about the correct usage, so I'm changing this to an improvement request for the error message. Change By: Greg Larkin Issue Type: Bug Improvement Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6329) puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename
Title: Message Title
Greg Larkin created an issue
Puppet / PUP-6329
puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename
Issue Type:
Bug
Assignee:
Kylo Ginsberg
Components:
Client
Created:
2016/05/19 3:53 PM
Priority:
Normal
Reporter:
Greg Larkin
I created a file named /tmp/foo/fo©.txt with some text in it. Then I wrote the following manifest and invoked it with puppet apply:
file { '/Users/glarkin/tmp':
source => '/private/tmp/foo',
ensure => directory,
Jira (PUP-6857) Puppet language specification doesn't call out use of metadata.json
Title: Message Title Greg Larkin created an issue Puppet / PUP-6857 Puppet language specification doesn't call out use of metadata.json Issue Type: Bug Assignee: Unassigned Components: Language Specification Created: 2016/11/01 10:57 AM Priority: Normal Reporter: Greg Larkin A discussion in Slack about function loading indicated that dependency information in the metadata.json file is used by Puppet during the compilation phase. The Puppet language specification does not mention the use of the metadata.json file, and it should be clarified to do so. Add Comment
Jira (PUP-6857) Puppet language specification doesn't call out use of metadata.json
Title: Message Title Greg Larkin updated an issue Puppet / PUP-6857 Puppet language specification doesn't call out use of metadata.json Change By: Greg Larkin A discussion in Slack about function loading indicated that dependency information in the metadata.json file is used by Puppet during the compilation phase. The Puppet language specification does not mention the use of the metadata.json file, and it should be clarified to do so. Reference: https://puppetcommunity.slack.com/archives/puppet/p1478021975008061 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-7097) Support progress reporting for long-running commands invoked by providers during "puppet apply"
Title: Message Title Greg Larkin created an issue Puppet / PUP-7097 Support progress reporting for long-running commands invoked by providers during "puppet apply" Issue Type: New Feature Assignee: Unassigned Created: 2017/01/12 10:27 AM Priority: Normal Reporter: Greg Larkin I would be interested to know if it's possible to add a callback mechanism to the types & providers framework so a provider can supply progress information to Puppet during "puppet apply" runs. Some providers may call long-running commands, such as curl on a large download file, and where possible, it would be an improved user experience to see how much time the operation will take. I expect this would be most useful during "puppet apply" and perhaps "puppet agent -t" running in the foreground. I envision a possible implementation using a callback mechanism. If supplied by a particular T&P, Puppet could query its progress percentage callback and report back to the user in realtime. Of course, the T&P would need to be able to extract this information from the underlying command or perhaps supply an estimate based on a calculation of some kind. Feedback and criticism of this idea are welcome! Add Comment
Jira (PUP-6329) puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename
Title: Message Title Greg Larkin updated an issue Puppet / PUP-6329 puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename Change By: Greg Larkin Affects Version/s: PUP 4.9.4 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-6329) puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename
Title: Message Title Greg Larkin commented on PUP-6329 Re: puppet apply fails with "Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII" with non-ASCII filename Hi Ethan Brown, I just tried it again with the same result using version 4.9.4. I should have specified that I originally tested this on my Mac, and I just retested on the same machine. Here is the output: $ puppet apply /tmp/foo/fo©.txt WARN: Unresolved specs during Gem::Specification.reset: hiera (< 4, >= 2.0) WARN: Clearing out unresolved specs. Please report a bug if this causes problems. Notice: Compiled catalog for gregorys-mbp-2 in environment production in 0.11 seconds Notice: /Stage[main]/Main/File[/Users/glarkin/tmp]/ensure: created Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII Error: Could not set 'file' on ensure: invalid byte sequence in US-ASCII
Jira (PUP-9241) Verify Hiera access to locally-scoped variables
Title: Message Title Greg Larkin commented on PUP-9241 Re: Verify Hiera access to locally-scoped variables Thank you Claire Cadman and not sure yet Henrik Lindberg, but I have asked the customer to supply his sample code, and he said he will do that tomorrow. I'll attach it here as soon as I get it. 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-9241) Verify Hiera access to locally-scoped variables
Title: Message Title
Greg Larkin commented on PUP-9241
Re: Verify Hiera access to locally-scoped variables
The customer (Richard Lawson @ Merrill Corp) sent this follow-up email with the details of his configuration: noformat Here’s a follow-up to our Slack discussion last week. Here is a shortened example. We have very long URI's that look like this: /subscriptions/123456789012345678901234567890123456789012345678901234567890/my_vnet_name/providers/Microsoft.Network/routeTables/directinternet I decided to shorten that a little. The long string after subscriptions is the subscription ID, and it is passed as a custom fact called azure_subscription_id. And since we're only managing resource group-based resources, I wanted to make the URI's a little easier to read by creating this abbreviation in the init.pp: subid = "/subscriptions/${azure_subscription_id}/resourceGroups" So that would turn the above URI into: "% {subid}/my_vnet_name/Microsoft.Network/routeTables/directinternet"Which seemed a little more readable to me.The documentation seemed to support setting up local scope variables in init.pp and passing them to hiera. So I tried it. Here was the hiera I set up. It is considerably condensed. (You should know we have a custom fact called "sub_name" that includes a list of resource groups called "rgs".)hiera.yaml:— version: 5 hierarchy: - name: 'Vnets' mapped_paths: [azure_subscription_resource_groups, this_rg, "%{azure_subscription_name}/vnets/%{this_rg}.yaml"] - name: 'Resource Groups' path: "%{azure_subscription_name}/resource_groups.yaml" - name: 'Common' path: 'common.yaml' defaults: data_hash: yaml_data datadir: 'data'data/common.yaml:— lookup_options: mrll_azure::subscription: merge: deep mrll_azure::subscription: # Nothing gets defined here my_subscription_name:data/my_subscription_name/resource_groups.yaml— mrll_azure::subscription: my_subscription_name: resource_groups: my_resource_group: ensure: present location: eastus2data/my_subscription_name/vnets/my_resource_group.yaml:— mrll_azure::subscription: my_subscription_name: resource_groups: my_resource_group: vnets: my_vnet: ensure: present resource_group_name: my_resource_group parameters: {} location: eastus2 properties: addressSpace: addressPrefixes: - 10.1.0.0/16 subnets: - name: my_subnet properties: addressPrefix: 10.1.1.0/24 routeTable: id: "%{subid} /my_vnet_name/providers/Microsoft.Network/routeTables/directinternet" manifests/init.pp: class mrll_azure ( $subscription, ) { subid = "/subscriptions/${azure_subscription_id}/resourceGroups" $subscription[$facts['sub_name']]['rgs'].each | $rg_name, $rg_info | { azure_resource_group { $rg_name: ensure => $rg_info['ensure'], parameters => {}, location => $rg_info['location'], } $rg_info['vnets'].each | $vnet_name, $vnet_info | { azure_virtual_network { $vnet_name: * => $vnet_info, } } } } This... did not work at all. Puppet failed evaluating $sub_id. I then commented out the line in init.pp where I defined subid. Next I went into the PE console set up a variable underneath the classification node group called "subid" with the value "/subscriptions/${azure_subscription_id}/resourceGroups". That worked fine and produced no errors and applied the proper values. So I'm not certain exactly how the local scope includes variables set in the classification node group on the PE Console and not variables set in init.pp. Let me know if you need any more info. I'm willing to give a live demonstration of this. Richard Lawson Cloud Services Engineer Merrill Corporation 221 North 1st Street Suite 370 Minneapolis, MN 55401 richard.l
Jira (PUP-9241) Verify Hiera access to locally-scoped variables
Title: Message Title
Greg Larkin updated an issue
Puppet / PUP-9241
Verify Hiera access to locally-scoped variables
Change By:
Greg Larkin
Comment:
The customer (Richard Lawson @ Merrill Corp) sent this follow-up email with the details of his configuration:{{noformat}}Here’s a follow-up to our Slack discussion last week. Here is a shortened example. We have very long URI's that look like this: /subscriptions/123456789012345678901234567890123456789012345678901234567890/my_vnet_name/providers/Microsoft.Network/routeTables/directinternet I decided to shorten that a little. The long string after subscriptions is the subscription ID, and it is passed as a custom fact called azure_subscription_id. And since we're only managing resource group-based resources, I wanted to make the URI's a little easier to read by creating this abbreviation in the init.pp: subid = "/subscriptions/${azure_subscription_id}/resourceGroups" So that would turn the above URI into: "%{subid}/my_vnet_name/Microsoft.Network/routeTables/directinternet" Which seemed a little more readable to me. The documentation seemed to support setting up local scope variables in init.pp and passing them to hiera. So I tried it. Here was the hiera I set up. It is considerably condensed. (You should know we have a custom fact called "sub_name" that includes a list of resource groups called "rgs".) hiera.yaml: --- version: 5 hierarchy:- name: 'Vnets' mapped_paths: [azure_subscription_resource_groups, this_rg, "%{azure_subscription_name}/vnets/%{this_rg}.yaml"]- name: 'Resource Groups' path: "%{azure_subscription_name}/resource_groups.yaml"- name: 'Common' path: 'common.yaml' defaults:data_hash: yaml_datadatadir: 'data' data/common.yaml: ---lookup_options: mrll_azure::subscription: merge: deepmrll_azure::subscription: # Nothing gets defined here my_subscription_name: data/my_subscription_name/resource_groups.yaml ---mrll_azure::subscription: my_subscription_name: resource_groups: my_resource_group: ensure: present location: eastus2 data/my_subscription_name/vnets/my_resource_group.yaml: ---mrll_azure::subscription: my_subscription_name: resource_groups:my_resource_group: vnets:my_vnet: ensure: present resource_group_name: my_resource_group parameters: {} location: eastus2 properties:addressSpace: addressPrefixes:- 10.1.0.0/16subnets: - name: my_subnetproperties: addressPrefix: 10.1.1.0/24 routeTable: id: "%{subid}/my_vnet_name/providers/Microsoft.Network/routeTables/directinternet" manifests/init.pp: class mrll_azure ( $subscription, ) { subid = "/subscriptions/${azure_subscription_id}/resourceGroups" $subscription[$facts['sub_name']]['rgs'].each | $rg_name, $rg_info | {azure_resource_group { $rg_name: ensure => $rg_info['ensure'], parameters => {}, location => $rg_info['location'],}$rg_info['vnets'].each | $vnet_name, $vnet_info | { azure_virtual_network { $vnet_name:* => $v
Jira (PUP-9241) Verify Hiera access to locally-scoped variables
Title: Message Title Greg Larkin commented on PUP-9241 Re: Verify Hiera access to locally-scoped variables Henrik Lindberg - Just added the contents of the email I received from the customer. From what I can see, the APL for mrll_azure::subscription occurs as the class parameter list is evaluated. At that point in time, the "subid" variable has not been assigned, so I'm assuming that's why it cannot be referenced in the Hiera data unless there is some provision for lazy evaluation. But it sounds like from his experience, that's not the case. Can you confirm that for me when you have a chance? If what I'm thinking is true, then maybe a small documentation update could include some verbiage that says referenced local variables have to be defined at the time the Hiera lookup occurs. 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-9241) Verify Hiera access to locally-scoped variables
Title: Message Title
Greg Larkin commented on PUP-9241
Re: Verify Hiera access to locally-scoped variables
Here’s a follow-up to our Slack discussion last week. Here is a shortened example. We have very long URI's that look like this: /subscriptions/123456789012345678901234567890123456789012345678901234567890/my_vnet_name/providers/Microsoft.Network/routeTables/directinternet I decided to shorten that a little. The long string after subscriptions is the subscription ID, and it is passed as a custom fact called azure_subscription_id. And since we're only managing resource group-based resources, I wanted to make the URI's a little easier to read by creating this abbreviation in the init.pp: subid = "/subscriptions/${azure_subscription_id}/resourceGroups" So that would turn the above URI into: "% {subid}/my_vnet_name/Microsoft.Network/routeTables/directinternet" Which seemed a little more readable to me. The documentation seemed to support setting up local scope variables in init.pp and passing them to hiera. So I tried it. Here was the hiera I set up. It is considerably condensed. (You should know we have a custom fact called "sub_name" that includes a list of resource groups called "rgs".) hiera.yaml: — version: 5 hierarchy: - name: 'Vnets' mapped_paths: [azure_subscription_resource_groups, this_rg, "%{azure_subscription_name}/vnets/%{this_rg}.yaml"] - name: 'Resource Groups' path: "%{azure_subscription_name}/resource_groups.yaml" - name: 'Common' path: 'common.yaml' defaults: data_hash: yaml_data datadir: 'data' data/common.yaml: — lookup_options: mrll_azure::subscription: merge: deep mrll_azure::subscription: # Nothing gets defined here my_subscription_name: data/my_subscription_name/resource_groups.yaml — mrll_azure::subscription: my_subscription_name: resource_groups: my_resource_group: ensure: present location: eastus2 data/my_subscription_name/vnets/my_resource_group.yaml: — mrll_azure::subscription: my_subscription_name: resource_groups: my_resource_group: vnets: my_vnet: ensure: present resource_group_name: my_resource_group parameters: {} location: eastus2 properties: addressSpace: addressPrefixes: - 10.1.0.0/16 subnets: - name: my_subnet properties: addressPrefix: 10.1.1.0/24 routeTable: id: "%{subid} /my_vnet_name/providers/Microsoft.Network/routeTables/directinternet" manifests/init.pp: class mrll_azure ( $subscription, ) { subid = "/subscriptions/${azure_subscription_id}/resourceGroups" $subscription[$facts['sub_name']]['rgs'].each | $rg_name, $rg_info | { azure_resource_group { $rg_name: ensure => $rg_info['ensure'], parameters => {}, location => $rg_info['location'], } $rg_info['vnets'].each | $vnet_name, $vnet_info | { azure_virtual_network { $vnet_name: * => $vnet_info, } } } } This... did not work at all. Puppet failed evaluating $sub_id. I then commented out the line in init.pp where I defined subid. Next I went into the PE console set up a variable underneath the classification node group called "subid" with the value "/subscriptions/${azure_subscription_id}/resourceGroups". That worked fine and produced no errors and applied the proper values. So I'm not certain exactly how the local scope includes variables se
Jira (PDB-3769) PuppetDB fails to find facts and emits maximum row size exception
Title: Message Title
Greg Larkin updated an issue
PuppetDB / PDB-3769
PuppetDB fails to find facts and emits maximum row size exception
Change By:
Greg Larkin
During a Puppet training class, the instructor reported the following error when running { { puppet agent -t} } on the master node:{{noformat}}# puppet agent -tWarning: Unable to fetch my node definition, but the agent run will continue:Warning: Error 500 on SERVER: Server Error: Failed to find facts from PuppetDB at master.puppetlabs.vm:8140: Failed to execute '/pdb/query/v4/nodes/master.puppetlabs.vm/facts' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed to execute '/pdb/cmd/v1?checksum=5d6dd93a53a2cc28ba8ca23fb9c3e43e13222625&version=5&certname=master.puppetlabs.vm&command=replace_facts&producer-timestamp=1512059310' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Warning: Not using cache on failed catalogError: Could not retrieve catalog; skipping run{{noformat}}Restarting PDB did not resolve the error, and "telnet localhost 8080" resulted in a "connection refused" message after PDB started up. The following exception appeared in the PDB log file at one point:{{noformat}}2017-11-30 14:35:23,996 INFO [p.p.command] [2150-1512052523941] [39 ms] 'replace facts' command processed for debeard.puppetlabs.vm2017-11-30 14:35:25,529 ERROR [p.p.command] [2,151] [replace catalog] Retrying after attempt 0 for debeard.puppetlabs.vm, due to: org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2284)at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2003)at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:200)at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:424)at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:161){{noformat}}The directory {/opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q} contained a few JSON files, and they have been attached to this ticket for analysis, along with the relevant log files
Jira (PDB-3769) PuppetDB fails to find facts and emits maximum row size exception
Title: Message Title Greg Larkin created an issue PuppetDB / PDB-3769 PuppetDB fails to find facts and emits maximum row size exception Issue Type: Bug Assignee: Unassigned Created: 2017/11/30 9:17 AM Priority: Normal Reporter: Greg Larkin During a Puppet training class, the instructor reported the following error when running puppet agent -t on the master node: noformat puppet agent -t Warning: Unable to fetch my node definition, but the agent run will continue: Warning: Error 500 on SERVER: Server Error: Failed to find facts from PuppetDB at master.puppetlabs.vm:8140: Failed to execute '/pdb/query/v4/nodes/master.puppetlabs.vm/facts' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081 Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed to execute '/pdb/cmd/v1?checksum=5d6dd93a53a2cc28ba8ca23fb9c3e43e13222625&version=5&certname=master.puppetlabs.vm&command=replace_facts&producer-timestamp=1512059310' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081 Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run noformat Restarting PDB did not resolve the error, and "telnet localhost 8080" resulted in a "connection refused" message after PDB started up. The following exception appeared in the PDB log file at one point: noformat 2017-11-30 14:35:23,996 INFO [p.p.command] [2150-1512052523941] [39 ms] 'replace facts' command processed for debeard.puppetlabs.vm 2017-11-30 14:35:25,529 ERROR [p.p.command] [2,151] [replace cat
Jira (PDB-3769) PuppetDB fails to find facts and emits maximum row size exception
Title: Message Title Greg Larkin updated an issue PuppetDB / PDB-3769 PuppetDB fails to find facts and emits maximum row size exception Change By: Greg Larkin Attachment: pdb_logs.zip Attachment: pdb_command_queue.zip Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-3769) PuppetDB fails to find facts and emits maximum row size exception
Title: Message Title
Greg Larkin updated an issue
PuppetDB / PDB-3769
PuppetDB fails to find facts and emits maximum row size exception
Change By:
Greg Larkin
During a Puppet training class, the instructor reported the following error when running { { puppet agent -t} } on the master node:{ { noformat} } # puppet agent -tWarning: Unable to fetch my node definition, but the agent run will continue:Warning: Error 500 on SERVER: Server Error: Failed to find facts from PuppetDB at master.puppetlabs.vm:8140: Failed to execute '/pdb/query/v4/nodes/master.puppetlabs.vm/facts' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed to execute '/pdb/cmd/v1?checksum=5d6dd93a53a2cc28ba8ca23fb9c3e43e13222625&version=5&certname=master.puppetlabs.vm&command=replace_facts&producer-timestamp=1512059310' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Warning: Not using cache on failed catalogError: Could not retrieve catalog; skipping run{ { noformat} } Restarting PDB did not resolve the error, and "telnet localhost 8080" resulted in a "connection refused" message after PDB started up. The following exception appeared in the PDB log file at one point:{ { noformat} } 2017-11-30 14:35:23,996 INFO [p.p.command] [2150-1512052523941] [39 ms] 'replace facts' command processed for debeard.puppetlabs.vm2017-11-30 14:35:25,529 ERROR [p.p.command] [2,151] [replace catalog] Retrying after attempt 0 for debeard.puppetlabs.vm, due to: org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2284)at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2003)at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:200)at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:424)at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:161){ { noformat} } The directory { { /opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q} } contained a few JSON files, and they have been attached to this ticket for analysis, along with the relevant log files
Jira (PDB-3769) PuppetDB fails to find facts and emits maximum row size exception
Title: Message Title
Greg Larkin updated an issue
PuppetDB / PDB-3769
PuppetDB fails to find facts and emits maximum row size exception
Change By:
Greg Larkin
During a Puppet training class, the instructor reported the following error when running {{puppet agent -t}} on the master node:{noformat}# puppet agent -tWarning: Unable to fetch my node definition, but the agent run will continue:Warning: Error 500 on SERVER: Server Error: Failed to find facts from PuppetDB at master.puppetlabs.vm:8140: Failed to execute '/pdb/query/v4/nodes/master.puppetlabs.vm/facts' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Failed to execute '/pdb/cmd/v1?checksum=5d6dd93a53a2cc28ba8ca23fb9c3e43e13222625&version=5&certname=master.puppetlabs.vm&command=replace_facts&producer-timestamp=1512059310' on at least 1 of the following 'server_urls': https://master.puppetlabs.vm:8081Warning: Not using cache on failed catalogError: Could not retrieve catalog; skipping run{noformat}Restarting PDB did not resolve the error, and "telnet localhost 8080" resulted in a "connection refused" message after PDB started up. The following exception appeared in the PDB log file at one point:{noformat}2017-11-30 14:35:23,996 INFO [p.p.command] [2150-1512052523941] [39 ms] 'replace facts' command processed for debeard.puppetlabs.vm2017-11-30 14:35:25,529 ERROR [p.p.command] [2,151] [replace catalog] Retrying after attempt 0 for debeard.puppetlabs.vm, due to: org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.org.postgresql.util.PSQLException: ERROR: index row size 6144 exceeds maximum 2712 for index "catalog_resources_type_title_idx" Hint: Values larger than 1/3 of a buffer page cannot be indexed.Consider a function index of an MD5 hash of the value, or use full text indexing.at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2284)at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2003)at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:200)at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:424)at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:161){noformat}The directory {{/opt/puppetlabs/server/data/puppetdb/stockpile/cmd/q}} contained a few JSON files, and they have been attached to this ticket for analysis, along with the relevant log files .This problem was worked around by stopping PDB, moving the queue directory aside, and then restarting PDB. After that, the agent run completed successfully, possibly indicating some corrupted data in one of the attached JSON files.
Jira (PUP-6022) Need explanation for error message when using data types
Title: Message Title
Greg Larkin created an issue
Puppet / PUP-6022
Need explanation for error message when using data types
Issue Type:
Improvement
Affects Versions:
PUP 4.3.2
Assignee:
Unassigned
Components:
DSL, Language, Language Specification
Created:
2016/03/08 2:28 PM
Priority:
Normal
Reporter:
Greg Larkin
I'm not sure this if this is bug or not, but I wanted to get some feedback on a small test case that I wrote while researching Puppet variable data types. I have a `params.pp` and `init.pp` class as follows:
params.pp
class vartest::params
Unknown macro: { String $param1 = 'teststring' }
init.pp
Jira (PUP-6022) Need explanation for error message when using data types
Title: Message Title
Greg Larkin updated an issue
Puppet / PUP-6022
Need explanation for error message when using data types
Change By:
Greg Larkin
I'm not sure this if this is bug or not, but I wanted to get some feedback on a small test case that I wrote while researching Puppet variable data types. I have a ` params.pp ` and ` init.pp ` class as follows:{ panel:title=params.pp noformat }class vartest::params { String $param1 = 'teststring'}{ panel noformat }{ panel:title=init.pp noformat }class vartest ( $param1 = $vartest::params::param1) inherits vartest::params { notice($param1)}{ panel noformat } I receive the following message when I invoke ` " puppet apply -e 'include vartest' ` " :{ noformat code }Error: This Type-Name has no effect. A value was produced and then forgotten (one or more preceding expressions may have the wrong form) at /etc/puppetlabs/code/environments/production/modules/vartest/manifests/params.pp:2:3 on node sdp-exercise.vagrant{ noformat code }If I delete the ` String ` token from the variable assignment in ` init.pp ` , I receive the same message. If I restore that token and then remove the ` String ` token from the variable assignment in ` params.pp ` , I see the following output from ` puppet apply ` :{ noformat code }Notice: Scope(Class[Vartest]): teststringNotice: Compiled catalog for sdp-exercise.vagrant in environment production in 0.15 secondsNotice: Applied catalog in 0.01 seconds{ noformat code }I'm just wondering if those errors above are expected and why you can't use the ` String ` data type in both of my classes. It seems like that might be a useful language feature, especially when heavily refactoring code and wanting to make sure inherited variable data types still match what's expected.
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-6022) Need explanation for error message when using data types
Title: Message Title
Greg Larkin updated an issue
Puppet / PUP-6022
Need explanation for error message when using data types
Change By:
Greg Larkin
I'm not sure this if this is bug or not, but I wanted to get some feedback on a small test case that I wrote while researching Puppet variable data types. I have a params.pp and init.pp class as follows:{noformat}class vartest::params { String $param1 = 'teststring'}{noformat}{noformat}class vartest ( String $param1 = $vartest::params::param1) inherits vartest::params { notice($param1)}{noformat}I receive the following message when I invoke "puppet apply -e 'include vartest'":{code}Error: This Type-Name has no effect. A value was produced and then forgotten (one or more preceding expressions may have the wrong form) at /etc/puppetlabs/code/environments/production/modules/vartest/manifests/params.pp:2:3 on node sdp-exercise.vagrant{code}If I delete the String token from the variable assignment in init.pp, I receive the same message. If I restore that token and then remove the String token from the variable assignment in params.pp, I see the following output from puppet apply:{code}Notice: Scope(Class[Vartest]): teststringNotice: Compiled catalog for sdp-exercise.vagrant in environment production in 0.15 secondsNotice: Applied catalog in 0.01 seconds{code}I'm just wondering if those errors above are expected and why you can't use the String data type in both of my classes. It seems like that might be a useful language feature, especially when heavily refactoring code and wanting to make sure inherited variable data types still match what's expected.
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-6022) Need explanation for error message when using data types
Title: Message Title
Greg Larkin updated an issue
Puppet / PUP-6022
Need explanation for error message when using data types
Change By:
Greg Larkin
I'm not sure this if this is bug or not, but I wanted to get some feedback on a small test case that I wrote while researching Puppet variable data types. I have a params.pp and init.pp class as follows:{noformat}class vartest::params { String $param1 = 'teststring'}{noformat}{noformat}class vartest ( String $param1 = $vartest::params::param1) inherits vartest::params { notice($param1)}{noformat}I receive the following message when I invoke "puppet apply -e 'include vartest'":{code}Error: This Type-Name has no effect. A value was produced and then forgotten (one or more preceding expressions may have the wrong form) at /etc/puppetlabs/code/environments/production/modules/vartest/manifests/params.pp:2:3 on node sdp-exercise.vagrant{code}If I delete the String token from the variable assignment in init.pp, I receive the same message. If I restore that token and then remove the String token from the variable assignment in params.pp, I see the following output from puppet apply:{code}Notice: Scope(Class[Vartest]): teststringNotice: Compiled catalog for sdp-exercise.vagrant in environment production in 0.15 secondsNotice: Applied catalog in 0.01 seconds{code}I'm just wondering if those errors above are expected and why you I can't use the String data type in both of my classes. It seems like that might be a useful language feature, especially when heavily refactoring code and wanting to make sure inherited variable data types still match what's expected.
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-6022) Typing local variables does not work - results in Error: This Type-Name has no effect
Title: Message Title Greg Larkin commented on PUP-6022 Re: Typing local variables does not work - results in Error: This Type-Name has no effect Thank you very much for the thorough explanation, Henrik Lindberg! I missed this key portion of the documentation where the use cases for data types are listed: https://docs.puppetlabs.com/puppet/latest/reference/lang_data_type.html#usage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
