Hi, After some time playing with Puppet, I came to realize simple node inheritance with includes is not enough, and you may experience unwanted results. Then I started playing with the External Node Classifier that Puppet Dashboard brings in, and even though they implement node groups the way one would expect (much better than native inheritance), I see various problems with it: - You introduce an external service, that if it breaks, may lead to disaster. I want to keep things simple. - If you want to do staging (production, development...) it forces you to do it its way, and I found no reasonable way to merge the stages the way I like. - It does not have version control. - Additionally, it does not support arrays or hashes as of today. I have found an alternative, that is using Hiera as a node classifier. It will allow me to have everything inside the same tree (that I can do version control with) I even found you can pass class parameters (within this very same list: http://www.mail-archive.com/puppet- users@googlegroups.com/msg28134.html ). But before diving into that see, I want to ask you: have any of you done this? What is your level of satisfaction? Is there anything you miss? I also found quite anoying having to have at least one .yaml file per node, specially when you have hundreds of nodes. Also, you must know all the facts before starting with the hierarchy, you can''t modify/include .yaml files on the fly (if you want to have machine groups, you need to have them as facts, essentially forcing you to do two runs every time you change a group). How do you overcome this limitation? Thanks a lot, Pablo -- 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 Pablo, I have done a number of on-site consultations and implemented Hiera with very positive results. To answer a couple of your questions: 1. You don''t NEED to have a YAML file for every node in your infrastructure, but if you need to overwrite values that are set at lower levels of the hierarchy then you CAN create one and set parameter values that are node-specific (if that makes sense). 2. You can alter your hierarchy ''on-the-fly'', but need to consider how that will impact your current environment. Levels can be added, but they must be based on fact values - so you do need to create a ''role'' fact or ''environment'' fact to correspond with adding ''role'' or ''environment'' in your hierarchy. Feel free to ask any more questions that you may have. On Thu, Mar 15, 2012 at 3:02 AM, Pablo Fernandez <pablo.fernandez@cscs.ch>wrote:> Hi, > > After some time playing with Puppet, I came to realize simple node > inheritance > with includes is not enough, and you may experience unwanted results. Then > I > started playing with the External Node Classifier that Puppet Dashboard > brings > in, and even though they implement node groups the way one would expect > (much > better than native inheritance), I see various problems with it: > - You introduce an external service, that if it breaks, may lead to > disaster. > I want to keep things simple. > - If you want to do staging (production, development...) it forces you to > do > it its way, and I found no reasonable way to merge the stages the way I > like. > - It does not have version control. > - Additionally, it does not support arrays or hashes as of today. > > I have found an alternative, that is using Hiera as a node classifier. It > will > allow me to have everything inside the same tree (that I can do version > control with) I even found you can pass class parameters (within this very > same list: http://www.mail-archive.com/puppet- > users@googlegroups.com/msg28134.html ). > > But before diving into that see, I want to ask you: have any of you done > this? > What is your level of satisfaction? Is there anything you miss? > > I also found quite anoying having to have at least one .yaml file per node, > specially when you have hundreds of nodes. Also, you must know all the > facts > before starting with the hierarchy, you can''t modify/include .yaml files > on the > fly (if you want to have machine groups, you need to have them as facts, > essentially forcing you to do two runs every time you change a group). How > do > you overcome this limitation? > > Thanks a lot, > Pablo > > -- > 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. > >-- Gary Larizza Professional Services Engineer Puppet Labs -- 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.
Thanks,
Yes, I was thinking about something like:
:hierarchy:
- %{fqdn}
- %{secundary_group}
- %{primary_group}
- %{productname}
- all
So, each machine goes and picks up the information from the more specific to
the more generic group. So, I guess if the fqdn.yaml file is not there, hiera
will go and pick up the second file, right?
> 2. You can alter your hierarchy ''on-the-fly'', but need
to consider how
> that will impact your current environment. Levels can be added, but they
> must be based on fact values - so you do need to create a
''role'' fact or
> ''environment'' fact to correspond with adding
''role'' or ''environment'' in
> your hierarchy.
Ok, so, I could create a custom fact from puppet too, but then that would
require two runs of puppet: one to apply the new custom fact to the node, and
a second to run puppet with the new fact active. Can you think of a way to do
it at once? That''s why I was thinking of using the :datasource: and
pick up
the group definitions from within the manifests tree, but it must be static
inside the tree, not depending on the module you are currently trying to
apply.
Thanks!
Pablo
On Saturday 17 March 2012 10:19:19 Gary Larizza wrote:> Hi Pablo,
>
> I have done a number of on-site consultations and implemented Hiera with
> very positive results. To answer a couple of your questions:
>
> 1. You don''t NEED to have a YAML file for every node in your
> infrastructure, but if you need to overwrite values that are set at lower
> levels of the hierarchy then you CAN create one and set parameter values
> that are node-specific (if that makes sense).
>
> 2. You can alter your hierarchy ''on-the-fly'', but need
to consider how
> that will impact your current environment. Levels can be added, but they
> must be based on fact values - so you do need to create a
''role'' fact or
> ''environment'' fact to correspond with adding
''role'' or ''environment'' in
> your hierarchy.
>
> Feel free to ask any more questions that you may have.
>
> On Thu, Mar 15, 2012 at 3:02 AM, Pablo Fernandez
<pablo.fernandez@cscs.ch>wrote:> > Hi,
> >
> > After some time playing with Puppet, I came to realize simple node
> > inheritance
> > with includes is not enough, and you may experience unwanted results.
> > Then I
> > started playing with the External Node Classifier that Puppet
Dashboard
> > brings
> > in, and even though they implement node groups the way one would
expect
> > (much
> > better than native inheritance), I see various problems with it:
> > - You introduce an external service, that if it breaks, may lead to
> > disaster.
> > I want to keep things simple.
> > - If you want to do staging (production, development...) it forces you
> > to
> > do
> > it its way, and I found no reasonable way to merge the stages the way
I
> > like.
> > - It does not have version control.
> > - Additionally, it does not support arrays or hashes as of today.
> >
> > I have found an alternative, that is using Hiera as a node classifier.
> > It
> > will
> > allow me to have everything inside the same tree (that I can do
version
> > control with) I even found you can pass class parameters (within this
> > very same list: http://www.mail-archive.com/puppet-
> > users@googlegroups.com/msg28134.html ).
> >
> > But before diving into that see, I want to ask you: have any of you
done
> > this?
> > What is your level of satisfaction? Is there anything you miss?
> >
> > I also found quite anoying having to have at least one .yaml file per
> > node, specially when you have hundreds of nodes. Also, you must know
> > all the facts
> > before starting with the hierarchy, you can''t modify/include
.yaml files
> > on the
> > fly (if you want to have machine groups, you need to have them as
facts,
> > essentially forcing you to do two runs every time you change a group).
> > How do
> > you overcome this limitation?
> >
> > Thanks a lot,
> > Pablo
> >
> > --
> > 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 Tue, Mar 20, 2012 at 9:44 PM, Pablo Fernandez <pablo.fernandez@cscs.ch>wrote:> ** > > Thanks, > > > > Yes, I was thinking about something like: > > > > :hierarchy: > > - %{fqdn} > > - %{secundary_group} > > - %{primary_group} > > - %{productname} > > - all > > > > So, each machine goes and picks up the information from the more specific > to the more generic group. So, I guess if the fqdn.yaml file is not there, > hiera will go and pick up the second file, right? >That''s correct.> > > > > > 2. You can alter your hierarchy ''on-the-fly'', but need to consider how > > > that will impact your current environment. Levels can be added, but they > > > must be based on fact values - so you do need to create a ''role'' fact or > > > ''environment'' fact to correspond with adding ''role'' or ''environment'' in > > > your hierarchy. > > > > > > Ok, so, I could create a custom fact from puppet too, but then that would > require two runs of puppet: one to apply the new custom fact to the node, > and a second to run puppet with the new fact active. Can you think of a way > to do it at once? That''s why I was thinking of using the :datasource: and > pick up the group definitions from within the manifests tree, but it must > be static inside the tree, not depending on the module you are currently > trying to apply. >No, this is completely incorrect. Puppet uses pluginsync to sync custom facts down to the node BEFORE Puppet is run, it then runs the custom fact to attain a value and only THEN does it run Puppet. You can be certain that custom facts will ALWAYS be on the node during the first run. If they do not, then this is a bug and should be reported.> > > > > Thanks! > Pablo > > > > > > > > > > > > On Saturday 17 March 2012 10:19:19 Gary Larizza wrote: > > > Hi Pablo, > > > > > > I have done a number of on-site consultations and implemented Hiera with > > > very positive results. To answer a couple of your questions: > > > > > > 1. You don''t NEED to have a YAML file for every node in your > > > infrastructure, but if you need to overwrite values that are set at lower > > > levels of the hierarchy then you CAN create one and set parameter values > > > that are node-specific (if that makes sense). > > > > > > 2. You can alter your hierarchy ''on-the-fly'', but need to consider how > > > that will impact your current environment. Levels can be added, but they > > > must be based on fact values - so you do need to create a ''role'' fact or > > > ''environment'' fact to correspond with adding ''role'' or ''environment'' in > > > your hierarchy. > > > > > > Feel free to ask any more questions that you may have. > > > > > > On Thu, Mar 15, 2012 at 3:02 AM, Pablo Fernandez < > pablo.fernandez@cscs.ch>wrote: > > > > Hi, > > > > > > > > After some time playing with Puppet, I came to realize simple node > > > > inheritance > > > > with includes is not enough, and you may experience unwanted results. > > > > Then I > > > > started playing with the External Node Classifier that Puppet Dashboard > > > > brings > > > > in, and even though they implement node groups the way one would expect > > > > (much > > > > better than native inheritance), I see various problems with it: > > > > - You introduce an external service, that if it breaks, may lead to > > > > disaster. > > > > I want to keep things simple. > > > > - If you want to do staging (production, development...) it forces you > > > > to > > > > do > > > > it its way, and I found no reasonable way to merge the stages the way I > > > > like. > > > > - It does not have version control. > > > > - Additionally, it does not support arrays or hashes as of today. > > > > > > > > I have found an alternative, that is using Hiera as a node classifier. > > > > It > > > > will > > > > allow me to have everything inside the same tree (that I can do version > > > > control with) I even found you can pass class parameters (within this > > > > very same list: http://www.mail-archive.com/puppet- > > > > users@googlegroups.com/msg28134.html ). > > > > > > > > But before diving into that see, I want to ask you: have any of you > done > > > > this? > > > > What is your level of satisfaction? Is there anything you miss? > > > > > > > > I also found quite anoying having to have at least one .yaml file per > > > > node, specially when you have hundreds of nodes. Also, you must know > > > > all the facts > > > > before starting with the hierarchy, you can''t modify/include .yaml > files > > > > on the > > > > fly (if you want to have machine groups, you need to have them as > facts, > > > > essentially forcing you to do two runs every time you change a group). > > > > How do > > > > you overcome this limitation? > > > > > > > > Thanks a lot, > > > > Pablo > > > > > > > > -- > > > > 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. >-- Gary Larizza Professional Services Engineer Puppet Labs -- 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.