Re: [Puppet Users] Smoke testing puppet modules within Red Hat Satellite v6.2 Puppet Master

2016-09-23 Thread Evan Hisey
Warron-
  Just something to think about also, you may be calling a class that
Satellite does not have as it is running an older version of the community
puppet.

On Wed, Sep 21, 2016 at 8:13 PM, Warron French 
wrote:

> Thanks Rob, I will review your advice when I am in the environment (back
> at work) tomorrow.
>
>
> Thanks again.
>
> On 9/21/2016 5:14 PM, Rob Nelson wrote:
>
> Warren,
>
> It seems like you might be running afoul of the autoloader. It expects
> that within the module path, each module has a certain layout - the class
> ntp is defined in ntp/manifests/init.pp, etc. if you place that in a
> directory called module2, puppet will not find it, since it expects
> module2/manifests/init.pp to contain the module2 class. That's my first
> guess, but it could be that you obfuscated your paths and did not call it
> module_name2 on disk but mas_shared_mas_menu as the error indicated,
> difficult to tell from here. Let us know if that helps!
>
> Rob Nelson
>
> On Wednesday, September 21, 2016, Warron French 
> wrote:
>
>> As most of you I know, I am a total novice at Puppet.  I have built, on
>> my own however, a PE Puppet Master at home and it is running on a
>> CentOS-6.7 VM.
>>
>> Now, I am at work, trying to write modules and smoke test them, like I
>> have learned to do much better now at home.
>>
>> At home, I can write some basic modules without having to constantly
>> refer to style guides, syntax documentation, etc... then I run:
>>
>>1. puppet parser validate module_name1/tests/init.pp
>>2. puppet apply --noop module_name1/tests/init.pp
>>
>> When I run the smoke test, I see an indicate of *what changes would have
>> occured*.  Normal right?
>>
>>
>> In my work environment, on the Red Hat Satellite Server, I wrote some
>> similar modules from memory, then I run:
>>
>>1. puppet parser validate module_name2/tests/init.pp
>>2. puppet apply --noop module_name2/tests/init.pp
>>
>> The syntax checks out, but the error(s) I get in response to the smoke
>> test are:
>>
>> Error: Could not find class mas_shared_mas_menu for x  on node x
>>
>> Error: Could not find class mas_shared_mas_menu for x on node  x
>>
>>
>> *NOTE1:*  I have learned how to upload a puppet module to my Puppet
>> Master on the Satellite Server.
>>
>> *NOTE2:*  I am smoketesting these modules from the ssh terminal session
>> connected to the Satellite/Puppet Master server = .
>>
>> *NOTE3:*  I don't have any agent nodes attached to my Puppet Master.
>>
>>
>> Can someone tell me what I am doing wrong please?
>> --
>> 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/ms
>> gid/puppet-users/2a3b3fc7-f287-48b4-9031-187f041a56be%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Rob Nelson
> rnels...@gmail.com
>
> --
> 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/CAC76iT-NeFxm5NPv%2B5YnZ2YGEYW%
> 2B81474t--i2TioysrJ0xX8w%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/4a5a407a-3681-eb14-587d-f35880ff428e%40gmail.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/CAEcFzYynBp%3D%2BT46xj4u-%3DzyXn5eofkzbVGN8UXtpag-C4bpRyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppet hiera error

2016-09-23 Thread Jagga Soorma
Hi Guys,

I am trying to setup a new puppet environment using hiera and have
everything setup.  However, when I do a puppet agent run I get the
following error:

--
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find data item classes in any Hiera data file and no
default supplied at
/etc/puppet/environments/production/manifests/site.pp:26 on node
resmesostst01.gene.com
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
--

I am running puppet version 3.8.7.  Here is my site.pp:

