I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn''t
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:
1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?
2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.
I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:
class profiles::oneofmyprofiles {
include myparameterizedclass
}
I would like to have a hiera.yaml like so:
---
:backends:
- yaml
:hierarchy:
- nodes/%{::hostname}
- profiles/%{class_name}
- common
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
Am I just completely off-base?
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Will this help? http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables -- Brian Lalor blalor@bravo5.org On Feb 13, 2013, at 6:17 PM, Chad Huneycutt <chad.huneycutt@gmail.com> wrote:> I have been following the various blog posts about the roles and > profiles pattern for classifying hosts, and I like it. It doesn''t > provide a perfect fit for our infrastructure, but it is much better > than the ad-hoc classification we do now. I have a couple of > questions for those that use it, though: > > 1. Where are you putting your role classes and profile classes? A > role module and a profile module makes sense to me, but it seems like > something more tightly integrated with the Puppet DSL might be nice? > > 2. Assuming you have roles and profiles in modules, at what point do > you specify the parameters to your modules? I am particularly > interested in the answer to this question with regards to hiera. I > find that I want to add roles and profiles to the hiera hierarchy, and > I cannot come up with a way to do it. > > I think if hiera supported lookup by the class containing the hiera > call, I could achieve what I want. For instance: > > class profiles::oneofmyprofiles { > include myparameterizedclass > } > > I would like to have a hiera.yaml like so: > > --- > :backends: > - yaml > :hierarchy: > - nodes/%{::hostname} > - profiles/%{class_name} > - common > :yaml: > :datadir: /etc/puppet/environments/%{environment}/data > > > Am I just completely off-base? > > -- > Chad M. Huneycutt > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Hi there, I was going to ask exact same questions too. I am also interested in how people solve these problems. On Wednesday, 13 February 2013 23:17:40 UTC, Chad Huneycutt wrote:> > I have been following the various blog posts about the roles and > profiles pattern for classifying hosts, and I like it. It doesn''t > provide a perfect fit for our infrastructure, but it is much better > than the ad-hoc classification we do now. I have a couple of > questions for those that use it, though: > > 1. Where are you putting your role classes and profile classes? A > role module and a profile module makes sense to me, but it seems like > something more tightly integrated with the Puppet DSL might be nice? > > 2. Assuming you have roles and profiles in modules, at what point do > you specify the parameters to your modules? I am particularly > interested in the answer to this question with regards to hiera. I > find that I want to add roles and profiles to the hiera hierarchy, and > I cannot come up with a way to do it. > > I think if hiera supported lookup by the class containing the hiera > call, I could achieve what I want. For instance: > > class profiles::oneofmyprofiles { > include myparameterizedclass > } > > I would like to have a hiera.yaml like so: > > --- > :backends: > - yaml > :hierarchy: > - nodes/%{::hostname} > - profiles/%{class_name} > - common > :yaml: > :datadir: /etc/puppet/environments/%{environment}/data > > > Am I just completely off-base? > > -- > Chad M. Huneycutt >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, February 13, 2013 5:17:40 PM UTC-6, Chad Huneycutt wrote:> > I would like to have a hiera.yaml like so: > > --- > :backends: > - yaml > :hierarchy: > - nodes/%{::hostname} > - profiles/%{class_name} > - common > :yaml: > :datadir: /etc/puppet/environments/%{environment}/data > > > Am I just completely off-base? > >No, but it''s spelled %{calling_class}. There is also %{calling_module}. Do be aware of http://projects.puppetlabs.com/issues/14985, however. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
It is my understanding that the calling_* variables are only available
to the puppet backend. At least they do not work for me.
%{module_name}, on the other hand, works as I expect it to with the
yaml backend.
On Thu, Feb 14, 2013 at 9:47 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:>
>
> On Wednesday, February 13, 2013 5:17:40 PM UTC-6, Chad Huneycutt wrote:
>>
>> I would like to have a hiera.yaml like so:
>>
>> ---
>> :backends:
>> - yaml
>> :hierarchy:
>> - nodes/%{::hostname}
>> - profiles/%{class_name}
>> - common
>> :yaml:
>> :datadir: /etc/puppet/environments/%{environment}/data
>>
>>
>> Am I just completely off-base?
>>
>
> No, but it''s spelled %{calling_class}. There is also
%{calling_module}. Do
> be aware of http://projects.puppetlabs.com/issues/14985, however.
>
>
> John
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Unfortunately not. I am already using %{module_name}, and it works
fine. But for what I am suggesting to work, I need to know the exact
class where the hiera call is.
- Chad
On Wed, Feb 13, 2013 at 7:49 PM, Brian Lalor <blalor@bravo5.org>
wrote:> Will this help?
>
http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables
>
> --
> Brian Lalor
> blalor@bravo5.org
>
> On Feb 13, 2013, at 6:17 PM, Chad Huneycutt
<chad.huneycutt@gmail.com>
> wrote:
>
> I have been following the various blog posts about the roles and
> profiles pattern for classifying hosts, and I like it. It doesn''t
> provide a perfect fit for our infrastructure, but it is much better
> than the ad-hoc classification we do now. I have a couple of
> questions for those that use it, though:
>
> 1. Where are you putting your role classes and profile classes? A
> role module and a profile module makes sense to me, but it seems like
> something more tightly integrated with the Puppet DSL might be nice?
>
> 2. Assuming you have roles and profiles in modules, at what point do
> you specify the parameters to your modules? I am particularly
> interested in the answer to this question with regards to hiera. I
> find that I want to add roles and profiles to the hiera hierarchy, and
> I cannot come up with a way to do it.
>
> I think if hiera supported lookup by the class containing the hiera
> call, I could achieve what I want. For instance:
>
> class profiles::oneofmyprofiles {
> include myparameterizedclass
> }
>
> I would like to have a hiera.yaml like so:
>
> ---
> :backends:
> - yaml
> :hierarchy:
> - nodes/%{::hostname}
> - profiles/%{class_name}
> - common
> :yaml:
> :datadir: /etc/puppet/environments/%{environment}/data
>
>
> Am I just completely off-base?
>
> --
> Chad M. Huneycutt
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
On Thursday, February 14, 2013 12:08:17 PM UTC-6, Chad Huneycutt wrote:> > It is my understanding that the calling_* variables are only available > to the puppet backend. At least they do not work for me. > %{module_name}, on the other hand, works as I expect it to with the > yaml backend. > >I can''t speak to whether or why these currently work for you, but they are certainly not targeted specifically at the Puppet back end. They are mostly intended for use in your hiera configuration file (hiera.yaml), which is independent of any particular back end (since it''s where you define which one(s) to use). It''s precisely the use case you described. With that said, it looks like at least one other bug has been filed against this functionality in Puppet 3, so perhaps you''re running up against that. In any case, I still say no, you''re not off-base: what you''re asking for is supposed to already work. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Thanks, John. I think you are right that puppet should support it, but I am pretty sure it does not. I chatted with RI, and it seems that the classname is not "exposed", so when the puppet backend does the lookup, it figures out the classname and sets the ''calling_class'' variable before it interprets the hierarchy. I am going to try to hack the same thing into the yaml backend, as well as file a bug (or +1 one) about it. - Chad On Thu, Feb 14, 2013 at 2:19 PM, jcbollinger <John.Bollinger@stjude.org> wrote:> > > On Thursday, February 14, 2013 12:08:17 PM UTC-6, Chad Huneycutt wrote: >> >> It is my understanding that the calling_* variables are only available >> to the puppet backend. At least they do not work for me. >> %{module_name}, on the other hand, works as I expect it to with the >> yaml backend. >> > > I can''t speak to whether or why these currently work for you, but they are > certainly not targeted specifically at the Puppet back end. They are mostly > intended for use in your hiera configuration file (hiera.yaml), which is > independent of any particular back end (since it''s where you define which > one(s) to use). It''s precisely the use case you described. > > With that said, it looks like at least one other bug has been filed against > this functionality in Puppet 3, so perhaps you''re running up against that. > In any case, I still say no, you''re not off-base: what you''re asking for is > supposed to already work. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >-- Chad M. Huneycutt -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:> > Thanks, John. I think you are right that puppet should support it, > but I am pretty sure it does not. I chatted with RI, and it seems > that the classname is not "exposed", so when the puppet backend does > the lookup, it figures out the classname and sets the ''calling_class'' > variable before it interprets the hierarchy. I am going to try to > hack the same thing into the yaml backend, as well as file a bug (or > +1 one) about it. > >Yes, R.I. was explaining the current state of the code, as is also summarized in the PL bug tracker. In addition to issue 14985, which we discussed above, there is http://projects.puppetlabs.com/issues/16730, which speaks directly to how %{calling_class} and %{calling_module} could be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed on that. That issue has been marked as a duplicate of 14985, however; I mention it to give you confidence about which issue to watch / vote up (14985). Also to confirm that PL not only agrees that there''s an issue, but has a solution in flight. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Friday, February 15, 2013 6:37:10 AM UTC-8, jcbollinger wrote:> > > > On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote: >> >> Thanks, John. I think you are right that puppet should support it, >> but I am pretty sure it does not. I chatted with RI, and it seems >> that the classname is not "exposed", so when the puppet backend does >> the lookup, it figures out the classname and sets the ''calling_class'' >> variable before it interprets the hierarchy. I am going to try to >> hack the same thing into the yaml backend, as well as file a bug (or >> +1 one) about it. >> >> > > Yes, R.I. was explaining the current state of the code, as is also > summarized in the PL bug tracker. In addition to issue 14985, which we > discussed above, there is http://projects.puppetlabs.com/issues/16730, > which speaks directly to how %{calling_class} and %{calling_module} could > be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed > on that. That issue has been marked as a duplicate of 14985, however; I > mention it to give you confidence about which issue to watch / vote up > (14985). Also to confirm that PL not only agrees that there''s an issue, > but has a solution in flight. > > >This is very good to hear. A few of weeks ago I was told about the calling_* vars in #puppet IRC when I was looking to solve basically the same sort of task. then when I tried to use them this past weekend and it didn''t work, I asked in #puppet again if there was an issue, and folks acted like I was crazy for thinking calling_{class,module} were supposed to work. Looking forward to having the issue resolved. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.