Jira (PUP-5623) Callable type should be able to describe return type
Title: Message Title
Thomas Hallgren commented on PUP-5623
Re: Callable type should be able to describe return type
I'm all in favor of using a '*d'. And on that note, why not also use & to describe the block and for the sake of consistency, also mark a parameter with a prefix rather than mix a prefix with a suffix? We could use the very common notation that when a * means 0..n, then ? means 0..1. Here's an alternative proposal with all of that in mind.
Callable[{
params => {
a => Any
'?b' => Integer,
'?c' => String,
'*d' => Any,
'&e' => Callable[1, 1]
},
returns => Integer
}]
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Thomas Hallgren assigned an issue to Thomas Hallgren Puppet / PUP-1985 Allow class & define parameters to reference earlier parameters Change By: Thomas Hallgren Assignee: Thomas Hallgren Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5655) Puppet master --compile does not hand over hiera() lookup value to local variables
Title: Message Title Tom De Vylder commented on PUP-5655 Re: Puppet master --compile does not hand over hiera() lookup value to local variables Hi Thomas Hallgren, thank you for looking into it. Apparently hiera-erbyaml was the cause. It must have slipped my mind that it wasn't disabled. Disabling that I no longer get the error. I'll have to look into that (dead) project and see if I can fix the issue. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1559) Windows - Specifying well-known SIDs as a group / user in manifests causes errors
Title: Message Title Ethan Brown commented on PUP-1559 Re: Windows - Specifying well-known SIDs as a group / user in manifests causes errors Unfortunately it appears that the code introduced here was incorrect - addressing for PUP-5684 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2311) Change command names to use `_` instead of `" "` or `-`
Title: Message Title Kenneth Barber commented on PDB-2311 Re: Change command names to use `_` instead of `" "` or `-` Or underscores. Most of our outbound API fields and entities are now words separated by an underscore, not a hyphen. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5659) Puppet master does not fail catalog on unexisting resource in resource parameter
Title: Message Title Julien Pivotto commented on PUP-5659 Re: Puppet master does not fail catalog on unexisting resource in resource parameter This is not a regression, it has been there for a while (at least puppet 3.5,maybe sooner) Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5607) Puppetmaster uses its own facts with providers
Title: Message Title Julien Pivotto updated an issue Puppet / PUP-5607 Puppetmaster uses its own facts with providers Change By: Julien Pivotto Component/s: Catalog Application Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5644) puppet lookup command creates new SSL hierarchy with self-signed CA
Title: Message Title Thomas Hallgren commented on PUP-5644 Re: puppet lookup command creates new SSL hierarchy with self-signed CA This can be verified using a root user + masterless too. The ssl directory hierarchy is always created but there are no files when the fix is in place. Look for the self signed CA ssl/certs/ca.pem. You will also see a difference in that the message: Notice: Signed certificate request for ca is present before the fix but not after. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5685) Require or Anchor doesn't work for create_resources()
Title: Message Title Thijs Cramer created an issue Puppet / PUP-5685 Require or Anchor doesn't work for create_resources() Issue Type: Bug Affects Versions: PUP 4.3.0 Assignee: Unassigned Created: 2016/01/11 4:54 AM Environment: Puppet Enterprise 2015.3.1 Priority: Major Reporter: Thijs Cramer We have issues using Require => or Anchoring to encapsulate resources created by create_resources(). Can you tell us how to circumvent this issue? Add Comment
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Thomas Hallgren updated an issue Puppet / PUP-1985 Allow class & define parameters to reference earlier parameters Change By: Thomas Hallgren Fix Version/s: PUP 4.x Fix Version/s: PUP 4.3.2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5644) puppet lookup command creates new SSL hierarchy with self-signed CA
Title: Message Title Thomas Hallgren assigned an issue to qa Puppet / PUP-5644 puppet lookup command creates new SSL hierarchy with self-signed CA Change By: Thomas Hallgren Status: Needs Information Ready for Test Assignee: Sean Griffin qa Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5644) puppet lookup command creates new SSL hierarchy with self-signed CA
Title: Message Title Thomas Hallgren assigned an issue to Sean Griffin Puppet / PUP-5644 puppet lookup command creates new SSL hierarchy with self-signed CA Change By: Thomas Hallgren Assignee: qa Sean Griffin Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5644) puppet lookup command creates new SSL hierarchy with self-signed CA
Title: Message Title Thomas Hallgren assigned an issue to Sean Griffin Puppet / PUP-5644 puppet lookup command creates new SSL hierarchy with self-signed CA Change By: Thomas Hallgren Assignee: Thomas Hallgren Sean Griffin Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Thomas Hallgren updated an issue Puppet / PUP-1985 Allow class & define parameters to reference earlier parameters Change By: Thomas Hallgren Scope Change Category: Found Scope Change Reason: TODO list of current sprint is empty. Sprint: Language Triage 2016-01-13 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5648) Add Iterable type and runtime object
Title: Message Title Thomas Hallgren updated an issue Puppet / PUP-5648 Add Iterable type and runtime object Change By: Thomas Hallgren Summary: Descending range semantics are broken in the compiler Add Iterable type and runtime object Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5623) Callable type should be able to describe return type
Title: Message Title Henrik Lindberg commented on PUP-5623 Re: Callable type should be able to describe return type I like that better than what I proposed earlier on the same theme. For a Ruby savvy person there should be no problem guessing the meaning of '&', what I am not so sure of is if we are going to use & as as operator the same way as in Ruby - if we do, then it makes total sense in the Callable as well, otherwise it can be a source of confusion. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5686) The addition of the output of "systemctl status (service)" in reports
Title: Message Title Helen Campbell created an issue Puppet / PUP-5686 The addition of the output of "systemctl status (service)" in reports Issue Type: Improvement Assignee: Unassigned Created: 2016/01/11 6:48 AM Environment: redhat-7-x86_64-master - sles-12-x86_64-agent - full PE 3.8 Priority: Normal Reporter: Helen Campbell When running module tests on Jenkins a couple of times I've had to investigate the following failure: Error: /Stage[main]/Ntp::Service/Service[ntp]: Failed to call refresh: Could not restart Service[ntp]: Execution of '/usr/bin/systemctl restart ntpd' returned 1: Job for ntpd.service failed. See "systemctl status ntpd.service" and "journalctl -xn" for details. Instead of simply having "See systemctl status ntpd.service for details" it would benefit the customer, and the modules team, for the output of this command to be available in the report. Especially since it is often the case the testing environment no longe
Jira (PUP-5623) Callable type should be able to describe return type
Title: Message Title Henrik Lindberg commented on PUP-5623 Re: Callable type should be able to describe return type I have one more idea, inspired by Clojure and macros. What if we use a prefix operator (say &) followed by what looks like a function call to be a macro expansion? This means that the AST will contain a MacroCallExpression, with the arguments as expressions. It then looks up and calls the macro-function that implements the macro and passes each of the arguments as unevaluated AST nodes to that function. Using this scheme we can allow the same notation in the Callable - don't have all the details worked out yet, but it would look like this: Callable[¶ms( Integer $a, String $b= '', String $c ='', Any *$d, &block(Callable[1,1])] Since the source text constituting the macro arguments must be valid PP syntax (not necessarily semantically valid if we so choose), the default parameters notation is the postfix = and it requires a value. This is a bit of a problem - it would be fine to include the default value itself when creating a Callable for a function signature, but the value can be both large (long array), and it becomes a chore to define when given manually (say for an array with a minimum number of elements and of complex type). We could use additional macros for that: Callable[¶ms( Integer $a, &optional(String $b), &optional(String $c), Any *$d, &block(Callable[1,1])] Without knowing the reason why it is supposed to be that way, a user will be confused and it would be better to use macros for each entry: Callable[¶m( Integer $a), ¶m(String $b, default), ¶m(String $c, default), ¶m(Any *$d), &block(Callable[1,1])]
Jira (PUP-5648) Add Iterable type and runtime object
Title: Message Title Thomas Hallgren commented on PUP-5648 Re: Add Iterable type and runtime object What happens if Puppet implements a function using the same name as a function provided by a module? Will the module function get precedence? If so, is it a good thing to give modules the ability to override core functions in puppet? If not, then I'd say the discussion about reverse is moot. Let's just reimplement in puppet in a backward compatible way. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5648) Add Iterable type and runtime object
Title: Message Title Henrik Lindberg commented on PUP-5648 Re: Add Iterable type and runtime object For 4.x functions it is well defined: core implementation wins, and 4.x functions wins over 3.x functions. For 3.x functions it is undefined but I believe that core 3.x functions will win over module 3.x functions but I suspect people can do things with gems and load paths to make this not be true. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-1985 Allow class & define parameters to reference earlier parameters Change By: Kylo Ginsberg Fix Version/s: PUP 4.3.2 Fix Version/s: PUP 4.4.0 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5661) Stack level too deep issue
Title: Message Title Matthew Fischer commented on PUP-5661 Re: Stack level too deep issue Okay I set this up over the weekend with the following code changes to the ruby function instantiator: https://gist.github.com/matthewfischer/cf3ad554e8da8d454772 I'm able to catch the exception and print out that info but it won't stop in the debugger, perhaps because of the exception context? Is this where/how you envisioned me using the debugger? I'm unable to use byebug because I believe it requires Ruby 2.x and we're using 1.9. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2291) puppetdb 3.2.3 2016-01-11 Release
Title: Message Title Wyatt Alt updated an issue PuppetDB / PDB-2291 puppetdb 3.2.3 2016-01-11 Release Change By: Wyatt Alt Scope Change Category: Adopted Scope Change Reason: planned work created after sprint started Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2291) puppetdb 3.2.3 2016-01-11 Release
Title: Message Title Wyatt Alt updated an issue PuppetDB / PDB-2291 puppetdb 3.2.3 2016-01-11 Release Change By: Wyatt Alt Sprint: PuppetDB 2016-01-13 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2291) puppetdb 3.2.3 2016-01-11 Release
Title: Message Title Wyatt Alt updated an issue PuppetDB / PDB-2291 puppetdb 3.2.3 2016-01-11 Release Change By: Wyatt Alt Story Points: 2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5651) A puppet function declaration must be a top level construct
Title: Message Title Kylo Ginsberg assigned an issue to qa Puppet / PUP-5651 A puppet function declaration must be a top level construct Change By: Kylo Ginsberg Status: Ready for CI Test Assignee: qa Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5209) call_function and metadata.json: call a function from a different module, very strange behavior
Title: Message Title Kylo Ginsberg assigned an issue to qa Puppet / PUP-5209 call_function and metadata.json: call a function from a different module, very strange behavior Change By: Kylo Ginsberg Status: Ready for CI Test Assignee: qa Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5465) Resource Collectors cannot use resource references in search expressions
Title: Message Title Kylo Ginsberg assigned an issue to qa Puppet / PUP-5465 Resource Collectors cannot use resource references in search expressions Change By: Kylo Ginsberg Status: Ready for CI Test Assignee: qa Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5661) Stack level too deep issue
Title: Message Title Henrik Lindberg commented on PUP-5661 Re: Stack level too deep issue Yes almost - you need to put the call to debugger somewhere else than the very last line in a block (in this case the exception handling block (I commented on the commit as well with this). Did you check that other calls to debugger ends up in the debugger and stops execution? If that worked, then it is the "debugger call on last line" problem that you need to get past first. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5658) Disallow numeric ranges where from > to
Title: Message Title Kylo Ginsberg assigned an issue to qa Puppet / PUP-5658 Disallow numeric ranges where from > to Change By: Kylo Ginsberg Status: Ready for CI Test Assignee: qa Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2255) Make services "notable-pdb-event?" configurable and use that in extensions tests
Title: Message Title Wyatt Alt updated an issue PuppetDB / PDB-2255 Make services "notable-pdb-event?" configurable and use that in extensions tests Change By: Wyatt Alt Fix Version/s: PDB 3.2.x Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2246) Include trivial system summary information in jenkins test log
Title: Message Title Wyatt Alt updated an issue PuppetDB / PDB-2246 Include trivial system summary information in jenkins test log Change By: Wyatt Alt Fix Version/s: PDB 3.2.x Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4744) Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf
Title: Message Title Kylo Ginsberg commented on PUP-4744 Re: Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf Last call for watchers on this. See my comment above. Please respond with objections to the behavior by Tuesday Jan 12. If I don't here otherwise I'll update the description to match the behavior (which, again, I think actually makes sense). Thanks all!! Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4744) Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-4744 Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf Change By: Kylo Ginsberg Fix Version/s: PUP 4.2.3 Fix Version/s: PUP 4.3.2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Nick Walker commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined Henrik Lindberg Zee Alexander it's unclear to me why this ticket is still open as strict_variables looks like it would accomplish the task. However, I wonder if we could implement strict_variables = warn so that when variables are undefined a warning would be emitted so that users who cannot enable this straight away could get more information to work towards turning it on. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Zee Alexander commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined Nick Walker +1 That would be a great addition. There's a lot of Puppet code out there that assumes undefined variables can be tested. That would definitely ease the transition for folks with that kind of code. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5644) puppet lookup command creates new SSL hierarchy with self-signed CA
Title: Message Title Sean Griffin updated an issue Puppet / PUP-5644 puppet lookup command creates new SSL hierarchy with self-signed CA Change By: Sean Griffin QA Risk Assessment: Low QA Status: Reviewed Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5658) Disallow numeric ranges where from > to
Title: Message Title Chun Du assigned an issue to Sean Griffin Puppet / PUP-5658 Disallow numeric ranges where from > to Change By: Chun Du Assignee: qa Sean Griffin Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5684) Windows ADSI User and Group exists? checks are invalid
Title: Message Title Ethan Brown updated an issue Puppet / PUP-5684 Windows ADSI User and Group exists? checks are invalid Change By: Ethan Brown Fix Version/s: PUP 4.3.2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4818) PUP-121 (relative namespacing) was never actually resolved in 3.x future parser
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-4818 PUP-121 (relative namespacing) was never actually resolved in 3.x future parser Change By: Kylo Ginsberg Scrum Team: Language Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4818) PUP-121 (relative namespacing) was never actually resolved in 3.x future parser
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-4818 PUP-121 (relative namespacing) was never actually resolved in 3.x future parser Change By: Kylo Ginsberg Fix Version/s: PUP 3.8.5 Fix Version/s: PUP 3.8.6 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4818) PUP-121 (relative namespacing) was never actually resolved in 3.x future parser
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-4818 PUP-121 (relative namespacing) was never actually resolved in 3.x future parser Change By: Kylo Ginsberg Sprint: Language Triage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2312) create jenkins job to bypass acceptance testing on version increment
Title: Message Title Wyatt Alt created an issue PuppetDB / PDB-2312 create jenkins job to bypass acceptance testing on version increment Issue Type: Improvement Assignee: Unassigned Created: 2016/01/11 10:23 AM Priority: Normal Reporter: Wyatt Alt As part of the release process we waste an acceptance test run testing a project.clj version bump. We should have a special parameterized jenkins job that bumps the version and publishes to nexus immediately. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-4818) PUP-121 (relative namespacing) was never actually resolved in 3.x future parser
Title: Message Title Kylo Ginsberg commented on PUP-4818 Re: PUP-121 (relative namespacing) was never actually resolved in 3.x future parser Hmm, this was off my radar. I assigned to Language team, and put it in our triage sprint. I tentative assigned it to 3.8.6 (although that's not a planned release yet, so we'll see). Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Peter Huene commented on PUP-1985 Re: Allow class & define parameters to reference earlier parameters This will also need to be fixed for evaluating classes and defined types in the native compiler (i.e. any "call" that is evaluated from a resource). Other "calls" currently support this behavior because the parameters are set in scope in declaration order, e.g. calls to Puppet functions (when implemented) and the following parameterized EPP evaluation: inline_epp(@(SOURCE)) <%| $param1 = foo, $param2 = $param1 |%> <%= notice($param2) %> -SOURCE Add Comment
Jira (PUP-5212) Pip package provider fails to honor HTTP proxy settings
Title: Message Title Michael Smith commented on PUP-5212 Re: Pip package provider fails to honor HTTP proxy settings The expected behavior is a little more nuanced. Your testing isn't hitting the modified workflow, to do so you need to do ensure=latest. However, it points out that the implementation isn't as complete as it could be. There are two separate tools being used, and with this fix specifying the proxy is done separately for each of them. When doing ensure=latest, the pip provider queries pypi.python.org/pypi directly using XMLRPC; there was no way to specify the proxy for that, and the original PR only targeted fixing this issue. The rest of the pip provider works via the pip command-line tool, which has its own method for specifying a proxy. The original description mentions modifying /etc/pip.conf to specify a proxy, which is how it's setup for the pip command. So with the current provider, to get it fully functioning with a proxy you need to specify the proxy in both /etc/pip.conf and Puppet's configuration. The question is, should specifying it in /etc/pip.conf be necessary? pip provides a command-line argument - proxy, and we could invoke it with that argument. In Puppet 4, an alternative to setting /etc/pip.conf is to use the install_options property to specify proxy; using an incorrect option doesn't appear to cause pip to fail. I don't know that we would want the pip provider to automatically set -proxy with Puppet's HTTP proxy settings. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-4744) Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf
Title: Message Title Josh Cooper commented on PUP-4744 Re: Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf The behavior seems to be intentional due to PUP-2218 in https://github.com/puppetlabs/puppet/commit/cd4e69f5dafac33740b6c1d711451f8da169cae3#diff-f9fc191a659f726148aafaef592ee558L109. It seems ok to me, but it'd be good to get confirmation from Adrien Thebo Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4744) Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf
Title: Message Title Adrien Thebo commented on PUP-4744 Re: Yumrepo doesn't recognize whitespace delimited reposdir settings in /etc/yum.conf In Puppet 3.5.0/3.5.1 the yumrepo type was split out into a distinct type and provider, which was a massive overhaul. Moreover that code had almost no effective tests beforehand so we regressed on more than a handful of features during the refactor. It looks like this line (https://github.com/puppetlabs/puppet/blob/3.2.3/lib/puppet/type/yumrepo.rb#L112) originally made either spaces or commas work, but this intent wasn't clearly called out so I suspect that it was accidentally dropped. +1 for treating commas and spaces as equivalent values for the reposdir setting. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-13) Allow class & define parameters to reference earlier parameters
Title: Message Title Peter Huene created an issue Native Puppet / NPUP-13 Allow class & define parameters to reference earlier parameters Issue Type: Bug Assignee: Peter Huene Created: 2016/01/11 11:27 AM Priority: Normal Reporter: Peter Huene See PUP-1985 for related Puppet ticket. The call evaluator already sets variables into the new scope in declaration-order when a call is evaluated with pass-by-array or a pass-by-hash (used in parameterized EPP). However, for pass-by-resource (class and defined type evaluation), the default parameters are set into the resource before set into scope, preventing later parameters from having their default values reference earlier parameters. This needs to be addressed with this ticket. Additionally, because of the way pass-by-resource works, parameters in classes and defined types are not being checked for duplicated variable names. While this should be handled by any future AST validator, the call evaluator should also fail if it cannot set a variable in the new scope because it already exists. Add Comment
Jira (PUP-5212) Pip package provider fails to honor HTTP proxy settings
Title: Message Title Kylo Ginsberg commented on PUP-5212 Re: Pip package provider fails to honor HTTP proxy settings Thanks for the writeup Michael Smith. I don't think I'd grokked the nuance here either. I agree that we wouldn't necessarily want the pip provider to assume it should use Puppet's HTTP proxy settings - there's a larger issue here around being able to fine tune what proxy settings are used for (e.g. puppet master? forge? sources that providers hit (like this one)? etc). I'd be tempted to file a separate issue to track pip.conf-less use of proxy in the pip provider. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5485) Update docs URLs in puppet source
Title: Message Title Kenn Hussey updated an issue Puppet / PUP-5485 Update docs URLs in puppet source Change By: Kenn Hussey Component/s: DOCS Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (NPUP-13) Allow class & define parameters to reference earlier parameters
Title: Message Title Peter Huene updated an issue Native Puppet / NPUP-13 Allow class & define parameters to reference earlier parameters Change By: Peter Huene Scope Change Category: Found Scope Change Reason: Found from related PUP ticket; brought into sprint as low-risk fix. Story Points: 2 1 Sprint: Language Triage 2016-01-13 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, vis
Jira (PUP-5661) Stack level too deep issue
Title: Message Title
Matthew Fischer commented on PUP-5661
Re: Stack level too deep issue
I can get the debugger to work outside of the exception handler context it seems, but not inside, even if its not the last line. Maybe it wont work in an exception handler?
Here it is when I stick at the top of the code:
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/ruby_function_instantiator.rb:18 unless ruby_code_string.is_a?(String) && ruby_code_string =~ /Puppet\:\:Functions\.create_function/
[13, 22] in /usr/lib/ruby/vendor_ruby/puppet/pops/loader/ruby_function_instantiator.rb 13 # @return [Puppet::Pops::Functions.Function] - an instantiated function with global scope closure associated with the given loader 14 # 15 def self.create(loader, typed_name, source_ref, ruby_code_string) 16 require 'debugger' 17 debugger => 18 unless ruby_code_string.is_a?(String) && ruby_code_string =~ /Puppet\:\:Functions\.create_function/ 19 raise ArgumentError, "The code loaded from # {source_ref}
does not seem to be a Puppet 4x API function - no create_function call." 20 end 21 begin 22 created = eval(ruby_code_string, nil, source_ref, 1) (rdb:1)
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann created an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2016/01/11 12:42 PM
Priority:
Normal
Reporter:
buck huppmann
Hi
We have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a
resource
Unknown macro: { 'user'}
or the like
Well, that ends up, for each resource type, calling Puppet::Type::Resources#generate, which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:
Generate any new resources we need to manage. This is pretty hackish
right now, because it only supports purging. def generate return [] unless self.purge? resource_type.instances. reject
Unknown macro: { |r| catalog.resource_refs.include? r.ref }
. select
Unknown macro: { |r| check(r) }
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a { quote} { resource { 'user':purge => true} {quote } } or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{ quote} { # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end {quote } } In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{ quote} { def generate return [] unless self.purge?# memoizing this speeds things up a ton refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {quote } } )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{ resource { 'user':purge => true}}}or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?# memoizing this speeds things up a ton refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{resource { 'user':purge => true}}}or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?# memoizing this speeds things up a ton refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{ resource { 'user':purge => true} }} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block: {{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end }} In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function: {{ def generate return [] unless self.purge?# memoizing this speeds things up a ton refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }} )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{ resource { 'user':purge => true} }} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{ resource { 'user':purge => true} }} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block: {{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end }} In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function: {{ def generate return [] unless self.purge? # memoizing this speeds things up a ton refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }} )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {quote} resource { 'user':purge => true} {quote} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{ { quote} # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end {quote }} In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{ { quote} def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {quote } } )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a { quote} { resource { 'user':purge => true} {quote } } or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{ quote} { # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end {quote }}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{ quote} { def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {quote } } )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {{ resource { 'user':purge => true} }} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {quote}Does this at least work #right?{quote} resource { 'user':purge => true}or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {quote} Does this at least work#right?{quote} resource { 'user':purge => true} {quote} or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{{ # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end}}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{{ def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. }})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a { quote noformat } } resource { 'user':purge => true}{ quote noformat }or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{ { noformat} # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end {noformat } } In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{ { noformat} def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {noformat } } )
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {noformat} } resource { 'user':purge => true}{noformat}or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{noformat} # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end{noformat}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{noformat} def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {noformat})
Add Comment
Jira (PUP-5687) resources type takes long time to evalutes
Title: Message Title
buck huppmann updated an issue
Puppet / PUP-5687
resources type takes long time to evalutes
Change By:
buck huppmann
HiWe have darn near everything on our systems managed by puppet, so almost all of the resource types we manage have a {noformat} resource resources { 'user':purge => true}{noformat}or the likeWell, that ends up, for each resource type, calling [Puppet::Type::Resources#generate|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/resources.rb#L112], which call resource_refs() for each resource instance (managed or unmanaged) in the below reject() block:{noformat} # Generate any new resources we need to manage. This is pretty hackish # right now, because it only supports purging. def generatereturn [] unless self.purge?resource_type.instances. reject { |r| catalog.resource_refs.include? r.ref }. select { |r| check(r) }. select { |r| r.class.validproperty?(:ensure) }. select { |r| able_to_ensure_absent?(r) }. each { |resource|@parameters.each do |name, param| resource[name] = param.value if param.metaparam?end# Mark that we're purging, so transactions can handle relationships# correctlyresource.purging } end{noformat}In our case, that was 7000 calls to resource_refs totaling 265 seconds of runtime (which is about half my agent runtime so there's a bit more tuning left to go) for 20 calls of generate(). (Seem to be 2 calls of generate() per managed type.) If you just factor out the call to resource_refs from the reject loop, assigning it to a local variable in generate() before calling reject(), this reduces our runtime to 42 seconds (26 seconds in Array#reject and 15 in the instances call. If i turn the resource_refs into the keys of a hash, runtime drops to 18 seconds, but that's perhaps an optimization too far for people who don't have our insane catalog size. But, for purposes of being concrete, this is how i rewrote the first few lines of the function:{noformat} def generate return [] unless self.purge?refs = Hash[*catalog.resource_refs.zip([]).flatten] resource_type.instances. reject { |r| refs.include? r.ref }. {noformat})
Add Comment
Jira (PUP-1123) make it possible to use notify{} without puppet agent return 2
Title: Message Title
Robin Lee Powell commented on PUP-1123
Re: make it possible to use notify{} without puppet agent return 2
Here's how to roll your own if you're stuck on this:
$ cat ./modules/core/lib/puppet/type/info.rb Puppet::Type.newtype(:info) do
desc "Like the notify type, except emits to the client log at the info level, and does not change the exit code of puppet (which notify does)."
ensurable
newparam(:name, :namevar => true) do desc 'Arbitrary name used as identity' end
newparam(:message) do desc 'The message to emit (defaults to name if not given).'
defaultto { @resource[:name] }
end end
$ cat ./modules/core/lib/puppet/provider/info/log.rb Puppet::Type.type(:info).provide(:log) do
def exists? info(resource[:message]) true end
def create true end
def destroy true end end
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2298) Tag the release and create packages (PDB 3.2.3)
Title: Message Title Morgan Rhodes commented on PDB-2298 Re: Tag the release and create packages (PDB 3.2.3) Packages for 1052afd12636fa4614ef82133f65b58a64217c70 available at http://builds.puppetlabs.lan/puppetdb/3.2.3/ Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5399) changes in environment.conf does not trigger env cache eviction
Title: Message Title Nick Walker commented on PUP-5399 Re: changes in environment.conf does not trigger env cache eviction Henrik Lindberg is this really a bug? I expect that environment.conf works similarly to puppet.conf and puppet.conf doesn't evict the cache for changes does it? I think that implementing this for environment.conf and not puppet.conf would be inconsistent. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5661) Stack level too deep issue
Title: Message Title Henrik Lindberg commented on PUP-5661 Re: Stack level too deep issue Right, it may be that there is no more stack, and it is therefore not possible to call into the debugger? (I am speculating, I know it works to break in exception handlers (in a rescue) in general. You will naturally hit that breakpoint (at the top for every 4.x function load). An approach I used to hunt down memory leaks was to do conditional breakpoints that checked how much free memory was left. I am not sure how to get how much stack there is left. Will investigate and see if I can come up with a strategy. Another approach is to install this https://github.com/tmm1/rbtrace gem and add the required calls into it at an early point in puppet's runtime - say in Compiler.compile. Some suitable filters are needed for interesting method calls. Note that it allows configuration that can print out selected variables from the the scope that is being traced (could be used to trace function names). There are more than one place where function calls are being performed - either using the 3.x function calling mechanisms (yes there are several), or via 4.x (where the loader loads and creates them, but calls take another path once they are loaded. One thing struck me; regular expressions containing certain types of patterns can lead to deep recursion, not sure if that is true on Ruby. The Java regexp has had that problem in the past. I know you are probably no way near a reproducible case, which makes it a lot harder to help narrow down where the problem is. Happy to help answering questions about things like where to add points to trace. Coming back to the first approach. Something you could do is to call Kernel#caller(limit=1), which returns an array of stack frames from the given limit to the top of the stack. That could potentially be used to add a breakpoint if the stack size is at a very high level. Say something like: if caller().size > 1000 require 'debugger'; debugger puts 'stack > 1000' end
Jira (PDB-2299) Smoke test packages (PDB 3.2.3)
Title: Message Title Wyatt Alt commented on PDB-2299 Re: Smoke test packages (PDB 3.2.3) smoke tested debian wheezy according to https://confluence.puppetlabs.com/display/PP/Smoke+Testing+Guide+for+PDB+Releases Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5399) changes in environment.conf does not trigger env cache eviction
Title: Message Title Henrik Lindberg commented on PUP-5399 Re: changes in environment.conf does not trigger env cache eviction The idea why it is problematic to not evict on envrionment.conf change is that if you enter unlimited as the timeout in environment.conf you are sort of stuck. Now, there are workarounds as you can restart, touch settings, or use the Puppet Server service that evicts the cache. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5399) changes in environment.conf does not trigger env cache eviction
Title: Message Title Henrik Lindberg commented on PUP-5399 Re: changes in environment.conf does not trigger env cache eviction It is not that I particularly would like to fix this - there is more than one can of worms related to environments and timeout. Will be glad to not work on this Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Henrik Lindberg commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined From what I can tell by reading the source, puppet already logs a warning for undefined variable lookup. It should at least log a warning for all the cases where strict_variables would raise an error. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1985) Allow class & define parameters to reference earlier parameters
Title: Message Title Henrik Lindberg assigned an issue to Thomas Hallgren Puppet / PUP-1985 Allow class & define parameters to reference earlier parameters Change By: Henrik Lindberg Assignee: Thomas Hallgren Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Henrik Lindberg assigned an issue to Unassigned Puppet / PUP-1540 Puppet should support compilation failure if a variable is undefined Change By: Henrik Lindberg Assignee: Andrew Parker Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Nick Walker commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined Henrik Lindberg would that show up when running puppet agent -t? Because I'm pretty sure I made this mistake the other day and didn't get any feedback on the CLI Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2299) Smoke test packages (PDB 3.2.3)
Title: Message Title Wyatt Alt commented on PDB-2299 Re: Smoke test packages (PDB 3.2.3) tested el7 according to the same Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2313) (maint) Merge in cpp-project-template to the puppetdb-cli repo
Title: Message Title gepetto-bot updated an issue PuppetDB / PDB-2313 (maint) Merge in cpp-project-template to the puppetdb-cli repo Change By: gepetto-bot Sprint: PuppetDB 2016-01-13 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-2313) (maint) Merge in cpp-project-template to the puppetdb-cli repo
Title: Message Title gepetto-bot created an issue PuppetDB / PDB-2313 (maint) Merge in cpp-project-template to the puppetdb-cli repo Issue Type: Bug Assignee: Unassigned Created: 2016/01/11 2:23 PM Priority: Normal Reporter: gepetto-bot Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit ht
Jira (PDB-2313) (maint) Merge in cpp-project-template to the puppetdb-cli repo
Title: Message Title Andrew Roetker updated an issue PuppetDB / PDB-2313 (maint) Merge in cpp-project-template to the puppetdb-cli repo Change By: Andrew Roetker Scope Change Category: Adopted Scope Change Reason: Had time, easy fix Fix Version/s: PDB CLI 0.1.0 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4339) Non-US paths in environment variables gets garbled on Windows
Title: Message Title Steve Barlow updated an issue Puppet / PUP-4339 Non-US paths in environment variables gets garbled on Windows Change By: Steve Barlow Sprint: Windows Triage 2016-01-27 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5060) Add support for --facts in 'puppet lookup' command
Title: Message Title Garrett Guillotte commented on PUP-5060 Re: Add support for --facts in 'puppet lookup' command This is resolved as fixed, but the Release Notes field lists it as a known issue without a summary. Is this still a known issue, and if so, what do we need to document? Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5661) Stack level too deep issue
Title: Message Title Henrik Lindberg commented on PUP-5661 Re: Stack level too deep issue I looked at your stacktrace again - there is a long sequence of this: /usr/lib/ruby/vendor_ruby/puppet/parser/ast.rb:61:in `safeevaluate' /usr/lib/ruby/vendor_ruby/puppet/parser/ast/block_expression.rb:11:in `block in evaluate' /usr/lib/ruby/vendor_ruby/puppet/parser/ast/block_expression.rb:10:in `each' /usr/lib/ruby/vendor_ruby/puppet/parser/ast/block_expression.rb:10:in `evaluate' until it breaks out of that loop and starts doing something different; an assignment and a function call. It is really the long repeated part that is of interest. In the stack trace you got - the depth somewhere 10-20 iterations from when it breaks the cycle would be useful, and that it is made inside of the safeevaluate method. Unforunately it is not that straight forward to figure out what it is actually doing - the "block_expression" in the 3.x AST (which this is), is used to hold almost all logic for setting parameters, code bodies in classes, etc. And going from a general 3.x AST to the specifics in the 4.x AST requires a bit of navigation in the debugger. Basically you will find a PopsBridge object, that in turn holds on to the 4.x AST. Once at 4.x AST it is possible to find out all about the puppet logic involved in the recursion. Add Comment
Jira (PUP-5212) Pip package provider fails to honor HTTP proxy settings
Title: Message Title John Duarte commented on PUP-5212 Re: Pip package provider fails to honor HTTP proxy settings Michael Smith thank you for pointing out the expectation of setting up a pip specific proxy. I am unable to verify the puppet provider, because I am unable to get pip itself to honor the proxy setting. Therefor I am unable to verify the original issue. I expect the following interaction with pip to fail due to the erroneous proxy setting. Example run via pip with proxy set. vagrant@localhost:~$ cat /etc/pip.conf [global] proxy = foo: vagrant@localhost:~$ sudo pip install --upgrade hufflepuff Downloading/unpacking hufflepuff Downloading hufflepuff-1.1.tar.gz Running setup.py (path:/tmp/pip_build_root/hufflepuff/setup.py) egg_info for package hufflepuff Installing collected packages: hufflepuff
Jira (PDB-2314) Attempt migration to Artemis
Title: Message Title Rob Browning created an issue PuppetDB / PDB-2314 Attempt migration to Artemis Issue Type: Improvement Assignee: Unassigned Created: 2016/01/11 2:42 PM Priority: Normal Reporter: Rob Browning Perhaps time boxed, since we don't know what this might involve yet? Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-5212) Pip package provider fails to honor HTTP proxy settings
Title: Message Title Michael Smith commented on PUP-5212 Re: Pip package provider fails to honor HTTP proxy settings The simplest way to test may be to setup a local http proxy using squid, and check that communication appears in its log file. Use `puppet ... ensure=latest` to trigger querying pypi for the latest version. https://www.linode.com/docs/networking/squid/squid-http-proxy-ubuntu-12-04 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5688) puppet module tool needs to respect metadata version constraint
Title: Message Title Daniele Sluijters created an issue Puppet / PUP-5688 puppet module tool needs to respect metadata version constraint Issue Type: Improvement Assignee: Unassigned Created: 2016/01/11 2:46 PM Priority: Normal Reporter: Daniele Sluijters In order to facilitate people moving to Puppet 4 only versions of their module the Puppet Module Tool should learn to respect the Puppet version constraint in metadata.json. If a module is to be installed on a Puppet 3.8 system (without future parser enabled) it should default to installing the latest version that is Puppet 3 compatible, not just the latest. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-5560) Look at Improving Unicode for all Windows gems
Title: Message Title Steve Barlow updated an issue Puppet / PUP-5560 Look at Improving Unicode for all Windows gems Change By: Steve Barlow Sprint: Windows 2016-01-27 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5689) puppet module tool to support passing in a version
Title: Message Title Daniele Sluijters created an issue Puppet / PUP-5689 puppet module tool to support passing in a version Issue Type: Improvement Assignee: Unassigned Created: 2016/01/11 2:48 PM Priority: Normal Reporter: Daniele Sluijters In order to help people running in a mixed Puppet environment (with modern masters but perhaps older agents) it should be possible to explicitly tell PMT which version of a module to install. This will allow the administrator to install a specific, Puppet 3 compatible, module version even though it might satisfy the version constraint according to metadata.json. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Jira (PUP-5689) puppet module tool to support passing in a version
Title: Message Title
Daniele Sluijters updated an issue
Puppet / PUP-5689
puppet module tool to support passing in a version
Change By:
Daniele Sluijters
In order to help people running in a mixed Puppet environment (with modern masters but perhaps older agents) it should be possible to explicitly tell PMT which version of a module to install. This will allow the administrator to install a specific, Puppet 3 compatible, module version even though it might satisfy the version constraint according to {{metadata.json}} that would otherwise cause it to install a Puppet 4 only compatible version .
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5690) Test run the windows 10 acceptance tests
Title: Message Title Steve Barlow created an issue Puppet / PUP-5690 Test run the windows 10 acceptance tests Issue Type: Task Assignee: Unassigned Created: 2016/01/11 2:54 PM Priority: Normal Reporter: Steve Barlow Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.c
Jira (FACT-1196) Get pre-suites working for Ubuntu 15.10 (i386, x86_64) for Facter
Title: Message Title Josh Cooper commented on FACT-1196 Re: Get pre-suites working for Ubuntu 15.10 (i386, x86_64) for Facter No additional facter-specific work is required to support ubuntu wily, closing. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5060) Add support for --facts in 'puppet lookup' command
Title: Message Title Henrik Lindberg commented on PUP-5060 Re: Add support for --facts in 'puppet lookup' command We added support for - facts in 4.3.2, but there were issues with using that. It looked strange to say this was released as a new feature only to take it back as a known issue. Instead, the entire feature was marked as known problem wrt the overall new feature of "the lookup command line tool". The problems are afaik, addressed in 4.3.2 for the supported use cases; puppet apply configuration, and running as root on master, and then a varying degree of support for cases in between those that we will address in 4.4. So, basically I think we need to change this from "known issue" to "new feature" Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5060) Add support for --facts in 'puppet lookup' command
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5060 Add support for --facts in 'puppet lookup' command Change By: Henrik Lindberg Release Notes Summary: The lookup command line tool now accepts --facts factsfile to set/mix-in facts from the command line. See the help for the lookup command for more information about the details. Release Notes: Known Issue New Feature Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5060) Add support for --facts in 'puppet lookup' command
Title: Message Title Garrett Guillotte commented on PUP-5060 Re: Add support for --facts in 'puppet lookup' command Thanks, Henrik Lindberg! Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Henrik Lindberg commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined It is logged on the master, but I just tried, and it looks like a regression: notice [$x, 1] Wonder if there is a change in the default for ignored warnings... or if something else has gone wrong. It raises an error at least with strict_variables turned on, but I expected to see a warning. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1540) Puppet should support compilation failure if a variable is undefined
Title: Message Title Henrik Lindberg commented on PUP-1540 Re: Puppet should support compilation failure if a variable is undefined Ah, it only warns for qualified variables with more than one namespace notice [$x::y, 1] logs a warning on the master notice [$osfanamliu, 1] Does not log an error. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https:/