--
# cat /etc/puppet/environments/production/manifests/site.pp | grep -v
'#' | sed '/^$/d'
filebucket { 'main':
  server => 'resforetst01.gene.com',
  path   => false,
}
File { backup => 'true' }
Package { allow_virtual => true }
node default {
  hiera_include('classes')
}
notify { 'debug_location': name => "THE NODE LOCATION IS: ${location}" }
notify { 'debug_environment': name => "THE NODE ENVIRONMENT IS:
${environment}" }
notify { 'debug_ype': name => "THE NODE TYPE IS: ${pr_type}" }
notify { 'debug_hostgroup': name => "THE NODE HOST GROUP IS: ${hostgroup}" }
--

Here is my hiera.yaml:

--
[root@resforetst01 production]# cat /etc/puppet/hiera.yaml  | grep -v '#'
---
:backends:
  - yaml
:hierarchy:
  - "node/%{::fqdn}"
  - "role/%{::hostgroup}"
  - "type/%{::pr_type}"
  - "site/%{::domain}"
  - common
:yaml:
  :datadir: "/etc/puppet/environments/%{::environment}/hieradata"
:logger: console
--

Any clues on what I seem to be missing?

Thanks!

-- 
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/CAKyjK51g9opXvj0UpVEs8owG7V3kn5v%3DjJb7s4j%2B%2Ba9iwGvwdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Re: notify resource different between 3 and 4?

2016-09-23 Thread Henrik Lindberg

On 20/09/16 15:54, R.I.Pienaar wrote:



- Original Message -

From: "jcbollinger" 
To: "puppet-users" 
Sent: Tuesday, 20 September, 2016 15:37:21
Subject: Re: [Puppet Users] Re: notify resource different between 3 and 4?



On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:




On 19 Sep 2016, at 15:31, jcbollinger 
wrote:
I see a difference between 3.8 and 4.6 with respect to the result of
interpolating an array into a string.  In Puppet 3 (and earlier) you get a
concatenation of the stringifications of all the elements, whereas in
Puppet 4, you get a more formatted representation.  I would have expected
such a change to be applied during a major version update -- so between 3.x
and 4.0 -- but a quick browse of the release notes does not appear to
mention it.

This is not a puppet behaviour change. Newer Ruby does nicer looking to_s
on arrays that's why






It was a deliberate change in how interpolation is done. Earlier it was 
unspecified and inconsistent. The change was introduced very early in 
the life cycle of "future parser", and I believe it was documented then.
When 4.0 was released, many of the language changes were not release 
noted. In some cases because it was impossible to define how it used to 
work :-). For this particular change, there should probably have been a 
note.



I'm prepared to believe that there's no Puppet code change, which would
explain why it's not documented in any release notes, but there's certainly
an observable behavior difference between the two example runs.  If that is
not to be accounted a Puppet behavior change then I suppose it must also be
observable with (only) Puppet 3.8 running on different Ruby versions.
That's a nice gotcha if you happen to rely on interpolating arrays (not
that I would recommend doing so in any case).


The recommendation is to be explicit about how arrays and hashes should 
be formatted if they are wanted in String form (Using either String.new 
with a suitable format, or using the join function).



yeah, and so you would I think, certainly recall people on IRC running into 
that.



On the other hand, I observe that the current (4.6) Puppet docs document
the array interpolation format
,
independent of underlying Ruby.  That may now be a distinction without much
practical difference, but it's the right thing to do: details of the
infrastructure -- and especially changes to them -- ought not to leak out
into Puppet's user-facing behavior.  This sort of thing will become more
important as Puppet continues its movement away from Ruby as the main
implementation language.


yup, this becomes a specified and supported way to do this and you can probably
expect these to be properly treated in future.


Yes, now that it is specified it is part of the API.


There is additionally massive amount of string formatting stuff now in the 
language
https://github.com/puppetlabs/puppet-specifications/blob/master/language/types_values_variables.md

Though their usability leaves a lot to be desired, I suppose they are meant to 
be
used as plumbing for higher order solutions like wrapper functions or something,
I can't imagine anyone using them as is.

Yes, the more advanced formatting stuff is intended to be the basic 
building blocks for functions. The current support should be compared to 
Ruby's Kernel#format. The surface level functionality is easy to use 
though - for example things like String('%d', 42)





In any case, inasmuch as the OP was asking about behavioral differences, it
is highly relevant that the one observable difference of any significance
arises not because of a difference in the version of Puppet, but because of
a difference in the version of the Ruby underneath.


Yeah, expect less of that as work moves toward C based compilers etc, this
will make pinning every thing down to specified behaviour, good times.


