Jira (PUP-11849) CRL authorityKeyIdentifier is not printed in puppet8
Title: Message Title Justin Stoller commented on PUP-11849 Re: CRL authorityKeyIdentifier is not printed in puppet8 FWIW, we don't hit this issue when printing info with the puppetserver-ca-cli. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.485441.1683744464000.13584.1684255440019%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller updated an issue Puppet / PUP-11691 Provide setting to report non-versioned path to resource when using versioned dirs Added Release notes. Change By: Justin Stoller Release Notes: Enhancement Release Notes Summary: When the "versioned_environment_dirs" setting is enabled Puppet would previously report the full directory path to the environment *after* resolving symlinks as the source for resources in a catalog.Puppet will now report the path to the resource *before* resolving symlinks in the "environmentpath". Users may revert to the previous behavior by setting the new configuration option "report_configured_environmentpath" to false. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller commented on PUP-11691 Re: Provide setting to report non-versioned path to resource when using versioned dirs Promoted to Puppet Agent in https://github.com/puppetlabs/puppet-agent/commit/88f65cc025cda2b76ae0fd270799e2de862efcfe Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.477092.1671051703000.975.1677258780091%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-11691 Provide setting to report non-versioned path to resource when using versioned dirs Change By: Justin Stoller Assignee: Justin Stoller Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.477092.1671051703000.8924.1675892760036%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller updated an issue Puppet / PUP-11691 Provide setting to report non-versioned path to resource when using versioned dirs Change By: Justin Stoller Team: Phoenix Skeletor Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.477092.1671051703000.3405.1674513180023%40Atlassian.JIRA.
Jira (PDB-5560) Update PuppetDB terminus for Puppet 8/Ruby 3
Title: Message Title Justin Stoller commented on PDB-5560 Re: Update PuppetDB terminus for Puppet 8/Ruby 3 Adding a blocking relationship to the PUP ticket to drop PSON support as I think PDB's terminus is the last remaining important internal consumer of PSON. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.474929.1668708016000.2289.1674067560092%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller commented on PUP-11691 Re: Provide setting to report non-versioned path to resource when using versioned dirs Some notes: We should start by looking into the parser/locator approach and fallback to the post processing/serialization if that doesn't work out. We need to coordinate the control of this behavior with consumers like CD4PE and may need to add a separate setting to manage whether or not versioned_dirs are reported or the symlink dir is reported. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.477092.1671051703000.1229.1673912220023%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller commented on PUP-11691 Re: Provide setting to report non-versioned path to resource when using versioned dirs Josh Cooper , Austin Blatt , Nick Burgan this is the work for option #2 in the linked PE escalation. I think we can ship this in the next agent release and then give folks encountering this (and not using CD4PE) a path forward. We can then release a toggle in the next PE release for easier usage. Once CD4PE can use this we can default to having it on. I think Nick was working with Product to prioritize and get the work distributed to the correct teams, and Austin was coordinating from a technical side (and had already talked to CD4PE). Are those assumptions correct? Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.477092.1671051703000.66888.1671056580044%40Atlassian.JIRA.
Jira (PUP-11691) Provide setting to report non-versioned path to resource when using versioned dirs
Title: Message Title Justin Stoller created an issue Puppet / PUP-11691 Provide setting to report non-versioned path to resource when using versioned dirs Issue Type: Improvement Assignee: Unassigned Created: 2022/12/14 1:01 PM Priority: Normal Reporter: Justin Stoller In PUP-10255 we added the ability to readlink symlinks within the environmentpath. This causes resources to report the full non-symlinked path as their location in the catalog and report. Now, when using versioned dirs, whenever a new code deployment happens that full path changes (because it contains the environment version in the path). This causes a lot of unnecessary churn in catalogs and reports because even unchanged resources look like they come from a different path. We should enable the ability for a resource to report itself as coming from the symlinked path rather than the full path after readlinking. This ability should be behind a configuration flag and default to off. NB. This maybe be possible by editing how the source locator in the parser reports what file a resource it created came from. Though, if resources take that file information and try to access the disk themselves (eg, in a create_resources like step) then we may not be able to do so. Another route may be to post process the catalog and adjust the every resource to use the original symlinked env path. Add Comment
Jira (PUP-11683) Tasks are unable to be listed when a single task in an environment has malformed metadata
Title: Message Title Justin Stoller commented on PUP-11683 Re: Tasks are unable to be listed when a single task in an environment has malformed metadata This caused a failure in Puppet Server CI that should be taken care of by https://github.com/puppetlabs/puppetserver/pull/2674 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.474434.1668124207000.64834.1670447700059%40Atlassian.JIRA.
Jira (PUP-11683) Tasks are unable to be listed when a single task in an environment has malformed metadata
Title: Message Title Justin Stoller updated an issue Puppet / PUP-11683 Tasks are unable to be listed when a single task in an environment has malformed metadata Added a release note, however I don't see this endpoint publicly documented so we probably don't need much in the way of docs for it. (Maybe just this mention in the release notes, no pages updated) Change By: Justin Stoller Release Notes: Bug Fix Release Notes Summary: Invalid JSON in a task metadata file will cause the task to be skipped in the GET `/tasks` endpoint rather than causing the whole response to return 500. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Jira (PUP-11683) Tasks are unable to be listed when a single task in an environment has malformed metadata
Title: Message Title Justin Stoller moved an issue Puppet / PUP-11683 Tasks are unable to be listed when a single task in an environment has malformed metadata Change By: Justin Stoller Key: PE PUP - 34928 11683 Project: Puppet Enterprise [Internal] Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.474434.1668124207000.62604.1669920780097%40Atlassian.JIRA.
Jira (PDB-5560) Update PuppetDB terminus for Puppet 8/Ruby 3
Title: Message Title Justin Stoller commented on PDB-5560 Re: Update PuppetDB terminus for Puppet 8/Ruby 3 Omg, please stop using PSON in Puppet 8 https://github.com/puppetlabs/puppetdb/blob/main/puppet/lib/puppet/util/puppetdb/command.rb#L44 Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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.474929.1668708016000.59321.1668727740051%40Atlassian.JIRA.
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10513 Do not recursively type check collections when creating iterables in puppet functions Change By: Justin Stoller Fix Version/s: PUP 5.5.22 Fix Version/s: PUP 6.18.0 Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- 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.359002.1589581228000.32291.1646778720040%40Atlassian.JIRA.
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller commented on PUP-10513 Re: Do not recursively type check collections when creating iterables in puppet functions It looks like this was merged as a (maint) PR in https://github.com/puppetlabs/puppet/pull/8150/files . Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- 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.359002.1589581228000.32290.1646778660080%40Atlassian.JIRA.
Jira (PUP-11401) Non-profiled CodeHeap size is constantly growing
Title: Message Title Justin Stoller assigned an issue to Pavel Sapezhka Puppet / PUP-11401 Non-profiled CodeHeap size is constantly growing Change By: Justin Stoller Assignee: Justin Stoller Pavel Sapezhka Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- 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.428106.1640164262000.6707.1642794480037%40Atlassian.JIRA.
Jira (PUP-11401) Non-profiled CodeHeap size is constantly growing
Title: Message Title Justin Stoller commented on PUP-11401 Re: Non-profiled CodeHeap size is constantly growing A couple general questions: 1. Have you run out of ReservedCodeCache before? I believe the JVM compiler will be disabled and everything will be interpretted. Though I don't know if there's any harm in the cache being 85-90% full. 2. In the screenshot you gave, have any Jruby instances hit their max-requests limit and been recycled? I would expect to see significant turn over in the code cache after a JRuby instance is destroyed. Any logs you can provide that can correlate codecache usage and JRuby recycling would be valuable. (There should be an INFO level log line that matches /Creating JRubyInstance with id (\d+)/. Conversely, I would expect more marginal code paths to be compiled to the codecache the longer the a JRuby instance is alive, which a logarithmic increase like your image shows. Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- 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.428106.1640164262000.21644.1642117560046%40Atlassian.JIRA.
Jira (PUP-11401) Non-profiled CodeHeap size is constantly growing
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-11401 Non-profiled CodeHeap size is constantly growing Change By: Justin Stoller Assignee: Justin Stoller Add Comment This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d) -- 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.428106.1640164262000.21166.1642098240040%40Atlassian.JIRA.
Jira (PUP-11247) Prepare release announcement (Puppet Platform 7.12.0)
Title: Message Title Justin Stoller commented on PUP-11247 Re: Prepare release announcement (Puppet Platform 7.12.0) These are the changes in 7.4.1: The v4 catalog endpoint now supports arbitrary fact termini. Support TLS v1.3 in FIPS. Both of those are essentially PE only features and I would not put out any Server highlights for this release. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.416089.163182758.151971.1633978380023%40Atlassian.JIRA.
Jira (PUP-11256) Prepare documentation updates and release notes (Puppet Platform 6.25.0)
Title: Message Title Justin Stoller commented on PUP-11256 Re: Prepare documentation updates and release notes (Puppet Platform 6.25.0) Here are all the things going out in Puppet Server 6.17.0 (most of these shipped in Puppet Server 7.4.0 and are now being released in our LTS stream): The time to retrieve a list of pending CSRs from the certificate_statuses endpoint no longer slows proportionally to the number of CSRs and signed certificates. Attempting to revoke an already revoked certificate is now a no-op and will not add a new entry to the CRL. The v4 catalog endpoint now supports arbitrary fact termini. Bolt task file endpoints now respect the special scripts directory within a project. AST compilation now has more robust environment support. The CA subcommand of the puppetserver cli tool now has a "purge" action to clean duplicate CRL entries. The CA subcommand of the puppetserver cli tool's "generate" action has a "–force" flag to allow generation even when safety checks have failed. TLS v1.3 is now enabled by default. Dependency bumps improve behavior on FIPS, resolve warnings in Java 9+, and update Jetty to v9.4.43. Of those, I would put three call outs (all previously released in 7.x): TLS v1.3 is enabled by default The CA no longer produces duplicate CRL entries when revoking already revoked certificates. The CA command line tool can purge duplicates from existing CRLs. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Justin Stoller commented on PUP-9577 Re: Large numbers of facts cause slow performance I think the state we left this was that: There was a support escalation with SF that was hit by this, we offered GC and JRuby tuning to hopefully help. We outlined a couple potential "fixes" for this: Parse ERB templates prior to evaluating them to see what variables we need for the scope. Possible costs in performance for the not-large-facts case and in general maintenance. Deprecate @ivar fact references and allow users to disable ivars as facts (skipping the slow paths). Probably has a large ecosystem lift? Would love to hear CS input on that. Share variables between templates, may only incur the facts -> ivars cost once per catalog, may have edge cases. I'd love to know if either of the performance mitigations were helpful? and how much work CS believes it would be to move users to not using instance variables for facts? Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Justin Stoller commented on PUP-9577 Re: Large numbers of facts cause slow performance I suspect there's something leaking in the JRuby side related to dynamically adding variables for ERB templates that's causing this massive slowdown. There's probably two culprits here. One is that large objects may be immediately tenured in Java. I think this is a particular problem with the G1 garbage collector. The other is that JRuby has been moving more and more of Ruby's programming constructs to use the JVM's InvokeDynamic feature. This causes dynamic code to better optimized in the long run but cause more upfront cost and the Java objects that back this process are difficult to garbage collect (there's custom classes and byte code generated by this process). Setting the JAVA_ARG -Djruby.invokedynamic.cache.ivars=false may help there. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.301092.1553181872000.58525.1623864300322%40Atlassian.JIRA.
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Justin Stoller commented on PUP-9577 Re: Large numbers of facts cause slow performance Is there an easy way to extend this approach to make it viable enough for a product patch? I've looked into this and I don't think it's super viable. For the solution to be robust enough I think you'd need to parse each template file and extract the ruby code blocks in a similar manner to to ERB itself and then run Ripper on it to analyze the code and extract any instance variables for there. Then you can only set the instance variables you need on the scope before actually evaluating the template. I think will make evaluating templates noticeably slower for the majority of users. If that's true we probably would want to check to see the number of facts a customer has before going down that parse-the-erb-before-evaluating-it path... Unfortunately, that feels like a lot of complexity to add however, the other ideas we have require customer/ecosystem changes. One of the ideas we had were to strongly prefer EPP templates and effectively make them a requirement at scale. The other is to provide a flag that disables referring to facts as instance variables. There are three different ways to refer to facts within a template and the other two (eg scope['fact_name']) don't require pre-setting instance variables on the scope object. (see https://puppet.com/docs/puppet/7/lang_template_erb.html#erb_variables), if a user doesn't have ERB templates that access instance variable style facts then they could set a flag and we could skip that action. I'm unclear the tractability of adding a lot of technical complexity vs getting users to stop using instance variable style fact references. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Jira (PUP-11082) Use PKey.read when loading private keys
Title: Message Title Justin Stoller updated an issue Puppet / PUP-11082 Use PKey.read when loading private keys Change By: Justin Stoller Fix Version/s: PUP 7.y Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- 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.401622.1622737597000.47475.1622737680358%40Atlassian.JIRA.
Jira (PUP-11082) Use PKey.read when loading private keys
Title: Message Title Justin Stoller created an issue Puppet / PUP-11082 Use PKey.read when loading private keys Issue Type: Task Assignee: Unassigned Created: 2021/06/03 9:26 AM Priority: Normal Reporter: Justin Stoller There's a littany of reasons that we couldn't use PKey.read in https://github.com/puppetlabs/puppet/blob/1a13e0cf96c70b303492e684f9ccf4c38207b3dd/lib/puppet/x509/cert_provider.rb#L218-L222. However, We no longer use this code in Terminii that will be loaded in JRuby (and so don't use this code at all in JRuby) nor do we support older versions of Ruby in Puppet 7.x. Our manual determination of which implementation class to construct is somewhat naive and PKey.read will do a better job. Consequently, we should use PKey.read in the above code. Add Comment
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10945 Change the master -> server in Server used http code Change By: Justin Stoller Team: Froyo 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.157604.1614880500197%40Atlassian.JIRA.
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10945 Change the master -> server in Server used http code Change By: Justin Stoller Sprint: Froyo - 03/10/2021 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.157605.1614880500244%40Atlassian.JIRA.
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10945 Change the master -> server in Server used http code Change By: Justin Stoller Story Points: 1 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.157599.1614880440037%40Atlassian.JIRA.
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Justin Stoller created an issue Puppet / PUP-10945 Change the master -> server in Server used http code Issue Type: Task Assignee: Unassigned Created: 2021/03/02 12:11 PM Priority: Normal Reporter: Justin Stoller Puppet Server currently loads 'puppet/network/http/api/master/v3' and uses the constant 'Puppet::Network::HTTP::MASTER_URL_PREFIX' as part of setting up the Server's routes. These should be changed to use 'server' in the place of master. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10945) Change the master -> server in Server used http code
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10945 Change the master -> server in Server used http code Change By: Justin Stoller Assignee: Justin Stoller 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.155354.1614715920092%40Atlassian.JIRA.
Jira (PUP-10212) SSL negotiation fails with "tls_process_ske_dhe:dh key too small"
Title: Message Title Justin Stoller commented on PUP-10212 Re: SSL negotiation fails with "tls_process_ske_dhe:dh key too small" We typically target the latest and earliest versions of a major OS release. ie, we have Redhat 7.1 in our CI system for that compatibility guarantee, and that image comes with Java 1.8 b08. I have a feeling we can make an exception that users should have been upgrading to builds of the JDK with better security, even if they've stayed on jdk8. I'll have to run that by RE or Product first and get the images updated. I'm out next week so I won't get an answer for a bit. 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.336537.1574710008000.141709.1613182200035%40Atlassian.JIRA.
Jira (PUP-10805) Prepare release announcement (Puppet Platform 7.1.0)
Title: Message Title Justin Stoller commented on PUP-10805 Re: Prepare release announcement (Puppet Platform 7.1.0) It's a very minor release for Server. The JRuby bump to 9.2.14.0 is the only thing that could be considered notable (but feel free to skip it if there's already a lot in there). 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.379888.1607039203000.98318.1608046500022%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Fix Version/s: Puppet 7.0.1 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.378889.1605805593000.85171.1606154340025%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title
Justin Stoller updated an issue
Puppet / PUP-10786
Puppet Node Clean action's LoggerIO needs to implement `warn`
Change By:
Justin Stoller
Release Notes:
Bug Fix
Release Notes Summary:
A known issue with Puppet 7.0.0 was that the {{puppet node clean}} action would fail if the user was had their {{cadir}} in the legacy location or inside the {{ssldir}}. This was a regression and it no longer does so.
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.378889.1605805593000.85170.1606154280029%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Method Found: Needs Assessment Automated Test 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.378889.1605805593000.84258.1605896040029%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Sprint: Froyo - 11/23/2020 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.378889.1605805593000.83000.1605805980224%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Assignee: Justin Stoller 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.378889.1605805593000.82995.1605805920025%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Team: Froyo 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.378889.1605805593000.82989.1605805800299%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Story Points: 1 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.378889.1605805593000.82990.1605805800344%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Change By: Justin Stoller Affects Version/s: PUP 7.0.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.378889.1605805593000.82991.1605805800388%40Atlassian.JIRA.
Jira (PUP-10786) Puppet Node Clean action's LoggerIO needs to implement `warn`
Title: Message Title Justin Stoller created an issue Puppet / PUP-10786 Puppet Node Clean action's LoggerIO needs to implement `warn` Issue Type: Bug Assignee: Unassigned Created: 2020/11/19 9:06 AM Priority: Normal Reporter: Justin Stoller In the Puppet Node face's 'clean' action, we load the Puppet Server CA CLI as a library, passing in a 'LoggerIO' object as an adapter between the CA's logging facilities and Puppet's. Previously, we only needed `inform` and `err` methods to call the relevant APIs in the CA - and it appears our LoggerIO adapter only implements those two methods. With the new cadir default change (see SERVER-2896) we may `warn` as well which will now cause puppet node clean calls to fail with an undefined method on LoggerIO. To fix this we should update the LoggerIO adapter to provide all the methods available in the Puppet Server CA's Logger. Add Comment
Jira (PUP-10720) Update `cadir` default to return the new location post-migration
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10720 Update `cadir` default to return the new location post-migration Change By: Justin Stoller Sprint: Froyo 11/02/2020 , Froyo 11/09/2020 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.375129.1602802813000.69916.1604356980107%40Atlassian.JIRA.
Jira (PUP-10720) Update `cadir` default to return the new location post-migration
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10720 Update `cadir` default to return the new location post-migration Change By: Justin Stoller Sprint: Froyo 11/02/2020 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.375129.1602802813000.64332.1603752120551%40Atlassian.JIRA.
Jira (PUP-10720) Update `cadir` default to return the new location post-migration
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10720 Update `cadir` default to return the new location post-migration Change By: Justin Stoller Story Points: 3 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.375129.1602802813000.64270.1603750620034%40Atlassian.JIRA.
Jira (PUP-10720) Update `cadir` default to return the new location post-migration
Title: Message Title
Justin Stoller updated an issue
Puppet / PUP-10720
Update `cadir` default to return the new location post-migration
Change By:
Justin Stoller
In order to make the transition to the new CA dir location as seamless as possible, we want to put some special logic into the default calculation for the {{cadir}} setting in Puppet, that will make it return the new location after the CA has been migrated, and warn otherwise.If the setting is not configured by the user ([default|https://github.com/puppetlabs/puppet/blob/e0746ca619fac312b86e26b4a1f73db70b146947/lib/puppet/defaults.rb#L1094], use a Ruby lambda /proc ): * and the files are in the old default spot, warn and prompt with a message that encourages users to migrate. Return the old default (/etc/puppetlabs/puppet/ssl/ca) * and there are no CA files (new install) or CA files in the new location, return the new location (/etc/puppetlabs/puppetserver/ca).If the setting is configured by the user (custom, use hook ([example)|https://github.com/puppetlabs/puppet/blob/main/lib/puppet/defaults.rb#L133]): * and points to a location within the SSL dir, warn with a message that encourages migration * and points to a location _outside_ the SSL dir, use it as-is.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10720) Update `cadir` default to return the new location post-migration
Title: Message Title
Justin Stoller updated an issue
Puppet / PUP-10720
Update `cadir` default to return the new location post-migration
Change By:
Justin Stoller
In order to make the transition to the new CA dir location as seamless as possible, we want to put some special logic into the default calculation for the {{cadir}} setting in Puppet, that will make it return the new location after the CA has been migrated, and warn otherwise.If the setting is not configured by the user ([default|https://github.com/puppetlabs/puppet/blob/e0746ca619fac312b86e26b4a1f73db70b146947/lib/puppet/defaults.rb#L1094], use lambda): * and the files are in the old default spot, warn and prompt users to migrate. Return the old default (/etc/puppetlabs/puppet/ssl/ca) * and there are no CA files (new install) or CA files in the new location, return the new location (/etc/puppetlabs/puppetserver/ca).If the setting is configured by the user (custom, use hook ([example)|https://github.com/puppetlabs/puppet/blob/main/lib/puppet/defaults.rb#L133]): * and points to a location within the SSL dir, warn and prompt with a message that encourages migration * and points to a location _outside_ the SSL dir, use it as-is.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10700) Puppet Platform 6.19.0 Release - 2020-10-20
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10700 Puppet Platform 6.19.0 Release - 2020-10-20 Change By: Justin Stoller Team/s: Coremunity,Froyo,Night's Watch,Platform OS,PuppetDB,Release Engineering 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.374315.1602110111000.60476.1603302420047%40Atlassian.JIRA.
Jira (PUP-10690) Puppet Platform 5.5.22 Release - 2020-10-20
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10690 Puppet Platform 5.5.22 Release - 2020-10-20 Change By: Justin Stoller Team/s: Coremunity,Froyo,Night's Watch,Platform OS,PuppetDB,Release Engineering 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.374279.1602109957000.60475.1603302360054%40Atlassian.JIRA.
Jira (PUP-10247) Support ruby 2.7
Title: Message Title Justin Stoller commented on PUP-10247 Re: Support ruby 2.7 I think this ticket was originally useful for tracking 2.7 support in the agent side Ruby code. There took a turn around May attempting to re-litigate the six year old business decision to deprecate the Ruby side compiler stack, which I think soured the tone of this ticket. The recent requests to work with debian maintainers to move forward with packaging recent versions of Puppet and Puppet Server are welcome and I've created CPR-760 to track and coordinate that work in a more productive environment. 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.342962.1579675679000.30131.1599151440035%40Atlassian.JIRA.
Jira (PUP-10656) Provide a JSON terminus for facts
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10656 Provide a JSON terminus for facts Change By: Justin Stoller We have a YAML terminus for facts, however YAML can problematic for hexidecimal numbers (see PUP- ... 9505 ).Additionally, JSON is generally a better serialization format for machines to understand, is a smaller spec than YAML, has a relatively mature ecosystem in Java around parsing/serializing, and is backwards compatible with YAML for recent YAML parsers (YAML has become a superset of JSON).For these reasons we should implement a JSON terminus for facts (there already exists one for catalogs) and users should be encouraged to use it instead of the YAML terminus. 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
Jira (PDB-4877) Prefer JSON fact terminus for fact cache to YAML
Title: Message Title Justin Stoller updated an issue PuppetDB / PDB-4877 Prefer JSON fact terminus for fact cache to YAML Change By: Justin Stoller Labels: platform_7 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.371010.1599070036000.29418.1599070140043%40Atlassian.JIRA.
Jira (PUP-10656) Provide a JSON terminus for facts
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10656 Provide a JSON terminus for facts Change By: Justin Stoller Labels: puppet_7 platform_7 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.371009.1599069868000.29419.1599070140088%40Atlassian.JIRA.
Jira (PDB-4877) Prefer JSON fact terminus for fact cache to YAML
Title: Message Title Justin Stoller created an issue PuppetDB / PDB-4877 Prefer JSON fact terminus for fact cache to YAML Issue Type: Improvement Assignee: Unassigned Created: 2020/09/02 11:07 AM Priority: Normal Reporter: Justin Stoller We currently recommend users configure the YAML fact cache when enabling PDB (and we do this configuration for them in PE). We are currently adding a JSON terminus for facts (see PUP-10656) and in Puppet 7 we should switch to enabling it (if we enable any fact caching). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10656) Provide a JSON terminus for facts
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10656 Provide a JSON terminus for facts Change By: Justin Stoller Labels: puppet_7 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.371009.1599069868000.29413.1599069900092%40Atlassian.JIRA.
Jira (PUP-10656) Provide a JSON terminus for facts
Title: Message Title Justin Stoller created an issue Puppet / PUP-10656 Provide a JSON terminus for facts Issue Type: Improvement Assignee: Unassigned Created: 2020/09/02 11:04 AM Priority: Normal Reporter: Justin Stoller We have a YAML terminus for facts, however YAML can problematic for hexidecimal numbers (see PUP-...). Additionally, JSON is generally a better serialization format for machines to understand, is a smaller spec than YAML, has a relatively mature ecosystem in Java around parsing/serializing, and is backwards compatible with YAML for recent YAML parsers (YAML has become a superset of JSON). For these reasons we should implement a JSON terminus for facts (there already exists one for catalogs) and users should be encouraged to use it instead of the YAML terminus. Add Comment
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Justin Stoller commented on PUP-9577 Re: Large numbers of facts cause slow performance FWIW, I think users can avoid this situation by writing EPP templates vs ERB ones. Ruby, afaict, does not provide a hook for instance variable look up like it does for method_missing so there's nothing to do if users reference @variable names besides preloading all possible instance variables. It would be possible to gate preloading facts as instance variables on a new setting, but users would need to validate that their ERB templates only use the other ways of accessing facts eg scope['variable']. At that point, though, I'm not sure if it wouldn't be better to encourage them to move to EPP? 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.301092.1553181872000.25673.1598569440087%40Atlassian.JIRA.
Jira (PUP-10436) Remove strict_hostname_checking
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10436 Remove strict_hostname_checking Change By: Justin Stoller Release Notes: Known Issue Release Notes Summary: This removes in Puppet 7 the deprecated strict_hostname_checking and node_name settings.The use cases for these settings (classification based on partial certname or fact based classification) are possible using newer more explicit constructs within a site.pp or fully featured enc. 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.356464.1587616816000.16521.1597428960026%40Atlassian.JIRA.
Jira (PUP-10436) Remove strict_hostname_checking
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10436 Remove strict_hostname_checking Change By: Justin Stoller Assignee: Justin Stoller 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.356464.1587616816000.14781.1597250160036%40Atlassian.JIRA.
Jira (PUP-10417) Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
Title: Message Title Justin Stoller commented on PUP-10417 Re: Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet Probably here: https://puppet.com/docs/puppet/6.17/functions_ruby_implementation.html. 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.354928.1586391583000.7120.1596475440222%40Atlassian.JIRA.
Jira (PUP-10594) Lock termini creation
Title: Message Title Justin Stoller created an issue Puppet / PUP-10594 Lock termini creation Issue Type: Improvement Assignee: Unassigned Created: 2020/07/21 2:25 PM Priority: Normal Reporter: Justin Stoller We currently wrap indirector information (terminus class, cache class, etc) in threadlocal containers, however, we don't initialize and cache the termini themselves in a threadsafe way and they are created on first invocation of each indirection's terminus method (which may not be called until required to handle the first find-like method). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10513 Do not recursively type check collections when creating iterables in puppet functions Change By: Justin Stoller When a user calls the Puppet functions `map`, `each`, etc. we create a Puppet Iterator and proxy requests through it to the wrapped Ruby object. When creating a Puppet Iterator in this way we recursively infer the type of the entire collection passed in.Some times these Iterators are directly exposed to users ( via the non-block arities of `reverse_each` and `step`). Unfortunately, where we expose Iterators they may use all of Puppet's type system and may be specialized like "Iterator[String]" or "Iterator[Variant[Hash[String,String],Undef]]". Consequently, to be backwards compatible we will need to recursively check the type for these invocations. (Maybe we can deprecate and remove them in Puppet 7??)In every other case the Iterator is not exposed to the user. Either the original collection, a new, modified collection, or elements of one of the afore mentioned collections is returned.The method invoked in Puppet functions to create the Iterator Iterators is `Iterable.asserted_iterable`, and as far as I can tell, it does additional type checking that the dispatcher doesn't do and then largely discards the computed type information. We should should probably keep the call to asserted_iterable (assuming the additional type checking is a good thing to do there ) , but make it non-recursive where possible.Note, `asserted_iterable` defers to `Iterable.on` to do a lot of this work, `Iterable.on` is used by other aspects of the type system so we might want to keep existing calls to `Iterable.on` backwards compatible with those invocations. (We might also want to look into whether or not those calls are unnecessarily doing recursive type inference.) Add Comment
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10513 Do not recursively type check collections when creating iterables in puppet functions Change By: Justin Stoller Environment: When a user calls the Puppet functions `map`, `each`, etc. we create a Puppet Iterator and proxy requests through it to the wrapped Ruby object. When creating a Puppet Iterator in this way we recursively infer the type of the entire collection passed in.Some times these Iterators are directly exposed to users (via the non-block arities of `reverse_each` and `step`). Unfortunately, where we expose Iterators they may use all of Puppet's type system and may be specialized like "Iterator[String]" or "Iterator[Variant[Hash[String,String],Undef]]". Consequently, to be backwards compatible we will need to recursively check the type for these invocations. (Maybe we can deprecate and remove them in Puppet 7??)In every other case the Iterator is not exposed to the user. Either the original collection, a new, modified collection, or elements of one of the afore mentioned collections is returned.The method invoked in Puppet functions to create the Iterators is `Iterable.asserted_iterable`, and as far as I can tell, it does additional type checking that the dispatcher doesn't do and then largely discards the computed type information. We should should probably keep the call to asserted_iterable (assuming the additional type checking is a good thing to do there), but make it non-recursive where possible.Note, `asserted_iterable` defers to `Iterable.on` to do a lot of this work, `Iterable.on` is used by other aspects of the type system so we might want to keep existing calls to `Iterable.on` backwards compatible with those invocations. (We might also want to look into whether or not those calls are unnecessarily doing recursive type inference.) Add Comment
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10513 Do not recursively type check collections when creating iterables in puppet functions Change By: Justin Stoller (the method invoked in Puppet functions to create the Iterator) 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.359002.1589581228000.64008.1589581260131%40Atlassian.JIRA.
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title Justin Stoller created an issue Puppet / PUP-10513 Do not recursively type check collections when creating iterables in puppet functions Issue Type: Task Assignee: Justin Stoller Created: 2020/05/15 3:20 PM Environment: When a user calls the Puppet functions `map`, `each`, etc. we create a Puppet Iterator and proxy requests through it to the wrapped Ruby object. When creating a Puppet Iterator in this way we recursively infer the type of the entire collection passed in. Some times these Iterators are directly exposed to users (via the non-block arities of `reverse_each` and `step`). Unfortunately, where we expose Iterators they may use all of Puppet's type system and may be specialized like "Iterator[String]" or "Iterator[Variant[Hash[String,String],Undef]]". Consequently, to be backwards compatible we will need to recursively check the type for these invocations. (Maybe we can deprecate and remove them in Puppet 7??) In every other case the Iterator is not exposed to the user. Either the original collection, a new, modified collection, or elements of one of the afore mentioned collections is returned. The method invoked in Puppet functions to create the Iterators is `Iterable.asserted_iterable`, and as far as I can tell, it does additional type checking that the dispatcher doesn't do and then largely discards the computed type information. We should should probably keep the call to asserted_iterable (assuming the additional type checking is a good thing to do there), but make it non-recursive where possible. Note, `asserted_iterable` defers to `Iterable.on` to do a lot of this work, `Iterable.on` is used by other aspects of the type system so we might want to keep existing calls to `Iterable.on` backwards compatible with those invocations. (We might also want to look into whether or not those calls are unnecessarily doing recursive type inference.) Priority: Normal Reporter: Justin Stoller
Jira (PUP-10509) Drop support for ruby < 2.5
Title: Message Title Justin Stoller commented on PUP-10509 Re: Drop support for ruby < 2.5 9.2 does report 2.5 though JRuby doesn't always fully support the version it reports as. As long as we keep 9.2 in the test matrix I think we're good. 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.358867.1589476926000.62714.1589477940235%40Atlassian.JIRA.
Jira (PUP-9469) Remove the setting to turn off func 3x API validation
Title: Message Title Justin Stoller commented on PUP-9469 Re: Remove the setting to turn off func 3x API validation Yes, we should add a deprecation notice for users who set the func3x_check setting to false. It currently defaults to true. There is one conditional in code that honors this setting it should be trivial to remove. 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.294057.1548939109000.51223.1588196760020%40Atlassian.JIRA.
Jira (PUP-9262) Remove fine grained file and environment timeouts
Title: Message Title Justin Stoller commented on PUP-9262 Re: Remove fine grained file and environment timeouts We've been talking more about environment ttls lately with the recent file-sync work. I think after this upcoming release we can look into whether the environment-ttl work will be doable in the pre-7 timeframe and if not we can remove the deprecation notice. 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.282027.1540333474000.51006.1588193820024%40Atlassian.JIRA.
Jira (PUP-10364) Add new ppRegCertExt OID "pp_owner"
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10364 Add new ppRegCertExt OID "pp_owner" Change By: Justin Stoller Fix Version/s: SERVER 6.10.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.349188.1583867523000.38195.1586896800028%40Atlassian.JIRA.
Jira (PUP-10364) Add new ppRegCertExt OID "pp_owner"
Title: Message Title Justin Stoller commented on PUP-10364 Re: Add new ppRegCertExt OID "pp_owner" It looks like this landed in Puppet, Puppet Server, & the ca cli? Can Reid Vandewiele or Josh Cooper confirm? 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.349188.1583867523000.38159.1586895720135%40Atlassian.JIRA.
Jira (FACT-2390) make facter 2x recursion check thread-safe
Title: Message Title Justin Stoller commented on FACT-2390 Re: make facter 2x recursion check thread-safe Maggie's comment was with reference to our dev env, but for posterity the Server 6.10.0 release will be the first release that was tested with Facter 2.5.8. 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.347008.1582157687000.38154.1586895420026%40Atlassian.JIRA.
Jira (PUP-10417) Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
Title: Message Title Justin Stoller commented on PUP-10417 Re: Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet Thanks, Henrik! Based on that I would say that this should be a documentation ticket that additional helper methods should all live inside the body of the block passed to create_function and the be made a documentation ticket. 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.354928.1586391583000.38019.1586888400030%40Atlassian.JIRA.
Jira (PUP-10137) HTTP Retry after 408 request timeout or 504 gateway timeout
Title: Message Title Justin Stoller commented on PUP-10137 Re: HTTP Retry after 408 request timeout or 504 gateway timeout Server uses 503 w/ a Retry-After: code, Mozilla's recommendations to deal w/ thundering heards. 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.334641.1573589453000.35444.1586475180032%40Atlassian.JIRA.
Jira (PUP-10417) Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
Title: Message Title
Justin Stoller commented on PUP-10417
Re: Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
I looked into this a little bit today and: I looked into changing how we do that eval and I'm very hesitant to change bindings w/o a lot more leg work, and probably not on anything but a major version boundary. Their "workaround" of "Don't monkey patch JSON" is less a dirty hack and more a best practice. Considering how the implementation of function loading was implemented, I think the assumption was that users would not be defining custom modules in their function files. The alternative would be to do what is recommended for library code w/in types and providers. I didn't see this recommendation on our docs but something like the "Shared Libraries" section of the old https://www.oreilly.com/library/view/puppet-types-and/9781449339319/ch04.html. (The weird "File.expand_path"s can be removed for a more modern "require_relative"). So I think we should document something to the effect of: If you want to factor out helper functions within your 4x style Ruby based Puppet functions you can define those inside the block given to Puppet::Functions.create_function. If you'd like to break those helper functions out to be easily unit testable, share them with other functions, or group them logically into a Ruby Module, you should define them in a namespaced helper file, and require that file within the body of the block you pass to Puppet::Functions.create_function. eg in some Ruby-ish pseudo code:
# cat mymodule/lib/puppet/functions/mymodule/foo.rb
Puppet::Functions.create_function("mymodule::foo") do
require_relative "../../../puppet_x/my_org/my_module/helpers.rb
dispatch "foo" do
...not pertinent...
end
Jira (PUP-6802) Agent cannot compile catalog if it specifies an non-existent environment in puppet.conf even when the classifier is controlling environment
Title: Message Title Justin Stoller commented on PUP-6802 Re: Agent cannot compile catalog if it specifies an non-existent environment in puppet.conf even when the classifier is controlling environment I was also thinking about this, though I think my two ideas are probably too large to have a good ROI: I think in general the indirector is doing too much here and pushing the error handling for if there's a valid environment into the individual indirections/terminii would be good. In this scenario, we could remove the requirement that requests contain an environment parameter and indirections/termini that need it could err if they require it and it isn't provided by an ENC. If the setting "environment" is set to "production" (its default) and it doesn't exist in an environment path, we create it from the modulepath - which allows a bare "/etc/puppetlabs/code" to be the "production" env. In doing so, the "production" environment almost always has a Ruby representation w/in the server, and consequently has been passed when the user means, "An environment isn't applicable to me", or "It's an error for the Server/ENC not to classify me". Something else we could do is to tease apart those use cases and how the effectively use "production" as a magic string. Maybe give them their own magic string? So we'd have calls that provide "environment=:not-applicable:" or "environment=:server-specified:"? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-8681) Allow passing the server_facts into Puppet when initializing settings.
Title: Message Title Justin Stoller commented on PUP-8681 Re: Allow passing the server_facts into Puppet when initializing settings. Yes, the intention was to remove the Facter dependency in Puppet Server. 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.248060.152511167.21915.1585251900051%40Atlassian.JIRA.
Jira (PUP-10257) Mark environments when superseded
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10257 Mark environments when superseded Change By: Justin Stoller In order to clean up old versions Note: A previous version of the code dir when using the new this ticket suggested writing timestamps to a file -sync layout, we need by Puppet's compiler (a proposed naive workaround to know whether or not those versions are still in use for compilation being able to rely on "atime" being available from the filesystem) . Since not all systems report access time for files, we need Subsequent discussion moved to record this metadata ourselves writing timestamps when an environment was superseded (ie another version of the same environment was deployed) . Puppet should write Consequently, some of the current time conversation in this ticket are no longer applicable and this ticket was moved from PUP to CODEMGMT.When deploying a file in the new lockless environment when it begins version, write a compilation for that env. The timestamp to a known file -sync client can then later reference specifying when other versions of this file to decide whether or not to purge the directory environment were superseded . Needs further specification... Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-10257) Mark environments when superseded
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10257 Mark environments when superseded Change By: Justin Stoller Summary: Write timestamp to file in environment Mark environments when beginning compilation superseded Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343770.1580166495000.32521.1582149540896%40Atlassian.JIRA.
Jira (PUP-10257) Write timestamp to file in environment when beginning compilation
Title: Message Title Justin Stoller commented on PUP-10257 Re: Write timestamp to file in environment when beginning compilation I like the idea of file-sync writing a file in versioned environment when that environment is superseded and then cleaning up any environment that was superseded more than X amount of time ago (30 minutes?). This also has the effect of limiting changes to the Puppet compiler (only those running PE will see this artifact). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343770.1580166495000.29562.1582063922183%40Atlassian.JIRA.
Jira (PUP-10052) Move indirector global config setting out of the default hooks
Title: Message Title Justin Stoller commented on PUP-10052 Re: Move indirector global config setting out of the default hooks After this ticket was created we audited the settings for threadsafety and the storeconfigs setting is not one we have found any uses of setting at runtime. It therefore didn't go into our general threadsafe settings work (unlike tasks, strict, strict_variables...). As such, when the hook is currently called (during initialization) is fine even in a multithreaded environment and re-setting this to another value during runtime (eg catalog compilation) won't be supported, consequently the fact that the hook isn't threadsafe shouldn't be a problem. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.326773.1569514905000.4025.1580257740107%40Atlassian.JIRA.
Jira (PUP-10210) puppet fails with JSON error when a fact value equals Infinity
Title: Message Title Justin Stoller commented on PUP-10210 Re: puppet fails with JSON error when a fact value equals Infinity I don't know if this is too conservative but the fact w/in the description could be changed to: Puppet.settings.setting(:maxwaitforcert).print(Puppet.settings[:maxwaitforcert]) Which would "properly" print the setting as "unlimited". This would require more work w/in a manifest for comparing, but is backwards compatible across different agent versions while allowing the value to be round tripped back into the settings system (don't know if that valuable). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340709.1577387077000.1780.1580152680280%40Atlassian.JIRA.
Jira (PDB-4094) Investigate query unexpectedly returning 500
Title: Message Title Justin Stoller commented on PDB-4094 Re: Investigate query unexpectedly returning 500 No idea if this is still an issue. Scott doesn't work here anymore, btw. I think the idea was that querying for the certname field with a value that would not match would return a 500 vs an empty result set. If you're saying that no longer causes a 500 then I'm happy to see this closed as "Cannot Reproduce". I don't know if the "a node that has submitted its cert but not had it signed yet" is applicable (I don't think fact or report submission happens until after a cert is acquired). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.276170.153728876.18857.1578613140192%40Atlassian.JIRA.
Jira (PUP-10170) Do not store Puppet stack within Ruby stack / Backport master work to 5.5.x
Title: Message Title Justin Stoller commented on PUP-10170 Re: Do not store Puppet stack within Ruby stack / Backport master work to 5.5.x Yes, this ticket was a performance improvement that has already gone out in the last Platform release (6.11?). Now it will also be going out in 5.5.x and 6.4.x. It caused a regression in stacktrace printing which will be fixed in 6.12, along with that fix we introduced the new feature of the "puppet_trace" setting. 5.5.x & 6.4.x won't see the regression but will get the new "puppet_trace" output option. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.338793.1576002994000.17274.1578519300859%40Atlassian.JIRA.
Jira (PUP-10213) Do not create exceptions for stacktrace information when we know we won't use that information
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10213 Do not create exceptions for stacktrace information when we know we won't use that information Change By: Justin Stoller Fix Version/s: PUP 6.12.0 Fix Version/s: PUP 6.4.5 Fix Version/s: PUP 5.5.18 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340907.1578000208000.13579.1578355500046%40Atlassian.JIRA.
Jira (PUP-10213) Do not create exceptions for stacktrace information when we know we won't use that information
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10213 Do not create exceptions for stacktrace information when we know we won't use that information Change By: Justin Stoller Release Notes Summary: Some compilation warnings will now take less time to compute. Release Notes: Enhancement Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340907.1578000208000.13578.1578355440045%40Atlassian.JIRA.
Jira (PUP-10142) Make Puppet settings not changed after a request is initiated
Title: Message Title Justin Stoller commented on PUP-10142 Re: Make Puppet settings not changed after a request is initiated Initially going through the code I looked to see if there were any refactors where we could pass the values of these settings into the methods that require information about the settings, or initialize different versions of the existing objects/subsystems that use them, storing these objects in the context and switching between them from calling code rather than munging the settings object. I failed to see how to refactor the existing objects w/o partitioning most of the server side code from the serialization through the compiler and down to the lexer. That set of changes seemed beyond the scope of this work. From there I investigated two less ideal ways to make these settings threadsafe. One was to move the settings in question into the context (https://github.com/puppetlabs/puppet/pull/7746). The other was to attempt to make the settings context itself threadsafe (https://github.com/puppetlabs/puppet/pull/7745). After some discussion we decided to go with moving the settings into the context because of two reason: ultimately we want the settings to be immutable with the context holding mutable info, and the settings code is entangled enough that we were concerned about edge cases with the threadsafe settings approach. However, there were some additional changes/gotchas with the context approach that we highlighted. I may be missing some here but if memory serves me they are: We need to keep the settings api to be backwards compatible. When a user attempts to read a moved setting a deprecation warning should be emitted and the actual value should be looked up in the context. When a user attempts to set a moved setting a deprecation warning should be emitted and the context should have the new value pushed onto it. Attempting to set any setting should result in a deprecation warning. I unfortunately don't remember what, if anything, we came up with regarding clearing settings? I do know we mentioned having alternate implementations for when running in a multithreaded environment (eg JRuby vs MRI) though I don't remember why or what changes in behavior were expected between them? Add Comment
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces I've gotten the just-puppet stack trace printing in that branch now. From the CLI it looks like: puppet (bug/5.5.x/PUP-10150_stacks *$%) :: be puppet apply broken.pp --puppet_trace Warning: Facter: Could not find a default route. Using first non-loopback interface Error: Evaluation Error: Error while evaluating a Function Call, somethinng (file: /Users/justin/Backup/code/work/puppet/broken.pp, line: 2, column: 3) on node localhost /Users/justin/Backup/code/work/puppet/broken.pp:2 /Users/justin/Backup/code/work/puppet/broken.pp:6 /Users/justin/Backup/code/work/puppet/broken.pp:9 /Users/justin/Backup/code/work/puppet/broken.pp:0
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces I opened a wip pr here https://github.com/puppetlabs/puppet/pull/7899/files that always interleaves the ruby and puppet stacks. Let me know if those stacks look right, Glen. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.11446.1578011580155%40Atlassian.JIRA.
Jira (PUP-10213) Do not create exceptions for stacktrace information when we know we won't use that information
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10213 Do not create exceptions for stacktrace information when we know we won't use that information Change By: Justin Stoller Assignee: Justin Stoller Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340907.1578000208000.11338.1578000240299%40Atlassian.JIRA.
Jira (PUP-10213) Do not create exceptions for stacktrace information when we know we won't use that information
Title: Message Title Justin Stoller created an issue Puppet / PUP-10213 Do not create exceptions for stacktrace information when we know we won't use that information Issue Type: Improvement Assignee: Unassigned Created: 2020/01/02 1:23 PM Priority: Normal Reporter: Justin Stoller Currently when the evaluator runs across a valid warning it will create an exception in the `optionally_fail` method. That exception is passed into the error handling code (acceptor) that later decides if the issue warrants erring out, printing a warning with a stacktrace, printing a warning without a stacktrace, or ignoring. Creating exceptions/backtraces are expensive in some environments, we should only create them when we know we will print the information they contain. There is no use in creating them when we know we will not use them. It should be possible to check the validator/acceptor from optionally_fail and only create the exception when the correct conditions hold. Add Comment
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces Since I never received any community feedback regarding how to fix this I'm inclined to do this: Add a puppet_trace setting. Then update the logging to the effect of if Puppet[:trace] interleave_ruby_and_puppet_stacks() elsif Puppet[:puppet_trace] just_output_puppet_stack() else output_error_without_stack_info() end That's based on the assumption that with the new implementation of PuppetStack the expensive thing is getting the Ruby stacktrace, so it isn't a big deal to interleave if we have to get the Ruby stack anyways (and signal to noise wise I dont think it hurts). But by adding the puppet_trace flag users can see just the Puppet code that's problematic which should be both faster and have a better signal to noise level for the average Puppet author. Let me know if those are incorrect assumption - maybe the puppet_trace bit is just yagni?? Add Comment
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces Okay, I'm going to get started on this. Just to clarify though, the entry with a zero as the line number was supposed to be there but wasn't being output due to a bug in the previous implementation, correct? I'm going to assume that it provides some additional information and that it can stay in the new implementation. Let me know if my understanding is incorrect or if this new implementation has to be bug-for-bug compatible. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.11180.1577991660427%40Atlassian.JIRA.
Jira (PUP-10159) Can't differentiate between cert and request on Puppet Server
Title: Message Title Justin Stoller commented on PUP-10159 Re: Can't differentiate between cert and request on Puppet Server I think this is captured in SERVER-2252 but is a good point to prioritizing that work. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.335692.1574091306000.9060.1576195980207%40Atlassian.JIRA.
Jira (PUP-10170) Do not store Puppet stack within Ruby stack / Backport master work to 5.5.x
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10170 Do not store Puppet stack within Ruby stack / Backport master work to 5.5.x I made a release here to describe the improvement backported. I figured I'd write about the change in output once we land PUP-10150 and do so there (since that ticket will be applicable to the release notes for both 5.5.x & 6.x. Lemme know if that's wrong. Change By: Justin Stoller Release Notes Summary: Puppet manifests that make use of stdlib's `deprecation` function, use the pseudo keywords `break`, `return`, and `next`, experience serialization warnings, or have custom Ruby code that makes use of the `PuppetStack.top_of_stack` function should see a marked increase in performance. Release Notes: Enhancement Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces Debugging Control Repos, seeing which manifests call others, is very useful. Is that the value in a Puppet only stack or both interleaved? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.42681.1574398140207%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces re: the last puppet function isn't in the stack with the extension of ExternalFileError. I have a hunch that the error which `fail` is throwing (which is a ParseError and should contain the correct PuppetStack) is being caught, wrapped, and re-thrown between the fail throwing it and the last include being called. Maybe in AST.safeevaluate? I think that is a solvable problem though w/o removing the ensure and I'd be happy to do more spelunking after we get some more comment from the community. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.42675.1574398080802%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces I've updated the title with what I think is the user facing effect. wrt the concern about not having a puppet stack available at the time of error formatting I think we could updated `ExternalFileError` to store the `PuppetStack.stacktrace` on creation and then extend the formatting to either print the puppet stack, ruby stack, or interleave them based on configuration. I'm unsure how valuable different parts of that work are, so I've also brought this ticket up to the Puppet community mailing list. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.42068.1574362560285%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10150 Ruby stacktraces no longer interleave Puppet Code stacktraces Change By: Justin Stoller Summary: Ruby stacktraces no longer interleave Puppet Stack Trace is cleared before exception handlers can query it Code stacktraces Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.42049.1574362321173%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10150 Puppet Stack Trace is cleared before exception handlers can query it Change By: Justin Stoller Assignee: Justin Stoller Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.41834.1574357340172%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller commented on PUP-10150 Re: Puppet Stack Trace is cleared before exception handlers can query it Would it be valuable to print the puppet stack as its own trace, or is it the interleaving of them with the ruby code valuable? (Or are there use cases for both?) Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.336155.1574344871000.41824.1574356140108%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller commented on PUP-10150 Re: Puppet Stack Trace is cleared before exception handlers can query it One thing that I wasn't clear from the description, there still is a ruby stack trace with `--trace`, right. ie, this is what I see on master: puppet (master *$%<>) :: be puppet apply broken.pp --trace Warning: Facter: Could not find a default route. Using first non-loopback interface Error: Evaluation Error: Error while evaluating a Function Call, somethinng (file: /Users/justin/Backup/code/work/puppet/broken.pp, line: 3, column: 3) on node localhost /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions/fail.rb:10:in `block in get_binding' /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions.rb:206:in `block (2 levels) in newfunction' /Users/justin/Backup/code/work/puppet/lib/puppet/util/profiler/around_profiler.rb:58:in `profile' /Users/justin/Backup/code/work/puppet/lib/puppet/util/profiler.rb:51:in `profile' /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions.rb:199:in `block in newfunction'
