Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
- Original Message - From: jcbollinger john.bollin...@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 good I 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
- Original Message - From: jcbollinger john.bollin...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[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? 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
- Original Message -
From: jcbollinger john.bollin...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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
[Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[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? -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
- Original Message - From: Ellison Marks gty...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 3.0.0 and Hiera
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=2shva=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 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#hieraconfighttp://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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet 3.0.0 and Hiera
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
