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

[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 boolean falses dont make a true do they?
Im confused  :(
The query could be explained as follows :



If 

[Puppet Users] Announce: Puppet Agent 1.7.0 is available

[Geoff Nichols]

Puppet Agent 1.7.0 is now available. This is the first release of the
puppet-agent with .deb and .rpm packages signed with our new GPG signing
key.

This release also includes Puppet 4.7.0, which contains a fix for a bug
potentially affecting Puppet Server’s HTTP ‘/status’ endpoint.

Please see our recent announcement

or the Puppet Agent 1.7.0 release notes for more information about the new
GPG signing key.

Check out the full release notes here:
https://docs.puppet.com/puppet/latest/reference/release_notes_agent.html

To install or upgrade puppet-agent, follow the getting started directions:

http://docs.puppetlabs.com/puppet/latest/reference/index.html


-- 
Geoff Nichols
Puppet Ecosystem - Agent and Platform Team

PuppetConf 2016 , 19 - 21 October, San
Diego, California
*Final Countdown - Register by 5 October and save $180
*

-- 
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/CADjnYBwZ_qU%3DE_s4RotQdZm_tB-ZeSMThKXUws_WXuBuhW5_%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Isaiah Frantz]

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 boolean falses dont make a true do they?
> Im confused  :(
>
> The query could be explained as follows :
>
>
> If iether there is a tag that is not 'one', or there is a tag that is not 
> two, then it will be collected.
>
> test1 : tag => one is != two, so that gives us true, and this collected
>
> test2: tag => two is != one, so here also gives us

Re: [Puppet Users] Re: mount point directory permissions

[Garrett Honeycutt]

On 9/22/16 6:54 AM, otheus uibk wrote:
> Chiming in...
> 
> The old feature request at https://projects.puppetlabs.com/issues/4815
>  had it right. This should
> be a part of the core Mount resource type. Eric's rejection of it was
> stupid. On most systems, when you mount a volume, the underlying file or
> directory must first be there. After you mount, the permissions of the
> mounted directory may need to be changed for whatever reason. In another
> thread, it was argued that the underlying filesystem -- if it's NFS --
> should have the permissions set on the server; that's a silly argument,
> but more importantly, the underlying filesystem might be a newly created
> one at the time of deployment. So either before or after, a File
> resource is needed. Actually, both, but because we can't define the same
> resource twice, we have to choose one. And because the alternative
> currently seems to be an Exec resource, the solution is system
> dependent. (Or, we have to go through a lot of trouble).
> 
> The following is an ugly hack, and must be tweaked for each system. This
> example works for linux:
> 
>  mount { 'fs:/mountpoint':
>name=> '/mountpoint',
>device=> 'fs:/vol/devid',
>ensure=> mounted,
>require=> Exec[mount-ensure-mountpoint],
>...
>  }
>  file { '/mountpoint':
># After mountpoint has been created
>owner=> newownerid,
>group=> newgroupid,
>mode=> '0770'
>require=> 'Mount[fs:/mountpoint]',
> }
> exec { 'mount-ensure-mountpoint'
>command=> 'mkdir -p m 0755 /mountpoint',
>creates=> '/mountpoint'
> }
> 
> I suppose a refreshonly => true in the Exec resource might provide a
> tiny optimization.
> Creating a custom type or function to do the above is silly, given that
> nearly every systemadmin needs. 
> 
> I cannot currently figure out PUppetlabs' new issue tracking/search
> system, otherwise I would try to add this to a ticket there.
> 

Hi,

You can use ghoneycutt/types, which has a class for mount[1]. It ensures
the directory exists for the mount by using `mkdir -p`.

You can use it directly from Hiera as per the docs or through a manifest
like this.


types::mount { '/srv/nfs/home':
  ensure  => 'present',
  device  => 'nfsserver:/export/home',
  fstype  => 'nfs',
  options => 'rw,rsize=8192,wsize=8192',
}

[1] - https://github.com/ghoneycutt/puppet-module-types#mount

Best regards,
-g

-- 
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

-- 
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/35d475fa-e4df-8b84-8682-ce7c8d6ae542%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: mount point directory permissions

[otheus uibk]

Chiming in...

The old feature request at https://projects.puppetlabs.com/issues/4815 
 had it right. This should be 
a part of the core Mount resource type. Eric's rejection of it was stupid. 
On most systems, when you mount a volume, the underlying file or directory 
must first be there. After you mount, the permissions of the mounted 
directory may need to be changed for whatever reason. In another thread, it 
was argued that the underlying filesystem -- if it's NFS -- should have the 
permissions set on the server; that's a silly argument, but more 
importantly, the underlying filesystem might be a newly created one at the 
time of deployment. So either before or after, a File resource is needed. 
Actually, both, but because we can't define the same resource twice, we 
have to choose one. And because the alternative currently seems to be an 
Exec resource, the solution is system dependent. (Or, we have to go through 
a lot of trouble).

The following is an ugly hack, and must be tweaked for each system. This 
example works for linux:

 mount { 'fs:/mountpoint':
   name=> '/mountpoint',
   device=> 'fs:/vol/devid',
   ensure=> mounted,
   require=> Exec[mount-ensure-mountpoint],
   ...
 }
 file { '/mountpoint':
   # After mountpoint has been created
   owner=> newownerid,
   group=> newgroupid,
   mode=> '0770'
   require=> 'Mount[fs:/mountpoint]',
}
exec { 'mount-ensure-mountpoint'
   command=> 'mkdir -p m 0755 /mountpoint',
   creates=> '/mountpoint'
}

I suppose a refreshonly => true in the Exec resource might provide a tiny 
optimization. 
Creating a custom type or function to do the above is silly, given that 
nearly every systemadmin needs. 

I cannot currently figure out PUppetlabs' new issue tracking/search system, 
otherwise I would try to add this to a ticket there.

-- 
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/d0331f9a-30e0-423a-babe-9cb4c28c70fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.