hello, Till now hiera-puppet was the only way I know that allowed hiera data to be loaded from inside a module. The problem with this was that it was still subject to the site specific hierarchy which means a module author had a pretty hard time to store his data in a proper way in his module thus perpetuating the use of the params classes pattern. Now that Puppet 3 is out and it''s gem extensible I can finally try some ideas I had but put off implementing because it was too hard to install and distribute these extensions. I propose extending the module layout with a data/ directory that can go into each module and in this data directory would live a hiera config file (optionally) and module specific data: your_module ├── data │ ├── hiera.json │ └── osfamily │ ├── Debian.json │ └── RedHat.json └── manifests └── init.pp Here the data/hiera.json is optional and specifies a hierarchy that the module author chooses and is unique to the specific backend. The default contents would be this is the file is absent: {"hierarchy": ["osfamily/%{osfamily}", "common"]} But a module author can pick anything there, should even be able to rely on facts that is shipped with the module in its lib dir since that''ll get pluginsynced out before compile time: Now given the data files for Redhat: {"apache::package" : "httpd"} ...and Debian: {"apache::package" : "apache2"} And your main hiera site config being something like: :backends: - json - module_json You should be able to just write module code like this: class apache($package="apache") { package{$package: ensure => present} } If no data is specified in the site hiera backends then this will use the in-module hierarchy and data and just do the right thing on RedHat and Debian systems but as always the site can still override the data using hard coding, site specific data, ENCs etc. So the important thing here is the module author has control over the hierarchy that gets used when the data in his module gets loaded. The site can has its own hierarchy policy but this backend will only use the hierarchy that is recorded in the module by its author. If you want to play with this idea on your Puppet 3 install just do ''gem install hiera-module-json'' So I am looking for feedback from the community on this pattern, will it solve the problem of author-supplied module data better than we have today? I''ve heard this problem brought up quite a lot so keen to hear feedback. I''d imagine eventually a backend like this might be a hard-coded backend shipped with puppet and always there as the lowest priority backend below any that the site might specify in their site wide hiera config so everyone can rely on this being there and with the new lookup helpers this should also be backward compatible - old Puppets or ones who specifically disable the hiera indirector will just not have data and will need to supply it some other way. --- 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.
This is -exactly- what I''ve wanted in my modules since I heard of Hiera and I am strongly supporting this proposal. I''ll be experimenting with your gem. I can''t give this enough support as this is what I wanted since Hiera began. It''ll make supporting multiple distros/operating systems much easier for modules on the forge. On Sun, Sep 30, 2012 at 5:37 AM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > Till now hiera-puppet was the only way I know that allowed hiera data to > be loaded from inside a module. > > The problem with this was that it was still subject to the site specific > hierarchy which means a module author had a pretty hard time to store > his data in a proper way in his module thus perpetuating the use of the > params classes pattern. > > Now that Puppet 3 is out and it''s gem extensible I can finally try some > ideas I had but put off implementing because it was too hard to install > and distribute these extensions. > > I propose extending the module layout with a data/ directory that can go > into each module and in this data directory would live a hiera config > file (optionally) and module specific data: > > your_module > ├── data > │ ├── hiera.json > │ └── osfamily > │ ├── Debian.json > │ └── RedHat.json > └── manifests > └── init.pp > > Here the data/hiera.json is optional and specifies a hierarchy that the > module author chooses and is unique to the specific backend. > > The default contents would be this is the file is absent: > > {"hierarchy": ["osfamily/%{osfamily}", "common"]} > > But a module author can pick anything there, should even be able to rely > on facts that is shipped with the module in its lib dir since that''ll > get pluginsynced out before compile time: > > Now given the data files for Redhat: > > {"apache::package" : "httpd"} > > ...and Debian: > > {"apache::package" : "apache2"} > > And your main hiera site config being something like: > > :backends: - json > - module_json > > You should be able to just write module code like this: > > class apache($package="apache") { > package{$package: ensure => present} > } > > If no data is specified in the site hiera backends then this will use > the in-module hierarchy and data and just do the right thing on RedHat > and Debian systems but as always the site can still override the data > using hard coding, site specific data, ENCs etc. > > So the important thing here is the module author has control over the > hierarchy that gets used when the data in his module gets loaded. The > site can has its own hierarchy policy but this backend will only use > the hierarchy that is recorded in the module by its author. > > If you want to play with this idea on your Puppet 3 install just do ''gem > install hiera-module-json'' > > So I am looking for feedback from the community on this pattern, will it > solve the problem of author-supplied module data better than we have > today? I''ve heard this problem brought up quite a lot so keen to hear > feedback. > > I''d imagine eventually a backend like this might be a hard-coded backend > shipped with puppet and always there as the lowest priority backend > below any that the site might specify in their site wide hiera config so > everyone can rely on this being there and with the new lookup helpers > this should also be backward compatible - old Puppets or ones who > specifically disable the hiera indirector will just not have data and > will need to supply it some other way. > > --- > 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. >-- 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 Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote:> > > I propose extending the module layout with a data/ directory that can go > into each module and in this data directory would live a hiera config > file (optionally) and module specific data: > >That sounds really attractive, but I''m not in a position to test it right now. Also (separately), I hope you have more distribution plans than just gem, because gem is a complete non-starter for me. 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/-/_shrRB45IfkJ. 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 1, 2012 2:15:22 PM > Subject: [Puppet Users] Re: in-module data with hiera > > > > On Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote: > > > I propose extending the module layout with a data/ directory that can > go > into each module and in this data directory would live a hiera config > file (optionally) and module specific data: > > > That sounds really attractive, but I''m not in a position to test it > right now. Also (separately), I hope you have more distribution > plans than just gem, because gem is a complete non-starter for me.personally the end goal would be to just merge it with hiera or puppet. -- 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.
I am looking forward to testing this out in my test lab, as this is something I have been looking for for quite a while. (That, and a good deployment mechanism, while waiting for Razor to mature.) Thank you for putting this out for testing/reflection. -- Patrick Roberts On Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote:> > hello, > > Till now hiera-puppet was the only way I know that allowed hiera data to > be loaded from inside a module. > > The problem with this was that it was still subject to the site specific > hierarchy which means a module author had a pretty hard time to store > his data in a proper way in his module thus perpetuating the use of the > params classes pattern. > > Now that Puppet 3 is out and it''s gem extensible I can finally try some > ideas I had but put off implementing because it was too hard to install > and distribute these extensions. > > I propose extending the module layout with a data/ directory that can go > into each module and in this data directory would live a hiera config > file (optionally) and module specific data: > > your_module > ├── data > │ ├── hiera.json > │ └── osfamily > │ ├── Debian.json > │ └── RedHat.json > └── manifests > └── init.pp > > Here the data/hiera.json is optional and specifies a hierarchy that the > module author chooses and is unique to the specific backend. > > The default contents would be this is the file is absent: > > {"hierarchy": ["osfamily/%{osfamily}", "common"]} > > But a module author can pick anything there, should even be able to rely > on facts that is shipped with the module in its lib dir since that''ll > get pluginsynced out before compile time: > > Now given the data files for Redhat: > > {"apache::package" : "httpd"} > > ...and Debian: > > {"apache::package" : "apache2"} > > And your main hiera site config being something like: > > :backends: - json > - module_json > > You should be able to just write module code like this: > > class apache($package="apache") { > package{$package: ensure => present} > } > > If no data is specified in the site hiera backends then this will use > the in-module hierarchy and data and just do the right thing on RedHat > and Debian systems but as always the site can still override the data > using hard coding, site specific data, ENCs etc. > > So the important thing here is the module author has control over the > hierarchy that gets used when the data in his module gets loaded. The > site can has its own hierarchy policy but this backend will only use > the hierarchy that is recorded in the module by its author. > > If you want to play with this idea on your Puppet 3 install just do ''gem > install hiera-module-json'' > > So I am looking for feedback from the community on this pattern, will it > solve the problem of author-supplied module data better than we have > today? I''ve heard this problem brought up quite a lot so keen to hear > feedback. > > I''d imagine eventually a backend like this might be a hard-coded backend > shipped with puppet and always there as the lowest priority backend > below any that the site might specify in their site wide hiera config so > everyone can rely on this being there and with the new lookup helpers > this should also be backward compatible - old Puppets or ones who > specifically disable the hiera indirector will just not have data and > will need to supply it some other way. > > --- > R.I.Pienaar >-- 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/-/J0XkwA_MAQUJ. 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/30/2012 05:01 PM, Ashley Penney wrote:> This is -exactly- what I''ve wanted in my modules since I heard of > Hiera and I am strongly supporting this proposal. I''ll be > experimenting with your gem. I can''t give this enough support as > this is what I wanted since Hiera began. It''ll make supporting > multiple distros/operating systems much easier for modules on the > forge.+1. Nice idea! ~pete -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBqkw0ACgkQbwltcAfKi398AACbBbGxDdWcpHBySXCSUY++yydb D4cAn318SEhFYPqjyKymaH45vKYUzxvi =3lWJ -----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.
Hi, I''m catching up on a backlog of tickets and wondered if any of the folks who''d expressed interest in this change have had the opportunity to try it out from RI''s branch: https://github.com/ripienaar/puppet/tree/feature/master/16856 If you have, can you please put your feedback in the associated redmine ticket: http://projects.puppetlabs.com/issues/16856 Seems like a pretty excellent feature but I don''t have a production use-case I can try it against so there might be unexpected consequences. It''d be great to hear from you. -=Eric On Tuesday, October 2, 2012 12:09:25 AM UTC-7, Peter Meier wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 09/30/2012 05:01 PM, Ashley Penney wrote: > > This is -exactly- what I''ve wanted in my modules since I heard of > > Hiera and I am strongly supporting this proposal. I''ll be > > experimenting with your gem. I can''t give this enough support as > > this is what I wanted since Hiera began. It''ll make supporting > > multiple distros/operating systems much easier for modules on the > > forge. > > +1. Nice idea! > > ~pete > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBqkw0ACgkQbwltcAfKi398AACbBbGxDdWcpHBySXCSUY++yydb > D4cAn318SEhFYPqjyKymaH45vKYUzxvi > =3lWJ > -----END PGP SIGNATURE----- >-- 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/-/zcUSd4em9oUJ. 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, I have tested the branch https://github.com/ripienaar/puppet/tree/feature/master/16856. The basic functionality of the data in the module seems to work as desired. Just a few things - If only using the param auto-lookup not having a hiera.yaml file is ok - if there is NO hiera.yaml config file, calling hiera() causes an error "Error 400 on SERVER: undefined method `include?'' for nil:NilClass" - Having an empty hiera.yaml is ok when using a hiera(call) - The lookup in the moduledata does not happen if only using the auto-lookup of the class params, unless you manually specify "module_data" as hiera backend. - When using the hiera() call, specifying "module_data" as hiera backend is not needed. I hope this helps. Regards, Stefan Goethals. On Friday, November 2, 2012 11:06:34 PM UTC+1, Eric Sorenson wrote:> > Hi, I''m catching up on a backlog of tickets and wondered if any of the > folks who''d expressed interest in this change have had the opportunity to > try it out from RI''s branch: > > https://github.com/ripienaar/puppet/tree/feature/master/16856 > > If you have, can you please put your feedback in the associated redmine > ticket: > > http://projects.puppetlabs.com/issues/16856 > > Seems like a pretty excellent feature but I don''t have a production > use-case I can try it against so there might be unexpected consequences. > It''d be great to hear from you. > > -=Eric > > On Tuesday, October 2, 2012 12:09:25 AM UTC-7, Peter Meier wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 09/30/2012 05:01 PM, Ashley Penney wrote: >> > This is -exactly- what I''ve wanted in my modules since I heard of >> > Hiera and I am strongly supporting this proposal. I''ll be >> > experimenting with your gem. I can''t give this enough support as >> > this is what I wanted since Hiera began. It''ll make supporting >> > multiple distros/operating systems much easier for modules on the >> > forge. >> >> +1. Nice idea! >> >> ~pete >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >> >> iEYEARECAAYFAlBqkw0ACgkQbwltcAfKi398AACbBbGxDdWcpHBySXCSUY++yydb >> D4cAn318SEhFYPqjyKymaH45vKYUzxvi >> =3lWJ >> -----END PGP SIGNATURE----- >> >-- 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/-/CuP12XiaWTQJ. 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: "ZipKid" <zipkid.com@gmail.com> > To: puppet-users@googlegroups.com > Sent: Tuesday, December 4, 2012 11:10:13 PM > Subject: Re: [Puppet Users] in-module data with hiera > > Hello, > > I have tested the branch > https://github.com/ripienaar/puppet/tree/feature/master/16856. > The basic functionality of the data in the module seems to work as > desired. > Just a few things > - If only using the param auto-lookup not having a hiera.yaml file is > ok > - if there is NO hiera.yaml config file, calling hiera() causes an > error "Error 400 on SERVER: undefined method `include?'' for > nil:NilClass" > - Having an empty hiera.yaml is ok when using a hiera(call) > - The lookup in the moduledata does not happen if only using the > auto-lookup of the class params, unless you manually specify > "module_data" as hiera backend. > - When using the hiera() call, specifying "module_data" as hiera > backend is not needed. > > I hope this helps.awesome, thanks a lot for taking the time to test it, I''ll incorporate this feedback in a few weeks. do you think the basic approach will improve your workflow and lead to easier to share modules? -- 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 12/4/12 2:38 PM, R.I.Pienaar wrote:> > > ----- Original Message ----- >> From: "ZipKid" <zipkid.com@gmail.com> >> To: puppet-users@googlegroups.com >> Sent: Tuesday, December 4, 2012 11:10:13 PM >> Subject: Re: [Puppet Users] in-module data with hiera >> >> Hello, >> >> I have tested the branch >> https://github.com/ripienaar/puppet/tree/feature/master/16856. >> The basic functionality of the data in the module seems to work as >> desired. >> Just a few things >> - If only using the param auto-lookup not having a hiera.yaml file is >> ok >> - if there is NO hiera.yaml config file, calling hiera() causes an >> error "Error 400 on SERVER: undefined method `include?'' for >> nil:NilClass" >> - Having an empty hiera.yaml is ok when using a hiera(call) >> - The lookup in the moduledata does not happen if only using the >> auto-lookup of the class params, unless you manually specify >> "module_data" as hiera backend. >> - When using the hiera() call, specifying "module_data" as hiera >> backend is not needed. >> >> I hope this helps. > > awesome, thanks a lot for taking the time to test it, I''ll incorporate > this feedback in a few weeks. > > do you think the basic approach will improve your workflow and lead > to easier to share modules? >Absolutely leads to modules that are easier to share. This functionality is critical for releasing modules that work on different system types without writing a bunch of conditional logic that replicates hiera. Outstanding work. -g -- Garrett Honeycutt 206.414.8658 http://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.
This functionality is a fantastic improvement over the, already useful, data.pp functionality of the hiera_puppet backend. For me this means i can create modules with defaults without limiting the module to the specific defaults i can think of and have them easily over-ridable without modifying the module itself. Great work! Thanks, Stefan Goethals. ps. Just let me know if you need more testing to be done. On Tue, Dec 4, 2012 at 11:34 PM, Garrett Honeycutt <garrett@puppetlabs.com>wrote:> On 12/4/12 2:38 PM, R.I.Pienaar wrote: > > > > > > ----- Original Message ----- > >> From: "ZipKid" <zipkid.com@gmail.com> > >> To: puppet-users@googlegroups.com > >> Sent: Tuesday, December 4, 2012 11:10:13 PM > >> Subject: Re: [Puppet Users] in-module data with hiera > >> > >> Hello, > >> > >> I have tested the branch > >> https://github.com/ripienaar/puppet/tree/feature/master/16856. > >> The basic functionality of the data in the module seems to work as > >> desired. > >> Just a few things > >> - If only using the param auto-lookup not having a hiera.yaml file is > >> ok > >> - if there is NO hiera.yaml config file, calling hiera() causes an > >> error "Error 400 on SERVER: undefined method `include?'' for > >> nil:NilClass" > >> - Having an empty hiera.yaml is ok when using a hiera(call) > >> - The lookup in the moduledata does not happen if only using the > >> auto-lookup of the class params, unless you manually specify > >> "module_data" as hiera backend. > >> - When using the hiera() call, specifying "module_data" as hiera > >> backend is not needed. > >> > >> I hope this helps. > > > > awesome, thanks a lot for taking the time to test it, I''ll incorporate > > this feedback in a few weeks. > > > > do you think the basic approach will improve your workflow and lead > > to easier to share modules? > > > > Absolutely leads to modules that are easier to share. This functionality > is critical for releasing modules that work on different system types > without writing a bunch of conditional logic that replicates hiera. > Outstanding work. > > -g > > -- > Garrett Honeycutt > > 206.414.8658 > http://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. > >-- 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, Maybe i should be clearer and specify that the hiera.yaml i mention in my comment is /etc/puppet/hiera.yaml and not the <module>/data/hiera.yaml version. That last one indeed only requires a hierarchy setting for things to work. Stefan. On Tuesday, December 4, 2012 10:38:46 PM UTC+1, R.I. Pienaar wrote:> > > > ----- Original Message ----- > > From: "ZipKid" <zipki...@gmail.com <javascript:>> > > To: puppet...@googlegroups.com <javascript:> > > Sent: Tuesday, December 4, 2012 11:10:13 PM > > Subject: Re: [Puppet Users] in-module data with hiera > > > > Hello, > > > > I have tested the branch > > https://github.com/ripienaar/puppet/tree/feature/master/16856. > > The basic functionality of the data in the module seems to work as > > desired. > > Just a few things > > - If only using the param auto-lookup not having a hiera.yaml file is > > ok > > - if there is NO hiera.yaml config file, calling hiera() causes an > > error "Error 400 on SERVER: undefined method `include?'' for > > nil:NilClass" > > - Having an empty hiera.yaml is ok when using a hiera(call) > > - The lookup in the moduledata does not happen if only using the > > auto-lookup of the class params, unless you manually specify > > "module_data" as hiera backend. > > - When using the hiera() call, specifying "module_data" as hiera > > backend is not needed. > > > > I hope this helps. > > awesome, thanks a lot for taking the time to test it, I''ll incorporate > this feedback in a few weeks. > > do you think the basic approach will improve your workflow and lead > to easier to share modules? >-- 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/-/lyTpSrtwgRsJ. 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 Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote:> > > I propose extending the module layout with a data/ directory that can go > into each module and in this data directory would live a hiera config > file (optionally) and module specific data: >[...]> Here the data/hiera.json is optional and specifies a hierarchy that the > module author chooses and is unique to the specific backend. > > The default contents would be this is the file is absent: > > {"hierarchy": ["osfamily/%{osfamily}", "common"]} > >Having thought about this some more, I still think it''s a great idea, but giving special support to ''osfamily'' in the default in-module hierarchy seems a bit smelly to me. I don''t doubt that categorizing data by osfamily would be a frequent practice, but making a special case for it straight off the bat doesn''t feel right to me. Certainly the default osfamily support wouldn''t be directly harmful to users, inasmuch as they can easily ignore or override it, but I nevertheless urge you to keep it simple. The backlog of open tickets attests to the fact that PL doesn''t really have enough engineering capacity as it is. 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/-/Lhdp3eelUZEJ. 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 Dec 2012, at 16:43, jcbollinger <John.Bollinger@stJude.org> wrote:> > > On Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote: >> >> >> I propose extending the module layout with a data/ directory that can go >> into each module and in this data directory would live a hiera config >> file (optionally) and module specific data: > [...] >> Here the data/hiera.json is optional and specifies a hierarchy that the >> module author chooses and is unique to the specific backend. >> >> The default contents would be this is the file is absent: >> >> {"hierarchy": ["osfamily/%{osfamily}", "common"]} > > Having thought about this some more, I still think it''s a great idea, but giving special support to ''osfamily'' in the default in-module hierarchy seems a bit smelly to me. I don''t doubt that categorizing data by osfamily would be a frequent practice, but making a special case for it straight off the bat doesn''t feel right to me. > > Certainly the default osfamily support wouldn''t be directly harmful to users, inasmuch as they can easily ignore or override it, but I nevertheless urge you to keep it simple.Do you have an alternative default hierarchy you''d prefer?> The backlog of open tickets attests to the fact that PL doesn''t really have enough engineering capacity as it is.Not sure what the relevance is here..> > > 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/-/Lhdp3eelUZEJ. > 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.
Not having any problem with osfamily i agree with John. A default to ''common'' would suffice i believe. Stefan. On Wed, Dec 5, 2012 at 3:43 PM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Sunday, September 30, 2012 4:37:29 AM UTC-5, R.I. Pienaar wrote: > >> >> I propose extending the module layout with a data/ directory that can go >> into each module and in this data directory would live a hiera config >> file (optionally) and module specific data: >> > [...] > >> Here the data/hiera.json is optional and specifies a hierarchy that the >> module author chooses and is unique to the specific backend. >> >> The default contents would be this is the file is absent: >> >> {"hierarchy": ["osfamily/%{osfamily}", "common"]} >> >> > Having thought about this some more, I still think it''s a great idea, but > giving special support to ''osfamily'' in the default in-module hierarchy > seems a bit smelly to me. I don''t doubt that categorizing data by osfamily > would be a frequent practice, but making a special case for it straight off > the bat doesn''t feel right to me. > > Certainly the default osfamily support wouldn''t be directly harmful to > users, inasmuch as they can easily ignore or override it, but I > nevertheless urge you to keep it simple. The backlog of open tickets > attests to the fact that PL doesn''t really have enough engineering capacity > as it is. > > > 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/-/Lhdp3eelUZEJ. > > 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.
On Wednesday, December 5, 2012 8:47:32 AM UTC-6, R.I. Pienaar wrote:> > > On 5 Dec 2012, at 16:43, jcbollinger <John.Bo...@stJude.org <javascript:>> > wrote: > > > Certainly the default osfamily support wouldn''t be directly harmful to > users, inasmuch as they can easily ignore or override it, but I > nevertheless urge you to keep it simple. > > > Do you have an alternative default hierarchy you''d prefer? >As Stefan said, just "common" would be fine, or some similar single, fixed-name file. The backlog of open tickets attests to the fact that PL doesn''t really have> enough engineering capacity as it is. > > > Not sure what the relevance is here.. > >I probably shouldn''t even have brought it up. My apologies. My point, however, was that new features are not free, even after they are written -- every line of code in Puppet has an ongoing maintenance cost. 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/-/aAqr--P3K9EJ. 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 12/05/2012 09:45 PM, Stefan Goethals wrote:> Not having any problem with osfamily i agree with John. > A default to ''common'' would suffice i believe.Agree, common is more than enough as default. -- 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.
----- Original Message -----> From: "Jakov Sosic" <jsosic@srce.hr> > To: puppet-users@googlegroups.com > Sent: Wednesday, December 5, 2012 11:15:57 PM > Subject: Re: [Puppet Users] Re: in-module data with hiera > > On 12/05/2012 09:45 PM, Stefan Goethals wrote: > > Not having any problem with osfamily i agree with John. > > A default to ''common'' would suffice i believe. > > Agree, common is more than enough as default.I''ve updated my pull request[1] with this feedback and the bugs Zipkid reported, any testers and more feedback welcome [1] https://github.com/puppetlabs/puppet/pull/1217 -- 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.
The good news: Without /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml = OK! Without /etc/puppet/hiera.yaml but with empty <module>/data/hiera.yaml = OK! Without /etc/puppet/hiera.yaml but with <module>/data/hiera.yaml with a hierarchy = OK! With empty /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml = OK! With /etc/puppet/hiera.yaml with a hierarch & Without <module>/data/hiera.yaml = OK! With /etc/puppet/hiera.yaml with a hierarch & with empty <module>/data/hiera.yaml = OK! With /etc/puppet/hiera.yaml with a hierarch & with <module>/data/hiera.yaml with a hierarchy = OK! Lookups via hiera() in a define also seem to work well! Comment: The default file looked up in the in-module data backend is ''default.yaml'', not ''common.yaml'' and that is different from the yaml backend so it is somewhat confusing. It is also not what was ''agreed'' in this thread. All this is based on a simple test with a module with one class and one define so it is not very in-depth but the results are clear and as expected.... Thank you Volcane ! We''re getting there. :-) Regards, Stefan - Zipkid - Goethals. On 12 Dec 2012, at 17:05, R.I.Pienaar <rip@devco.net> wrote:> > > ----- Original Message ----- >> From: "Jakov Sosic" <jsosic@srce.hr> >> To: puppet-users@googlegroups.com >> Sent: Wednesday, December 5, 2012 11:15:57 PM >> Subject: Re: [Puppet Users] Re: in-module data with hiera >> >> On 12/05/2012 09:45 PM, Stefan Goethals wrote: >>> Not having any problem with osfamily i agree with John. >>> A default to ''common'' would suffice i believe. >> >> Agree, common is more than enough as default. > > I''ve updated my pull request[1] with this feedback and the bugs > Zipkid reported, any testers and more feedback welcome > > [1] https://github.com/puppetlabs/puppet/pull/1217 > > -- > 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. >-- 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.
----- Original Message -----> From: "Stefan Goethals" <zipkid.com@gmail.com> > To: puppet-users@googlegroups.com > Sent: Thursday, December 13, 2012 5:37:30 PM > Subject: Re: [Puppet Users] in-module data with hiera > > > The good news: > > Without /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml > OK! > Without /etc/puppet/hiera.yaml but with empty > <module>/data/hiera.yaml = OK! > Without /etc/puppet/hiera.yaml but with <module>/data/hiera.yaml with > a hierarchy = OK! > > With empty /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml > = OK! > With /etc/puppet/hiera.yaml with a hierarch & Without > <module>/data/hiera.yaml = OK! > With /etc/puppet/hiera.yaml with a hierarch & with empty > <module>/data/hiera.yaml = OK! > With /etc/puppet/hiera.yaml with a hierarch & with > <module>/data/hiera.yaml with a hierarchy = OK! > > Lookups via hiera() in a define also seem to work well! > > > Comment: > > The default file looked up in the in-module data backend is > ''default.yaml'', not ''common.yaml'' and > that is different from the yaml backend so it is somewhat confusing. > It is also not what was ''agreed'' in this thread.yes good, actually common is a default set by hiera, this should be consistant here too, I agree will fix. https://github.com/puppetlabs/hiera/blob/master/lib/hiera/config.rb#L13-14> All this is based on a simple test with a module with one class and > one define so it is not very in-depth > but the results are clear and as expected.... > > Thank you Volcane ! We''re getting there. :-)no thank you, community members testing this stuff is super awesome and help us a lot. -- 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.
----- Original Message -----> From: "R.I.Pienaar" <rip@devco.net> > To: puppet-users@googlegroups.com > Sent: Thursday, December 13, 2012 5:58:42 PM > Subject: Re: [Puppet Users] in-module data with hiera > > > > ----- Original Message ----- > > From: "Stefan Goethals" <zipkid.com@gmail.com> > > To: puppet-users@googlegroups.com > > Sent: Thursday, December 13, 2012 5:37:30 PM > > Subject: Re: [Puppet Users] in-module data with hiera > > > > > > The good news: > > > > Without /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml > > OK! > > Without /etc/puppet/hiera.yaml but with empty > > <module>/data/hiera.yaml = OK! > > Without /etc/puppet/hiera.yaml but with <module>/data/hiera.yaml > > with > > a hierarchy = OK! > > > > With empty /etc/puppet/hiera.yaml & Without > > <module>/data/hiera.yaml > > = OK! > > With /etc/puppet/hiera.yaml with a hierarch & Without > > <module>/data/hiera.yaml = OK! > > With /etc/puppet/hiera.yaml with a hierarch & with empty > > <module>/data/hiera.yaml = OK! > > With /etc/puppet/hiera.yaml with a hierarch & with > > <module>/data/hiera.yaml with a hierarchy = OK! > > > > Lookups via hiera() in a define also seem to work well! > > > > > > Comment: > > > > The default file looked up in the in-module data backend is > > ''default.yaml'', not ''common.yaml'' and > > that is different from the yaml backend so it is somewhat > > confusing. > > It is also not what was ''agreed'' in this thread. > > yes good, actually common is a default set by hiera, this should be > consistant > here too, I agree will fix. > > https://github.com/puppetlabs/hiera/blob/master/lib/hiera/config.rb#L13-14yay, confused myself - this is of course in the backend too, doh. I updated the pull with this fix, thanks again. -- 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.
If anyone is interested, here is the puppet env i used to test this. https://github.com/zipkid/puppet3-hiera_data_in_module Regards, Stefan - Zipkid - Goethals. On Thu, Dec 13, 2012 at 9:59 PM, R.I.Pienaar <rip@devco.net> wrote:> > > ----- Original Message ----- > > From: "R.I.Pienaar" <rip@devco.net> > > To: puppet-users@googlegroups.com > > Sent: Thursday, December 13, 2012 5:58:42 PM > > Subject: Re: [Puppet Users] in-module data with hiera > > > > > > > > ----- Original Message ----- > > > From: "Stefan Goethals" <zipkid.com@gmail.com> > > > To: puppet-users@googlegroups.com > > > Sent: Thursday, December 13, 2012 5:37:30 PM > > > Subject: Re: [Puppet Users] in-module data with hiera > > > > > > > > > The good news: > > > > > > Without /etc/puppet/hiera.yaml & Without <module>/data/hiera.yaml > > > OK! > > > Without /etc/puppet/hiera.yaml but with empty > > > <module>/data/hiera.yaml = OK! > > > Without /etc/puppet/hiera.yaml but with <module>/data/hiera.yaml > > > with > > > a hierarchy = OK! > > > > > > With empty /etc/puppet/hiera.yaml & Without > > > <module>/data/hiera.yaml > > > = OK! > > > With /etc/puppet/hiera.yaml with a hierarch & Without > > > <module>/data/hiera.yaml = OK! > > > With /etc/puppet/hiera.yaml with a hierarch & with empty > > > <module>/data/hiera.yaml = OK! > > > With /etc/puppet/hiera.yaml with a hierarch & with > > > <module>/data/hiera.yaml with a hierarchy = OK! > > > > > > Lookups via hiera() in a define also seem to work well! > > > > > > > > > Comment: > > > > > > The default file looked up in the in-module data backend is > > > ''default.yaml'', not ''common.yaml'' and > > > that is different from the yaml backend so it is somewhat > > > confusing. > > > It is also not what was ''agreed'' in this thread. > > > > yes good, actually common is a default set by hiera, this should be > > consistant > > here too, I agree will fix. > > > > > https://github.com/puppetlabs/hiera/blob/master/lib/hiera/config.rb#L13-14 > > yay, confused myself - this is of course in the backend too, doh. > > I updated the pull with this fix, thanks again. > > -- > 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. > >-- 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, What is still needed to get this issue ''moving''? I have 2 customers where i have to start a new Puppet environment starting in January 2013 and i would really like to be able to use this functionality for those. Regards, Stefan - Zipkid - Goethals. -- 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/-/qpmxRhRUIhsJ. 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.