Re: [Puppet Users] Template problems

[R.I.Pienaar]

You can't nest the <% %> inside another. Try:

<%= if @rotatelogsuselink then "-L /var/log/httpd/#{@name}/access.log" end %>

Everything inside is normal Ruby and that's how interpolation works there

---
R.I.Pienaar

> On 8 Mar 2016, at 04:32, Ugo Bellavance  wrote:
> 
> > <%= if @rotatelogsuselink then "-L /var/log/httpd/<%= name %>/access.log" 
> > end %>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/DCC11E2D-E90A-4105-8806-BA73A897C620%40devco.net.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Template problems

[Ugo Bellavance]

Hi,

I'd like to be able to do something but I always get an error.

Here is my code:

<% if userotatelogs == false -%>

CustomLog /var/log/httpd/<%= name %>/access.log combined

<% else -%>

CustomLog "|/usr/sbin/rotatelogs <%= if @rotatelogsuselocaltime then 
'-l' end %> <%= if @rotatelogsforceopen then '-f' end %> <%= if 
@rotatelogsuselink then "-L /var/log/httpd/<%= name %>/access.log" end %> 
/var/log/httpd/<%= name %>/access.log.%Y-%m-%d <%= rotatelogstime %>" 
combined

<% end -%>


The problematic part seems to be the part in yellow.


Here is the error I get:


compile error 
/etc/puppet/modules/apache/templates/vhost-proxy_w_access.conf.erb:70: 
syntax error, unexpected $undefined, expecting kEND ...; _erbout.concat 
"/access.log\" end %> /var/log/httpd/"; _er...   
^ /etc/puppet/modules/apache/templates/vhost-proxy_w_access.conf.erb:76: 
syntax error, unexpected $end, expecting ')' ; _erbout


I tried with single quotes, as <%= name %>, <%= @name %>, <%= $name %>, but 
it always fails.


Thanks,


Ugo

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ad4ba9ae-5213-4885-9198-5fcda6003eea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet catalog compilation job queue idea

[SG Madurai]

Hi John, Thank you for the update.

Pardon me if i am asking about things that have been clarified/ settled 
already.

>From what i understand, agent run times are primarily determined by
- catalog compilation time at master
- the time for agent to apply catalog on its node

So was basically wondering if there is an option to separate these 2 
functions and manage these 2 independent of each other (at times convenient 
for each of these activities)

If these concerns shouldn't arise with running multiple puppet masters w/ 
puppet db (or by imply upgrading...we are on v3.8 btw), then will explore 
that option first.

I couldn't be sure if these configuration options (multiple puppet masters 
w/ puppet db) by itself can take care of the issues we are facing with 
agent runs  in our environment 
(timeouts, slowness..)

We have one puppet master (v3.8) managing 150-200 nodes in an environment.

BEFORE actually implementing this setup (multiple puppetmasters w/ puppet 
db) in our environment, i wanted to see if this is all there is to do - to 
fix these timeouts/ delays we see in our agent runs.


PS:
I did read thru http://www.aosabook.org/en/puppet.html but I am still new 
to puppet.

Looking into what is the right way to config puppet for our env. I am yet 
to see if there are Performance tuning guides/ tips for a puppet managed 
environment.
Something insightful for deployment scenarios/ options - and relative 
advantages - will help. 

I understand this is open source to start with, and can't expect 
*everything* from the community etc but just looking to skip some trial and 
error cycles where community insight already exists.



On Monday, March 7, 2016 at 11:29:05 PM UTC+9, jcbollinger wrote:
>
>
>
> On Sunday, March 6, 2016 at 7:50:32 PM UTC-6, SG Madurai wrote:
>>
>> Hi,  
>>
>> did we further  explore options/alternatives with respect to pre-caching 
>> of catalogs by puppet master to improve agent run times.
>> Or  Is it like this was never looked at after this discussion.
>>
>> I see an accepted ticket from Robin Bowes: 
>> https://projects.puppetlabs.com/issues/4486 
>> and trying to see the current status of this 'Accepted' feature request.
>>
>>
>
> As far as I can tell, JIRA ticket 4486 was never transitioned to the new 
> ticket system .  I have no explanation 
> for that.  Meanwhile, however, Puppet has gone through two major version 
> number increments and substantial concomitant architectural changes, with a 
> great deal of attention to performance of the master.
>
> As far as I am aware, the master still does not serve catalogs from a 
> cache on its side, but I don't find that particularly surprising, because 
> my conclusion from the previous round of discussion was that doing so is 
> not practical -- at least, not if one wants to be confident of serving 
> catalogs equivalent to demand-built ones.
>
> In any event, catalog compilation is rarely the determining factor in 
> agent runtimes.  This may be another reason why the feature request you 
> referenced got little love, despite being accepted.
>
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5202bbf3-3cf9-427f-b3e4-16933a4e0894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to safely distibute SSL keys with PuppetMaster

