Jira (PUP-477) Implement Strict Numbers
Title: Message Title Henrik Lindberg commented on PUP-477 Re: Implement Strict Numbers Josh Cooper at some point you may want to make "strict numbers" the only behavior (not behind the strict-flag) and some logic could then be removed. Add Comment This message was sent by Atlassian Jira (v8.20.21#820021-sha1:38274c8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.16072.1380731456000.1196.1684829580040%40Atlassian.JIRA.
Jira (PUP-11813) Parenthesized expression causes EPP template validation failures
Title: Message Title Henrik Lindberg commented on PUP-11813 Re: Parenthesized _expression_ causes EPP template validation failures The validation and transformation of the AST that comes back from the parser is probably where the problem is. It may naively look for "Something followed by parentheses" and it finds TEXT PARENTHESIZED_EXPRESSION. It should just let that pass as it cannot possibly be the start of a parameterized EPP. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.483957.1680802564000.13261.1684142520020%40Atlassian.JIRA.
Jira (PUP-11066) optional_param does not set Integer to optional for custom ruby functions
Title: Message Title Henrik Lindberg commented on PUP-11066 Re: optional_param does not set Integer to optional for custom ruby functions The proposal to make all optional_parameter wrap the type in Optional is bad because it would break the contract of the function API and possibly deliver undef values to functions that are not implemented to handle that. As Josh pointed out, it is easy to get confused because "optionality" differs depending on context. I regret that we named the "also accepts undef" data type Optional, we were debating several names like Nullable[T], Undefable[T], and Maybe[T]. We also discussed if Undef[T] made sense or not. Unfortunately, it is way too late to make such a change. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.399614.1621017826000.13238.1684139940023%40Atlassian.JIRA.
Jira (PUP-10928) Puppet falls back to non-rich data if there is binary data in the catalog
Title: Message Title Henrik Lindberg commented on PUP-10928 Re: Puppet falls back to non-rich data if there is binary data in the catalog Isn't the "accidental binary in the catalog" solved by automatically transforming binary string to a proper Binary intsance? (Thus requiring rich data transfer). Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.388074.1613713885000.1605.1679231040021%40Atlassian.JIRA.
Jira (PUP-11784) Running `puppet epp render` on a template fails subtemplates
Title: Message Title Henrik Lindberg commented on PUP-11784 Re: Running `puppet epp render` on a template fails subtemplates The epp tool simply does not set up that the call it makes to the epp function is made within the scope of a module. While it could look at the path of the given template file and assume this is from a module it may be better to add an option to the command --module to force it to set up the context from which the call is made. This would also allow adding support for giving module relative template names. That would be of value to test that template files are placed at the expected location. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.483160.1679074293000.1604.1679230740030%40Atlassian.JIRA.
Jira (PUP-11726) Allow Puppet function calls from hiera data
Title: Message Title
Henrik Lindberg commented on PUP-11726
Re: Allow Puppet function calls from hiera data
This was something I really wanted to address but did not have a good solution for at the time. The main issue was that the hiera specified/implemented interpolation syntax/logic blocks innovation in this area - we were not able to find syntax that would be 100% backwards compatible. I always thought it was a shame that hiera interpolation is different in syntax and features compared to puppet string interpolation. I wrote the puppet language hiera backend in my tahu module as a proof of concept of what it would take to support this if done in the most powerful way - i.e. data is puppet language. I had ideas of incorporating that implementation into the existing hiera json/yaml backends by having backend options to toggle the interpolation behavior, either for an entry in hiera.yaml, or as a lookup_option per key. That would enable people to opt in where they need this feature. I.e. that flag would control how the content of a hiera {{%{ }}} part would be interpreted, as current hiera interpolation or as if it was a {{${ } }}part in a puppet language string. Just my 2c...
Add Comment
This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.478042.1673279887000.9720.1676151420022%40Atlassian.JIRA.
Jira (PUP-5612) Error message for declaring resource without title is confusing
Title: Message Title Henrik Lindberg commented on PUP-5612 Re: Error message for declaring resource without title is confusing Kjetil Torgrim Homme It is an error by design - when slicing (i.e. using [] as an operator) it must follow the left hand side _expression_ without any whitespace inbetween). Class ['acme'] and Class ['acme'] means the same thing - just a reference to the type Class (which is meaningless), and then the production of an array with a single string value. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Jira (PUP-11621) Drop Hiera 3 Requirement
Title: Message Title Henrik Lindberg commented on PUP-11621 Re: Drop Hiera 3 Requirement Ben Ford Hiera 5 backends would most likely be written in ruby and be functions that operates on the lookup context passed into those functions - most likely having a call to context.not_found. Something to look out for are modules with both hiera 3 and hira 5 implementations where the hiera 5 implementation just delegates to the hiera 3 implementation. In those cases, the hiera 3 implementation may (unfortunately) require the hiera 3 gem. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.465779.1661814931000.39479.1664746260025%40Atlassian.JIRA.
Jira (HI-633) Content from eyaml should be Sensitive by default
Title: Message Title Henrik Lindberg commented on HI-633 Re: Content from eyaml should be Sensitive by default This would need to be done in the eyaml module since it can read plain yaml as well as the specially encoded eyaml content. Many users rely on eyaml backend to also read plain text so cannot be done in hiera as it would not know if the source was encoded or not. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.468337.1663599642000.39478.1664745660025%40Atlassian.JIRA.
Jira (PUP-11632) locator.extract_tree_text does returns bad string on simple function call
Title: Message Title Henrik Lindberg commented on PUP-11632 Re: locator.extract_tree_text does returns bad string on simple function call Daniel Parks Are you saying that when using the Puppet::Pops::Adapters::SourcePosAdapter the correct result is obtained, but not when using ast.extract_tree_text ? Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.469454.166422969.39477.1664745480216%40Atlassian.JIRA.
Jira (PUP-11632) locator.extract_tree_text does returns bad string on simple function call
Title: Message Title
Henrik Lindberg commented on PUP-11632
Re: locator.extract_tree_text does returns bad string on simple function call
The most probable cause of these kinds of problems are mistakes in the grammar itself where the parsing logic assigns a location (position and length) to produced ast nodes using a call to loc. For example like this lines 229 to 230
bracketed_expression
: _expression_ LBRACK access_args endcomma RBRACK =LBRACK { result = val[0].access(val[2]); loc result, val[0], val[4] }
The rules in the grammar should allow location information to bubble upwards, and when doing so, it must return a result with a location based on the correct reduced tokens. The grammar source I references above for expr[expr] the correct tokens (val[0] and val[4]) are used. For the selector _expression_ however found [here|http://example.com] it seems to be wrong as it accesses val[0] and val[1], which means that the ast node for a selector entry will stop at the =>. Here is the source:
selector_entry
: _expression_ FARROW _expression_ { result = Factory.MAP(val[0], val[2]) ; loc result, val[1] }
Unfortunately location information is somewhat different throughout the grammar, for some an astnode will have the position of the operator and the operators length, and others include the location of length of the entire _expression_. That is naturally where the method extract_tree_text comes in as it should find the earliest source position and longest length starting from the ast node it operates on. Since the off by one error is not visible for every node, it most likely not the calculation itself that is wrong, but the information recorded by the parser. The problem could also be in the factory methods that produce the ast nodes. Fo anyone tackling this, there is an overview of how this works in Puppet Internals - Puppet LanguageDevelopment PS, it would have been handy if the puppet parser dump command had an option to output the location information as it would then be trivial to manually verify the location and lengths produced by the
Jira (PUP-11546) Request feature to normalize case in Hiera interpolation tokens within hiera.yaml
Title: Message Title
Henrik Lindberg commented on PUP-11546
Re: Request feature to normalize case in Hiera interpolation tokens within hiera.yaml
Seems far better to normalize the facts values. An open ended solution would be to make the interpolation syntax of values in hiera.yaml be able to describe arbitrary function calls (to puppet functions) thereby making it possible to transform values used in paths. This would cater to other requests as well were users need to process values in other ways. This is somewhat difficult though due to the syntax of hiera interpolations so it can be hard to find suitable operators without causing breaking changes. An alternative discussed in the past was to allow one or more function calls to be listed in the hiera.yaml under a new top level key - each entry would name a (new) variable and the returned value of the function call would be the value. Those variables would be local to hiera.yaml. For example:
derived_variables:
normalized:
my_facts_normalizer
And a normalized value could then be interpolated with something like (assuming normalized is a hash of all normalized facts of interest):
"somewhere/% {normalized.foo_fact} /x.yaml"
Add Comment
Jira (HI-628) convert_to: Sensitive only unless undef
Title: Message Title Henrik Lindberg commented on HI-628 Re: convert_to: Sensitive only unless undef Another implementation option is to add an optionally_convert_to feature that does what is requested. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.434696.1644408649000.5113.1659127980031%40Atlassian.JIRA.
Jira (HI-628) convert_to: Sensitive only unless undef
Title: Message Title Henrik Lindberg commented on HI-628 Re: convert_to: Sensitive only unless undef Kind of difficult to quick fix since a Sensitive.new should always return a Sensitive instance (or error). Also, it makes sense that an undef value could be sensitive (i.e you don't want to leak the information that a value is explicitly undef). It would be more coherent if it was possible to specify convert_to: Optional[Sensitive] (which IIRC isn't supported). It could be implemented such that Optional's new function checks if the value it is converting is undef, and then returning undef, otherwise delegating the call to new for the type it decorates. Then, no internal protocols would be broken and it is totally clear what is wanted. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.434696.1644408649000.5109.1659127800046%40Atlassian.JIRA.
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Henrik Lindberg commented on PUP-9577 Re: Large numbers of facts cause slow performance IIRC, the context with variables is created each time an ERB is called - it could be possible to cache this for all the facts (i.e. the global static state), and just mix in the scope specific variables at the time of the ERB call. Add Comment This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.301092.1553181872000.60490.1624104240027%40Atlassian.JIRA.
Jira (PUP-10966) Allow full-relative path references in file(), template(), related functions
Title: Message Title
Henrik Lindberg commented on PUP-10966
Re: Allow full-relative path references in file(), template(), related functions
I always wondered why the reference isn't a proper URL/URI including scheme. That would also open up for reading files and templates via http. For example module scheme could address any file in a module (i.e. what Reid proposed) - it would then not clash with the current "path only" based argument. You have to type a bit more though
# This retrieves content from /modname/templates/filename
template('module://modname/templates/filename')
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Jira (HI-622) Hiera/Lookup should emit warning about keys with malformed namespaces
Title: Message Title Henrik Lindberg commented on HI-622 Re: Hiera/Lookup should emit warning about keys with malformed namespaces This sounds like something for puppet lint rather than puppet core. If added to puppet it could spit out the warning if the lookup of the key resulted in a "not found" and explain is on. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.390573.1615409101000.166264.1615832400256%40Atlassian.JIRA.
Jira (PUP-10958) Load everything in an environment upfront before first compile
Title: Message Title Henrik Lindberg commented on PUP-10958 Re: Load everything in an environment upfront before first compile Did you look into rewriting resource loading for compilation? That was something I wanted to do so that resource types and classes were also loaded with 4x loaders (the agent could continue loading the old way). I believe that would untangle one mess where logic needs to jump through hoops due to the many entry points leading to resource type loading - there must be a representation of it in the 4.x loaders to ensure a resource type isn't overridden with a pcore data type (for example). Thomas struggled with that and as I recall it there was a long tail of bugs related to that. Having a clear separation of what happens during compilation and what the agent does would be very beneficial. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.390453.1615313252000.161239.1615320240141%40Atlassian.JIRA.
Jira (HI-621) Need some help of call same hiera variable from multiple hiera files
Title: Message Title Henrik Lindberg commented on HI-621 Re: Need some help of call same hiera variable from multiple hiera files Have you tried using Google? (Search for puppet community slack for example) Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389949.1614876617000.159109.1615195020031%40Atlassian.JIRA.
Jira (HI-621) Need some help of call same hiera variable from multiple hiera files
Title: Message Title Henrik Lindberg updated an issue Hiera / HI-621 Need some help of call same hiera variable from multiple hiera files Change By: Henrik Lindberg Priority: Major Low Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389949.1614876617000.157636.1614881880098%40Atlassian.JIRA.
Jira (HI-621) Need some help of call same hiera variable from multiple hiera files
Title: Message Title Henrik Lindberg commented on HI-621 Re: Need some help of call same hiera variable from multiple hiera files You opened a ticket against the now deprecated Hiera version 3. It is also more of a usage question that an issue. You will get much better (and quicker) help from the community if you hop on to puppet's slack and ask for help there. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389949.1614876617000.157635.1614881880047%40Atlassian.JIRA.
Jira (PUP-8539) Hiera trusted fact lookup
Title: Message Title Henrik Lindberg commented on PUP-8539 Re: Hiera trusted fact lookup Josh Cooper Does it make a difference if you add --compile to the lookup command? It may be that trusted is only set when doing a compile. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.220490.1509835991000.154874.1614684780090%40Atlassian.JIRA.
Jira (PUP-10944) Enum.new
Title: Message Title Henrik Lindberg commented on PUP-10944 Re: Enum.new The Enum data type does not support new at the moment and would be easy to add without any consequences. It makes sense to be able to create a string from an enumeration based on Boolean or Numeric. It should error if the converted value leads to an index out of range for the enum. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.389306.1614616131000.154872.1614684240029%40Atlassian.JIRA.
Jira (PUP-10929) Syntax error in previously valid puppet code due to removal of application orchestration keywords
Title: Message Title Henrik Lindberg commented on PUP-10929 Re: Syntax error in previously valid puppet code due to removal of application orchestration keywords Josh Cooper The benefit of keeping them reserved is that you may want to use them in the future for something other than the now removed application orchestration and it takes a major release to get there plus a lot of pain for users if they again would be put to use if they had been free to use for a while. You are right about the options. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.388276.1614006941000.154108.1614622080320%40Atlassian.JIRA.
Jira (PUP-10491) Allow adding descriptive or administrative information to resources
Title: Message Title
Henrik Lindberg commented on PUP-10491
Re: Allow adding descriptive or administrative information to resources
A couple of thoughts to make annotations composable is to require that they are set for a specific data type. This way users can both get validation (the value must match the data type), and clashes are avoided, say you want to use more than one annotation. The data type can be a simple alias, but have to exist. For example:
type OurOrg::Owner = String[1]
annotation => { OurOrg::Owner => "Kim Jones" }
Also note that Pcore has the notion of annotation that works in a similar way - there the type must be a kind of annotation, and any Pcore Object can be annotated. Annotations are included in the serialization of a Pcore Object. Puppet has a function to allow users to annotate Objects. In Pcore, you use the annotation type to retrieve the annotation value from the object. This was done so that annotations can have behavior - for example, the value associated with the annotated target could be some kind of identifier and the value may be stored some place else and retrieved from an external source, or it could be some other kind of derived value. Something important to decide on is if annotations should propagate (like tags) or not. The use case "notify an owner if resource failed" kind of implies that it needs to propagate. Just my 2c thrown into the mix.
Add Comment
Jira (PUP-10929) Syntax error in previously valid puppet code due to removal of application orchestration keywords
Title: Message Title Henrik Lindberg commented on PUP-10929 Re: Syntax error in previously valid puppet code due to removal of application orchestration keywords Josh Cooper It is this part of the grammar: attribute_name : NAME | keyword and keyword is a rule with a list of tokens. The tokens for the now reserved keywords must be on that list to make them ok to use as names of resource attributes or the result is the reported "syntax error". Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe
Jira (PUP-10928) Puppet falls back to non-rich data if there is binary data in the catalog
Title: Message Title Henrik Lindberg commented on PUP-10928 Re: Puppet falls back to non-rich data if there is binary data in the catalog IIRC, when rich data serialization encounters ascii-8-bit strings then it turns those into proper Binary instances I may be wrong though as that may not have made it in for some reason). It is only if the receiver does not accept rich-data there will be a real problem - and it should then fail when there is rich data. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.388074.1613713885000.146312.1613743080048%40Atlassian.JIRA.
Jira (PUP-10890) empty lookup_options
Title: Message Title Henrik Lindberg commented on PUP-10890 Re: empty lookup_options line 288 is weird with two trailing unless - I think it errors as it should if value is neither nil nor a hash. Then it returns options as is if modulename is not given. Then it will fail if options are nil on line 292. The correct thing is probably to change line 293 to read: return options if module_name.nil? || options.nil? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.386484.1612558652000.135094.1612612980050%40Atlassian.JIRA.
Jira (PUP-10863) Invalid parser function breaks catalog compilation in all environments
Title: Message Title
Henrik Lindberg commented on PUP-10863
Re: Invalid parser function breaks catalog compilation in all environments
It is probably going wrong in the logic that validates the old 3x functions when they are loaded. The borked function in question is overly verbose and uses constructs that the validation parsing was not designed to handle. If the "borked" was written on the form shown below, it should load (did not try though).
module Puppet::Parser::Functions newfunction( :bork, :type => :rvalue, :doc => 'B0rks the puppetserver' ) do |args| return true end end {ruby} I realize that the issue is really "loading completely borked function implementation should not have effect on subsequent compilations where the borked function is unused" - and not "I cannot load this function". As a side note - In general the recommendation is to not use the legacy (3.x) style for function implementations. Also note that it is close to impossible to ward off all possible cases of "loading bad logic in Ruby" due to Ruby's super flexible nature. The 3.x function loading is susceptible to a wider range of mistakes than the 4.x API and that is why the Ruby source is parsed and analyzed before being passed on to actually loading it. The 3.x API was invented long before the Ruby syntax was invented that is used in the borked function, so here is also a question about how much energy should be spent on fixing modern style mistakes made in this antique context. - - - In other words - fix the borked function.
Add Comment
This message was sent by Atlassian Jira
Jira (PUP-9560) master compile errors on upper case class ref with unknown class where apply works
Title: Message Title Henrik Lindberg commented on PUP-9560 Re: master compile errors on upper case class ref with unknown class where apply works I agree with Josh Cooper, the correct way to reference the class is by using the lower class name in this case. The upper cased name is actually a reference to the data type - so when writing Class[A] that should really mean the meta type of the class named "a". With classes, since their instances are singletons it does not make a difference if statements are made about the specific "a" instance or all instances since there can be only one. In the puppet language the _expression_ Class[A] gives an error since it does not accept a type reference to the type A. Ideally the same kind of reference in string form "Class[A]" should be an error. The puppet language accepts Class["A"] since it is specified that class names are case independant (and lower case in normal form), and now the class name is a string so it downcases it. There are a bunch of other problems with the parser that parses resource references (the classic being resources with square brackets in their name). If that is ever sanitized it would be worth to clean up this case mismatch as well. OTOH, puppet db could do a case insensitive compare. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PUP-10846) Add a subdirectory constructor for modules
Title: Message Title Henrik Lindberg commented on PUP-10846 Re: Add a subdirectory constructor for modules If you have a module foo, with a name space zoo having classes lion and tiger you can organize them like this: . └── foo └── manifests ├── zoo │ ├── lion.pp │ └── tiger.pp ├── init.pp └── zoo.pp And your foo::zoo::lion and foo::zoo::tiger classes should both use include foo::zoo. The only thing you are not getting is the "magic" processing of the init.pp which is done only at the module level. What is it you cannot do with this? Add Comment
Jira (PUP-10782) Could not parse for environment ...: Syntax error at '=>' ...
Title: Message Title
Henrik Lindberg commented on PUP-10782
Re: Could not parse for environment ...: Syntax error at '=>' ...
Well, that is the point at which the syntax error occurs. There isn't really much that can be done about that. The second function is just wrong - it cannot be parsed - the first _expression_ appears to set a variable to an empty array, but it actually continues with the brace enclosed part since an _expression_ followed by a block may be one of the resource type expressions. In most cases when wanting to return a literal hash, the preceding line must be terminated with semicolon ;, or use an explicit return.
function test::invalid() >> Data {
$test_one = [
];
{
"test" => $test_one
}
}
function test::invalid() >> Data {
$test_one = [
]
Jira (PUP-10782) Could not parse for environment ...: Syntax error at '=>' ...
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-10782 Could not parse for environment ...: Syntax error at '=>' ... Change By: Henrik Lindberg Issue Type: Bug Improvement Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.378063.1605190342000.77846.1605200760252%40Atlassian.JIRA.
Jira (PUP-10775) Puppet agent fails with `Failed to deserialize Puppet::Resource::Catalog`
Title: Message Title Henrik Lindberg commented on PUP-10775 Re: Puppet agent fails with `Failed to deserialize Puppet::Resource::Catalog` A guess here is that binary files that cause it to fail contain sequences that result in invalid UTF-8 encoding. There is a function binary_file() that works like the file() function but it returns a Binary data type instead of a String. That function should be used instead of file() for binary content. This is supported since puppet 6 where the "rich data" catalog format is the default format (it can serialize all of the data types in the Puppet type system in two different encodings; JSON or Msgpack, where JSON is the default). In addition to handling instance of the Binary data type, it also does the right thing if it gets a string in ASCII-8bit encoding as it will be treated the same way as Binary. In a JSON encoding the binary content will be Base64 encoded text, and in Msgpack it will be a Msgpack binary. Hope that helps. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.377304.1604596654000.73826.1604671620027%40Atlassian.JIRA.
Jira (PUP-10726) hiera lookup removes duplicate array elements during deep merge
Title: Message Title Henrik Lindberg commented on PUP-10726 Re: hiera lookup removes duplicate array elements during deep merge Yes it does. I believe it has always done that and what is wanted in most situations as you would otherwise end up with duplicates. Don't think the default behaviour can be changed as that would be a breaking change for many users. Maybe this could be controlled with a lookup option to not unique merged arrays. It then depends on if this is supported in the deep merge gem that is used to perform the deep merge. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.375651.1603374334000.63168.1603540680028%40Atlassian.JIRA.
Jira (PUP-10727) Cannot define a default Timespan value for an attribute in a Ruby language data type
Title: Message Title Henrik Lindberg commented on PUP-10727 Re: Cannot define a default Timespan value for an attribute in a Ruby language data type This could be something simple, like the static/constant evaluator used to evaluate the interface specification not handling calls to new as it should. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.375925.1603486678000.63167.1603540260029%40Atlassian.JIRA.
Jira (PUP-7843) The list of reserved type names known to the parser validator is incomplete
Title: Message Title Henrik Lindberg commented on PUP-7843 Re: The list of reserved type names known to the parser validator is incomplete The issue is that for each define 'x' which is of type Resource['x'], there is also an alias 'X' to the defined Resource type. (the same for class 'x' which is a Class['x']). Thus any define or class in top scope has the potential to clash wrt. aliases vs. core data types. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.205816.1502784101000.46092.1601464080032%40Atlassian.JIRA.
Jira (PUP-8969) Support interpolation of sensitive values in EPP templates
Title: Message Title Henrik Lindberg commented on PUP-8969 Re: Support interpolation of sensitive values in EPP templates I don't think that problem can be resolved with some kind of general implementation as that would mean unwrapping arguments to calls and rewrapping them for every function call. OTOH, you kind of want it to break as that signals "hey, you need to deal with the fact this is a Sensitive value". The other approach is naturally to add support for operating on Sensitive to every function. For some functions that would not be hard to do, but for others with complex dispatches it becomes difficult and would necessitate a feature allowing "re-dispatch" after unwrapping. I don't think that is worth the effort! Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.262922.1530114614000.38535.1600417320024%40Atlassian.JIRA.
Jira (HI-620) Hiera mapped_paths should permit glob expansion
Title: Message Title Henrik Lindberg commented on HI-620 Re: Hiera mapped_paths should permit glob expansion The HI project is for the deprecated hiera 3 gem. Please move this ticket to Puppet since this is for hiera 5. I think that in order to support this there would need to be something like a mapped_globs as it would not otherwise be 100 backwards compatible (risk of expanding glob when this is not wanted). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371891.1600185467000.37100.1600259280022%40Atlassian.JIRA.
Jira (PUP-10665) Add weak dependencies to puppet resources
Title: Message Title Henrik Lindberg commented on PUP-10665 Re: Add weak dependencies to puppet resources Is the case "resource must be there, but don't propagate errors" valid? Seems like optionally_requires and do_not_propagate are separate things. Maybe these concepts are: optionally_before, optionaly_after (since optionally_require is a bit of an oxymoron) - this is a soft dependency, no error if missing isolated_before, isolated_after - this does not propagate errors (isolated == isolated from errors) and implies optionality unless resource is also listed as required. Just a thought. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371714.1599956556000.35178.1600094280037%40Atlassian.JIRA.
Jira (HI-619) Hiera return all keys (or keys matching pattern)
Title: Message Title Henrik Lindberg commented on HI-619 Re: Hiera return all keys (or keys matching pattern) Hiera is not designed to be able to enumerate all the keys. It can only answer with the value bound to a key (which it arrives at via a large set of rules). You cannot do this by just looking at simple yaml/json files since it is a particular backend that reads those and provides the answer. You can also have backends that are backed by a database, or say LDAP. If you asked for "all keys" you would get a return that potentially consists of very large amounts of data. Further, since lookups are done in a particular context (set of variable values) the result and indeed the set of available keys changes. Thus the answer to the question "give me all keys" is multidimensional - or would need to be constrained with the set of variables that the hiera key resolution depends on - something that is possible for some known variables like facts - but the full set of variables isn't declared anywhere - the backends can do pretty much what they want. It difficult, but not impossible to add "enumeration of keys" to the hiera API, but it would need to have a mechanism for backends to opt in to support it, and also some mechanism for backends to respond with a signal that it would result in too much data. The implementation would be difficult since a backend in hiera 5 is just a simple function with a very clear purpose; too lookup a value. It would probably have to be an additional function that can do the enumeration which each hiera backend function provider would need to implement to support this feature. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10642) Uppercase Default value in conditional documentation a typo?
Title: Message Title
Henrik Lindberg commented on PUP-10642
Re: Uppercase Default value in conditional documentation a typo?
There should be more examples showing those other types of matches.
case $x {
Integer: { ... } # x is an Integer value
String[10]: { ...}# x is a string 10 or more chars long
String: { ... } # x is a string short than 10 (since option above took the longer ones}case [$x, $y] { [String, Integer]: { ... } # x is String and y is an Integer [10, "hello"]: { ... } # x is the integer 10, and y the string "hello" [1, default]: { ... }# x is the integer 1, and y can be any value (could also have been written Any)}
if that is not already in the documentation, it should be.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10642) Uppercase Default value in conditional documentation a typo?
Title: Message Title
Henrik Lindberg commented on PUP-10642
Re: Uppercase Default value in conditional documentation a typo?
The intention was probably to have this (with a lower case default:
case $facts['os']['name'] {
'Solaris': {
include role::solaris
}
'RedHat', 'CentOS': {
include role::redhat
}
/^(Debian|Ubuntu)$/: {
include role::debian
}
default: {
include role::generic
}
}
Jira (PUP-10660) $module_name is not available up in epp()
Title: Message Title Henrik Lindberg commented on PUP-10660 Re: $module_name is not available up in epp() Ah, yes... the global scope is actually named "" (nothing). Also an ancient design decision. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371297.1599469893000.34695.1599850620030%40Atlassian.JIRA.
Jira (PUP-10660) $module_name is not available up in epp()
Title: Message Title Henrik Lindberg commented on PUP-10660 Re: $module_name is not available up in epp() That is also by design (ancient design decision that all variables that does not exist resolve to undef which renders as empty string). You can turn on "strict variables" as that would make it error instead. It is not on by default due to backwards compatibility reasons and if you turn it on you may find that the code you are running needs to be modified. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371297.1599469893000.34396.1599832440034%40Atlassian.JIRA.
Jira (PUP-10660) $module_name is not available up in epp()
Title: Message Title
Henrik Lindberg commented on PUP-10660
Re: $module_name is not available up in epp()
It is actually that way by design. The epp()} function does not have access to the calling scope as it is evaluated in the top scope, and all variables must be given to it. In contrast {{inline_epp has access to the variables in the calling scope. The $modulename is a special variable that is not really a top scope var - it cannot be since it since it has a different value depending on scope.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371297.1599469893000.31405.1599506220043%40Atlassian.JIRA.
Jira (PUP-10659) Data Type casts cause Puppet Server to retain Compiler instances
Title: Message Title Henrik Lindberg commented on PUP-10659 Re: Data Type casts cause Puppet Server to retain Compiler instances Charlie SharpsteenI think you are right. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.371191.1599234718000.31240.1599323400037%40Atlassian.JIRA.
Jira (PUP-10654) Supplying data of mixed data types (Variant) via Hiera (YAML backend)
Title: Message Title Henrik Lindberg commented on PUP-10654 Re: Supplying data of mixed data types (Variant) via Hiera (YAML backend) Possibly hacky suggestion... The RichData datatype could be given a new function that takes two parameters, a value, and an extra argument "encode" or "decode" - then it would either "serialize" or "deserialize". Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370870.1598950851000.29900.1599129180207%40Atlassian.JIRA.
Jira (PUP-10654) Supplying data of mixed data types (Variant) via Hiera (YAML backend)
Title: Message Title Henrik Lindberg commented on PUP-10654 Re: Supplying data of mixed data types (Variant) via Hiera (YAML backend) I also think a RichData backend could be difficult for people to adopt especially since you may want this support for both yaml, json, and eyaml. This is why I suggested adding deserialization as an option to existing backends. RichData is really an encoding on top of an existing data format, so this is a natural fit. This could also be done at the lookup_option level similar to how convert_to works. Unfortunately it cannot be done with convert_to since IIRC there is no data type that accepts Pcore as input to its new() and that would return a deserialized value - one could be created though. A general lookup_option feature would be to add a convert_with which has the name of a function as its value. It would be called before a convert_to if both are used. The convert_with would take RichData as an argument and produce Any (although in hiera it would be restricted to returning RichData. Then you can plug in a function like this one: https://github.com/hlindberg/tahu/blob/master/lib/puppet/functions/tahu/convert_from_rich_data.rb to do the deserialization. Or users can do their own simple conversion per key. The same feature could be added as an option to backends. The hiera implementation would then call the given function for every value the backend returns. This way the backend implementations does not have to change. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe
Jira (PUP-10654) Supplying data of mixed data types (Variant) via Hiera (YAML backend)
Title: Message Title Henrik Lindberg commented on PUP-10654 Re: Supplying data of mixed data types (Variant) via Hiera (YAML backend) Josh Cooper IMHO it is a mistake to allow any non YAML/JSON supported data types into the data as that prohibits a standard reader from reading the data. So... no ruby specific extensions should be allowed. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370870.1598950851000.29439.1599071220025%40Atlassian.JIRA.
Jira (PUP-10642) Uppercase Default value in conditional documentation a typo?
Title: Message Title Henrik Lindberg commented on PUP-10642 Re: Uppercase Default value in conditional documentation a typo? The docs shows two examples; one with uppercase and one with lower case. Only the lower case is explained, and the other is quite advanced. Simply remove the example with the upper case Default to at least not make it confusing, but why the example outputs that it is using a "lowercase" default is a mystery. Would make sense if the first option was an os name in upper case, for example "Debian", with a notice "this is a debian", and the "default" says "this is not debian" - or something like that Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370111.159834180.29435.1599070980045%40Atlassian.JIRA.
Jira (PUP-10654) Supplying data of mixed data types (Variant) via Hiera (YAML backend)
Title: Message Title
Henrik Lindberg commented on PUP-10654
Re: Supplying data of mixed data types (Variant) via Hiera (YAML backend)
You can achieve the same by using a hiera lookup option to convert a string to a Regexp. Then you alias the typecasted key. For example for a parameter foo::bar, if value should be a string, just bind it to a string, if you wanted to be a regexp bind it to
"%{alias("foo::bar::regexp")}"
and bind the regexp string to that key and associate a lookup_option that converts it to a Regexp. You could also have your own backed function if you have lots of these. Josh Cooper A cool feature for hiera would be to support pcore serialization, could be an option to json/yaml backends or a separate backend - it would read json/yaml, and then run that through pcore deserialize before returning the data hash. That way it would be possible to safely produce and return any pcore compatible data type.
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google
Jira (PUP-9577) Large numbers of facts cause slow performance
Title: Message Title Henrik Lindberg commented on PUP-9577 Re: Large numbers of facts cause slow performance Justin Stoller you are right, there is no way to cut in on the @variable references unless going the route of transforming the ERB code - i.e. parse it and modify the parsed Ruby AST to get an ERB that uses a different mechanism to look up variables - which would then result in a new variant of Puppet/ERB mapping (that this would use), and in that case, users could just as well be told to switch to that alternative binding... In any case a lot of work. So, as you suggest the short term solution is really to point people to EPP. I was toying with the idea of replacing @varname access to be @var.varname and bind a value to @var with a missing_method implementation that would lookup the method name as the name of a variable. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.301092.1553181872000.25967.1598623500030%40Atlassian.JIRA.
Jira (PUP-10650) Remove TypeSetType from RichData
Title: Message Title Henrik Lindberg commented on PUP-10650 Re: Remove TypeSetType from RichData See comments on the PR. Basically the instance? method on TypeSet should only accept a typeset instance and not use the default instance? version (in super) that first infers the type and then compares that against that against a target type. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370572.1598569423000.25919.1598616240039%40Atlassian.JIRA.
Jira (PUP-8969) Sensitive parameters are not redacted from reports / agent output when used in templates
Title: Message Title Henrik Lindberg commented on PUP-8969 Re: Sensitive parameters are not redacted from reports / agent output when used in templates Josh Cooper EPP results in AST elements specific to EPP for rendering a value as a string. That evaluation could evaluate the _expression_, check if the result is a Sensitive, and then instead of getting a REDACTED result it would unwrap the sensitive value and turn that into a string. It would then need to communicate the the top level that the entire result should be wrapped in a Sensitive. The passing back of that value is the most difficult as it needs to handle nesting (one EPP could call another for example). Well - you managed to nerd snipe me The relevant parts is in the `evaluator_impl.rb` def eval_EppExpression(o, scope) scope["@epp"] = [] evaluate(o.body, scope) result = scope["@epp"].join result end def eval_RenderStringExpression(o, scope) scope["@epp"] << o.value.dup nil end
Jira (PUP-10642) Uppercase Default value in conditional documentation a typo?
Title: Message Title Henrik Lindberg commented on PUP-10642 Re: Uppercase Default value in conditional documentation a typo? An uppercase bare word like Default is a reference to a datatype. There happens to be a datatype named Default and it matches the value that results when you type default. So - the example will either match a literal default (with the Default entry), or a missing value (the default entry). While not wrong per se. if that is what the documentation is trying to show it should say so, otherwise it is just cryptic. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.370111.159834180.23067.1598354460036%40Atlassian.JIRA.
Jira (PUP-10628) Performance regression with large hashes using lookup
Title: Message Title Henrik Lindberg commented on PUP-10628 Re: Performance regression with large hashes using lookup Josh Cooper I think it is may be as easy as checking if it has the key "pcore_uri" - which should be present and signifies that "this is something that has to do with pcore" - but it could be that actual usage is too relaxed with the formalities of declaring this (or the pcore_version for that matter). Apart from Puppet core and possibly Bolt, I don't think there is any use of `TypeSet` in the wild - if so, the worst case would be that manually authored typeset files would need to be updated with the pcore_uri. Would need to ask Thomas Hallgren to get all the details. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369684.1597848926000.21909.1598120880088%40Atlassian.JIRA.
Jira (PUP-10628) Performance regression with large hashes using lookup
Title: Message Title Henrik Lindberg commented on PUP-10628 Re: Performance regression with large hashes using lookup An optimization that was done in other places were that instead of inferring the type of the value and then matching the inferred against the desired you ask if it is an instance of the desired type - not sure if there is something like that going on here, or if also asking if it is an instance requires a deep recursion. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.369684.1597848926000.20605.1597951620156%40Atlassian.JIRA.
Jira (PUP-10628) Performance regression with large hashes using lookup
Title: Message Title Henrik Lindberg commented on PUP-10628 Re: Performance regression with large hashes using lookup RichData as a format allows for types to be embedded in the serialization of data - that way, a serialization can be self describing. In serialization it is optional to use this, or to simply include types as reference via their name (i.e. "hoping" that the other side has the same definition of the type). Early on in the implementation of rich-data support in the catalog we did include the serialized types - but this proved to be too bulky. There is currently no other data type (alias) defined for RichData without the Type and Type set types, but one could be created. Don't see it is of much practical use to support Type/TypeSet in hiera data, you would get the same if types were returned as strings and then turned into types dynamically - rather than a hiera backend returning an instance of Type/TypeSet. Not sure if dropping them from RichData would cause problems - probably not that difficult to test. Speeding up the inference is still of value - there may be some obvious things that can be done to make it faster to discriminate if a hash could possibly represent a type or typeset. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PUP-10587) Add plan_hierarchy key to hiera config
Title: Message Title Henrik Lindberg commented on PUP-10587 Re: Add plan_hierarchy key to hiera config Did you consider a second instance of hiera/lookup with a separate hiera.yaml file for plans, and then just using one or the other depending on context when doing lookups? You would then get the global/env/module + default layers for free for the plan specific hiera instance. Either name the file plan_hiera.yaml or have something like a relative path ./plan/hiera.yaml to where the regular hiera.yaml is. I think that would reduce the complexities in implementing this. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.366423.1594943799000.110498.1594979820032%40Atlassian.JIRA.
Jira (PUP-9005) epp template fails to translate <%= ... %> when it is followed by a left parenthesis
Title: Message Title
Henrik Lindberg commented on PUP-9005
Re: epp template fails to translate <%= ... %> when it is followed by a left parenthesis
This bit:
<% if $opensshCfg { -%> ### <% (\{ 'a' => [ 'b', 'c' ]}).each |String $my_hash, $my_array| { -%> ### <%= $my_hash %> <%= $my_array %> ### <% }
When turned into puppet language is:
if $opensshCfg { emitString("###")({ 'a' => [ 'b', 'c' ]}).each |String $my_hash, $my_array| { emitString("###") emitExpr($my_hash) emitExpr($my_array) emitString("###"(}
The emitString, and emitExpr are internal instructions that are expressions that are specific to EPP. And I suspect that the problem is here:
emitString("###")({ 'a' => [ 'b', 'c' ]})
As that may be seen as an attempt of calling the result of emitString with the literal hash as an argument. This is why an intermediate assignment makes it work (since it cannot possibly be a continuation of what is to the left of it). You could probably use a semicolon "statement separator" there instead of the assignment to clearly state to the parser that "don't try to take the rest as part of the same _expression_".
Add Comment
Jira (FACT-2666) Puppet lookup CLI loads external Facts on the initiating node
Title: Message Title Henrik Lindberg commented on FACT-2666 Re: Puppet lookup CLI loads external Facts on the initiating node There is the masterless use case to consider as well - then there is no master to obtain facts from using --node and if not running facter to get the node's facts, then the user would have to produce them to a file and give that on the command line. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.363107.1592385941000.102612.159420330%40Atlassian.JIRA.
Jira (PUP-8088) add mechanism for cache eviction callback / finalizers
Title: Message Title Henrik Lindberg commented on PUP-8088 Re: add mechanism for cache eviction callback / finalizers Josh Cooper exactly that - it is typically for hiera backend function developers that use some 3rd party connection/service they have no control over; i.e. getting some kind of client handle back that they want to hold on to for subsequent operations, and then they need to do a close of that at some point. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.218549.150892772.91717.1592833140187%40Atlassian.JIRA.
Jira (PUP-6645) Remove the hiera_xxx functions
Title: Message Title Henrik Lindberg commented on PUP-6645 Re: Remove the hiera_xxx functions Lee Lowder You could probably write a backend function and stick it into the hierarchy. Give it a URI of your choice instead of a path, then use logic in your backend function similar to what you have in your manifest where you decide on which path to use as overlay in your call to hiera. (just an idea). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.148538.1471963467000.82550.1591727880083%40Atlassian.JIRA.
Jira (PUP-10513) Do not recursively type check collections when creating iterables in puppet functions
Title: Message Title
Henrik Lindberg commented on PUP-10513
Re: Do not recursively type check collections when creating iterables in puppet functions
Maybe it is possible to pass along any constraints to the iterator creator and then attempt to short circuit certain subsequent type matching; i.e. when someone writes:
$myhash.each |$k String, $v Hash| { something() }
It would probably be more lightweight to check if the produced iterator satisfies the constraints that the lambda imposes (must be something producing String/Hash) and then skip the checking on each invocation of the lambda. Likewise, if the lambda given to each imposes no constraints the inference can be skipped. For the remaining cases, it is perhaps possible to make the inference lazy, waiting until type information is actually needed. In some cases it will never be needed; for example:
$data.reverse_each.map |$x| { "$x" }
There are other opportunities to do type inference optimizations - consider this for example:
function foo($data Array[String]) >> Array[String] {
return *$data.reverse_each
}
In the function's body it is known that `$data` must be an Array of String. Thus the reverse_each could be made to know that is the case, and the type of the splat (since it is an Array (and not a Tuple with possible different type per slot)) will also produce Array[String], and then it is known that the return is Array[String]. Thus, it is possible to avoid 2 type inferences. The optimizations would take
Jira (PUP-10503) hiera glob files not included in order
Title: Message Title Henrik Lindberg commented on PUP-10503 Re: hiera glob files not included in order You are right, it does not sort. It should do that - it was a design criteria that went missing in the implementation (i.e. the documentation is "right"). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.358492.158931013.60681.1589321580028%40Atlassian.JIRA.
Jira (PUP-10478) Add getvar Hiera backend
Title: Message Title Henrik Lindberg commented on PUP-10478 Re: Add getvar Hiera backend Hiera eyaml is a module that is shipped with puppet agent - there is just a tiny bit of support for it in puppet's repo because puppet's hiera5 implementation needed to override the hiera3 version of it. I.e the actual eyaml logic is in a module. What is suggested here should be in a separate module as well. When hiera 3 is gone completely (in hiera eyaml module as well) then the puppet core specials for it can be cleaned up. We had to support getting variables in scope since hiera 5 needed to be backwards compatible in this respect. What the hiera 5 implementation does is that it monitors if any values that affect the context has changed in such a way that the hierarchy may be affected and if that is detected then the cache is evicted. This leads to worse performance. Thus - using variables in scope leads to worse performance. When using a solution like the proposed you also have to use the lookup cli with `compile` which makes it slower. Without `compile` it would not produce what is produced in real use. A far better solution would be to allow a hiera.yaml to specify a function that is called to produce variables that are derived from initial topscope variables. Those variables (produced by function returning a hash) would be available for interpolation in hiera yaml, and in hiera data, but not be available as variables in the puppet language. This way, there would be no dynamic changes to the context and no messy order of evaluation problems to confuse people. (This was one of the features I wanted to add to hiera 5). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Jira (PUP-10446) Remove application orchestration language features
Title: Message Title Henrik Lindberg commented on PUP-10446 Re: Remove application orchestration language features Keywords can be kept in the lexer in order for them to be reserved for the future. The grammar should be changed to remove the app orch stuff to allow future changes of the grammar without having to take app orchestration into concern. If just making the deprecations errors, that would work too if you are in a pinch for time - can then remove at will later although it will change how those errors surface as they will become syntax errors once removed from grammar. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.356722.1587765694000.53475.1588418040031%40Atlassian.JIRA.
Jira (PUP-9309) Remove unused AST class SublocatedExpression
Title: Message Title Henrik Lindberg commented on PUP-9309 Re: Remove unused AST class SublocatedExpression No need to deprecate other than in release notes IMO - only highly specialized logic that deals with parsing would be affected. For example nwops debugger, maybe puppet strings. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.284713.1542018073000.51945.1588267200106%40Atlassian.JIRA.
Jira (PUP-10478) Add getvar Hiera backend
Title: Message Title Henrik Lindberg commented on PUP-10478 Re: Add getvar Hiera backend This does not have to go into puppet, and is not a good idea in general as it makes the result of lookup depend on order of evaluation - it creates a hard to debug and reason about configuration. Features like this was deliberately removed from the hiera 5 implementation because of the mess they create. If you really want to do this, you can write your own backend function (in puppet language for example), it has access to puppet variables in scope. Don't however try to make `paths` be anything other than file paths - there are other options for passing other things to backends - such as "options", and "uri/uris". The file paths are automatically handled with change monitoring etc. If all you want to do is to produce a hash with values from facts, that is super simple to do in a custom backend function. Suggest closing this ticket with Won't Do. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.357322.1588196554000.51938.1588267020028%40Atlassian.JIRA.
Jira (PUP-10417) Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet
Title: Message Title Henrik Lindberg commented on PUP-10417 Re: Custom Ruby functions that define a JSON module can ambiguate its scope and break Puppet FWIW, and IIRC - the spec says that it is illegal to define new Ruby constants in a 4.x function. Irrespective of where they end up in the ruby runtime they will cause problems Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.354928.1586391583000.35615.1586501760074%40Atlassian.JIRA.
Jira (PUP-10413) Overriding a default argument with undef has no effect
Title: Message Title Henrik Lindberg commented on PUP-10413 Re: Overriding a default argument with undef has no effect You are right - this is by design; decisions made a long time ago in puppet. It is now expected behavior and changing it would break a lot of code. For the Puppet 4 version I wanted to change this by allowing an override (such that an undef value could actually be set), but there was zero support for that idea. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.354349.1586193307000.31464.1586206380191%40Atlassian.JIRA.
Jira (PUP-10399) Error: wrong number of arguments (given 2, expected 1) Deferred function doesn't return file / line number
Title: Message Title Henrik Lindberg commented on PUP-10399 Re: Error: wrong number of arguments (given 2, expected 1) Deferred function doesn't return file / line number Hm, that is bad and something I did not think about when implementing the support for Deferred. The problem here is that the file/line is not included in the serialization of the deferred value into the catalog. Thus when it is resolved (i.e. called) on the agent side it has lost all of the context in which it was created. To fix this, when an instance of Deferred is created it needs to look on the puppet stack to get the caller's location. These two values must then be encoded in the Deferred instance, and then serialized. Then the logic that performs the call must make use of the file/line information which probably involves catch and re-raise-or-wrap depending on type of error being raised. Since this affects the serialization a decision to include file/line must depend on what the agent accepts. A compromise could be to show file/line for the resource attribute for which the deferred is resolved (IIRC those are available in the catalog). This may not be correct if the deferred is nested in some other structure, but perhaps better than nothing. Doing that would not require messing with the serialization protocol. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PUP-10356) Empty YAML files cause warnings in yaml_data and eyaml_lookup_key functions
Title: Message Title Henrik Lindberg commented on PUP-10356 Re: Empty YAML files cause warnings in yaml_data and eyaml_lookup_key functions IIRC there was an earlier ticket about something like (or very similar), and also IIRC there were some (possibly historic) issues where you could get a nil back under some other conditions when parsing yaml - thus making it really hard to find if a returned nil was to be taken as an empty hash. Think you came to the right conclusion (fix it in PDK and leave the hiera impl as it is). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.348764.1583374648000.14033.1584396780956%40Atlassian.JIRA.
Jira (PUP-10350) Abort puppet run if empty values retrieved
Title: Message Title Henrik Lindberg commented on PUP-10350 Re: Abort puppet run if empty values retrieved The lookup_options allows you to use a pattern to match keys - the options then applies to all keys that match that pattern. It gets a bit difficult if you also want to set other options but not the same way for all matched keys - for example options for deep merging. Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.348512.1583314551000.6269.1583488740024%40Atlassian.JIRA.
Jira (PUP-10350) Abort puppet run if empty values retrieved
Title: Message Title Henrik Lindberg commented on PUP-10350 Re: Abort puppet run if empty values retrieved In hiera 5 there is a difference between nil and empty string - both are valid as values in yaml - if that is what you are asking. As long as the backend signals "not found" as it should I think it should be possible to return both "undef" and empty string. This because you may want to be able to override some other bound value with "nothing". A user can do a type cast to String[1] to ensure they do not get undef or empty string. (but may be difficult in practice - not sure if it returns Sensitive or not). Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.348512.1583314551000.4220.1583347560168%40Atlassian.JIRA.
Jira (PUP-10321) Resource 'notify': Attribute 'message' accepts Array but only use the first element
Title: Message Title
Henrik Lindberg commented on PUP-10321
Re: Resource 'notify': Attribute 'message' accepts Array but only use the first element
That indeed looks like a bug. OTOH - allowing notify to do the string conversion means you have no control over how the resulting string is formatted. It is recommended to turn values into a string before assigning it to the message attribute. Depending on how much control you want - use one of:
"${theArray}"
$theArray.join(" ,")
String($theArray) - with lots of options
Add Comment
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.348009.1582967531000.797.1582977240036%40Atlassian.JIRA.
Jira (PUP-10317) hiera-eyaml should print helpful error message when decryption fails
Title: Message Title Henrik Lindberg commented on PUP-10317 Re: hiera-eyaml should print helpful error message when decryption fails Note that the function in question is in puppet because of backwards compatibility support for hiera 3 where hiera 5 hijacks and improves on the hiera 3 backends for yaml, json, and eyaml. Once hiera 3 is no longer supported and the hiera 3 to hiera 5 "lifting features" are removed from puppet, then the function can (and probably should) move to the eyaml gem. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.347764.1582794561000.1627.1582795800090%40Atlassian.JIRA.
Jira (PUP-10300) find_file function returns path even if absolute path does not exit
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-10300 find_file function returns path even if absolute path does not exit Change By: Henrik Lindberg Labels: beginner Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.346683.1582114324000.31184.1582119301819%40Atlassian.JIRA.
Jira (PUP-10300) find_file function returns path even if absolute path does not exit
Title: Message Title Henrik Lindberg assigned an issue to Unassigned Puppet / PUP-10300 find_file function returns path even if absolute path does not exit Change By: Henrik Lindberg Assignee: Henrik Lindberg Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.346683.1582114324000.31186.1582119301952%40Atlassian.JIRA.
Jira (PUP-7197) make type aliases from modules available on the agent
Title: Message Title Henrik Lindberg commented on PUP-7197 Re: make type aliases from modules available on the agent I looked into syncing more things - pluginsync builds a Puppet catalog that gets applied on the agent so it is a matter of adding more resources to that catalog that plugin sync builds. It would be doable to create type metadata for a module and sync that, but you would still need to plugin sync that information and would then need to add a loader on the agent side to make use of that information. One possibility would be to let `puppet generate types` generate this information. Since PCore can serialize types and type aliases it could possibly also include them in the catalog - but then the question is which types to include. Best is to do it with pluginsync, and even better would be to redesign puppet sync. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.174775.1486632721000.31123.1582112881709%40Atlassian.JIRA.
Jira (PUP-7197) make type aliases from modules available on the agent
Title: Message Title Henrik Lindberg commented on PUP-7197 Re: make type aliases from modules available on the agent In case you wonder why that happens Alexander Fisher (or anyone else for that matter) is that by definition in the specification that any mentioned data type is a Resource (type) reference unless there is a specific data type available for that name. It would have been reasonable for the type reference to simply not resolve and an error to be raised for the `Stdlib::HTTPUrl` data type. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.174775.1486632721000.29222.1582057920703%40Atlassian.JIRA.
Jira (PUP-10270) Allow testing for data types with defined()
Title: Message Title Henrik Lindberg commented on PUP-10270 Re: Allow testing for data types with defined() For anyone implementing this: it is important to know that when asking for a data type, all types that are not explicitly defined are by design a Resource datatype (yes, for historical reasons it needs to do this). Since the ask for a data type must use a string the logic ends up doing this: # Find a resource type, definition or class definition Puppet::Pops::Evaluator::Runtime3ResourceSupport.find_resource_type_or_class(scope, val) I think it may need to do that first, and if not found, then try the 4.x loaders to load the data type - i.e. something like this: loader = Puppet.lookup(:loaders).private_environment_loader() type = loader.load(:type, type_name) But, in Puppet 6 it may work to only use the 4.x loaders. Add Comment
Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title Henrik Lindberg commented on PUP-9602 Re: puppet 6 apply fails if puppet types have been generated I looked at Trevor's patch and while it "may work", it is really a band aid on the actual problem, so I don't think it should be fixed that way. I think the correct thing to do is what I commented with earlier - i.e. do not include the loader that loads resource types from metadata (i.e. the "generated types" loader) in the configuration of the loaders on the agent side. I think it was Tony Vu who worked on this logic last. With the support for Deferred (and improved handling of Sensitive) values in the catalog there is one walk over the entire catalog at the beginning of the apply. This needs to take place even if there are no Deferred or Sensitive values since the walk is required to find them. I can imagine that a huge catalog would take time to walk over. The other piece of logic that was added is the setting up of a PAL context for the resolution of deferred values. The setting up of PAL will configure loaders for all modules on the modulepath, but won't do any loading until something is asked for. The invocation of PAL itself would be more or less constant and what it does per module is not much. Next, when resolving deferred values, it would load functions and evaluate puppet logic. The loading of a function would search for it using the loaders config. Given that the agent has pretty much all squashed everything together the search should be faster than the corresponding on the master side (fewer paths to look at) - unless of course there is something wrong with the loaders config on the agent side. To get to grip with the performance issue I think it would be easiest to instrument the deferred loading with profiling around what it is doing, and around setting up PAL. Hopefully it is something other than the catalog walk that is the cause since that is much harder to tackle. A very simple test if it is the deferred resolution at all would be to simply patch it out and compare - that would only work naturally if the catalog in question does not contain any Deferred or nested Sensitive values. I mean, it could be something else completely. Add Comment
Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title Henrik Lindberg commented on PUP-9602 Re: puppet 6 apply fails if puppet types have been generated Pinging type loading domain expert: Thomas Hallgren - see comment above. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.302978.1554294806000.9486.1580552700487%40Atlassian.JIRA.
Jira (PUP-10225) Puppetserver 6 performance regression
Title: Message Title Henrik Lindberg commented on PUP-10225 Re: Puppetserver 6 performance regression There are other reports about performance issues - I just added a link to one such issue that has just been fixed. Others are in the pipeline. There has been some extensive firefighting on performance issues lately and what you report are hopefully caused by what has been found and fixed. Checkout release notes as new releases are rolled out... Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.341411.1578473781000.4896.1580319420223%40Atlassian.JIRA.
Jira (PUP-10259) Hiera cannot interpolate non-string values
Title: Message Title
Henrik Lindberg commented on PUP-10259
Re: Hiera cannot interpolate non-string values
I was thinking that you bind the value facts.selinux.enabled to docker::selinux_enabled key. Then, you make that value special using lookup_options - in a way defining the syntax & semantics of what is there. One way (as I suggested) is to simply take the value and give it to a function (that defines the meaning of the value). Then, you could (if you wanted to) put a string of Puppet code as the value of the lookup, and say the function is puppet_eval if you wanted to - i.e. completely open ended extendable by functions. So, specifically for aliases I imagine the function would be something like `strict_alias` and it would be called with the looked up value, and the function would then use the context it gets to perform a lookup using the value it got as the key. You can do really powerful things with a general purpose "delegate". Another option here (not using lookup_options) would be to add the delegate support as an interpolation function (even though (as stated earlier) have a dislike for "non interpolation features expressed as an interpolation"). This would require some more expressiveness in how you can invoke interpolation functions, for example giving multiple arguments to it, support for different kinds of literal data, etc. etc. - and that starts to snowball... It could be something like:
some::key: "%{`puppet: ...puppetcode here `}"
some::key: "%{`myfunc: ...whatever myfunc understands`}"
But I have not thought much about that idea as opposed to having the `puppet` or `myfunc` part be in lookup_options and then just putting whatever the argument should be into the value. One thing is that you could probably combine so that the key looks up a hash (maybe even with merge) and then get that as input to your function. ... Maybe it is not so much a `delegate` as a `post_process` since it would be acting on the looked up result... Anyhow, there are probably dragons to watch out for, and meanwhile, I have to objection against adding a strict_ailas interpolation function. (I am just brainstorming about what we could possibly do for the future to allow anyone to innovate in this area without requiring further additions to puppet/hiera itself and without completely changing the hiera data syntax. One more thought... the lookup_option could be a kind of delegation, that if turned on it expects the lookup result to be a hash, and it expects a key in this hash to be the function to call with that hash as argument - then you would see something like this in data (using a puppet_eval as an example):
Jira (PUP-10259) Hiera cannot interpolate non-string values
Title: Message Title Henrik Lindberg commented on PUP-10259 Re: Hiera cannot interpolate non-string values I don't mind adding strict_alias being added as an interpolation function. Just saying that I would like to have a solution at some point that is more general. Small comment on your comment: What I intended was that the looked up value to be given to a function, not that the value would be given as `arguments` in the lookup_options (while that would naturally be a way to add additional arguments). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.244421.1522942982000.4254.1580294640236%40Atlassian.JIRA.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title Henrik Lindberg commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Something I have wanted for a long time is to have the concept of "query" as a separate thing; like a lambda if you like, a value that could be given to different functions, or be used in resource like in Ben's Manifold. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.191187.1494891335000.4172.1580291161496%40Atlassian.JIRA.
Jira (PUP-10259) Hiera cannot interpolate non-string values
Title: Message Title
Henrik Lindberg commented on PUP-10259
Re: Hiera cannot interpolate non-string values
To be honest I am so sick and tired of the horrible hiera interpolation syntax - here with interpolation functions that makes the result not be an interpolation - I think it is just bizarre ... I never liked this because playing tricks with interpolation functions is pretty much the only thing that can be done and retaining backwards data compatibility. Using lookup_options is however different in that there we decide the meaning/encoding of whatever is described there. So, we could "type" the meaning of a key - for example "get the value using getvar()" (which the example above from thomas means). Now, if we instead generalize that to state that the looked up value is given to a mentioned function before being returned - the lookup would first produce 'facts.selinux.enabled', and the lookup_option would say that it should be passed through getvar(), and thus yielding the result of getvar('facts.selinux.enabled'). This mechanism can then be used such that if the called function accepts a LookupContext then it would be given it when function is called - the called function can then also perform a "not-found" as an outcome, and it would be able to (somehow) also keep track of that context for recursion. (This is something I did in a Puppet language hiera 5 backend function - where you would simply write "getvar('facts.selinux.enabled') as the value for the key. The code for that ppyaml backend function is here: https://github.com/hlindberg/tahu/blob/master/lib/puppet/functions/tahu/ppyaml_key.rb in case someone is interested.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-10251) Feature request: Add a way to turn looked up undef values in Hiera into "not found"
Title: Message Title Henrik Lindberg commented on PUP-10251 Re: Feature request: Add a way to turn looked up undef values in Hiera into "not found" Thomas Hallgren I thought strict_alias would result in a "not-found" and that was the entire idea why having it in the first place. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343178.1579803772000.3243.1580238540248%40Atlassian.JIRA.
Jira (PUP-8593) Add alias to lookup_options and make it redirect to lookup of the alias
Title: Message Title Henrik Lindberg commented on PUP-8593 Re: Add alias to lookup_options and make it redirect to lookup of the alias Thomas Hallgren That is solving PUP-8341, a completely different problem than this ticket (what is described above would also benefit from having some kind of "strict" option). I think PUP-8341 should be reopened for the purpose of adding strict_alias interpolation function. This ticket is about having a more powerful mechanism for aliasing than what is currently possible with the hiera interpolation functions. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.242722.1521802594000.3237.1580238240107%40Atlassian.JIRA.
Jira (PUP-10257) Write timestamp to file in environment when beginning compilation
Title: Message Title Henrik Lindberg commented on PUP-10257 Re: Write timestamp to file in environment when beginning compilation Nick Walker, I think that makes more sense as well - then there is just an entry barrier that is checked before compiling - I suppose that means "go over there instead" - or is that switch over to another version done based on something else? To me it seems that a compiling server would be able to keep track of the number of compiles per version that it has ongoing (there are all active in memory, so if it dies they cannot be ongoing). If there are multiple servers acting on the same information it gets more complicated. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343770.1580166495000.3193.1580237640323%40Atlassian.JIRA.
Jira (PUP-10257) Write timestamp to file in environment when beginning compilation
Title: Message Title Henrik Lindberg commented on PUP-10257 Re: Write timestamp to file in environment when beginning compilation Would this not then create a problem with not knowing if that compile has finished, and would this not also create a race condition (just after checking a compilation starts). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343770.1580166495000.2739.1580227560103%40Atlassian.JIRA.
Jira (PUP-10210) puppet fails with JSON error when a fact value equals Infinity
Title: Message Title Henrik Lindberg commented on PUP-10210 Re: puppet fails with JSON error when a fact value equals Infinity Justin Stoller I think that is a sensible and pragmatic solution as it makes the value symmetric (i.e. it roundtrips). Any other special value would have to be compared against anyway - only small benefit of using a numeric value (a supported Infinity or a defined MAX_INT) would be that it is directly comparable. The cost for proper Infinity support is however quite high. So... what you suggest makes a lot of sense. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.340709.1577387077000.1946.1580160240267%40Atlassian.JIRA.
Jira (PUP-7541) Explore removing export / collect / virtual / realize syntax
Title: Message Title Henrik Lindberg commented on PUP-7541 Re: Explore removing export / collect / virtual / realize syntax Since this thread has woken up again I like to point out some of the difficulties with the current collectors and what a replacement needs to consider. First, the collectors run after the normal compilation has finished - in this sense it is a kind of post processing of the catalog. Each collector is triggered once (and thus the outcome depends on the order they are executed in). This is done because of possible conflicts and endless loops (for example rule A sets x to 2 if it is < 2, and rule B sets x to 1 if it is >= 2). Earlier there was an issue with defaults values - if they were applied "at end of regular compilation" or "after collectors/overrides". This was changed so defaults are set before collectors kick in. If a new design simply allows lambdas to be called (on some kind of set of resources produced by some query function) in some kind of deferred way while compiling then the logic in the lambdas would need to be allowed to do overrides, they would need to run in some order, and would need to be protected from infinite loops etc. This is very difficult with general purpose puppet logic because it could do anything (override what is in catalog, and add to it). The deferred/lazy mode of collectors is why they cannot really return anything to the language, and it has some hoops to jump through because of the relationships that can be established between collector results (those are also done in a lazy way, and thus depend on the order of evaluation of the lazily evaluated collectors/overrides/relationships). The exported resources and collection use cases seems to be all solved by PQL and regular logic - do you agree? For virtual resources and overrides use cases the replacement is less obvious. I think it may require logic programming in the vein of Datalog / OPA. Which could be applied in a catalog post processing step. A difficulty is how to express those in the Puppet Language in a natural way. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-10251) Feature request: Add a way to turn looked up undef values in Hiera into "not found"
Title: Message Title
Henrik Lindberg commented on PUP-10251
Re: Feature request: Add a way to turn looked up undef values in Hiera into "not found"
I wonder if it would be possible to solve this with the existing version by instead of binding the key to null in json you would bind it to an alias lookup of a key that does not exists. I have not tested, but that may result in the desired "not found". For example {{key: "% {alias(non_existing_key)} "}. It may be that results in an undef, but if it doesn't then that is a possible workaround and there would be no need to add anything to the hiera implementation. Would be great if someone has the time to test this.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343178.1579803772000.36093.1579860480628%40Atlassian.JIRA.
Jira (PUP-10251) Feature request: Add a way to turn looked up undef values in Hiera into "not found"
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-10251 Feature request: Add a way to turn looked up undef values in Hiera into "not found" Change By: Henrik Lindberg Component/s: Hiera & Lookup Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343178.1579803772000.36083.1579856040286%40Atlassian.JIRA.
Jira (PUP-10251) Feature request: Add a way to turn looked up undef values in Hiera into "not found"
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-10251 Feature request: Add a way to turn looked up undef values in Hiera into "not found" Change By: Henrik Lindberg Summary: Feature request: Add a way to look turn looked up undef values in Hiera into "not found" Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.343178.1579803772000.36079.1579855980199%40Atlassian.JIRA.
Jira (PUP-521) Allow modules to specify what they provide in terms of API; classes, defines, functions, etc.
Title: Message Title Henrik Lindberg commented on PUP-521 Re: Allow modules to specify what they provide in terms of API; classes, defines, functions, etc. Josh, yes, that is a description. And what is suggested there (using the go parser) is perhaps a better choice. I don't really want to reopen the ticket just making a note for posterity if someone digs it out again or likes the idea for other reasons. The con of the idea is that you would need some kind of build step and ideas requiring that has not been received positively in the past - so I don't think people really want to go down that path - and hence why the idea of using the go parser in PUP-10233 is the better idea IMO). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.16244.1380842804000.35974.1579824840525%40Atlassian.JIRA.