Having the Puppet Language specification is key here.

- 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/ns3jbl%24pd2%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: mount point directory permissions

2016-09-23 Thread jcbollinger


On Friday, March 21, 2014 at 11:41:25 AM UTC-5, Paolo wrote:
>
> Hi 
>
> I have the following problem: in a certain module I need to set 
> permissions on a directory after the mount was executed. If I do the 
> following 
>
> file { '/app_dir':
>   ensure  => 'directory' 
>   owner   => 'app_user' 
>   group   => 'app_group' 
>   mode   => '2775'
> } mount { '/app_dir': 
>   ensure => mounted,
>   atboot => true, 
>   device => /dev/mapper/lv_app, 
>   fstype => ext3, 
>   options => 'defaults', 
>   dump => '1', 
>   pass => '2',
>   require => File['/app_dir'],
> }
>
> This would require 2 rounds of puppet: round 1 to setup directory, mount 
> the filesystem and round 2 to fix permissions set to root:root,0755 by the 
> mount command... 
>
> In looking for a solution I found the following link: 
> https://projects.puppetlabs.com/issues/4815 
> 
>  
> that asks for the option to add permission settings to mount resource. The 
> request was rejected and in the comments 
>  Eric Sorenson writes that it would be trivial to accomplish with a 
> defined type, but without going into details... :-( Can any one give me 
> some details on how to do it with a defined type? 
>
>

Eric does give details.  In a followup comment, he refers to this example 
,
 
which apparently relies on the puppetlabs/mount_providers 
 Forge module.  Except 
the example seems to miss the point: as far as I can tell, it does nothing 
to address setting permissions of either the mount point directory or of 
the root of the filesystem mounted on it.  It furthermore relies on the 
defined() function, which I cannot endorse under any circumstances.  I 
think you need to regard his comment as a non sequitur.

We have discussed the matter here before, and I don't think the request is 
trivial at all.  In fact, there is no general solution with acceptable 
characteristics.

To see that, you need to recognize that Puppet is expected to manage the 
state of the system on an ongoing basis, not merely to set it up in a 
one-time provisioning sense.  Consider, then, what happens if there is 
already a filesystem mounted on the mount point. Puppet cannot even check, 
much less change, the properties of the mount point directory without first 
unmounting the filesystem from it, and unless the filesystem is to be 
ensured unmounted, it is simply unacceptable for Puppet to unmount the 
filesystem to manage the underlying mount point.

Another way to look at it is that the mount point directory and the mounted 
filesystem root do not have distinct identities.  That's more or less a 
design feature of a UNIX-style single-root filesystem.  You can tell which 
one the shared identity refers to at any given time, but you cannot 
reference them independently.

That does not necessarily mean that you cannot persuade Puppet to do what 
you want, but you should at least consider whether this should be a job for 
pre-Puppet provisioning.  If you insist on doing it with Puppet, then the 
details of what you want factor in to how you would implement it.  In 
general, however, the shared identity problem means that you cannot manage 
both mount point and mounted root via File resources.  Unless you want to 
write a custom resource type, that leaves you with using an Exec for one or 
the other to (maybe) accomplish everything in one catalog run.


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/da68330b-0d15-4c58-99b8-79d6e4f67f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: [Puppet Users] resource collector with multiple 'tag !=' test

2016-09-23 Thread Johan De Wit
Hi, 



I'm aware it is a bit 'unlogic' :) but that's how it works now.  

Thx for the ticket, will follow it to see what happens



Grts



Johan



-Original message-
From: Isaiah Frantz 
Sent: Thursday 22nd September 2016 20:44
To: Puppet Users 
Subject: Re: [Puppet Users] resource collector with multiple 'tag !=' test

I disagree, the way it works breaks basic logic.
With the == case, if the property is an array type, the code will only return 
objects that contain the term.
The != case only checks for equality, regardless of the object type. It 
*should*, in my opinion, follow basic negation rules and do the opposite of the 
== case. We should get back objects that dont equal or contain the term.

That makes sense and follows all the normal behaviour you should expect from 
searching through objects, array or otherwise.

I have submitted a jira ticket with a pull request if you are interested in 
more detail:
https://tickets.puppetlabs.com/browse/PUP-6723

On Wednesday, September 21, 2016 at 11:30:52 PM UTC-7, Johan De Wit wrote:





-Original message-
From: Isaiah Frantz 
Sent: Wednesday 21st September 2016 21:35
To: Puppet Users 
Subject: [Puppet Users] resource collector with multiple 'tag !=' test

Hello,
I am trying to realize users and am not getting what I expect with multiple != 
test.
Here is a simplified version that I have tested with puppet gem 4.2.2 and 4.6.2 
(results were the same for all tests):
cat t.ppt.pp (common to all tests): 
@notify {'This is a test 1':
        tag => 'one'
}
@notify {'This is a test 2':
        tag => 'two'
}
@notify {'This is a test 3':
        tag => ['one', 'two']
}
@notify {'This is a test 4':
        tag => 'three'
}
Notify <| test_goes_here |>

First 3 expected:
tail -1 t.pp 
Notify <| tag == 'one' or tag == 'two' |>

puppet apply t.pp 
Notice: Compiled catalog for defiant.cequintecid.com 
 in environment production in 0.70 seconds
Notice: This is a test 1
Notice: /Stage[main]/Main/Notify[This is a test 1]/message: defined 'message' 
as 'This is a test 1'
Notice: This is a test 2
Notice: /Stage[main]/Main/Notify[This is a test 2]/message: defined 'message' 
as 'This is a test 2'
Notice: This is a test 3
Notice: /Stage[main]/Main/Notify[This is a test 3]/message: defined 'message' 
as 'This is a test 3'
Notice: Applied catalog in 0.02 seconds


Test 3 only, as expected:
tail -1 t.pp 
Notify <| tag == 'one' and tag == 'two' |>

puppet apply t.pp 
Notice: Compiled catalog for defiant.cequintecid.com 
 in environment production in 0.47 seconds
Notice: This is a test 3
Notice: /Stage[main]/Main/Notify[This is a test 3]/message: defined 'message' 
as 'This is a test 3'
Notice: Applied catalog in 0.02 seconds

Now we get to the '!=' tests.
with a single tag it works as expected so I wont take space here to show that.
With multiple tags, it does not work as expected

Since tags is a hash that contains lots of things, including all explicit tag's 
set on a resource. The == and != operators are supposed to act like contains 
and !contains functions (or so I thought)
Here I expect to only get test 4. 1 and 2 are filtered because one of the 
and'ed tests is false.
3 should fail too because both test are false: tags contains both 'one' and 
'two'. 
tail -1 t.pp 
Notify <| tag != 'one' and tag != 'two' |>

puppet apply t.pp 
Notice: Compiled catalog for defiant.cequintecid.com 
 in environment production in 0.48 seconds
Notice: This is a test 3
Notice: /Stage[main]/Main/Notify[This is a test 3]/message: defined 'message' 
as 'This is a test 3'
Notice: This is a test 4
Notice: /Stage[main]/Main/Notify[This is a test 4]/message: defined 'message' 
as 'This is a test 4'
Notice: Applied catalog in 0.01 seconds


Frankly, I also expect that 3 should be filtered from the or version too 
because neither of the tests should be true if this is a contains function and 
not one that tests against each hash value.
tail -1 t.pp                                                                    
                                             
Notify <| tag != 'one' or tag != 'two' |>

puppet apply t.pp 
Notice: Compiled catalog for defiant.cequintecid.com 
 in environment production in 0.58 seconds
Notice: This is a test 1
Notice: /Stage[main]/Main/Notify[This is a test 1]/message: defined 'message' 
as 'This is a test 1'
Notice: This is a test 2
Notice: /Stage[main]/Main/Notify[This is a test 2]/message: defined 'message' 
as 'This is a test 2'
Notice: This is a test 3
Notice: /Stage[main]/Main/Notify[This is a test 3]/message: defined 'message' 
as 'This is a test 3'
Notice: This is a test 4
Notice: /Stage[main]/Main/Notify[This is a test 4]/message: defined 'message' 
as 'This is a test 4'
Notice: Applied catalog in 0.02 seconds



Two