[Matthew Nicholson]

So I've done this simple with hiera email and using the contents of the ssl
keys and certs as strings for file resources to use with created resources
On Mon, Mar 7, 2016 at 6:57 PM Sans  wrote:

>
> Hi there ,
>
> I've a situation here, where I need to provide SSL key-pair for Nginx
> configuration and the SSL keys, that copied on to the agents as file{}
> resources goes to the repo, which is accessed by a number of people in the
> organization, which I don't like. What's the general recommendation (which
> goes along with the automation flow) here to handle this kind of situation?
>
> I use eyal back-end for password and other secret string but how do I
> handle the files? I know: eyaml edit -f  can encrypt a file
> but how do I use that in Puppet or in a file{} resource? Thanks in
> advance!
>
> -S
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/d08cabb6-a1dc-412a-a03a-2b69d906fa7f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2BnEbkZpp_CTLwAmtZNTVPHubAT-VO5%2BxN7jmiNv49Hdrc4E7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] how to safely distibute SSL keys with PuppetMaster

[Sans]

Hi there ,

I've a situation here, where I need to provide SSL key-pair for Nginx 
configuration and the SSL keys, that copied on to the agents as file{} 
resources goes to the repo, which is accessed by a number of people in the 
organization, which I don't like. What's the general recommendation (which 
goes along with the automation flow) here to handle this kind of situation?

I use eyal back-end for password and other secret string but how do I 
handle the files? I know: eyaml edit -f  can encrypt a file but 
how do I use that in Puppet or in a file{} resource? Thanks in advance!

-S

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d08cabb6-a1dc-412a-a03a-2b69d906fa7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Avoiding duplicate exported resource

[Daniel Urist]

I've managed to solve this with query_resources() from puppedbquery to
generate an array of the resources and ensure_resource() to only create a
single instance. That seems to be the cleanest way at the moment to handle
this.

On Mon, Mar 7, 2016 at 9:25 AM, Ken Barber  wrote:

> >> Model wise, in an ideal world, the proxied/virtual address would be a
> >> 'node' of sorts, and have that entry, but if no box exists to compile
> >> that catalog, well then we're just talking crazy :-).
> >>
> >
> >
> > Well no, if the proxied / virtual address is not a property specific to
> any
> > individual node, then it is a property of the overall site configuration.
> > Puppet therefore does not need to determine this from the nodes;
> instead, it
> > needs to *apply* it to them.  As such, it ought to be recorded in the
> Hiera
> > data repository from which Puppet is working.  If it's in the data, then
> it
> > does not need to be communicated between nodes via exported resources.
> > Rather, Puppet should draw it from the same source for all nodes that
> need
> > it for any purpose.
>
> I think you've missed my modelling point or perspective, I was simply
> expressing that if you could do it, you would record the intended
> exported resource to a virtual node that maps to the virtual address,
> but this isn't possible today. Hiera isn't part of the resulting
> model, its just input that creates the graph. This is academic though,
> its not possible anyway.
>
> Irrespective of this imaginary world, one could store the data in
> hiera to be consumed, if one chose to - or somewhere else, it matters
> little for the resulting graph.
>
> ken.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAE4bNTk-D4w96-7729kOzZhx%2B4DnkR7VrR0Uat9x8HmnFribPA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAEo6%3DKYjR2ifPKpnGeLAkv%2Bo4P2tG%2BT6kxvoJAMiCHCsWt7vgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Setting up Code Manager and running in to problem with r10k_api_user needing key and web hook failing test pushes

[evan . hisey]

