Re: [Puppet Users] Re: replacing mkdir -p

[Tony C]

I have the same issue, I basically create an array, that way it cuts it 
down to one FILE, and not the same thing over and over again.


file { ["/blah", "/blah/blah", "/blah/blah/blah", "/blah/blah/blah/blah", 
"/blah/blah/blah/blah/blah"]:
ensure => directory,
owner => "blah",
group => "blah",
mode => 0700,
}

On Monday, April 8, 2013 1:27:11 PM UTC-7, Luca Gioppo wrote:
>
> Can you post a complete example please?
> Thanks
> Luca
>
>
> 2013/4/4 Mike Power >
>
>> Actually I found if I created a resource between path and file called 
>> element, I could give it a unique name.  Then inside the body I could check 
>> to see if the File is declared, if not I could declare it.  
>>
>> On Thursday, April 4, 2013 9:23:54 AM UTC-7, Mike Power wrote:
>>>
>>> Puppet right now requires every element of a path to have an individual 
>>> file definition.  This makes it had to take an arbitrary path as a 
>>> parameter.  You are forced to require your client to make the entire path 
>>> structure for you or instead you use an exec resource and call mkdir -p.  
>>> Using an exec resource does not generate an File resources so autorequire 
>>> does not work.
>>>
>>> I didn't like this, I wanted to be able to once specify a path and have 
>>> puppet do that autorequire as needed.
>>>
>>> Something like:
>>> path {"/blah/blah/blah/and/blah":
>>> }
>>>
>>>
>>> In order to make this happen I would have to manually define each file:
>>> file {"/blah/":
>>> ensure  => directory,
>>> }
>>>
>>> file {"/blah/blah/":
>>> ensure  => directory,
>>> }
>>>
>>> file {"/blah/blah/blah/":
>>> ensure  => directory,
>>> }
>>>
>>> file {"/blah/blah/blah/and/":
>>> ensure  => directory,
>>> }
>>>
>>> file {"/blah/blah/blah/and/blah/":
>>> ensure  => directory,
>>> }
>>>
>>> Of course there is a short hand for this:
>>> file {["/blah/", "/blah/blah/", "/blah/blah/blah/", 
>>> "/blah/blah/blah/and/","/blah/**blah/blah/and/blah/"]:
>>> ensure  => directory,
>>> }
>>>
>>> Then it occurred to me I could parse the path and produce the array of 
>>> elements needed.  Something like:
>>> $path = "/blah/blah/blah/and/blah"
>>> $file_list = split($path, $file_separator)
>>> $paths = inline_template('<% parent = nil %><%=@file_list.collect{ 
>>> |file| parent.nil? ? parent = "#{@file_separator}":parent = 
>>> "#{parent}#{file}#{@file_**separator}"}.join(@path_**separator) %>')
>>> $path_list = split($paths, $path_separator)
>>> file{$path_list:
>>> ensure  => directory,
>>> }
>>>
>>> This works great once.  Then you get errors like:
>>> Error: Duplicate declaration: File[/]
>>>
>>> If there anyway to trim down the produced array by removing the 
>>> resources that already exist?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  -- 
>> 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...@googlegroups.com .
>> To post to this group, send email to puppet...@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+unsubscr...@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.

Re: [Puppet Users] Not custom facts, but variables?

[Tony C]

Right on!

Thanks Jon,

That was it. Got it working just as you stated. It's exactly what I need. 

Tony

On Monday, April 8, 2013 1:01:58 PM UTC-7, Jonathan Proulx wrote:
>
>
> On Mon, Apr 8, 2013 at 3:33 PM, Tony C  >wrote:
>
>> Jon,
>>
>> Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar 
>> with this module. I read on it but not sure specifically how you are using 
>> it.
>>
>>
> stdlib provides many useful functions, most of which are called by other 
> modules.
>
> The use that relates to  this case is "facter-dot-d" see 
> https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for
>  a write up.
>
> The simple case (which is the one we use is making a plain text file in 
> /etc/facter/facts.d (anything in there ending in .txt gets parsed as plain 
> text)) with key=value pairs that then become facter facts.
>
> for example on my puppet managed workstation:
>
> $ cat /etc/facter/facts.d/csail.txt  
> role=wkst
> autofs=true
>
> So when puppet runs the fact "role" is set to "wkst" which pulls in the 
> right classes to make a generic workstation, the fact "group" mentioned 
> above is undefined which is OK there's just no customization based on 
> groups and "autofs" is a facter key that our local wkst module looks at to 
> see if our NFS automount should be configured or not.  By default we don't 
> but the local root user can define this to true and on the next puppet run 
> the config will happen for them.
>
> We install the stdlib module on the puppet masters (implemneted as a git 
> submodule in our git repo) and use "pluginsync=true" on the clients to pull 
> down the bits they need from this and other modules.  Though you could 
> distribute the required facter-dot-d.rb file in other ways, pluginsync is 
> most convenient for us.
>
> -Jon
>

-- 
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+unsubscr...@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.

[Puppet Users] Re: Not custom facts, but variables?

[Tony C]

Looks like external facts are available after facter 1.7, i'm using 1.6 

-- 
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+unsubscr...@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.

Re: [Puppet Users] Not custom facts, but variables?

[Tony C]

Jon,

Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar 
with this module. I read on it but not sure specifically how you are using 
it.

Thanks,

Tony

