Jira (PUP-6692) Improve access to "master" settings
Title: Message Title John Duarte updated an issue Puppet / PUP-6692 Improve access to "master" settings Change By: John Duarte QA Risk Assessment: No Action Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Thomas Hallgren assigned an issue to Unassigned Puppet / PUP-6692 Improve access to "master" settings Change By: Thomas Hallgren Assignee: Thomas Hallgren Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Thomas Hallgren commented on PUP-6692 Re: Improve access to "master" settings Merged to master at 1d0607e. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg assigned an issue to Thomas Hallgren Puppet / PUP-6692 Improve access to "master" settings Change By: Henrik Lindberg Assignee: Henrik Lindberg Thomas Hallgren Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-6692
Improve access to "master" settings
Change By:
Henrik Lindberg
Release Notes Summary:
All individual variables in the {{$settings}} namespace are now available as a Hash of => in the variable {{$settings::all_local}}. This makes it easy to lookup a setting that may be missing when {{\--strict_variables}} is in effect.
Release Notes:
New Feature
Fix Version/s:
PUP 5.0.0
Component/s:
Language
Component/s:
DOCS
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg assigned an issue to Henrik Lindberg Puppet / PUP-6692 Improve access to "master" settings Change By: Henrik Lindberg Assignee: Henrik Lindberg Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-6692 Improve access to "master" settings Change By: Henrik Lindberg Sprint: PDE Triage 2017-05-31 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg commented on PUP-6692 Re: Improve access to "master" settings In PUP-5635 the handling of qualified variables was changed, it is now very easy to add additional values in the $settings namespace without having to also create scopes in that/those namespaces. The solution to use $settings::all_local as a hash of all settings is thus possible with minimal effort. It would also be easy to later (when available from a node) also set those. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg commented on PUP-6692 Re: Improve access to "master" settings Kind of agree. Not sure how we will end up with this since the solution preferred by users is a global $settings variable. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Thomas Hallgren commented on PUP-6692 Re: Improve access to "master" settings I think that implementing a function that returns different types based on its parameters is bad practice. How about using two separate functions? One named settings which (as the name suggests) returns all settings, and one named setting that requires an argument? Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg commented on PUP-6692 Re: Improve access to "master" settings To summarize options: use of $settings would be most idiomatic - this will however break quite a few modules as $settings is often used as a variable. Thus $settings cannot be (easily and without performance implications) be reserved (which means someone can assign to the variable, shadow it, etc.) use of $settings::all_local would be backwards compatible and not requiring a flag. It would however cement the use of a named scope that requires special handling. This also leaves it open for PUP-1581, to add $settings:all_node. implement a function setting() that when called with a key returns that setting, and when called without a key returns all settings as a hash. This has the benefit of not requiring construction of the entire hash, it is backwards compatible, allows retiring the old settings:: scope, and is not based on the anitpattern of using global variables. It is however the least (current) puppet idiomatic solution. This solution makes it possible for those that want $setting as a global hash to stick $settings = setting() in their site.pp}} (leaving it up the user to decide if that is clashing or not). Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg commented on PUP-6692 Re: Improve access to "master" settings One idea that was floated is that $server_facts should be used, and that settings would be a key in that hash. That is unfortunately not possible (or will create a mess) as the server facts are merged into the node facts - thus creating a confusion over where values comes from (agent/server) - this is already confusing as it is. So, that idea is scrapped. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-6692
Improve access to "master" settings
Change By:
Henrik Lindberg
Currently, there is a namespace {{settings}} in which all settings are set as individual variables. This makes them harder to use as the available settings change between versions, and using strict variables can cause errors, and the available settings cannot be enumerated. Having a {{$settings}} as a hash of all settings is also desirable, and is analog to how {{$facts}} work.Note that PUP-1581 is about making possible to also access the settings from a node. That complicates this ticket with having to take future agent settings into account when designing how the improved access should be done. The settings for the compiling runtime (in master mode, or when doing a puppet apply) is what is currently reflected in {{settings}}. When designing the support for {{$settings}}, is that a good name for the variable? What should the variable for the "node settings" be? Should we use "local" and "node" as subkeys - that is {{$settings\[local]}} is what we have now, and {{$settings\[node]}} what will be added in PUP-1581, or should we have two global variables? We could also keep the existing namespace, so that {{$settings::local}} and {{$settings::node}} (or the asymmetrical {{$settings}} and {{$settings::node}}).If we use the existing namespace, support for this can be added in 4.x. If we go for that option, the two sections "local" and "node" will need to coexist with all the existing settings, and thus those names cannot be used as new settings (they are not used now).Another alternative is to add a function {{settings(name)}} which would return a setting or an Iterable over all settings if not given a name. This would reduce the amount of data kept in memory (there are many settings, and only a few of them, if any) are ever used in manifests. The return of an iterable means that the settings can be efficiently iterated (without first having to create a hash copy).We could also bind the Iterable to $settings, as that would be the most efficient, as the result is almost indistinguishable from a Hash.
Add Comment
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-6692
Improve access to "master" settings
Change By:
Henrik Lindberg
Currently, there is a namespace {{settings}} in which all settings are set as individual variables. This makes them harder to use as the available settings change between versions, and using strict variables can cause errors, and the available settings cannot be enumerated. Having a {{$settings}} as a hash of all settings is also analog to how {{$facts}} work.Note that PUP-1581 is about making possible to also access the settings from a node. That complicates this ticket with having to take future agent settings into account when designing how the issue improved access should be done . The settings for the compiling runtime (in master mode, or when doing a puppet apply) is what is currently reflected in {{settings}}. When designing the support for {{$settings}}, is that a good name for the variable? What should the variable for the "node settings" be? Should we use "local" and "node" as subkeys - that is {{$settings\[local]}} is what we have now, and {{$settings\[node]}} what will be added in PUP-1581, or should we have two global variables? We could also keep the existing namespace, so that {{$settings::local}} and {{$settings::node}} (or the asymmetrical {{$settings}} and {{$settings::node}}).If we use the existing namespace , support for this can be added in 4.x. If we go for that option, the two sections "local" and "node" will need to coexist with all the existing settings, and thus those names cannot be used as new settings (they are not used now).Another alternative is to add a function {{settings(name)}} which would return a setting or an Iterable over all settings if not given a name. This would reduce the amount of data kept in memory (there are many settings, and only a few of them, if any) are ever used in manifests. The return of an iterable means that the settings can be efficiently iterated (without first having to create a hash copy).We could also bind the Iterable to $settings, as that would be the most efficient, as the result is almost indistinguishable from a Hash.
Add Comment
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title
Henrik Lindberg updated an issue
Puppet / PUP-6692
Improve access to "master" settings
Change By:
Henrik Lindberg
Currently, there is a namespace {{settings}} in which all settings are set as individual variables. This makes them harder to use as the available settings change between versions, and using strict variables can cause errors, and the available settings cannot be enumerated. Having a {{$settings}} as a hash of all settings is also analog to how {{$facts}} work.Note that PUP-1581 is about making possible to also access the settings from a node. That complicates the issue. The settings for the compiling runtime (in master mode, or when doing a puppet apply) is what is currently reflected in {{settings}}. When designing the support for {{$settings}}, is that a good name for the variable? What should the variable for the "node settings" be? Should we use "local" and "node" as subkeys - that is {{$settings\[local]}} is what we have now, and {{$settings\[node]}} what will be added in PUP-1581, or should we have two global variables? We could also keep the existing namespace, so that {{$settings::local}} and {{$settings::node}} (or the asymmetrical {{$settings}} and {{$settings::node}}).If we use the existing namespace support for this can be added in 4.x. If we go for that option, the two sections "local" and "node" will need to coexist with all the existing settings, and thus those names cannot be used as new settings (they are not used now).Another alternative is to add a function {{settings(name)}} which would return a setting or an Iterable over all settings if not given a name. This would reduce the amount of data kept in memory (there are many settings, and only a few of them, if any) are ever used in manifests. The return of an iterable means that the settings can be efficiently iterated (without first having to create a hash copy). We could also bind the Iterable to $settings, as that would be the most efficient, as the result is almost indistinguishable from a Hash.
Add Comment
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg updated an issue Puppet / PUP-6692 Improve access to "master" settings Change By: Henrik Lindberg Sprint: PDS Triage Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6692) Improve access to "master" settings
Title: Message Title Henrik Lindberg created an issue Puppet / PUP-6692 Improve access to "master" settings Issue Type: Improvement Assignee: Unassigned Created: 2016/09/09 3:59 AM Priority: Normal Reporter: Henrik Lindberg Currently, there is a namespace settings in which all settings are set as individual variables. This makes them harder to use as the available settings change between versions, and using strict variables can cause errors, and the available settings cannot be enumerated. Having a $settings as a hash of all settings is also analog to how $facts work. Note that PUP-1581 is about making possible to also access the settings from a node. That complicates the issue. The settings for the compiling runtime (in master mode, or when doing a puppet apply) is what is currently reflected in settings. When designing the support for $settings, is that a good name for the variable? What should the variable for the "node settings" be? Should we use "local" and "node" as subkeys - that is $settings[local] is what we have now, and $settings[node] what will be added in PUP-1581, or should we have two global variables? We could also keep the existing namespace, so that $settings::local and $settings::node (or the asymmetrical $settings and $settings::node). If we use the existing namespace support for this can be added in 4.x. If we go for that option, the two sections "local" and "node" will need to coexist with all the existing settings, and thus those names cannot be used as new settings (they are not used now). Another alternative is to add a function settings(name) which would return a setting or an Iterable over all settings if not given a name. This would reduce the amount of data kept in memory (there are many settings, and only a few of them, if any) are ever used in manifests. The return of an iterable means that the settings can be efficiently