Discovered the solution. Turns out port 8170 was closed on the Puppet 
server firewall. The logs were not very helpful in finding this, and the 
error had me looking in the wrong place to begin with as it was on the 
Master and not the GitLab server despite the error.

On Friday, March 4, 2016 at 4:23:58 PM UTC-6, evan@noaa.gov wrote:
>
> As the title says this is dealing with Code Manager. First I followed the 
> directions in the gitlab module to setup gitlab, and that much worked up to 
> testing code pushes. At this point it was apparent the the r10k_api_user 
> had a problem do to no ssh key, and that the web hook trigger is not 
> working. I am not sure where how to go about debugging this as the only 
> error I have found is the un helpful:
> 500 Whoops, something went wrong on our end. 
> --
>
> Try refreshing the page, or going back and attempting the action again.
>
> Please contact your GitLab administrator if this problem persists.
>
>
> This looks like something is configured wrong on the gitlab side by I need 
> help in hunting it down. 
>
>
> Evan
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3644378e-59ee-4f00-99c2-6b48a7aea26d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Force Fact within manifest

[Trevor Vaughan]

Personally, I've never come across a case where I needed a post-mortem fact
collection. But, I do tend to write custom types when I need to get things
into the catalog so that may be my particular way of doing things coming
out.

While this could be useful in some cases for reporting, I would very much
like to have the (thread related) ability to add one-off values to the fact
DB from either the master or the client.

Outside of that, a simple method for extending the PuppetDB schema to store
items of interest would be most welcome.

Trevor

On Wed, Mar 2, 2016 at 3:03 PM, Kylo Ginsberg  wrote:

> On Tue, Mar 1, 2016 at 9:09 AM, JS  wrote:
>
>> Which guy?  The OP?
>>
>> Yep, OP, per the rest of the post.
>>
>> That's not what anyone else in this necro'd thread said back in its
>>> previous life, so exactly what and who are you agreeing with?
>>
>> Yes, it was actually this necro'd threads main point of emphasis,
>> including subject, introduction, middle and final answer from OP.  Even the
>> word "requirement" was used.
>>
>> Yes, they can, but normally they are zilch (nada, bumpkus, zero).
>>> Moreover, even when massive changes are applied, they rarely change the
>>> values of any of the standard facts.  Of course, all bets are off with
>>> custom facts.
>>
>> "Normally" and Puppet dont really go hand in hand with the vast
>> customizable use of it, especially when custom facts come into the equation.
>>
>> Well that's not what Puppet is, or ever was intended to be.
>>
>> Many products start out not intending to be what they become.
>> It may not be the purpose of Puppet, but Puppet uses Facter, which does
>> report facts, so they are basically bonded to each other.  If something
>> becomes what it wasn't intended to be, should the designer and creator
>> continue to tell users they are using it wrong?  Seems to me a lot of
>> things have failed that way.
>>
>> it would be a potentially dangerous mistake to rely on PuppetDB to hold
>>> an accurate representation of node state between Puppet runs.  Furthermore,
>>> it is difficult to determine at the time you query PuppetDB whether the
>>> node in question actually is between runs, as for each node there will be
>>> from seconds to minutes out of each catalog run interval in which a catalog
>>> run is in progress.
>>
>> Querying isn't an issue with mcollective. Nor is puppet going to run with
>> a statelock.  I even have a custom fact that says when the facts were
>> gathered, so I have exact time stamps.
>>
>> I'm not so sure that yours is a commonly requested feature.
>>
>> The word "common" means something different to each individual.  However,
>> I have had 3 customers request this feature, which have led to searches,
>> which have led to quite a few requests from others, over the years.  Just
>> as the OP has requested here.
>> I wouldnt say its common to "hope" puppet recognizes fact values during a
>> run, I would almost say that is expected.
>>
>> I think the best debate I read against our wishes or hopes, was that
>> facts should only be viewed as what they were prior to a catalog run.  I
>> guess that makes sense.  However, since they CAN and ARE used as a
>> reporting method or "inventory", there should be some form of seeing what
>> they have changed to.
>> The other side of this debate though too, is users that want to see what
>> the facts are BEFORE a puppet run.  Current reported facts would only show
>> what they were before the previous run, which is also not an "accurate
>> representation".
>>
>> Puppet is a configuration management system, not an inventory system.  To
>>> the extent that it can also serve incidentally as a poor man's inventory
>>> system, that's great, but not of much import to me.  As far as I am
>>> concerned, Puppet is better suited to working alongside or even under an
>>> inventory system than it is to working as an inventory system
>>
>> I suppose most of what I said could use subbing of the word "Puppet" with
>> "Facter".   I do agree that Puppet doesn't need to, and probably even
>> shouldn't always grab the changed facts at the end of the run.  However,
>> Facter itself is widely used as a reporting or inventory system (and even
>> marketed by puppetlabs as so).  Thus, I do agree what you say, in regards
>> to Puppet.  However, they are two separate systems that work together.  I
>> think most people just want to see Facter expand on the whole gathering of
>> inventory.  No need to pull in another inventory management system, when
>> Facter can do it.   Facter and Puppet allow you to get new facts at the
>> end, but don't provide any native way of doing so.  I think that is the
>> main point people that request this are trying to say.
>>
>> You are in luck, however: Puppet's source is open
>>
>> Yep, and thats what makes it such an amazing tool and great community.
>> As well as allows users like myself, OP, and others, that want this kind of
>> reporting 