On Monday, April 8, 2013 12:14:04 PM UTC-7, Jonathan Proulx wrote:
>
> On Mon, Apr 8, 2013 at 2:57 PM, Dan White 
> > wrote:
>
>> Based on your description, I would suggest the following:
>>
>> Let's take tomcat as a specific example.
>> Assumption: You have a tomcat module that can be configured with 
>> parameters.
>>
>> Here is the suggestion: Add a hostname level to your heirarchy
>>
>
>
> but if you have multiple tomcat servers (for example) then you have to 
> repeat data for each hostname which is exactly the wrong thing.
>
> using a custom fact (I use "role" for essentially the same thing Tony 
> wants to use "application for) you can classify nodes without an ENC and 
> without repeating yourself.
>
> My hierarchy is:
> # cat /etc/puppet/hiera.yaml
> ---
> :hierarchy:
>  - %{fqdn}
>  - %{role}
>  - %{group}
>  - %{osfamily}
>  - common
> :backends: 
>  - yaml
>  - puppet
> :yaml:
>  :datadir: /etc/puppet/environments/%{environment}/data
> :puppet:
>  :datasource: data
>
> I do have fqdn, but that is always too specific, except maybe for 
> testing.  "Role" is what the system does and "group" is who manages it, 
> both of these come form custom facts on the system in /etc/factor/facts.d 
> (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases 
> hundreds) with the same role.  Keying this off fqdn or cert name would me a 
> nightmare
>
> Picking the right hierarchy and the right level into to place data is a 
> bit of a black art, but crucial to having a manageable config.  This has 
> been workable for me for the past 9 months or so, but not pretenses to 
> perfection...
>
> -Jon
>
>   
>
>> OK, so now for node hostx.example.org, you want this to be a tomcat 
>> server.  All you need do is put the appropriate parameters into 
>> hostx.example.org.yaml
>>
>> I am still a hiera n00b myself, so I am not totally sure exactly how to 
>> do this, but I am working on it.
>>
>>
>> “Sometimes I think the surest sign that intelligent life exists elsewhere 
>> in the universe is that none of it has tried to contact us.”
>> Bill Waterson (Calvin & Hobbes)
>>
>> --
>> *From: *"Tony C" >
>> *To: *puppet...@googlegroups.com 
>> *Sent: *Monday, April 8, 2013 2:43:41 PM
>> *Subject: *Re: [Puppet Users] Not custom facts, but variables?
>>
>>
>> sure, to be specific,
>>
>> we have environments, dev, test, qa, stage, and prod. That part I got 
>> with your help on my last post. Thank you.
>>
>> Within these environments, we have applications. We only have a few apps. 
>> So let's say some machines are oracle db machines, some are tomcat, and 
>> some are apache. 
>>
>> I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
>> of these yaml files contain some key value pair that is specific to that 
>> environment. 
>>
>> So when some machine is provisioned, I want to say this machine is a 
>> tomcat machine, and I don't care what environment it since I will let the 
>> agent conf figure that out. That way I can one puppet module for tomcat, 
>> but different values per environment.
>>
>> I hope that makes sense, and if my approach is completely wrong, I'm open 
>> to hear some alternatives. Thanks again everyone.
>>
>> -- 
>> 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...@googlegroups.com .
>> To post to this group, send email to puppet...@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...@googlegroups.com .
>> To post to this group, send email to puppet...@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+unsubscr...@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.

Re: [Puppet Users] Not custom facts, but variables?

[Tony C]

Thanks for your response, but I can see me possibly having tons of yaml 
files since it's very possible I may have 100 tomcat servers, all with the 
same configuration. I don't think it will scale. 

 
On Monday, April 8, 2013 11:57:10 AM UTC-7, Ygor wrote:
>
> Based on your description, I would suggest the following:
>
> Let's take tomcat as a specific example.
> Assumption: You have a tomcat module that can be configured with 
> parameters.
>
> Here is the suggestion: Add a hostname level to your heirarchy.
>
> OK, so now for node hostx.example.org, you want this to be a tomcat 
> server.  All you need do is put the appropriate parameters into 
> hostx.example.org.yaml
>
> I am still a hiera n00b myself, so I am not totally sure exactly how to do 
> this, but I am working on it.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> *From: *"Tony C" >
> *To: *puppet...@googlegroups.com 
> *Sent: *Monday, April 8, 2013 2:43:41 PM
> *Subject: *Re: [Puppet Users] Not custom facts, but variables?
>
> sure, to be specific,
>
> we have environments, dev, test, qa, stage, and prod. That part I got with 
> your help on my last post. Thank you.
>
> Within these environments, we have applications. We only have a few apps. 
> So let's say some machines are oracle db machines, some are tomcat, and 
> some are apache. 
>
> I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
> of these yaml files contain some key value pair that is specific to that 
> environment. 
>
> So when some machine is provisioned, I want to say this machine is a 
> tomcat machine, and I don't care what environment it since I will let the 
> agent conf figure that out. That way I can one puppet module for tomcat, 
> but different values per environment.
>
> I hope that makes sense, and if my approach is completely wrong, I'm open 
> to hear some alternatives. Thanks again everyone.
>
> -- 
> 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...@googlegroups.com .
> To post to this group, send email to puppet...@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+unsubscr...@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.

Re: [Puppet Users] Not custom facts, but variables?

[Tony C]

sure, to be specific,

we have environments, dev, test, qa, stage, and prod. That part I got with 
your help on my last post. Thank you.

Within these environments, we have applications. We only have a few apps. 
So let's say some machines are oracle db machines, some are tomcat, and 
some are apache. 

I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
of these yaml files contain some key value pair that is specific to that 
environment. 

So when some machine is provisioned, I want to say this machine is a tomcat 
machine, and I don't care what environment it since I will let the agent 
conf figure that out. That way I can one puppet module for tomcat, but 
different values per environment.

I hope that makes sense, and if my approach is completely wrong, I'm open 
to hear some alternatives. Thanks again everyone.

-- 
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+unsubscr...@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.

[Puppet Users] Not custom facts, but variables?

[Tony C]

After reading several posts, it looks like setting a key on every host, and 
supplying a different value based on that host's function is not a proper 
use of facts, but more for variables.

We are using hiera, and based on my hierarchy,


:hierarchy:
  - common
  - %{application}
:yaml:
  :datadir: /etc/puppetlabs/hieradata/%{environment}

Without using an ENC, what's are some good ways to "tag" the server with a 
value for %{application}. 

thanks so much,

Tony


-- 
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+unsubscr...@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.

Re: [Puppet Users] More Hiera and Environment questions

[Tony C]

Thank you so much. I have never seen that page before. I think my issue is 
resolved for now. I'll open another post for facts.

On Monday, April 8, 2013 11:11:18 AM UTC-7, Ygor wrote:
>
> I must retract my earlier claim.
> I tried mine with and without the scoping double-colon and it works both 
> ways.
>
> The documentation ( http://docs.puppetlabs.com/hiera/1/variables.html ) 
> uses the double-colon.
>
> HOWEVER, I think (again) I see your problem: What is "application" ?
>
> All the variables I use are in the settings ( 
> http://docs.puppetlabs.com/references/latest/configuration.html )
>
> "application" is not a setting.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> *From: *"Tony C" >
> *To: *puppet...@googlegroups.com 
> *Sent: *Monday, April 8, 2013 2:04:05 PM
> *Subject: *Re: [Puppet Users] More Hiera and Environment questions
>
> Yes, the double colon was a problem, also it looks like in the agent conf, 
> this does not work
> applicaton = app_1
>
> So this goes back to my original issue. Without an ENC, how can I 'tag" my 
> machines with specific info. I was playing with custom facts but it looks 
> like the same facts get applied to every node. 
>
> Thanks!
>
> Tony
>
> -- 
> 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...@googlegroups.com .
> To post to this group, send email to puppet...@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+unsubscr...@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.

Re: [Puppet Users] More Hiera and Environment questions

[Tony C]

Yes, the double colon was a problem, also it looks like in the agent conf, 
this does not work
applicaton = app_1

So this goes back to my original issue. Without an ENC, how can I 'tag" my 
machines with specific info. I was playing with custom facts but it looks 
like the same facts get applied to every node. 

Thanks!

Tony

-- 
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+unsubscr...@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.

Re: [Puppet Users] More Hiera and Environment questions

[Tony C]

Yes, I have restarted every service. If I replace the %{environment} and 
%{application} with the actual values in hiera.yaml, everything works so I 
know at least I'm on the right track.

I have also run the hiera command with -c  with environment=dev 
application=app1 and that works as well.

Tony

-- 
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+unsubscr...@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.

Re: [Puppet Users] More Hiera and Environment questions

[Tony C]

Oops, I copied and pasted the wrong thing.


hiera.yaml

:yaml:
  :datadir: /etc/puppetlabs/hieradata/%{::environment}
:hierarchy:
  - common
  - %{::application}


On my agent puppet.conf, I have tried what you suggested already but it 
can't find the value in hiera.

[agent]
certname = xx
server = xx
report = true
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
graph = true
pluginsync = true
environment = dev
application = app_1


On Monday, April 8, 2013 10:33:26 AM UTC-7, Ygor wrote:
>
> http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node
>
> I put it in the [agent] block of puppet.conf
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> ------
> *From: *"Tony C" >
> *To: *puppet...@googlegroups.com 
> *Sent: *Monday, April 8, 2013 1:28:37 PM
> *Subject: *[Puppet Users] More Hiera and Environment questions
>
> Hi everyone,
>
> I have a question that I can't seem to find a solution to.
>
> I am using hiera, and having a hard time understanding how to pass 
> environments for dynamic look ups.
>
> For example, if my hiera.yaml looks like this:
>
> :hierarchy: - %{::environment} - common
>
> How / where do I pass the $environment variable that the host will know 
> it's in a particular environment. I had something working before using an 
> ENC, but I do not have an option of using an ENC this time around.
>
> Thanks!
>
> Tony
>
> -- 
> 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...@googlegroups.com .
> To post to this group, send email to puppet...@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+unsubscr...@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.

[Puppet Users] More Hiera and Environment questions

[Tony C]

Hi everyone,

I have a question that I can't seem to find a solution to.

I am using hiera, and having a hard time understanding how to pass 
environments for dynamic look ups.

For example, if my hiera.yaml looks like this:

:hierarchy: - %{::environment} - common

How / where do I pass the $environment variable that the host will know 
it's in a particular environment. I had something working before using an 
ENC, but I do not have an option of using an ENC this time around.

Thanks!

Tony

-- 
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+unsubscr...@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.

[Puppet Users] Re: Question about reusing classes/modules

[Tony C]

http://www.craigdunn.org/2011/10/puppet-configuration-variables-and-hiera/

Hiera it is! Exactly what I needed. i just need a bit more explaining.

On Feb 11, 5:48 pm, Eric Shamow  wrote:
> I would avoid this approach - global variables aren't a good idea.
>
> Hiera would be a better approach:
>
> http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Serviceshttp://puppetlabs.com/
> (c)631.871.6441
>
>
>
>
>
>
>
> On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
> > > My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > > of these environments lives in 2 sites, LA and NY. I have 5
> > > applications that are site and env specific.
>
> > > I want to use puppet to template-ize the config files that is required
> > > for each env, per site, per app, so 40 files.
>
> > > The config file is basically key=value pairs. Here's a simple example
> > > of what each file may look like:
>
> > > site=LA
> > > env=Dev
> > > app=App1
> > > masterServer=host1
> > > clientServer1=host2
> > > clientServer2=host3
>
> > How about having these key value pairs in site.pp with a case environment
> > Then they become global to all modules.
>
> > --
> > Krish
> > olindata.com (http://olindata.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 
> > (mailto:puppet-users@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com 
> > (mailto:puppet-users+unsubscr...@googlegroups.com).
> > For more options, visit this group 
> > athttp://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, Facter and Mcollective

[Tony C]

I just read another article in the mcollective-users group and re-read
what you put, and  see how I have this wrong.

Puppet can do everything I need as far as
> role = tomcat
> tomcat_installed = no
> env=dev
> designated_app = MyApp1
> then install Tomcat
 and the apply the config files.

Mcollective should be used for things like, I want to deploy a new
app, use mcollective to shutdown these specific servers, deploy and
bring them back up, etc etc etc





On Feb 17, 1:13 pm, Tony C  wrote:
> Hey Gary, Thanks for that, I read the link, as well as this article
> written by you
>
> http://puppetlabs.com/blog/the-problem-with-separating-data-from-pupp...
>
> I think I have 2 use cases here. I need mcollective to do ad-hoc
> triggering of jobs and some orchestration based on some criteria, like
> role, env and site.  I also want my puppet manifests to control the
> state of a machine, after this orchestration based on the criteria
> used to trigger and ad-hoc job, just as you stated.
>
> For example, for mcollective
>
> role = tomcat
> tomcat_installed = no
> env=dev
> designated_app = MyApp1
> then install Tomcat
>
> After the installation, I would want puppet to run, and if those same
> criteria matches the logic in my puppet manifest, deploy the proper
> config files needed to power that tomcat, in that site, for that
> particular application.
>
> So I think it comes down to, where do I put the source of truth. If
> hiera uses yaml in the backend, can I use Hiera's yaml file to power /
> etc/puppetlabs/mcollective/facts.yaml? I really like the Puppet
> Console. Easy to setup, easy to use.
>
> I think I understand how Hiera works. When doing a search, it will
> basically look down the chain and return values that will match
> whatever you asked for, even if that value is not in the immediate
> "level" you are searching against.
>
> My apologies if I am all over the place. Just really amped to getting
> this thing off the ground. I feel like I'm right there, I just need to
> make a decision.
>
> On Feb 17, 12:19 pm, Gary Larizza  wrote:
>
>
>
>
>
>
>
> > Tony,
>
> > You might want to look at Hiera and doing this INSIDE Puppet instead of MC.
> >  MC is awesome for orchestration and ad-hoc triggering of jobs, but it
> > sounds like what YOU want to do is ensure a final state of a machine based
> > on its role, environment, and site.
>
> > Hiera allows you to specify a hierarchy (such as node-specific, then role,
> > environment, and so on all the way down to a global file that has all your
> > defaults in it) and return data based on the hierarchy that is pertinent to
> > your node.  For example, if you wanted to ensure that all App-nodes had
> > Tomcat, you could have Hiera search through the hierarchy for a 'classes'
> > parameter and return an array of ALL the classes that were declared in
> > every level of the hierarchy.  At the app-node level of the hierarchy, you
> > would have 'tomcat' returned as a value for the 'classes' parameter.  This
> > would allow you to dynamically classify ALL app-nodes to include the tomcat
> > class without having to change a bunch of individual node declarations in
> > Puppet.  It would also let you limit/change behavior based on their
> > environment, role, and so on.  Does this make sense?
>
> > Check out the blog post here 
> > -->http://puppetlabs.com/blog/first-look-installing-and-using-hiera/andthe
> > repositories 
> > athttp://github.com/puppetlabs/hieraandhttp://github.com/puppetlabs/hie...
>
> > On Fri, Feb 17, 2012 at 10:47 AM, Tony C  wrote:
> > > Gary and Greg, wow, thanks a whole lot. I've been reading the same
> > > things you typed, in different posts, but for some reason after
> > > reading your posts, the light bulb went off and almost everything came
> > > together for me. How do I use facts.d? I understand what it does, but
> > > how can I leverage puppet and facter to
>
> > > Bottom line, it all depends on our requirements. I basically want to
> > > be able to query Mcollective based on facts, such as env, site, and
> > > application. The place i work uses weblogic and they build out a brand
> > > new WLS domain for every application set, so I want to do something
> > > like (excuse my pseudo code here, not a developer)
>
> > > if app = MyAppSet1,
> > >  if site = LA
> > >    if env=Dev
> > >      do some action
>
> > > At first I thought I could use custom facts but shot that idea down
> > > because of how it distributes to every puppet client. Now 

[Puppet Users] Re: Puppet, Facter and Mcollective

[Tony C]

Hey Gary, Thanks for that, I read the link, as well as this article
written by you

http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/

I think I have 2 use cases here. I need mcollective to do ad-hoc
triggering of jobs and some orchestration based on some criteria, like
role, env and site.  I also want my puppet manifests to control the
state of a machine, after this orchestration based on the criteria
used to trigger and ad-hoc job, just as you stated.

For example, for mcollective

role = tomcat
tomcat_installed = no
env=dev
designated_app = MyApp1
then install Tomcat

After the installation, I would want puppet to run, and if those same
criteria matches the logic in my puppet manifest, deploy the proper
config files needed to power that tomcat, in that site, for that
particular application.


So I think it comes down to, where do I put the source of truth. If
hiera uses yaml in the backend, can I use Hiera's yaml file to power /
etc/puppetlabs/mcollective/facts.yaml? I really like the Puppet
Console. Easy to setup, easy to use.

I think I understand how Hiera works. When doing a search, it will
basically look down the chain and return values that will match
whatever you asked for, even if that value is not in the immediate
"level" you are searching against.

My apologies if I am all over the place. Just really amped to getting
this thing off the ground. I feel like I'm right there, I just need to
make a decision.


On Feb 17, 12:19 pm, Gary Larizza  wrote:
> Tony,
>
> You might want to look at Hiera and doing this INSIDE Puppet instead of MC.
>  MC is awesome for orchestration and ad-hoc triggering of jobs, but it
> sounds like what YOU want to do is ensure a final state of a machine based
> on its role, environment, and site.
>
> Hiera allows you to specify a hierarchy (such as node-specific, then role,
> environment, and so on all the way down to a global file that has all your
> defaults in it) and return data based on the hierarchy that is pertinent to
> your node.  For example, if you wanted to ensure that all App-nodes had
> Tomcat, you could have Hiera search through the hierarchy for a 'classes'
> parameter and return an array of ALL the classes that were declared in
> every level of the hierarchy.  At the app-node level of the hierarchy, you
> would have 'tomcat' returned as a value for the 'classes' parameter.  This
> would allow you to dynamically classify ALL app-nodes to include the tomcat
> class without having to change a bunch of individual node declarations in
> Puppet.  It would also let you limit/change behavior based on their
> environment, role, and so on.  Does this make sense?
>
> Check out the blog post here 
> -->http://puppetlabs.com/blog/first-look-installing-and-using-hiera/and the
> repositories 
> athttp://github.com/puppetlabs/hieraandhttp://github.com/puppetlabs/hiera-puppet
>
>
>
>
>
>
>
>
>
> On Fri, Feb 17, 2012 at 10:47 AM, Tony C  wrote:
> > Gary and Greg, wow, thanks a whole lot. I've been reading the same
> > things you typed, in different posts, but for some reason after
> > reading your posts, the light bulb went off and almost everything came
> > together for me. How do I use facts.d? I understand what it does, but
> > how can I leverage puppet and facter to
>
> > Bottom line, it all depends on our requirements. I basically want to
> > be able to query Mcollective based on facts, such as env, site, and
> > application. The place i work uses weblogic and they build out a brand
> > new WLS domain for every application set, so I want to do something
> > like (excuse my pseudo code here, not a developer)
>
> > if app = MyAppSet1,
> >  if site = LA
> >    if env=Dev
> >      do some action
>
> > At first I thought I could use custom facts but shot that idea down
> > because of how it distributes to every puppet client. Now that I have
> > read about confine, I maybe able to pull off some combination of
> > confine and group parameters specified in the Puppet Console?
>
> > I'm going to play with this today and see what I come up with. I think
> > there are a few different ways of pulling off what I need, and I do
> > thank everyone who has put in the time to reply.
>
> > - Tony
>
> > On Feb 16, 7:19 pm, Greg  wrote:
> > > As far as I know thats true... One option to limit facts is to use
> > > confine to limit where its gets run.
>
> > > For example, here is a fact that is clearly only applicable for
> > > Solaris hosts:
>
> > >     Facter.add("obpversion") do
> > >         confine :kernel => :sunos
> > >         setcode do
> > >     

[Puppet Users] Re: Puppet, Facter and Mcollective

[Tony C]

Gary and Greg, wow, thanks a whole lot. I've been reading the same
things you typed, in different posts, but for some reason after
reading your posts, the light bulb went off and almost everything came
together for me. How do I use facts.d? I understand what it does, but
how can I leverage puppet and facter to

Bottom line, it all depends on our requirements. I basically want to
be able to query Mcollective based on facts, such as env, site, and
application. The place i work uses weblogic and they build out a brand
new WLS domain for every application set, so I want to do something
like (excuse my pseudo code here, not a developer)

if app = MyAppSet1,
  if site = LA
if env=Dev
  do some action

At first I thought I could use custom facts but shot that idea down
because of how it distributes to every puppet client. Now that I have
read about confine, I maybe able to pull off some combination of
confine and group parameters specified in the Puppet Console?

I'm going to play with this today and see what I come up with. I think
there are a few different ways of pulling off what I need, and I do
thank everyone who has put in the time to reply.

- Tony


On Feb 16, 7:19 pm, Greg  wrote:
> As far as I know thats true... One option to limit facts is to use
> confine to limit where its gets run.
>
> For example, here is a fact that is clearly only applicable for
> Solaris hosts:
>
>     Facter.add("obpversion") do
>         confine :kernel => :sunos
>         setcode do
>                 %x{/usr/sbin/prtconf -V}.chomp.split(" ")[1]
>         end
>     end
>
> Whilst this won't stop it from being downloaded, it will mean that the
> code will only be run on hosts that meet the requirements.
>
> Hope that helps...
>
> On Feb 17, 11:23 am, Nan Liu  wrote:
>
>
>
>
>
>
>
> > On Thu, Feb 16, 2012 at 3:19 PM, Tony C  wrote:
> > > I'm not sure if this is the right group or not, but i'll start here.
>
> > > I have Puppet enterprise 2.0, playing around with custom facts.
>
> > > I have noticed that adding a custom fact to any module will distribute
> > > that fact to all machines, regardless if they are assigned to that
> > > module or not. Is there a way around this, or is this just by design?
>
> > Gary already pointed out the cron job. I'm not aware of an easy way to
> > perform limited pluginsync, it's either all or nothing. The reason
> > this is not possible, puppet need facts to compile catalog to know
> > what modules belong to a node, and puppet can't compile without facts,
> > so chicken and egg. For example, puppet can't know if it should
> > pluginsync my_fact if it's in my_module with the following code:
>
> > if $my_fact {include my_module}
>
> > HTH,
>
> > Nan

-- 
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, Facter and Mcollective

[Tony C]

Thanks Nan.

I supposed every one's environment is different. For the facts.d, how
does that work exactly?

On Feb 16, 4:31 pm, Nan Liu  wrote:
> On Thu, Feb 16, 2012 at 3:52 PM, Tony C  wrote:
> > I see, but following this page does allow for that
>
> >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact...
>
> > I just tested it. So in my enterprise, i would much rather control the
> > facts.yaml using a module of the above listed link and a puppet run,
> > than allowing a cron job to do this. Also, the parameters defined in
> > the ENC really help me carve out my infrastructure nicely for my
> > puppet manifests, as well as the ability to run queries in mcollective
> > using these parameters. A good examle would be a group in the
> > Dashboard called PRODUCTION, with a parameter for site=LA
>
> I can see scenarios where I wouldn't want to dump the entire ENC
> content since there's confidential settings though relevant for that
> system, I don't want to make discoverable through mco inventory.
>
> Since you are using PE, another options you can take advantage of
> facts.d directory, and write out custom facts in key=value format in
> txt file under /etc/puppetlabs/facter/facts.d/
>
> See the puppet_enterprise_installer.txt for example, and this will be
> a fairly straightforward file resource using a template.
>
> Thanks,
>
> Nan

-- 
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, Facter and Mcollective

[Tony C]

No worries Gary. Thanks for your help already. I'm definitely on your
time so just chime in if / when you have a second.

On Feb 16, 4:00 pm, Gary Larizza  wrote:
> Our cron entry is declared in the pe_mcollective module that we ship in our
> modulepath
> --> /opt/puppet/share/puppet/modules/pe_mcollective/manifests/metadata.pp
>
> I'll answer this more in-depth when I get a free second to expound on it,
> but I'm a bit tied-up at the moment :)
>
>
>
>
>
>
>
>
>
> On Thu, Feb 16, 2012 at 3:52 PM, Tony C  wrote:
> > I see, but following this page does allow for that
>
> >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact...
>
> > I just tested it. So in my enterprise, i would much rather control the
> > facts.yaml using a module of the above listed link and a puppet run,
> > than allowing a cron job to do this. Also, the parameters defined in
> > the ENC really help me carve out my infrastructure nicely for my
> > puppet manifests, as well as the ability to run queries in mcollective
> > using these parameters. A good examle would be a group in the
> > Dashboard called PRODUCTION, with a parameter for site=LA
>
> > How do people typically manage that puppet generated crontab?
>
> > On Feb 16, 3:38 pm, Gary Larizza  wrote:
> > > Tony,
>
> > > No.  Those don't become custom fact values, so client's aren't aware of
> > > them.
>
> > > On Thu, Feb 16, 2012 at 3:34 PM, Tony C  wrote:
> > > > Awesome Gary, Thanks for the reply.
>
> > > > Will this also populate parameters assigned via an ENC (my case would
> > > > be the puppet dashboard)?
>
> > > > Thanks again.
>
> > > > On Feb 16, 3:33 pm, Gary Larizza  wrote:
> > > > > Hey there,
>
> > > > > Check your cron with crontab -l and you'll see a line that calls
> > > > > "/opt/puppet/sbin/refresh-mcollective-metadata" every 15 minutes.
> >  That's
> > > > > the process that updates the facts.yaml file with your current custom
> > > > > facts.  You can trigger it whenever you'd like :)
>
> > > > > On Thu, Feb 16, 2012 at 3:19 PM, Tony C 
> > wrote:
> > > > > > I'm not sure if this is the right group or not, but i'll start
> > here.
>
> > > > > > I have Puppet enterprise 2.0, playing around with custom facts.
>
> > > > > > I have noticed that adding a custom fact to any module will
> > distribute
> > > > > > that fact to all machines, regardless if they are assigned to that
> > > > > > module or not. Is there a way around this, or is this just by
> > design?
>
> > > > > > I have the pluginsync and mcollective setup to use /etc/puppetlabs/
> > > > > > mcollective/facts.yaml.
>
> > > > > > server.cfg
> > > > > > # Facts
> > > > > > factsource = yaml
> > > > > > plugin.yaml = /etc/puppetlabs/mcollective/facts.yaml
>
> > > > > > Without doing anything, after a few minutes, my facts.yaml gets
> > > > > > populated with the new custom fact, even without following this
> > guide:
>
> >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact.
> > > > ..
>
> > > > > > and mco find -F myfact will work as well, not at first, but after a
> > > > > > minute or 2. why is that?
>
> > > > > > --
> > > > > > 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.
>
> > > > > --
>
> > > > > 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet, Facter and Mcollective

[Tony C]

I see, but following this page does allow for that

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML

I just tested it. So in my enterprise, i would much rather control the
facts.yaml using a module of the above listed link and a puppet run,
than allowing a cron job to do this. Also, the parameters defined in
the ENC really help me carve out my infrastructure nicely for my
puppet manifests, as well as the ability to run queries in mcollective
using these parameters. A good examle would be a group in the
Dashboard called PRODUCTION, with a parameter for site=LA


How do people typically manage that puppet generated crontab?




On Feb 16, 3:38 pm, Gary Larizza  wrote:
> Tony,
>
> No.  Those don't become custom fact values, so client's aren't aware of
> them.
>
>
>
>
>
>
>
>
>
> On Thu, Feb 16, 2012 at 3:34 PM, Tony C  wrote:
> > Awesome Gary, Thanks for the reply.
>
> > Will this also populate parameters assigned via an ENC (my case would
> > be the puppet dashboard)?
>
> > Thanks again.
>
> > On Feb 16, 3:33 pm, Gary Larizza  wrote:
> > > Hey there,
>
> > > Check your cron with crontab -l and you'll see a line that calls
> > > "/opt/puppet/sbin/refresh-mcollective-metadata" every 15 minutes.  That's
> > > the process that updates the facts.yaml file with your current custom
> > > facts.  You can trigger it whenever you'd like :)
>
> > > On Thu, Feb 16, 2012 at 3:19 PM, Tony C  wrote:
> > > > I'm not sure if this is the right group or not, but i'll start here.
>
> > > > I have Puppet enterprise 2.0, playing around with custom facts.
>
> > > > I have noticed that adding a custom fact to any module will distribute
> > > > that fact to all machines, regardless if they are assigned to that
> > > > module or not. Is there a way around this, or is this just by design?
>
> > > > I have the pluginsync and mcollective setup to use /etc/puppetlabs/
> > > > mcollective/facts.yaml.
>
> > > > server.cfg
> > > > # Facts
> > > > factsource = yaml
> > > > plugin.yaml = /etc/puppetlabs/mcollective/facts.yaml
>
> > > > Without doing anything, after a few minutes, my facts.yaml gets
> > > > populated with the new custom fact, even without following this guide:
>
> > > >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact.
> > ..
>
> > > > and mco find -F myfact will work as well, not at first, but after a
> > > > minute or 2. why is that?
>
> > > > --
> > > > 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.
>
> > > --
>
> > > 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet, Facter and Mcollective

[Tony C]

Awesome Gary, Thanks for the reply.

Will this also populate parameters assigned via an ENC (my case would
be the puppet dashboard)?

Thanks again.

On Feb 16, 3:33 pm, Gary Larizza  wrote:
> Hey there,
>
> Check your cron with crontab -l and you'll see a line that calls
> "/opt/puppet/sbin/refresh-mcollective-metadata" every 15 minutes.  That's
> the process that updates the facts.yaml file with your current custom
> facts.  You can trigger it whenever you'd like :)
>
>
>
>
>
>
>
>
>
> On Thu, Feb 16, 2012 at 3:19 PM, Tony C  wrote:
> > I'm not sure if this is the right group or not, but i'll start here.
>
> > I have Puppet enterprise 2.0, playing around with custom facts.
>
> > I have noticed that adding a custom fact to any module will distribute
> > that fact to all machines, regardless if they are assigned to that
> > module or not. Is there a way around this, or is this just by design?
>
> > I have the pluginsync and mcollective setup to use /etc/puppetlabs/
> > mcollective/facts.yaml.
>
> > server.cfg
> > # Facts
> > factsource = yaml
> > plugin.yaml = /etc/puppetlabs/mcollective/facts.yaml
>
> > Without doing anything, after a few minutes, my facts.yaml gets
> > populated with the new custom fact, even without following this guide:
>
> >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact...
>
> > and mco find -F myfact will work as well, not at first, but after a
> > minute or 2. why is that?
>
> > --
> > 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.
>
> --
>
> 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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Puppet, Facter and Mcollective

[Tony C]

I'm not sure if this is the right group or not, but i'll start here.

I have Puppet enterprise 2.0, playing around with custom facts.

I have noticed that adding a custom fact to any module will distribute
that fact to all machines, regardless if they are assigned to that
module or not. Is there a way around this, or is this just by design?

I have the pluginsync and mcollective setup to use /etc/puppetlabs/
mcollective/facts.yaml.

server.cfg
# Facts
factsource = yaml
plugin.yaml = /etc/puppetlabs/mcollective/facts.yaml

Without doing anything, after a few minutes, my facts.yaml gets
populated with the new custom fact, even without following this guide:

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML


and mco find -F myfact will work as well, not at first, but after a
minute or 2. why is that?

-- 
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: Question about reusing classes/modules

[Tony C]

My own problem is that once I setup a variable, I can't reassign the
variable again in the same module. Based on what I saw in the in
dashboard, there is a conflict.

I think I over engineered this piece of my project. I am better off
manually creating 40 properties values, treating all of the values as
static points of truth, and then just using FILE in 1 huge manifest.

Thanks for all your help. It has led me to leverage the Dashboard as
an ENC.


On Feb 13, 7:56 pm, Brian Gupta  wrote:
> I would say Global vars aren't necessarily evil. However, they ideally fit
> into a hierarchical structure, where one can have variable scoping with an
> ability to override global vars with more tightly scoped local overrides.
>
> Foreman, and Hiera support the ability to set the same variable at
> multiple hierarchical levels and have the most "local" variable scoping
> override the global. Think Global vars, datacenter vars, domain specific
> vars, subnet vars, host vars, hostgroup vars, etc.
>
> (Folks please correct me if I explained this incorrectly.)
>
> -Brian
>
>
>
>
>
>
>
>
>
> On Mon, Feb 13, 2012 at 12:14 PM, Kenneth Lo  wrote:
> >  Eric:
>
> >  Can you elborate on why global variables is a bad idea? Most of my
> > environment's key-value pairs are set via dashboard as ENC, which I think
> > are all global.
>
> >  --KL
>
> >   From: Eric Shamow 
> > Reply-To: "puppet-users@googlegroups.com" 
> > Date: Sat, 11 Feb 2012 20:48:24 -0500
> > To: "puppet-users@googlegroups.com" 
> > Subject: Re: [Puppet Users] Question about reusing classes/modules
>
> >  I would avoid this approach - global variables aren't a good idea.
>
> >  Hiera would be a better approach:
>
> >http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...
> >http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php
>
> >  -Eric
>
> >  --
>
> >  Eric Shamow
> > Professional Services
> >http://puppetlabs.com/
> > (c)631.871.6441
>
> >  On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
>
> >    My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > of these environments lives in 2 sites, LA and NY. I have 5
> > applications that are site and env specific.
>
> >  I want to use puppet to template-ize the config files that is required
> > for each env, per site, per app, so 40 files.
>
> >  The config file is basically key=value pairs. Here's a simple example
> > of what each file may look like:
>
> >  site=LA
> > env=Dev
> > app=App1
> > masterServer=host1
> > clientServer1=host2
> > clientServer2=host3
>
> >  How about having these key value pairs in site.pp with a case environment
> > Then they become global to all modules.
>
> >  --
> > Krish
> > olindata.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+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.
> > This message is for the designated recipient only and may contain
> > privileged, proprietary, or otherwise private information. If you have
> > received it in error, please notify the sender immediately and delete the
> > original. Any other use of the email by you is prohibited.
>
> > --
> > 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.
>
> --
> 

-- 
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: Question about reusing classes/modules

[Tony C]

node classification seems essential to growing out my puppet
infrastructure and to do some neat things with it.

Can someone post a very simple example of how I can leverage external
node classification in my scenario? If this warrants another thread,
please let me know.

Thanks everyone.


On Feb 11, 6:58 pm, Tony C  wrote:
> Thanks for the assistance. I checked out Hiera and to be honest, that
> is really way out of my league right now. When I get there, I will
> definitely be looking into it, because I know I will get there soon,
> unless you want to give me the 5 minutes selling pitch?
> =)
>
> I have been reading the style guide and the best practices pages and
> came up with this model: (using CONFIG in caps to represent it as my
> base module)
>
> Since I have to manage 40 files all with different values, I just
> created a subclass called
> CONFIG::show1_prod_LA. In the show1_prod_LA.pp file, I created all my
> specific key=value pairs, and then I included config.
>
> in the CONFIG init.pp i have:
>
>   file { "/tmp/${app}_${site}_${env}.properites":
>     ensure => present,
>         content => template("mymodule/
> template.properties.erb"),
>
> So basically I am reusing the same class CONFIG but having each
> subclass over write the values. This worked for the first subclass. I
> tried creating a second subclass, called CONFIG:show1_prod_NY. This
> subclass has the same keys, but obviously different values.
>
> In my site.pp I have this:
>
> node mydesktop{
>  include CONFIG::show1_prod_LA:
>  include CONFIG::show1_prod_NY
>
> }
>
> My problem is, only the first include  "include
> CONFIG::show1_prod_LA:" runs. Am I completely using puppet in a way
> I'm not supposed to?
>
> On Feb 11, 5:48 pm, Eric Shamow  wrote:
>
>
>
>
>
>
>
> > I would avoid this approach - global variables aren't a good idea.
>
> > Hiera would be a better approach:
>
> >http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...
>
> > -Eric
>
> > --
>
> > Eric Shamow
> > Professional Serviceshttp://puppetlabs.com/
> > (c)631.871.6441
>
> > On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
> > > > My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > > > of these environments lives in 2 sites, LA and NY. I have 5
> > > > applications that are site and env specific.
>
> > > > I want to use puppet to template-ize the config files that is required
> > > > for each env, per site, per app, so 40 files.
>
> > > > The config file is basically key=value pairs. Here's a simple example
> > > > of what each file may look like:
>
> > > > site=LA
> > > > env=Dev
> > > > app=App1
> > > > masterServer=host1
> > > > clientServer1=host2
> > > > clientServer2=host3
>
> > > How about having these key value pairs in site.pp with a case environment
> > > Then they become global to all modules.
>
> > > --
> > > Krish
> > > olindata.com (http://olindata.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 
> > > (mailto:puppet-users@googlegroups.com).
> > > To unsubscribe from this group, send email to 
> > > puppet-users+unsubscr...@googlegroups.com 
> > > (mailto:puppet-users+unsubscr...@googlegroups.com).
> > > For more options, visit this group 
> > > athttp://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: Question about reusing classes/modules

[Tony C]

Thanks for the assistance. I checked out Hiera and to be honest, that
is really way out of my league right now. When I get there, I will
definitely be looking into it, because I know I will get there soon,
unless you want to give me the 5 minutes selling pitch?
=)

I have been reading the style guide and the best practices pages and
came up with this model: (using CONFIG in caps to represent it as my
base module)

Since I have to manage 40 files all with different values, I just
created a subclass called
CONFIG::show1_prod_LA. In the show1_prod_LA.pp file, I created all my
specific key=value pairs, and then I included config.

in the CONFIG init.pp i have:

  file { "/tmp/${app}_${site}_${env}.properites":
ensure => present,
content => template("mymodule/
template.properties.erb"),

So basically I am reusing the same class CONFIG but having each
subclass over write the values. This worked for the first subclass. I
tried creating a second subclass, called CONFIG:show1_prod_NY. This
subclass has the same keys, but obviously different values.

In my site.pp I have this:

node mydesktop{
 include CONFIG::show1_prod_LA:
 include CONFIG::show1_prod_NY

}

My problem is, only the first include  "include
CONFIG::show1_prod_LA:" runs. Am I completely using puppet in a way
I'm not supposed to?

On Feb 11, 5:48 pm, Eric Shamow  wrote:
> I would avoid this approach - global variables aren't a good idea.
>
> Hiera would be a better approach:
>
> http://www.devco.net/archives/2011/06/05/hiera_a_pluggable_hierarchic...http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Serviceshttp://puppetlabs.com/
> (c)631.871.6441
>
>
>
>
>
>
>
> On Saturday, February 11, 2012 at 7:08 PM, krish wrote:
> > > My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
> > > of these environments lives in 2 sites, LA and NY. I have 5
> > > applications that are site and env specific.
>
> > > I want to use puppet to template-ize the config files that is required
> > > for each env, per site, per app, so 40 files.
>
> > > The config file is basically key=value pairs. Here's a simple example
> > > of what each file may look like:
>
> > > site=LA
> > > env=Dev
> > > app=App1
> > > masterServer=host1
> > > clientServer1=host2
> > > clientServer2=host3
>
> > How about having these key value pairs in site.pp with a case environment
> > Then they become global to all modules.
>
> > --
> > Krish
> > olindata.com (http://olindata.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 
> > (mailto:puppet-users@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com 
> > (mailto:puppet-users+unsubscr...@googlegroups.com).
> > For more options, visit this group 
> > athttp://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: Question about reusing classes/modules

[Tony C]

Thanks for the assistance. I checked out Hiera and to be honest, that
is really way out of my league right now. When I get there, I will
definitely be looking into it, because I know I will get there soon.
=)

I have been reading the style guide and the best practices pages and
came up with this model:

Since I have to manage 40 files, I just created a subclass called
config:show1_prod_LA. In the show1_prod_LA.pp file, I created all my
specific key=value pairs, and then I included config.

in the config init.pp i have:

  file { "/tmp/${showname}_${env}_${site}.properites":
ensure => present,
content => template("wls_install_properties/
template.properties.erb"),

So basically I am reusing the same class config but having each
subclass over write the values. This worked for the first subclass. I
tried creating a second subclass, called config:show1_prod_NY. This
subclass has the same keys, but obviously different values.

In my site.pp I have this:


node mydesktop{
 include config::show1_prod_LA:
 include config::show1_prod_NY
}

My problem is, only the first include runs.




-- 
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] Question about reusing classes/modules

[Tony C]

Hello Everyone,

I'm still pretty new with puppet so please bare with me. I tried
searching and I'm pretty sure I've ready my answer but I'm not sure if
I'm going down the right path just yet.

My scenario is this: I have 4 environments, Dev, Test, QA, Prod. Each
of these environments lives in 2 sites, LA and NY. I have 5
applications that are site and env specific.

I want to use puppet to template-ize the config files that is required
for each env, per site, per app, so 40 files.

The config file is basically key=value pairs. Here's a simple example
of what each file may look like:

site=LA
env=Dev
app=App1
masterServer=host1
clientServer1=host2
clientServer2=host3

Even more interesting, the the config files have the naming structure
app_site_env.properites. So lots of the same, over and over again,
just different values. Let's say the machine managing these files is
called

node configbox

My first idea was to create an erb of that config file, use
parameterized classes and variables to fill in the blanks, some if/
else logic and the populate each file. That works. The thing is, I
will have 40 modules with the same init.pp and anytime I update
something, I'd have to make that change across 39 more modules!

What is the best strategy to reuse a base module, and then apply
specific values on top of that base module based on some condition? Do
I use inherit or subclasses?

config
config::app and then in that config::app define what I need to replace
depending on site and env?

Sorry for the long winded and confusing post.

Thanks so much!

Tony

-- 
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.