I''ve been using Hiera and Hiera-Puppet with Puppet 2.7 for a while now, and I''ve been quite enjoying it. I just noticed the available update for Puppet and saw that Hiera was now part of core Puppet. However, I''ve been unable to parse exactly what parts made it over, and every source of information I read seems to have different info. My confusion includes: 1. The Hiera-Puppet functions, hiera() and the array, hash and include versions. They appear in the 3.0.0 doc, but I''ve read they may be deprecated, changed or even unnecessary, their functionality having been incorporated into things like lookup() and include(). Since I''ve been making fairly heavy use of them, I need to know if I should migrate my modules to something else. 2. The hierarchy itself. How much of the configurability made it over? I''ve been using a custom fact or two in mine, and I''m wondering if that''s still supported. Also, I''ve been using a combination of YAML on disk and a puppet data module to store variables, is that still supported? Basically, I''ve been having trouble finding consistent documentation on the subject of what changed and what didn''t, so if someone could explain or point me to the correct docs, that would be greatly appreciated, as I really want to upgrade to take advantage of the other new features. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/rbwWoB1WDGEJ. 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 Friday, October 5, 2012 10:47:58 AM UTC-7, Ellison Marks wrote:> > I''ve been using Hiera and Hiera-Puppet with Puppet 2.7 for a while now, > and I''ve been quite enjoying it. I just noticed the available update for > Puppet and saw that Hiera was now part of core Puppet. However, I''ve been > unable to parse exactly what parts made it over...Yeah sorry, I''m working on clarifying that today. The answer is: ALL OF IT, but you might have to move your config file or change a setting. - Puppet has a hiera_config setting that defaults to $confdir/hiera.yaml. It won''t fall back to hiera''s default conf file. If your conf is at /etc/hiera.yaml, move it or tell puppet.conf where it is. http://docs.puppetlabs.com/references/latest/configuration.html#hieraconfig - The hierarchy itself works the same, including fact interpolation. - All four hiera functions are still there. No need to change their names. - The "puppet" backend is still there! That''s one that we were planning to remove at one point, and I don''t yet have the whole story on how that went down, but it did stay in. Or at least, it''s in the source code; I don''t know how packages and gems deal with it, yet. - The generic "lookup" function didn''t happen. The built-in "data_binding" code currently only applies to class parameters; we left an expansion of it for a later date, once we have a deeper understanding of users'' needs and challenges. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/KluWo130L3kJ. 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.
Thanks for the reply. I''ll probably start migrating things to the new "parameter" based lookup and a disk based hierarchy anyway, but it''s good to know that my setup probably won''t break immediately upon upgrading. ^_^ On Friday, October 5, 2012 12:44:41 PM UTC-7, Nick Fagerlund wrote:> > > > On Friday, October 5, 2012 10:47:58 AM UTC-7, Ellison Marks wrote: >> >> I''ve been using Hiera and Hiera-Puppet with Puppet 2.7 for a while now, >> and I''ve been quite enjoying it. I just noticed the available update for >> Puppet and saw that Hiera was now part of core Puppet. However, I''ve been >> unable to parse exactly what parts made it over... > > > Yeah sorry, I''m working on clarifying that today. The answer is: ALL OF > IT, but you might have to move your config file or change a setting. > > - Puppet has a hiera_config setting that defaults to $confdir/hiera.yaml. > It won''t fall back to hiera''s default conf file. If your conf is at > /etc/hiera.yaml, move it or tell puppet.conf where it is. > http://docs.puppetlabs.com/references/latest/configuration.html#hieraconfig > - The hierarchy itself works the same, including fact interpolation. > - All four hiera functions are still there. No need to change their names. > - The "puppet" backend is still there! That''s one that we were planning to > remove at one point, and I don''t yet have the whole story on how that went > down, but it did stay in. Or at least, it''s in the source code; I don''t > know how packages and gems deal with it, yet. > - The generic "lookup" function didn''t happen. The built-in "data_binding" > code currently only applies to class parameters; we left an expansion of it > for a later date, once we have a deeper understanding of users'' needs and > challenges. >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/pjyE89rYin4J. 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.
Sorry to burst you bubble.... The puppet backend has been ''broken'' (intentionally?) - https://projects.puppetlabs.com/issues/16321 - https://mail.google.com/mail/u/1/?ui=2&shva=1#search/label%3Apuppet-users+pienaar/13a168982ad38854 Lots needs fixing... Zipkid (Stefan) On Fri, Oct 5, 2012 at 10:43 PM, Ellison Marks <gtyaoi@gmail.com> wrote:> Thanks for the reply. I''ll probably start migrating things to the new > "parameter" based lookup and a disk based hierarchy anyway, but it''s good > to know that my setup probably won''t break immediately upon upgrading. ^_^ > > > On Friday, October 5, 2012 12:44:41 PM UTC-7, Nick Fagerlund wrote: >> >> >> >> On Friday, October 5, 2012 10:47:58 AM UTC-7, Ellison Marks wrote: >>> >>> I''ve been using Hiera and Hiera-Puppet with Puppet 2.7 for a while now, >>> and I''ve been quite enjoying it. I just noticed the available update for >>> Puppet and saw that Hiera was now part of core Puppet. However, I''ve been >>> unable to parse exactly what parts made it over... >> >> >> Yeah sorry, I''m working on clarifying that today. The answer is: ALL OF >> IT, but you might have to move your config file or change a setting. >> >> - Puppet has a hiera_config setting that defaults to $confdir/hiera.yaml. >> It won''t fall back to hiera''s default conf file. If your conf is at >> /etc/hiera.yaml, move it or tell puppet.conf where it is. >> http://docs.puppetlabs.com/**references/latest/** >> configuration.html#hieraconfig<http://docs.puppetlabs.com/references/latest/configuration.html#hieraconfig> >> - The hierarchy itself works the same, including fact interpolation. >> - All four hiera functions are still there. No need to change their names. >> - The "puppet" backend is still there! That''s one that we were planning >> to remove at one point, and I don''t yet have the whole story on how that >> went down, but it did stay in. Or at least, it''s in the source code; I >> don''t know how packages and gems deal with it, yet. >> - The generic "lookup" function didn''t happen. The built-in >> "data_binding" code currently only applies to class parameters; we left an >> expansion of it for a later date, once we have a deeper understanding of >> users'' needs and challenges. >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/pjyE89rYin4J. > > 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. >-- 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.
Ah, thanks. I''ll look into that. On Sunday, October 7, 2012 1:07:02 PM UTC-7, Stefan Goethals wrote:> > Sorry to burst you bubble.... > The puppet backend has been ''broken'' (intentionally?) > > - https://projects.puppetlabs.com/issues/16321 > - > https://mail.google.com/mail/u/1/?ui=2&shva=1#search/label%3Apuppet-users+pienaar/13a168982ad38854 > > Lots needs fixing... > > Zipkid (Stefan) > > > On Fri, Oct 5, 2012 at 10:43 PM, Ellison Marks <gty...@gmail.com<javascript:> > > wrote: > >> Thanks for the reply. I''ll probably start migrating things to the new >> "parameter" based lookup and a disk based hierarchy anyway, but it''s good >> to know that my setup probably won''t break immediately upon upgrading. ^_^ >> >> >> On Friday, October 5, 2012 12:44:41 PM UTC-7, Nick Fagerlund wrote: >>> >>> >>> >>> On Friday, October 5, 2012 10:47:58 AM UTC-7, Ellison Marks wrote: >>>> >>>> I''ve been using Hiera and Hiera-Puppet with Puppet 2.7 for a while now, >>>> and I''ve been quite enjoying it. I just noticed the available update for >>>> Puppet and saw that Hiera was now part of core Puppet. However, I''ve been >>>> unable to parse exactly what parts made it over... >>> >>> >>> Yeah sorry, I''m working on clarifying that today. The answer is: ALL OF >>> IT, but you might have to move your config file or change a setting. >>> >>> - Puppet has a hiera_config setting that defaults to >>> $confdir/hiera.yaml. It won''t fall back to hiera''s default conf file. If >>> your conf is at /etc/hiera.yaml, move it or tell puppet.conf where it is. >>> http://docs.puppetlabs.com/**references/latest/** >>> configuration.html#hieraconfig<http://docs.puppetlabs.com/references/latest/configuration.html#hieraconfig> >>> - The hierarchy itself works the same, including fact interpolation. >>> - All four hiera functions are still there. No need to change their >>> names. >>> - The "puppet" backend is still there! That''s one that we were planning >>> to remove at one point, and I don''t yet have the whole story on how that >>> went down, but it did stay in. Or at least, it''s in the source code; I >>> don''t know how packages and gems deal with it, yet. >>> - The generic "lookup" function didn''t happen. The built-in >>> "data_binding" code currently only applies to class parameters; we left an >>> expansion of it for a later date, once we have a deeper understanding of >>> users'' needs and challenges. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/puppet-users/-/pjyE89rYin4J. >> >> To post to this group, send email to puppet...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> puppet-users...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/FxueGhxdGAQJ. 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.
Not to let this thread go to waste... Since I''m now trying to move away from the hiera functions themselves to the parameter style, is there a way I can specify that the lookup should be additive, hiera_hash or hiera_array style? If not, is that a planned feature? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/9AoVaYwICuoJ. 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.
----- Original Message -----> From: "Ellison Marks" <gtyaoi@gmail.com> > To: puppet-users@googlegroups.com > Sent: Friday, October 12, 2012 6:10:38 PM > Subject: [Puppet Users] Re: Puppet 3.0.0 and Hiera > > Not to let this thread go to waste... > > Since I''m now trying to move away from the hiera functions themselves > to the parameter style, is there a way I can specify that the lookup > should be additive, hiera_hash or hiera_array style? If not, is that > a planned feature?unfortunately not -- 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 Friday, October 12, 2012 12:10:38 PM UTC-5, Ellison Marks wrote:> > Not to let this thread go to waste... > > Since I''m now trying to move away from the hiera functions themselves to > the parameter styleWhy? The ability to achieve separation of data from code while avoiding parametrized classes is one of the greatest advantages conferred by hiera. Every parametrized-style class declaration (not definition) in your manifests is a bug waiting to happen. And if you''re not going to use such declarations, then why do you want to spend effort on converting your classes to make it possible? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/l2lUe9QHBGQJ. 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.
----- Original Message -----> From: "jcbollinger" <John.Bollinger@stJude.org> > To: puppet-users@googlegroups.com > Sent: Monday, October 15, 2012 3:35:30 PM > Subject: [Puppet Users] Re: Puppet 3.0.0 and Hiera > > > > On Friday, October 12, 2012 12:10:38 PM UTC-5, Ellison Marks wrote: > > Not to let this thread go to waste... > > Since I''m now trying to move away from the hiera functions themselves > to the parameter style > > > Why? The ability to achieve separation of data from code while > avoiding parametrized classes is one of the greatest advantages > conferred by hiera. Every parametrized-style class declaration (not > definition) in your manifests is a bug waiting to happen. And if > you''re not going to use such declarations, then why do you want to > spend effort on converting your classes to make it possible? > >the param classes integration with hiera in puppet 3 does make it worth taking another look at param classes: The code: class x($y="hello") { notify{$y: } } include x include x actually works fine, note this is basically your old school puppet syntax, multiple calls to include etc, but with hiera integration for the variable key "x::y". this deals with the dynamic scoping problem, deals with most of the things I hate(d) about param classes and gives me magical abilities to do overrides where and how I need them. You can still if u wish use the new param classes style of including, ENC etc can all supply data just like always. from a code share perspective this is a big win, simply using param classes means your module is forwards and backwards compatible with hiera or without hiera. -- 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 Monday, October 15, 2012 9:49:38 AM UTC-5, R.I. Pienaar wrote:> > > > ----- Original Message ----- > > From: "jcbollinger" > > To: puppet...@googlegroups.com <javascript:> > > Sent: Monday, October 15, 2012 3:35:30 PM > > Subject: [Puppet Users] Re: Puppet 3.0.0 and Hiera > > > > > > > > On Friday, October 12, 2012 12:10:38 PM UTC-5, Ellison Marks wrote: > > > > Not to let this thread go to waste... > > > > Since I''m now trying to move away from the hiera functions themselves > > to the parameter style > > > > > > Why? The ability to achieve separation of data from code while > > avoiding parametrized classes is one of the greatest advantages > > conferred by hiera. Every parametrized-style class declaration (not > > definition) in your manifests is a bug waiting to happen. And if > > you''re not going to use such declarations, then why do you want to > > spend effort on converting your classes to make it possible? > > > > > > the param classes integration with hiera in puppet 3 does make it > worth taking another look at param classes: >Indeed, I have taken a second look, and a third, and maybe more. I love the hiera integration with parametrized classes. It was a fabulous idea, as it makes it reasonable and safe to use existing parametrized classes (provided you use only ''include'' or ''require'' to declare them). Even with that, however, parametrized classes offer very little of value over non-parametrized analogs that implement the same hiera-based external data access. One could argue, perhaps, that there is a documentary advantage in parametrization, but I think that''s poor justification for introducing functional (so to speak) elements to any class. That''s what comments are for.> > The code: > > class x($y="hello") { > notify{$y: } > } > > include x > include x > > > actually works fine, note this is basically your old school puppet > syntax, multiple calls to include etc, but with hiera integration > for the variable key "x::y". >Yes, that''s great. The problem is that include x class { ''x'': y => ''goodbye'' } blows up. On the other hand, I understand that class { ''x'': y => ''goodbye'' } include x works again, which may be even worse (poor consistency). Of course in that simple example you can just remove either duplicate declaration, but in real-world examples those declarations are likely to be in different classes, maybe in different modules. Even if the problem is known to the site maintainer, it''s not necessarily easy to ensure that those declarations are parsed in an order that will work. The problem is not the parametrized classes themselves, and certainly not the hiera integration, but rather the parametrized-style declarations. Indeed, it was true at least in 2.7 that parametrized-style declarations could cause you trouble for non-parametrized classes: class z { notify { ''z'': } } class { ''z'': } include ''z'' # kapow! As far as I have been able to determine -- and I''ve been looking -- Puppet 3 carries over 2.7''s biggest problems attending parametrized class declarations. It''s easy enough in Puppet 3 to just avoid using parametrized-style declarations (yay!), but if you''re going to avoid using them then where''s the value in modifying existing classes to support using them?> this deals with the dynamic scoping problem, deals with most of the > things I hate(d) about param classes and gives me magical abilities > to do overrides where and how I need them. >The alternative I would recommend to anyone is this: class x { $y = hiera(''y'', ''hello'') notify{$y: } } coupled with avoiding parametrized-style class declarations. It solves the dynamic scoping problem exactly as well as does the parametrized version does. It is slightly more verbose than the parametrized version, but more explicit about what''s happening. That''s what I gathered the OP''s classes looked like to begin with, since he said he was using the hiera functions. So I ask again, given classes structured similar to that, why would it be worth the investment in time and effort to convert them to parametrized classes?> > You can still if u wish use the new param classes style of including, > ENC etc can all supply data just like always. > > from a code share perspective this is a big win, simply using param > classes means your module is forwards and backwards compatible with > hiera or without hiera. >Ok, so there''s at least one fair consideration. If you are looking to write classes that are backwards-compatible with Puppet 2.[67] setups not augmented with hiera, then parametrized classes are a way to do it. They may even be the best way. I don''t think you do users any favors by doing so, however; I would prefer to just make my modules depend on hiera, and let that be a threshold issue for 2.x sites. Indeed, I personally look at it quite the other way around: hiera integration makes parametrized classes tolerable. It provides a good way forward for the many people who wrote and now rely on parametrized classes despite their shortcomings (which were more prominent before Puppet 3), and to me that seems by far its most important compatibility dimension. I would never dream of using parametrized classes in Puppet older than 3.0. Having in hand a class that loads its external data via hiera, and not personally being interested in encouraging anyone to use parametrized-style class declarations, I would have no inclination whatever to convert it to a substantially equivalent parametrized form. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/gp8--TwX6z8J. 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 Monday, October 15, 2012 7:35:30 AM UTC-7, jcbollinger wrote:> > > > On Friday, October 12, 2012 12:10:38 PM UTC-5, Ellison Marks wrote: >> >> Not to let this thread go to waste... >> >> Since I''m now trying to move away from the hiera functions themselves to >> the parameter style > > > > Why? The ability to achieve separation of data from code while avoiding > parametrized classes is one of the greatest advantages conferred by hiera. > Every parametrized-style class declaration (not definition) in your > manifests is a bug waiting to happen. And if you''re not going to use such > declarations, then why do you want to spend effort on converting your > classes to make it possible? > > > John > >Er, perhaps I wasn''t being clear, which is entirely possible. I don''t intend to use parametrized declarations(Right now I''m simply using hiera_include in the default node for everything and loving it). I do however, very much like the convenience of the new syntax. In addition, my use case for default values in the puppet backend that shipped with the class wasn''t terribly complex, so simply including a default value in the class itself serves my needs well. In my case, the new features are simply a more convenient way of doing what i was already doing(sans the array and hash functionality). -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/rLJp0Go7mw0J. 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 Monday, October 15, 2012 1:45:12 PM UTC-7, jcbollinger wrote:> > > Indeed, I have taken a second look, and a third, and maybe more. I love > the hiera integration with parametrized classes. It was a fabulous idea, > as it makes it reasonable and safe to use existing parametrized classes > (provided you use only ''include'' or ''require'' to declare them). > > Even with that, however, parametrized classes offer very little of value > over non-parametrized analogs that implement the same hiera-based external > data access. One could argue, perhaps, that there is a documentary > advantage in parametrization, but I think that''s poor justification for > introducing functional (so to speak) elements to any class. That''s what > comments are for. >But parameters expose that info to more than humans -- for example, you can use the resource_type REST endpoint today to get a list of all classes and their parameters and defaults. Not a lot is using that today, but I expect more and more things to start doing auto-discovery of parameters, since it''s a really machine-friendly way to find out what a class "wants." -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/g8Pq3vllaScJ. 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.
----- Original Message -----> From: "jcbollinger" <John.Bollinger@stJude.org> > To: puppet-users@googlegroups.com > Sent: Monday, October 15, 2012 9:45:12 PM > Subject: Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera > ><snip>> > Indeed, I personally look at it quite the other way around: hiera > integration makes parametrized classes tolerable. It provides a goodI agree, tolerable is the right word here, was not suggesting the integration now makes them totally usable. however with a simple consistent approach and style in your own modules you can work around some of the remaining issues. We knew dynamic scoping sucked yet most of us have come up with a way to write our modules so we don''t get bit by those issues by adopting a few simple rules and avoid some of the more problematic areas. Applying the same approach to param classes did at least get me to a place that I feel was better off than the older method - but yes, its a shame we even have to come up with a style for working around problems in something as key as class paramaterization. -- 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 Monday, October 15, 2012 4:32:28 PM UTC-5, Ellison Marks wrote:> > I don''t intend to use parametrized declarations(Right now I''m simply using > hiera_include in the default node for everything and loving it). I do > however, very much like the convenience of the new syntax. In addition, my > use case for default values in the puppet backend that shipped with the > class wasn''t terribly complex, so simply including a default value in the > class itself serves my needs well. > > In my case, the new features are simply a more convenient way of doing > what i was already doing(sans the array and hash functionality). > >I don''t see it, but that''s a question of style and personal preference. Other than the effort required to get from here to there, there is nothing inherently negative about your plan as you describe it. Please don''t take my comments as personal criticism. I truly am interested in whether there are advantages to class parametrization that may not be evident to me, but I used your comments mostly as a springboard for the discussion that now ensues. Regulars around here know that I am a longtime critic of Puppet''s parametrized class design. It is better in Puppet 3 -- a lot better, in fact -- but there are still some significant issues. I consider it a community service to publicize those issues, both to help people avoid tripping over them and to keep PL''s feet to the fire. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/3YOfOaxcwUkJ. 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 Monday, October 15, 2012 6:59:45 PM UTC-5, Nick Fagerlund wrote:> > > > On Monday, October 15, 2012 1:45:12 PM UTC-7, jcbollinger wrote: >> >> >> Indeed, I have taken a second look, and a third, and maybe more. I love >> the hiera integration with parametrized classes. It was a fabulous idea, >> as it makes it reasonable and safe to use existing parametrized classes >> (provided you use only ''include'' or ''require'' to declare them). >> >> Even with that, however, parametrized classes offer very little of value >> over non-parametrized analogs that implement the same hiera-based external >> data access. One could argue, perhaps, that there is a documentary >> advantage in parametrization, but I think that''s poor justification for >> introducing functional (so to speak) elements to any class. That''s what >> comments are for. >> > > But parameters expose that info to more than humans -- for example, you > can use the resource_type REST endpoint today to get a list of all classes > and their parameters and defaults. Not a lot is using that today, but I > expect more and more things to start doing auto-discovery of parameters, > since it''s a really machine-friendly way to find out what a class "wants." >That''s an interesting angle of which I was not aware. I''m not sure I see a use case beyond automatic documentation generation, however, and there are alternative approaches that could serve that particular purpose. Do you envision other specific uses? Also, have you considered that any explicit hiera lookups in the class body also represent machine-discoverable things that a class "wants"? So long as there is no plan to deprecate the hiera functions, any approach to identifying classes'' data dependencies that does not account for explicit lookups is incomplete. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/u5u9iR5s_8MJ. 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.
----- Original Message -----> From: "jcbollinger" <John.Bollinger@stJude.org> > To: puppet-users@googlegroups.com > Sent: Tuesday, October 16, 2012 3:11:55 PM > Subject: Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera<snip>>> But parameters expose that info to more than humans -- for example, >> you can use the resource_type REST endpoint today to get a list of >> all classes and their parameters and defaults. Not a lot is using >> that today, but I expect more and more things to start doing >> auto-discovery of parameters, since it''s a really machine-friendly >> way to find out what a class "wants." > > > That''s an interesting angle of which I was not aware. I''m not sure I > see a use case beyond automatic documentation generation, however, > and there are alternative approaches that could serve that > particular purpose. Do you envision other specific uses?web interfaces that prompts for the right info when someone adds a class to a machine. It would be great if you can set your email client to send plain text emails as per list guidelines. -- 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 Tuesday, October 16, 2012 3:23:14 AM UTC-5, R.I. Pienaar wrote:> > its a > shame we even have to come up with a style for working around problems > in something as key as class paramaterization. >I think it''s a shame that prevailing opinion holds class parametrization to be a key feature. There continue to be problems with it largely because it is conceptually inconsistent with Puppet''s model for classes (specifically, with their singleton nature). Because Puppet cannot accept inconsistent declarations of a class, Puppet DSL should not facilitate users writing such declarations into their manifests. Indeed, isn''t that much the same logic PL used in deciding to remove dynamic scoping? Here''s one solution: keep parametrized classes themselves, but deprecate and eventually remove the parametrized-class declaration syntax. That would leave class parameters as formalized declarations of external data used by classes, while removing the possibility of inconsistent class declarations. It would also pull back from the confusing effort to make classes appear to be resources when in fact they are not (for example, create_resources() won''t "create" classes). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/_jiSN1JwQvMJ. 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 Tuesday, October 16, 2012 9:16:43 AM UTC-5, R.I. Pienaar wrote:> > It would be great if you can set your email client to send plain text > emails as per list guidelines. >If I were using an e-mail client then I would be happy to do so, but I''m posting via Google''s web interface. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/eNDqDeSzLn8J. 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.
No worries. I''m enjoying the discussion. On Tuesday, October 16, 2012 7:01:47 AM UTC-7, jcbollinger wrote:> > > > On Monday, October 15, 2012 4:32:28 PM UTC-5, Ellison Marks wrote: >> >> I don''t intend to use parametrized declarations(Right now I''m simply >> using hiera_include in the default node for everything and loving it). I do >> however, very much like the convenience of the new syntax. In addition, my >> use case for default values in the puppet backend that shipped with the >> class wasn''t terribly complex, so simply including a default value in the >> class itself serves my needs well. >> >> In my case, the new features are simply a more convenient way of doing >> what i was already doing(sans the array and hash functionality). >> >> > I don''t see it, but that''s a question of style and personal preference. > Other than the effort required to get from here to there, there is nothing > inherently negative about your plan as you describe it. Please don''t take > my comments as personal criticism. > > I truly am interested in whether there are advantages to class > parametrization that may not be evident to me, but I used your comments > mostly as a springboard for the discussion that now ensues. Regulars > around here know that I am a longtime critic of Puppet''s parametrized class > design. It is better in Puppet 3 -- a lot better, in fact -- but there are > still some significant issues. I consider it a community service to > publicize those issues, both to help people avoid tripping over them and to > keep PL''s feet to the fire. > > > John > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/e23mEImUQ0oJ. 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 10/16/2012 04:34 PM, jcbollinger wrote:> Here''s one solution: keep parametrized classes themselves, but deprecate > and eventually remove the parametrized-class declaration syntax. That > would leave class parameters as formalized declarations of external data > used by classes, while removing the possibility of inconsistent class > declarations. It would also pull back from the confusing effort to make > classes appear to be resources when in fact they are not (for example, > create_resources() won''t "create" classes).I really like this solution. Great post jcbollinger - as always. Really enjoy reading your opinions and solutions. -- Jakov Sosic www.srce.unizg.hr -- 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.