Re: [Puppet Users] Force Fact within manifest

[JS]

I like the idea.  Personally I've always wished to just see facts in the 
form of:

pre_puppet => post_puppet

You now have a record of what it was before going into puppet as well as a 
record when it comes out.  Thats about the best accuracy one can hope for.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/eb0efdac-c525-4ee4-95da-39ae9f5d984e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] mirroring puppet 4

[Christopher Wood]

That PC1 thing is intentional.

https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html

I'm curious how it came to be that anybody needs to know the specific 
repository and package to install to get puppet working? In your situation I 
would probably have cobbler or similar install the repos on server build, or 
supply some kind of bootstrap rpm or shell script.

On Mon, Mar 07, 2016 at 08:22:09AM -0800, steve moulton wrote:
>Greetings,
> 
>I maintain a open source software mirror used internally at ORNL, and have
>been successfully mirroring Puppet for some time.  However a user asked me
>why he could not get Puppet 4 using the standard repository information.  
>After some research/fumbling around we located it at
>https://yum.puppetlabs.com/el/7/PC1/x86_64/, which means we were mirroring
>it all along.
> 
>This means to get puppet4 I need to have users instantiate a separate
>yum.repos.d configuration file.  
> 
>Is this the recommended approach, or is there a yum configuration that
>would work better for users?  I have no problem maintaining two separate
>yum configuration files, but users will find it confusing.
> 
>Why was puppet4 released under PC1?  Is it not ready for prime time yet?
> 
>Thanks,
> 
>  - Steve
> 
>--
>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 [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/34cd941b-f393-4fb5-8d47-6fb8cd03b64f%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/34cd941b-f393-4fb5-8d47-6fb8cd03b64f%40googlegroups.com?utm_medium=email_source=footer
>3. https://groups.google.com/d/optout

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20160307174749.GA17001%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Module parameter handling

[Thomas Bendler]

Thanks for the hints, I’ll check what fits best.

Regards Thomas

> Am 03.03.2016 um 19:29 schrieb Henrik Lindberg 
> :
> 
> On 02/03/16 11:26, Thomas Bendler wrote:
>> Hi @all,
>> 
>> I write a module that create local users on my boxes. Now I try to make
>> that module fully dynamic so that the user informations are passed to
>> the module as parameter like this:
>> 
>> class { 'local_users':
>>   user => [
>> { 'john' => { name => 'John Doe', home => '/export/home/john' } },
>> { 'jane' => { name => 'Jane Doe', home => '/export/home/jane' } }
>>   ]
>> }
>> 
> You could use a hash there directly instead of an array of hashes. The 'id' 
> (e.g. 'john', 'jane' has to be unique anyway.
> 
>> So far, so good. But now I would like to iterate through the user array
>> and create the user resource and I have no clue how this should be done
>> correctly. My approach is to call a define:
>> 
>> local_users::config::account { $local_users::user }
>> 
>> Which look like this:
>> 
>> define local_users::config::account (
>>   $id   = $title,
>>   $name = undef,
>>   $home = undef
>> ) {
>>   user { $id:
>> ensure => present,
>>   comment=> $name,
>>   home   => $home,
>>   managehome => true,
>>   password   => '!!';
>>   }
>> }
>> 
>> I guess the direction should be understandable, I would like to specify
>> the users and their attributes as a parameter. What I don't get so far
>> is, do I need one resource definition for each possible combination or
>> is there a way that only the parameter that contain values are used
>> within the resource type? Is the path in general the correct one that I
>> use or is there a better approach to get this done?
>> 
> 
> If you are on 3.x with future parser, or on 4.x you can iterate.
> 
> I made some simplifications here, everything is one hash, and
> I renamed 'name' to 'comment' so I could use the hash directly
> to set all attributes without having to first transform 'name'
> into 'comment'.
> 
> class { 'local_users':
>  user => {
>'john' => { comment => 'John Doe', home => '/export/home/john' },
>'jane' => { comment => 'Jane Doe', home => '/export/home/jane' }
>  }
> }
> 
> class local_users($users) {
>  $users.each |$id, $attributes | {
>user { $id:
>  managehome => true,
>  password   => '!!',
>  *  => $attributes  # attributes from hash
>}
>  }
> }
> 
> With typed parameter
> 
> 
> To make it more robust you can also type the $users argument
> 
> class local_users(
>  Hash[String, Struct[{
>name => String,
>home => String}]
>  ] $users)
> {
>  $users.each |$id, $attributes | {
>user { $id:
>  managehome => true,
>  password => '!!',
>  * => $attributes
>}
>  }
> }
> 
> Hope that helps.
> 
> Regards
> - henrik
> 
> --
> 
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/ 
> 
> 
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/56D88274.2010101%40puppetlabs.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/C15FDCB5-3E68-4598-B4E8-055A509C31FA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Puppet Users] Avoiding duplicate exported resource

[Ken Barber]

>> Model wise, in an ideal world, the proxied/virtual address would be a
>> 'node' of sorts, and have that entry, but if no box exists to compile
>> that catalog, well then we're just talking crazy :-).
>>
>
>
> Well no, if the proxied / virtual address is not a property specific to any
> individual node, then it is a property of the overall site configuration.
> Puppet therefore does not need to determine this from the nodes; instead, it
> needs to *apply* it to them.  As such, it ought to be recorded in the Hiera
> data repository from which Puppet is working.  If it's in the data, then it
> does not need to be communicated between nodes via exported resources.
> Rather, Puppet should draw it from the same source for all nodes that need
> it for any purpose.

I think you've missed my modelling point or perspective, I was simply
expressing that if you could do it, you would record the intended
exported resource to a virtual node that maps to the virtual address,
but this isn't possible today. Hiera isn't part of the resulting
model, its just input that creates the graph. This is academic though,
its not possible anyway.

Irrespective of this imaginary world, one could store the data in
hiera to be consumed, if one chose to - or somewhere else, it matters
little for the resulting graph.

ken.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAE4bNTk-D4w96-7729kOzZhx%2B4DnkR7VrR0Uat9x8HmnFribPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] mirroring puppet 4

