Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title
Reinhard Vicinus created an issue
Puppet / PUP-5898
Data types seems to be messed up on hash parameters
Issue Type:
Bug
Affects Versions:
PUP 4.3.2
Assignee:
Unassigned
Components:
Language
Created:
2016/02/13 3:48 AM
Priority:
Normal
Reporter:
Reinhard Vicinus
The following code:
define test ($b) {
$a = { key => undef }
notice("a: $a")
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title
Reinhard Vicinus updated an issue
Puppet / PUP-5898
Data types seems to be messed up on hash parameters
Change By:
Reinhard Vicinus
The following code:{code :java }define test ($b) { $a = { key => undef } notice("a: $a") notice("b: $b") $a.each |Array $values| {notice("a values: $values") } $b.each |Array $values| {notice("b values: $values") }}$a = { key => undef }test { "test": b => $a,}{code}generates the following output if run with puppet apply:{code :java }puppet apply test.ppNotice: Scope(Test[test]): a: {key => }Notice: Scope(Test[test]): b: {key => }Notice: Scope(Test[test]): a values: [key, ]Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Method call, block parameter 'values' expects an Array value, got Tuple at /home/rvicinus/test.pp:8:5 at /home/rvicinus/test.pp:14 on node puppetmaster{code}I would expect that the second each statement would run like the first, because the supplied hash is absolutely equally created like the one provided to the first each statement. I think somehow assigning the hash to a parameter messes up the data types, because the code works as expected if the Array keyword in the second each statement is removed. This is also the workaround that I use.
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title
Reinhard Vicinus updated an issue
Puppet / PUP-5898
Data types seems to be messed up on hash parameters
Change By:
Reinhard Vicinus
The following code:{code :java }define test ($b) { $a = { key => undef } notice("a: $a") notice("b: $b") $a.each |Array $values| {notice("a values: $values") } $b.each |Array $values| {notice("b values: $values") }}$a = { key => undef }test { "test": b => $a,}{code}generates the following output if run with puppet apply:{code}puppet apply test.ppNotice: Scope(Test[test]): a: {key => }Notice: Scope(Test[test]): b: {key => }Notice: Scope(Test[test]): a values: [key, ]Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Method call, block parameter 'values' expects an Array value, got Tuple at /home/rvicinus/test.pp:8:5 at /home/rvicinus/test.pp:14 on node puppetmaster{code}I would expect that the second each statement would run like the first, because the supplied hash is absolutely equally created like the one provided to the first each statement. I think somehow assigning the hash to a parameter messes up the data types, because the code works as expected if the Array keyword in the second each statement is removed. This is also the workaround that I use.
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
Jira (PUP-5895) puppet parser validate fails for functions
Title: Message Title Thomas Hallgren commented on PUP-5895 Re: puppet parser validate fails for functions A loader is required when using type aliases even if it's just validating. There are two reasons for this: The TypeParser must be able to distinguish between a type alias and a resource type. The alias is resolved by the TypeParser when the parser interprets the _expression_. In order to resolve, the alias must exist in the loader (or self references will fail). That said, I'm not sure if is necessary to be able to distinguish between a type alias and a resource type. Perhaps it's enough to just treat everything as type references? That's what the TypeParser currently does when no loader is available. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5897) Support Ubuntu 16.04 in systemd provider
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-5897 Support Ubuntu 16.04 in systemd provider Change By: Kylo Ginsberg Story Points: 0 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5897) Support Ubuntu 16.04 in systemd provider
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-5897 Support Ubuntu 16.04 in systemd provider Change By: Kylo Ginsberg Scrum Team: Client Platform Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5897) Support Ubuntu 16.04 in systemd provider
Title: Message Title Kylo Ginsberg updated an issue Puppet / PUP-5897 Support Ubuntu 16.04 in systemd provider Change By: Kylo Ginsberg Sprint: Client 2016-02-24 (Burn FF) Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title
Thomas Hallgren commented on PUP-5898
Re: Data types seems to be messed up on hash parameters
This is very odd. I tested the above code back and forth. The type inference of the $values when iterating $b is, for some reason, completely wrong.
This works and reaches the notice statement (it really should not):
$b.each |Tuple[String,Runtime['ruby','Symbol']] $values| {
assert_type(String, $values[0])
assert_type(Undef, $values[1])
notice("b values: $values")
}
which raises several questions:
Why was the key => value tuple inferred to have a ruby Symbol as its value?
How can the type assertion work for the block parameter and then also work when asserting that $values[1] is an Undef?
Why does this happen with the $b hash but not with the $a hash?
I suspect that this might have something to do with the internal interpretation of :default. Will investigate further.
Jira (PUP-5897) Support Ubuntu 16.04 in systemd provider
Title: Message Title Kylo Ginsberg assigned an issue to Kylo Ginsberg Puppet / PUP-5897 Support Ubuntu 16.04 in systemd provider Change By: Kylo Ginsberg Assignee: Kylo Ginsberg Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5891) Impossible to see the difference in the logs between a refreshed exec that has run and one that has not run
Title: Message Title Kylo Ginsberg commented on PUP-5891 Re: Impossible to see the difference in the logs between a refreshed exec that has run and one that has not run It seems like we could drop an additional Notice in https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/exec.rb#L107-L118. It would also be nice if one could distinguish the two cases in the report, but if that gets sticky, we could do so under a separate ticket. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title
Thomas Hallgren commented on PUP-5898
Re: Data types seems to be messed up on hash parameters
Internally $a is
{'key' => nil}
whereas $b is
{'key' => :undef}
This, in combination with that the TypeCalculator doesn't recognize the :undef symbol during type inference (it only recognizes :default) but does recognize it when testing instance? results in the described problem. Henrik Lindberg, what is you opinion on this? Should :undef be recognized when doing type inference or should we track down all places where an :undef might be assigned?
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title Henrik Lindberg commented on PUP-5898 Re: Data types seems to be messed up on hash parameters This is caused by the need to transform to 3.x value convention when using resource types and functions. We do the transformation when the evaluator evaluates a resource _expression_, or when calling a 3.x function. The best solution here would be to not use 3.x value convention when the resource is of user defined type (since that is puppet logic). The problem is that the check cannot be done when the evaluator creates the resource as it is queued and values are bound to parameters later. If we were to enforce that the type must exist at creation time we will break peoples code, as it changes the order of evaluation. So, we need to delay the transformation to 3.x, and always give 4.x values to PopsBridge, and that it converts the 4.x values when needed (i.e. when target is something other than a user defined resource. This in turn may cause some follow on problems, as the Resource logic is not designed to handle the 4.x values - most likely having issues with nil vs. :undef (where :undef is a known undefined, and nil is unknown if undefined so to say), ad logic may need to be updated to use explicit .nil? checks. We should also handle :undef in the TypeCalculator. The reason for this is that 3.x functions, hiera backends etc. may return :undef, or structures containing :undef. The TypeCalculator should equate :undef with nil. It is too soon to remove support for 3.x functions and types in Puppet 5.0.0, but it may be possible to change the value convention. There is a ticket for --strict mode, maybe that could also mean that the 4.x value convention is followed - a guess is that >90% of all functions and types have no problem with this. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop
Jira (PUP-5898) Data types seems to be messed up on hash parameters
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5898 Data types seems to be messed up on hash parameters Change By: Henrik Lindberg Priority: Normal Major Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5645) Can't install gems on Arch Linux
Title: Message Title Victor Engmark updated an issue Puppet / PUP-5645 Can't install gems on Arch Linux Change By: Victor Engmark Affects Version/s: PUP 4.3.2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5895) puppet parser validate fails for functions
Title: Message Title Henrik Lindberg commented on PUP-5895 Re: puppet parser validate fails for functions Thanks Thomas Hallgren I think that the function should be handled the same way. A parse validate does not need to actually define the function. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5875) Iterators are presenting themselves as Ruby type names
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5875 Iterators are presenting themselves as Ruby type names Change By: Henrik Lindberg Release Notes Summary: Bug fixed before feature is released. Release Notes: Not Needed Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5895) puppet parser validate fails for functions
Title: Message Title Henrik Lindberg commented on PUP-5895 Re: puppet parser validate fails for functions I am on the fence here. People do use puppet parser validate as a quality check, but it does not do any referential checks or data type checks at all. It would be a much more valuable tool if it did. When doing so it needs access to the loaders. May just as well add the instantiation of the loaders even if functions are not added to a loader during parsing. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5697) Inline file permissions
Title: Message Title Michael Smith assigned an issue to Michael Smith Puppet / PUP-5697 Inline file permissions Change By: Michael Smith Assignee: Michael Smith Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5754) Update lang specification with parameter scope information
Title: Message Title Henrik Lindberg commented on PUP-5754 Re: Update lang specification with parameter scope information Specification merged to specifications repo at: 26abc6e9a55b514eac9e27b6e0331872647c63e7 This was merged directly. as this was already reviewed, and the work consisted of a reformatting and cleanup. A correction was also made as github did not render the tables as intended. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5754) Update lang specification with parameter scope information
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5754 Update lang specification with parameter scope information Change By: Henrik Lindberg We have specified (https://docs.google.com/document/d/1BAkV6rIhW-EWqUKXrqhlh7FmmUUK8wlfS5Xiw1e6ync/edit#heading=h.6sclasyj9mhb) and implemented parameter scope to enable variables to the left of a default parameter value _expression_ to be used in default expressions. The link is a google doc containing a description and testcases. The task is to modify that into the specification format and add it to the language specification. The specification was traslated from the google doc and is not available here: https://github.com/puppetlabs/puppet-specifications/blob/master/language/parameter_scope.md Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-5754) Update lang specification with parameter scope information
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-5754 Update lang specification with parameter scope information Change By: Henrik Lindberg Sprint: Language Triage 2016-02-24 (Burn FF) Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4911) Parameters on exported resources consiting of an array with a single element are "de-arrayified"
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-4911
Parameters on exported resources consiting of an array with a single element are "de-arrayified"
Change By:
Henrik Lindberg
If a exported resource with a parameter consisting of an array with a single value is defined on one puppet node and then collected on another puppet node the array with the single value is "de-arrayified". Example: {code:puppet} define profiles::vres ( $dummy,) { if is_array($dummy) {notify { "array_$title": message => join($dummy, '_'),} } else {notify { "nonarray_$title": message => "NOT AN ARRAY: $dummy",} }} {code} on one server: {code:puppet} @@profiles::vres { "arraywithonevalue":dummy => [ "a", ],} {code} on another server: {code:puppt} Profiles::Vres <<| |>> {code} result of collecting the resource: {code} Notice: NOT AN ARRAY: aNotice: /Stage[main]/Roles::Collectvres/Profiles::Vres[arraywithonevalue]/Notify[nonarray_arraywithonevalue]/message: defined 'message' as 'NOT AN ARRAY: a' {code} This is probably related to PUP-1299
Add Comment
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4911) Parameters on exported resources consiting of an array with a single element are "de-arrayified"
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-4911 Parameters on exported resources consiting of an array with a single element are "de-arrayified" Change By: Henrik Lindberg Sprint: Language Triage Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4911) Parameters on exported resources consiting of an array with a single element are "de-arrayified"
Title: Message Title Henrik Lindberg commented on PUP-4911 Re: Parameters on exported resources consiting of an array with a single element are "de-arrayified" Are you running with parser=future ? The issue PUP-1299 was fixed for future parser only in 3.x and is the default in Puppet 4.x. The work around for earlier versions was to include the same value twice in the array (although this may not always work). Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4911) Parameters on exported resources consiting of an array with a single element are "de-arrayified"
Title: Message Title Henrik Lindberg assigned an issue to Reinhard Vicinus Puppet / PUP-4911 Parameters on exported resources consiting of an array with a single element are "de-arrayified" Change By: Henrik Lindberg Assignee: Reinhard Vicinus Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4669) Varargs support for (defined) types (and possibly classes)
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-4669 Varargs support for (defined) types (and possibly classes) Change By: Henrik Lindberg Story Points: 2 Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1341) Facter Throws Unhandled Exception when Run Under Unicode User
Title: Message Title Michael Smith commented on FACT-1341 Re: Facter Throws Unhandled Exception when Run Under Unicode User The Facter errors are because the Facter APIs are not correctly handling encoded text. With that code-page, they receive text encoded as Windows-1252; if I force the encoding to UTF-8 most of the errors go away. Add Comment This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
