Hi all,
Given the number of threads on variable scoping recently, it''s pretty
clear we need to change how it works. Markus has a lot of this redone
in his futures branch, and I''m asking him to fully describe what the
results will be when that''s merged, but my guess is that there are
different expectations for what people want to see.
So, my question is, what behaviour changes would you like to see in
how variable scoping works? How would you like the edge cases that
are currently hurting you to behave?
--
On Bureaucracy....
The Pythagorean theorem contains 24 words. Archimedes
Principle, 67. The Ten Commandments, 179. The American Declaration of
Independence, 300. And recent legislation in Europe concerning when
and where to smoke, 23,942. -- The European, June 23-29, 1995
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On 06/29/2010 12:22 PM, Luke Kanies wrote:> Hi all, > > Given the number of threads on variable scoping recently, it''s pretty > clear we need to change how it works. Markus has a lot of this redone > in his futures branch, and I''m asking him to fully describe what the > results will be when that''s merged, but my guess is that there are > different expectations for what people want to see. > > So, my question is, what behaviour changes would you like to see in > how variable scoping works? How would you like the edge cases that > are currently hurting you to behave? >Since order is not guaranteed, re-defining is kind of a no-go, but maybe some kind of ''final override'' keyword would work. Some logic like "if var is defined, i don''t care, this value takes final precedence." But you wouldn''t be able to have more than one ''final override'' or whatever term you want to call it. Also, it would be *huge* to be able to append to vars. Right now I open fw ports via a variable in the node def like: $open_tcp_ports = "22,443" If I could always open 22 in the node def, but += inside classes for httpd, nfs, etc. things would be nice. I''m guessing this might be a little difficult because all the variables in the catalog would have to be assembled before applying the catalog. -- -- Joe McDonagh Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Gabriel Filion
2010-Jun-30 03:43 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 2010-06-29 19:47, Joe McDonagh wrote:> On 06/29/2010 12:22 PM, Luke Kanies wrote: >> Hi all, >> >> Given the number of threads on variable scoping recently, it''s pretty >> clear we need to change how it works. Markus has a lot of this redone >> in his futures branch, and I''m asking him to fully describe what the >> results will be when that''s merged, but my guess is that there are >> different expectations for what people want to see. >> >> So, my question is, what behaviour changes would you like to see in >> how variable scoping works? How would you like the edge cases that >> are currently hurting you to behave? >> > Since order is not guaranteed, re-defining is kind of a no-go, but maybe > some kind of ''final override'' keyword would work. Some logic like "if > var is defined, i don''t care, this value takes final precedence." But > you wouldn''t be able to have more than one ''final override'' or whatever > term you want to call it. > > Also, it would be *huge* to be able to append to vars. Right now I open > fw ports via a variable in the node def like: > > $open_tcp_ports = "22,443" > > If I could always open 22 in the node def, but += inside classes for > httpd, nfs, etc. things would be nice. I''m guessing this might be a > little difficult because all the variables in the catalog would have to > be assembled before applying the catalog. >I think the appending facility would be nice.. It could be something similar to virtual resources that you realize in a precise place. Only, it would not be a resource, but a list that you realize as a metaparameter or variable value. And to go with that, having access to joining lists into a string without having to use an inline template would be nice. I think that collecting values inside a list from within any arbitrary class, that should be used in one place is a not-so-edgy case that is currently halted by class scopes. Firewall rules, as Joe McDonagh mentioned, is one example. Another example is nagios hostgroups/servicegroups. -- Gabriel Filion -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 29 June 2010 17:22, Luke Kanies <luke@puppetlabs.com> wrote:> Hi all, > > Given the number of threads on variable scoping recently, it''s pretty clear > we need to change how it works. Markus has a lot of this redone in his > futures branch, and I''m asking him to fully describe what the results will > be when that''s merged, but my guess is that there are different expectations > for what people want to see. > > So, my question is, what behaviour changes would you like to see in how > variable scoping works? How would you like the edge cases that are > currently hurting you to behave? >I''d like to see the ability to reference and change variables from other classes. class httpd { $monitor::services += ''httpd1'' } class nginx { $monitor::services += ''nginx'' } And if $monitor::services doesn''t exist then it''s just created with one of the above rather than having to specify $monitor::services = [] Or use the new staging feature for ordering where I could do: stage 1 includes class monitor { $monitor::services = [] } stage 2 includes class httpd, nginx as above Concerning nodes, it would be nice to see those variables declared in an inherited node be used in a child node without specify the same classes that are in the inherited node. Matt -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- "Luke Kanies" <luke@puppetlabs.com> wrote:> Hi all, > > Given the number of threads on variable scoping recently, it''s pretty > clear we need to change how it works. Markus has a lot of this redone > in his futures branch, and I''m asking him to fully describe what the > results will be when that''s merged, but my guess is that there are > different expectations for what people want to see. > > So, my question is, what behaviour changes would you like to see in > how variable scoping works? How would you like the edge cases that > are currently hurting you to behave?Apart the strangeness in variables in node inheritance, I think the variable scoping in Puppet is spot on. Once we have parametrized classes, I think: class foo { $bar = 1 include meh } class meh { notice($bar) } should not produce the results it does today. It''s a very handy side effect but mostly it''s not going to give you deterministic behavior in a order independent language and one where the same class can be included many times into many parent classes. Any and all order dependence should go, things like defined() should work as you''d expect, this is probably not a scope issue though. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Trevor Vaughan
2010-Jun-30 09:31 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If possible, I would like to see a special variables derivative of class that allow for multiple inheritance so that you could pull variables from multiple top-level classes and override them at a single point. This would prevent the multiple tree to ton of includes scenario. Also, I''m not entirely convinced that variables can''t be overridden. I understand that the final compilation is order independent, but I believe that the initial run is file order dependent. I.e. if you don''t declare an ''include'' before an ''if'' statement checking for the included class, then you end up with an ''if'' that is not called. Could the variable parsing be moved to this layer? If this were the case, then it would be like any other language in terms of variable overrides. Yes, it could get massively confusing. I think that being able to pass variables into classes solves quite a bit of this, but it''s truly an issue of having to constantly re-declare variables to make manifest/module usage easier. Thanks, Trevor On 06/29/2010 12:22 PM, Luke Kanies wrote:> Hi all, > > Given the number of threads on variable scoping recently, it''s pretty > clear we need to change how it works. Markus has a lot of this redone > in his futures branch, and I''m asking him to fully describe what the > results will be when that''s merged, but my guess is that there are > different expectations for what people want to see. > > So, my question is, what behaviour changes would you like to see in how > variable scoping works? How would you like the edge cases that are > currently hurting you to behave? >- -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaughan@onyxpoint.com phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJMKw7ZAAoJECNCGV1OLcyp4coH/REcuublLnqFBowgbZ4mtdBm jBIygeWfU9zILgSqqVr0hgHeAR3AJH5X3Yy8FISCJNTlDzEP7TyeKIlYnuph9aXr Cj9OThm5GcPJKm1ZR5DhUGY3Vr5Hy/RCh2Y6Q8KuuKk+T7dH8bOlQRk4knTX5Isj TpnWVoVj8SxZimU2RRzx778IAwmDNdRJxY9R73O1Fgrk8uO2VkGCwy3/j+6pII36 iW01uvmY5VImAOM6nmA0J+bMaOciauzr7AGmnj1yzG0tInmzVx5gPGSErJKTpjzb NgER+hvKQRC83pbI9Pv6pwwDvlM+tcRzLU7HkOog/8cDu15MTG55LghVvG8bEsM=/wgk -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote:> Also, I''m not entirely convinced that variables can''t be overridden. > I understand that the final compilation is order independent, but I > believe that the initial run is file order dependent. I.e. if you > don''t declare an ''include'' before an ''if'' statement checking for the > included class, then you end up with an ''if'' that is not called. Could the > variable parsing be moved to this layer?I''d call this parsing behavior a bug, see my comment about defined(), it''s related to that http://projects.reductivelabs.com/issues/3049 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Trevor Vaughan
2010-Jun-30 14:01 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
Fair enough. If it is a bug, then consider that suggestion null and void. Did you note that defined() should not blow up if you don''t have the class on your system at all? Sorry, running in text only mode today :-/. Thanks, Trevor On 6/30/10, R.I.Pienaar <rip@devco.net> wrote:> > ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: > >> Also, I''m not entirely convinced that variables can''t be overridden. >> I understand that the final compilation is order independent, but I >> believe that the initial run is file order dependent. I.e. if you >> don''t declare an ''include'' before an ''if'' statement checking for the >> included class, then you end up with an ''if'' that is not called. Could the >> variable parsing be moved to this layer? > > I''d call this parsing behavior a bug, see my comment about defined(), it''s > related to that > > http://projects.reductivelabs.com/issues/3049 > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
''lo ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote:> Did you note that defined() should not blow up if you don''t have the > class on your system at all?hehe never seen this behavior but did just test, I''d say that another bug worth filing separately> > Sorry, running in text only mode today :-/. > > Thanks, > > Trevor > > On 6/30/10, R.I.Pienaar <rip@devco.net> wrote: > > > > ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: > > > >> Also, I''m not entirely convinced that variables can''t be > overridden. > >> I understand that the final compilation is order independent, but > I > >> believe that the initial run is file order dependent. I.e. if you > >> don''t declare an ''include'' before an ''if'' statement checking for > the > >> included class, then you end up with an ''if'' that is not called. > Could the > >> variable parsing be moved to this layer? > > > > I''d call this parsing behavior a bug, see my comment about > defined(), it''s > > related to that > > > > http://projects.reductivelabs.com/issues/3049 > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaughan@onyxpoint.com > > -- This account not approved for unencrypted proprietary information > -- > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.-- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jun 30, 2010, at 3:09 AM, R.I.Pienaar wrote:> > ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: > >> Also, I''m not entirely convinced that variables can''t be overridden. >> I understand that the final compilation is order independent, but I >> believe that the initial run is file order dependent. I.e. if you >> don''t declare an ''include'' before an ''if'' statement checking for the >> included class, then you end up with an ''if'' that is not called. Could the >> variable parsing be moved to this layer? > > I''d call this parsing behavior a bug, see my comment about defined(), it''s > related to that > > http://projects.reductivelabs.com/issues/3049By the way, ignoring the technical aspect, how do you think defined should work in this case? In this case, what aleart should be printed, or what error should be printed? This is a rather contrived example, but I''m not really sure what puppet should actually do here with your suggestion. (Please excuse my syntax errors). node ''test-node'' { include classA include classB } class classA { if !defined Package[''apache''] { package { ''apache'': ensure => installed, } alert("Package apache included by classA") } } class classB { if !defined Package[''apache''] { package { ''apache'': ensure => installed, } alert("Package apache included by classB") } } -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
hey ----- "Patrick Mohr" <kc7zzv@gmail.com> wrote:> On Jun 30, 2010, at 3:09 AM, R.I.Pienaar wrote: > > > > > ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: > > > >> Also, I''m not entirely convinced that variables can''t be > overridden. > >> I understand that the final compilation is order independent, but > I > >> believe that the initial run is file order dependent. I.e. if you > >> don''t declare an ''include'' before an ''if'' statement checking for > the > >> included class, then you end up with an ''if'' that is not called. > Could the > >> variable parsing be moved to this layer? > > > > I''d call this parsing behavior a bug, see my comment about > defined(), it''s > > related to that > > > > http://projects.reductivelabs.com/issues/3049 > > By the way, ignoring the technical aspect, how do you think defined > should work in this case? In this case, what aleart should be printed, > or what error should be printed? This is a rather contrived example, > but I''m not really sure what puppet should actually do here with your > suggestion. (Please excuse my syntax errors). > > > > node ''test-node'' { > include classA > include classB > } > > > class classA { > if !defined Package[''apache''] > { > package { ''apache'': > ensure => installed, > } > > alert("Package apache included by classA") > } > } > > class classB { > if !defined Package[''apache''] > { > package { ''apache'': > ensure => installed, > } > > alert("Package apache included by classB") > } > }This would fall under the umbrella of bad manifest design :) I''d expect it to print different alerts between runs - today it would be predictable, i think but I wouldnt treat that as something to rely on. -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jun 30, 2010, at 8:33 AM, R.I.Pienaar wrote:> hey > > ----- "Patrick Mohr" <kc7zzv@gmail.com> wrote: > >> On Jun 30, 2010, at 3:09 AM, R.I.Pienaar wrote: >> >>> >>> ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: >>> >>>> Also, I''m not entirely convinced that variables can''t be >> overridden. >>>> I understand that the final compilation is order independent, but >> I >>>> believe that the initial run is file order dependent. I.e. if you >>>> don''t declare an ''include'' before an ''if'' statement checking for >> the >>>> included class, then you end up with an ''if'' that is not called. >> Could the >>>> variable parsing be moved to this layer? >>> >>> I''d call this parsing behavior a bug, see my comment about >> defined(), it''s >>> related to that >>> >>> http://projects.reductivelabs.com/issues/3049 >> >> By the way, ignoring the technical aspect, how do you think defined >> should work in this case? In this case, what aleart should be printed, >> or what error should be printed? This is a rather contrived example, >> but I''m not really sure what puppet should actually do here with your >> suggestion. (Please excuse my syntax errors). >> >> >> >> node ''test-node'' { >> include classA >> include classB >> } >> >> >> class classA { >> if !defined Package[''apache''] >> { >> package { ''apache'': >> ensure => installed, >> } >> >> alert("Package apache included by classA") >> } >> } >> >> class classB { >> if !defined Package[''apache''] >> { >> package { ''apache'': >> ensure => installed, >> } >> >> alert("Package apache included by classB") >> } >> } > > > This would fall under the umbrella of bad manifest design :) I''d expect it to print different alerts between runs - today it would be predictable, i think but I wouldnt treat that as something to rely on.I agree it''s bad design and I''m not using that code, but I think you need to know how puppet should treat this case before the problem can be fixed. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Trevor Vaughan
2010-Jun-30 22:10 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, it''s this bug: http://projects.reductivelabs.com/issues/3490 That''s definitely going to need to get fixed before the module forge is really going to take off. Trevor On 06/30/2010 10:05 AM, R.I.Pienaar wrote:> ''lo > > ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: > >> Did you note that defined() should not blow up if you don''t have the >> class on your system at all? > > hehe never seen this behavior but did just test, I''d say that another bug worth filing separately > >> >> Sorry, running in text only mode today :-/. >> >> Thanks, >> >> Trevor >> >> On 6/30/10, R.I.Pienaar <rip@devco.net> wrote: >>> >>> ----- "Trevor Vaughan" <tvaughan@onyxpoint.com> wrote: >>> >>>> Also, I''m not entirely convinced that variables can''t be >> overridden. >>>> I understand that the final compilation is order independent, but >> I >>>> believe that the initial run is file order dependent. I.e. if you >>>> don''t declare an ''include'' before an ''if'' statement checking for >> the >>>> included class, then you end up with an ''if'' that is not called. >> Could the >>>> variable parsing be moved to this layer? >>> >>> I''d call this parsing behavior a bug, see my comment about >> defined(), it''s >>> related to that >>> >>> http://projects.reductivelabs.com/issues/3049 >>> >>> -- >>> You received this message because you are subscribed to the Google >> Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >>> >>> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> tvaughan@onyxpoint.com >> >> -- This account not approved for unencrypted proprietary information >> -- >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >- -- Trevor Vaughan Vice President, Onyx Point, Inc. email: tvaughan@onyxpoint.com phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJMK8DhAAoJECNCGV1OLcypjxUH+gIu8CaRVxEPg0HKSM2N208i 5bT3YmG3qMsS+H85g6IFSBvdx/ygpg/q5Clzeh14uMzjxtcVBhq0efNujEilNu9B LHY5wEUFW0eJYHDm7CSS9DSBbcrGLE50ZcnWEz08iXVJEBMukZmhZmy9W5FXKWbn A/JsB94lvJYqmuxSYfjUV/qKqGHXrkgfIfZ0Zhrj94s3i+6rwEVBcmuaQk95eOxX BcyGqGKA6M7aS9W5CQ0tU9UYgw2Iz+bC8tkU5N/J67XOBza6iMa6NIqa7xcpKXKd WfAFa+A96SkKg7lOPUSxbZZTx+qQAhDIyOEysSBol8Go4okm+VpjlHKu1a8brNs=HTWs -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2010-Jul-02 08:45 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 6/30/2010 1:47 AM, Joe McDonagh wrote:> Also, it would be *huge* to be able to append to vars. Right now I open > fw ports via a variable in the node def like: > > $open_tcp_ports = "22,443" > > If I could always open 22 in the node def, but += inside classes for > httpd, nfs, etc. things would be nice. I''m guessing this might be a > little difficult because all the variables in the catalog would have to > be assembled before applying the catalog.Please model your ports as resources: fw::port { 20: ensure => open } Even if this only drops a concat snippet somewhere, this is brings you so much benefits I don''t know where to start. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2010-Jul-02 08:50 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 6/30/2010 10:57 AM, Matt wrote:> On 29 June 2010 17:22, Luke Kanies<luke@puppetlabs.com> wrote: >> Hi all, >> >> Given the number of threads on variable scoping recently, it''s pretty clear >> we need to change how it works. Markus has a lot of this redone in his >> futures branch, and I''m asking him to fully describe what the results will >> be when that''s merged, but my guess is that there are different expectations >> for what people want to see. >> >> So, my question is, what behaviour changes would you like to see in how >> variable scoping works? How would you like the edge cases that are >> currently hurting you to behave? >> > > I''d like to see the ability to reference and change variables from > other classes. > > class httpd { $monitor::services += ''httpd1'' } > class nginx { $monitor::services += ''nginx'' } > > And if $monitor::services doesn''t exist then it''s just created with > one of the above rather than having to specify $monitor::services = [] > > Or use the new staging feature for ordering where I could do: > > stage 1 includes class monitor { $monitor::services = [] } > stage 2 includes class httpd, nginx as aboveHow is $monitor::service used, that this cannot read class httpd { monitor::service { ''httpd1'': } } class nginx { monitor::service { ''nginx'': } } ? Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2010-Jul-02 08:56 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 6/30/2010 5:07 PM, Patrick Mohr wrote:> By the way, ignoring the technical aspect, how do you think defined > should work in this case? In this case, what aleart should be printed, > or what error should be printed? This is a rather contrived example, but > I''m not really sure what puppet should actually do here with your > suggestion. (Please excuse my syntax errors). > > > > node ''test-node'' { > include classA > include classB > } > > > class classA { > if !defined Package[''apache''] > { > package { ''apache'': > ensure => installed, > } > > alert("Package apache included by classA") > } > } > > class classB { > if !defined Package[''apache''] > { > package { ''apache'': > ensure => installed, > } > > alert("Package apache included by classB") > } > }In an ideal world, this is an invalid manifest. Especially when you add more resources in there, that have different properties in classA vs classB. The correct way to implement that would be to extract the conditional resources into a common class. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 2 July 2010 09:50, David Schmitt <david@dasz.at> wrote:> On 6/30/2010 10:57 AM, Matt wrote: >> >> On 29 June 2010 17:22, Luke Kanies<luke@puppetlabs.com> wrote: >>> >>> Hi all, >>> >>> Given the number of threads on variable scoping recently, it''s pretty >>> clear >>> we need to change how it works. Markus has a lot of this redone in his >>> futures branch, and I''m asking him to fully describe what the results >>> will >>> be when that''s merged, but my guess is that there are different >>> expectations >>> for what people want to see. >>> >>> So, my question is, what behaviour changes would you like to see in how >>> variable scoping works? How would you like the edge cases that are >>> currently hurting you to behave? >>> >> >> I''d like to see the ability to reference and change variables from >> other classes. >> >> class httpd { $monitor::services += ''httpd1'' } >> class nginx { $monitor::services += ''nginx'' } >> >> And if $monitor::services doesn''t exist then it''s just created with >> one of the above rather than having to specify $monitor::services = [] >> >> Or use the new staging feature for ordering where I could do: >> >> stage 1 includes class monitor { $monitor::services = [] } >> stage 2 includes class httpd, nginx as above > > How is $monitor::service used, that this cannot read > > class httpd { monitor::service { ''httpd1'': } } > class nginx { monitor::service { ''nginx'': } } > > ?$monitor::service is used to monitor all services that are in that array. So node include monitor, httpd, nginx class monitor { deploy monitoring for all services in $monitor::service } Being able to do if $monitor::service includes(httpd) would also be cool. Matt -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2010-Jul-05 08:15 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 7/5/2010 12:04 AM, Matt wrote:> On 2 July 2010 09:50, David Schmitt<david@dasz.at> wrote: >> On 6/30/2010 10:57 AM, Matt wrote: >>> >>> On 29 June 2010 17:22, Luke Kanies<luke@puppetlabs.com> wrote: >>>> >>>> Hi all, >>>> >>>> Given the number of threads on variable scoping recently, it''s pretty >>>> clear >>>> we need to change how it works. Markus has a lot of this redone in his >>>> futures branch, and I''m asking him to fully describe what the results >>>> will >>>> be when that''s merged, but my guess is that there are different >>>> expectations >>>> for what people want to see. >>>> >>>> So, my question is, what behaviour changes would you like to see in how >>>> variable scoping works? How would you like the edge cases that are >>>> currently hurting you to behave? >>>> >>> >>> I''d like to see the ability to reference and change variables from >>> other classes. >>> >>> class httpd { $monitor::services += ''httpd1'' } >>> class nginx { $monitor::services += ''nginx'' } >>> >>> And if $monitor::services doesn''t exist then it''s just created with >>> one of the above rather than having to specify $monitor::services = [] >>> >>> Or use the new staging feature for ordering where I could do: >>> >>> stage 1 includes class monitor { $monitor::services = [] } >>> stage 2 includes class httpd, nginx as above >> >> How is $monitor::service used, that this cannot read >> >> class httpd { monitor::service { ''httpd1'': } } >> class nginx { monitor::service { ''nginx'': } } >> >> ? > > $monitor::service is used to monitor all services that are in that > array. So node include monitor, httpd, nginx > > class monitor { deploy monitoring for all services in $monitor::service } > > Being able to do if $monitor::service includes(httpd) would also be cool.You didn''t answer my question. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 5 July 2010 09:15, David Schmitt <david@dasz.at> wrote:> On 7/5/2010 12:04 AM, Matt wrote: >> >> On 2 July 2010 09:50, David Schmitt<david@dasz.at> wrote: >>> >>> On 6/30/2010 10:57 AM, Matt wrote: >>>> >>>> On 29 June 2010 17:22, Luke Kanies<luke@puppetlabs.com> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Given the number of threads on variable scoping recently, it''s pretty >>>>> clear >>>>> we need to change how it works. Markus has a lot of this redone in his >>>>> futures branch, and I''m asking him to fully describe what the results >>>>> will >>>>> be when that''s merged, but my guess is that there are different >>>>> expectations >>>>> for what people want to see. >>>>> >>>>> So, my question is, what behaviour changes would you like to see in how >>>>> variable scoping works? How would you like the edge cases that are >>>>> currently hurting you to behave? >>>>> >>>> >>>> I''d like to see the ability to reference and change variables from >>>> other classes. >>>> >>>> class httpd { $monitor::services += ''httpd1'' } >>>> class nginx { $monitor::services += ''nginx'' } >>>> >>>> And if $monitor::services doesn''t exist then it''s just created with >>>> one of the above rather than having to specify $monitor::services = [] >>>> >>>> Or use the new staging feature for ordering where I could do: >>>> >>>> stage 1 includes class monitor { $monitor::services = [] } >>>> stage 2 includes class httpd, nginx as above >>> >>> How is $monitor::service used, that this cannot read >>> >>> class httpd { monitor::service { ''httpd1'': } } >>> class nginx { monitor::service { ''nginx'': } } >>> >>> ? >> >> $monitor::service is used to monitor all services that are in that >> array. So node include monitor, httpd, nginx >> >> class monitor { deploy monitoring for all services in $monitor::service } >> >> Being able to do if $monitor::service includes(httpd) would also be cool. > > > You didn''t answer my question.$monitor::service is used in multiple erb templates as an array. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hello All, Thanks for opening up this discussion to the community. I quickly scanned through this thread, but didn''t see anything from Markus, does he post under a different name. Not to side track the conversation, but could anyone explain why variable scoping is the way it is in puppet? I "understand" how to use variables in puppet (I ALWAYS use fully qualified variable names, and I ALWAYS use myvar.lookup in my templates.) But, I struggle to communicate to new puppet programmers why. Is it because puppet is "declarative", is this a "feature" in declarative languages? Is there a parallel in SQL? Is it a rubyism? I believe that String.sub! and String.sub change the variables differently. Any light someone could shed on the background, would be greatly appreciated. Have a nice July 5th. -Tom On Jul 5, 7:04 am, Matt <mattmora...@gmail.com> wrote:> On 5 July 2010 09:15, David Schmitt <da...@dasz.at> wrote: > > > > > > > On 7/5/2010 12:04 AM, Matt wrote: > > >> On 2 July 2010 09:50, David Schmitt<da...@dasz.at> wrote: > > >>> On 6/30/2010 10:57 AM, Matt wrote: > > >>>> On 29 June 2010 17:22, Luke Kanies<l...@puppetlabs.com> wrote: > > >>>>> Hi all, > > >>>>> Given the number of threads on variable scoping recently, it''s pretty > >>>>> clear > >>>>> we need to change how it works. Markus has a lot of this redone in his > >>>>> futures branch, and I''m asking him to fully describe what the results > >>>>> will > >>>>> be when that''s merged, but my guess is that there are different > >>>>> expectations > >>>>> for what people want to see. > > >>>>> So, my question is, what behaviour changes would you like to see in how > >>>>> variable scoping works? How would you like the edge cases that are > >>>>> currently hurting you to behave? > > >>>> I''d like to see the ability to reference and change variables from > >>>> other classes. > > >>>> class httpd { $monitor::services += ''httpd1'' } > >>>> class nginx { $monitor::services += ''nginx'' } > > >>>> And if $monitor::services doesn''t exist then it''s just created with > >>>> one of the above rather than having to specify $monitor::services = [] > > >>>> Or use the new staging feature for ordering where I could do: > > >>>> stage 1 includes class monitor { $monitor::services = [] } > >>>> stage 2 includes class httpd, nginx as above > > >>> How is $monitor::service used, that this cannot read > > >>> class httpd { monitor::service { ''httpd1'': } } > >>> class nginx { monitor::service { ''nginx'': } } > > >>> ? > > >> $monitor::service is used to monitor all services that are in that > >> array. So node include monitor, httpd, nginx > > >> class monitor { deploy monitoring for all services in $monitor::service } > > >> Being able to do if $monitor::service includes(httpd) would also be cool. > > > You didn''t answer my question. > > $monitor::service is used in multiple erb templates as an array.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Jeff McCune
2010-Jul-05 20:57 UTC
Re: [Puppet Users] Re: Variable Scoping: What do you want?
On Mon, Jul 5, 2010 at 8:30 AM, TomTom <mcgonagle@gmail.com> wrote:> Hello All, > Thanks for opening up this discussion to the community. I quickly > scanned through this thread, but didn''t see anything from Markus, does > he post under a different name. > Not to side track the conversation, but could anyone explain why > variable scoping is the way it is in puppet? I "understand" how to use > variables in puppet (I ALWAYS use fully qualified variable names, and > I ALWAYS use myvar.lookup in my templates.) But, I struggle to > communicate to new puppet programmers why. > > Is it because puppet is "declarative", is this a "feature" in > declarative languages? Is there a parallel in SQL?Much of the variable referencing gotchas come from the declarative nature of puppet. It''s actually fairly straight forward what''s happening (in my opinion). You cannot re-declare a variable in the same scope because of the declarative nature of puppet, puppet does not know which declaration is "right" since order doesn''t matter. You can, however declare the same variable name in a different scope however. They''re actually different variables. In module "jeff" I create class jeff::params {} in manifests/params.pp and place variables here. This allows me to reference $params::shirtcolor from class jeff. Note too I''m not using absolute name-space syntax. Finally, in 0.25.x the parser is single-pass which causes some of the constraints and inconsistencies with variable declarations related to their order inside manifests. In the future, the parser will be multi-pass which will correct these inconsistencies. Hope this helps, -- Jeff McCune http://www.puppetlabs.com/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 07/02/2010 04:45 AM, David Schmitt wrote:> On 6/30/2010 1:47 AM, Joe McDonagh wrote: >> Also, it would be *huge* to be able to append to vars. Right now I open >> fw ports via a variable in the node def like: >> >> $open_tcp_ports = "22,443" >> >> If I could always open 22 in the node def, but += inside classes for >> httpd, nfs, etc. things would be nice. I''m guessing this might be a >> little difficult because all the variables in the catalog would have to >> be assembled before applying the catalog. > > Please model your ports as resources: > > fw::port { 20: ensure => open } > > Even if this only drops a concat snippet somewhere, this is brings you > so much benefits I don''t know where to start. > > > Best Regards, DavidThis brings nothing to the table for me and means I would have to add a ridiculous amount of puppet code and risk breaking all of production. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
David Schmitt
2010-Jul-09 07:31 UTC
Re: [Puppet Users] Variable Scoping: What do you want?
On 7/8/2010 10:33 PM, Joe McDonagh wrote:> On 07/02/2010 04:45 AM, David Schmitt wrote: >> On 6/30/2010 1:47 AM, Joe McDonagh wrote: >>> Also, it would be *huge* to be able to append to vars. Right now I open >>> fw ports via a variable in the node def like: >>> >>> $open_tcp_ports = "22,443" >>> >>> If I could always open 22 in the node def, but += inside classes for >>> httpd, nfs, etc. things would be nice. I''m guessing this might be a >>> little difficult because all the variables in the catalog would have to >>> be assembled before applying the catalog. >> >> Please model your ports as resources: >> >> fw::port { 20: ensure => open } >> >> Even if this only drops a concat snippet somewhere, this is brings you >> so much benefits I don''t know where to start. >> >> >> Best Regards, David > This brings nothing to the table for me and means I would have to add a > ridiculous amount of puppet code and risk breaking all of production.I do not understand why people are so intent on NOT using puppet''s resource model to model their resources. Since I''m not responsible for your manifests, I''d agree to disagree on this. Best Regards, David -- dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at Klosterneuburg UID: ATU64260999 FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.