[steve moulton]

Greetings,

I maintain a open source software mirror used internally at ORNL, and have 
been successfully mirroring Puppet for some time.  However a user asked me 
why he could not get Puppet 4 using the standard repository information.   
After some research/fumbling around we located it at 
https://yum.puppetlabs.com/el/7/PC1/x86_64/, which means we were mirroring 
it all along.

This means to get puppet4 I need to have users instantiate a separate 
yum.repos.d configuration file.   

Is this the recommended approach, or is there a yum configuration that 
would work better for users?  I have no problem maintaining two separate 
yum configuration files, but users will find it confusing.

Why was puppet4 released under PC1?  Is it not ready for prime time yet?

Thanks,

  - Steve

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/34cd941b-f393-4fb5-8d47-6fb8cd03b64f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Avoiding duplicate exported resource

[jcbollinger]

On Thursday, March 3, 2016 at 11:51:13 AM UTC-6, Ken Barber wrote:
 

> Model wise, in an ideal world, the proxied/virtual address would be a 
> 'node' of sorts, and have that entry, but if no box exists to compile 
> that catalog, well then we're just talking crazy :-). 
>
>

Well no, if the proxied / virtual address is not a property specific to any 
individual node, then it is a property of the overall site configuration.  
Puppet therefore does not need to determine this from the nodes; instead, 
it needs to *apply* it to them.  As such, it ought to be recorded in the 
Hiera data repository from which Puppet is working.  If it's in the data, 
then it does not need to be communicated between nodes via exported 
resources.  Rather, Puppet should draw it from the same source for all 
nodes that need it for any purpose.


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/78c780b8-dc2f-4a0d-b651-c1be71a936de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Avoiding duplicate exported resource

[jcbollinger]

On Friday, March 4, 2016 at 3:53:30 PM UTC-6, Reinhard Vicinus wrote:
>
> We use a wrapper resource to ensure that only one resource is created. 
> It's not perfect, because you need an additional resource, but it works. 
> Here is an example:
>
> Multiple nodes want to ensure that the following resource is created on a 
> node:
>
> file { '/tmp/at_least_one_node_exists.txt':
> }
>
> so we create a wrapper resource:
>
> define export_file (
>   filename,
> ) {
>   ensure_resource('file', $filename, {})
> }
>
> and export the wrapper resource (here you need different names for all 
> nodes, so we use fqdn in the name):
>
> @@export_file { "${fqdn}_one_node":
>   filename => '/tmp/at_least_one_node_exists.txt',
> }
>
> and also collect the wrapper resource on the destination node:
>
> Export_file <<| |>>
>


Almost any use of the ensure_resource() function is a kludge.  It's entire 
purpose is to circumvent Puppet's checks for duplicate resources, which 
themselves serve an important purpose.  Even in that respect, usage of that 
function is typically reliable in only for resources that are declared only 
by that means, for an ordinary declaration of the same resource that is 
evaluated later will still fail as a duplicate declaration.

Where it really falls down, however, is the case where the various 
ensure_resource() declarations of a given resource are not all identical.  
In that case, no catalog can be built that is consistent with all the 
declarations, but ensure_resource() prevents the catalog builder from 
recognizing that.  A catalog is therefore built, based on some random one 
of the conflicting declarations, and the system state consequently applied 
by the agent is then likely to be inconsistent.

The fact is that if you have a means to be confident that you have no 
inconsistent ensure_resource() declarations, then usually that is also a 
means to avoid ensure_resource() declarations altogether.  Generally, you 
would do that by factoring out the duplicate declarations to a single 
(ordinary) declaration somewhere else.

Your particular example, however, happens to find a crevice in which to 
lodge because, as presented, the exported resources involved encode only 
the titles of the wrapped resources (no resource properties), yet they 
afford the possibility of resources of multiple different titles being 
wrapped that way.  If they also encoded properties for the wrapped 
resources then they would be potentially unsafe, and if they wrapped a 
resource or resources of consistent title then there would be good 
alternatives that do not require ensure_resource().


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/65a06b23-256f-47da-bcd9-21e2212c28a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppet catalog compilation job queue idea

[jcbollinger]

On Sunday, March 6, 2016 at 7:50:32 PM UTC-6, SG Madurai wrote:
>
> Hi,  
>
> did we further  explore options/alternatives with respect to pre-caching 
> of catalogs by puppet master to improve agent run times.
> Or  Is it like this was never looked at after this discussion.
>
> I see an accepted ticket from Robin Bowes: 
> https://projects.puppetlabs.com/issues/4486 
> and trying to see the current status of this 'Accepted' feature request.
>
>

As far as I can tell, JIRA ticket 4486 was never transitioned to the new 
ticket system .  I have no explanation for 
that.  Meanwhile, however, Puppet has gone through two major version number 
increments and substantial concomitant architectural changes, with a great 
deal of attention to performance of the master.

As far as I am aware, the master still does not serve catalogs from a cache 
on its side, but I don't find that particularly surprising, because my 
conclusion from the previous round of discussion was that doing so is not 
practical -- at least, not if one wants to be confident of serving catalogs 
equivalent to demand-built ones.

In any event, catalog compilation is rarely the determining factor in agent 
runtimes.  This may be another reason why the feature request you 
referenced got little love, despite being accepted.


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/61a87005-d736-4a02-97e5-b48903c84285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.