[Puppet-dev] Action required: ruby-shadow package broken, update required

*Bottom line on top* Due to a incompatible change found after release, if you installed version 2.3.2 of the ruby-shadow package from yum.puppetlabs.com then you need to upgrade your yum cache and downgrade to version 1:2.2.0 of ruby-shadow. *What happened?* As part of our on-going effort to pro

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On Wed, Feb 19, 2014 at 12:55 PM, Andy Parker wrote: > This time was a little more relax and slow. Lots of things piling up in > the backlog of actions... :( We have started punting a lot of these to the > 3.6 timeframe. Many are good changes, but with the effort to get 3.5 out we > don't want to

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On Wed, Feb 19, 2014 at 2:48 PM, Erik Dalén wrote: > Right, that is the intended behaviour. > > The behaviour that should be removed is this though: > > class b { > file_line { foo: > # provider => ruby magically implied by class a resource defaults. > } > } > > class a { > File_line { >

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

Right, that is the intended behaviour. The behaviour that should be removed is this though: class b { file_line { foo: # provider => ruby magically implied by class a resource defaults. } } class a { File_line { provider => ruby, } include b } On 19 February 2014 17:43, Nan L

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On Wed, Feb 19, 2014 at 2:36 PM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote: > On 02/19/2014 11:23 PM, Erik Dalén wrote: > > No, removing it means they behave the same as for variables, so they > > are either global or local. But not passed on through include > > statements etc. > > Or e

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On 02/19/2014 11:23 PM, Erik Dalén wrote: > No, removing it means they behave the same as for variables, so they > are either global or local. But not passed on through include > statements etc. Or even more specifically, variables have three scoping levels IIRC. 1. global scope 2. node scope 3.

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

> I'm not very fond of the idea of hardwiring special support for > Package resources into Puppet (nor for resources of any other specific > type). I still like my "constraints" idea, to which Felix directed > your attention, but if something like that is ever implemented then > adopting it will

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On 19 February 2014 17:14, Nan Liu wrote: > On Wed, Feb 19, 2014 at 11:55 AM, Andy Parker wrote: > >> This time was a little more relax and slow. Lots of things piling up in >> the backlog of actions… :( We have started punting a lot of these to the >> 3.6 timeframe. Many are good changes, but w

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

On Wed, Feb 19, 2014 at 1:58 PM, Wolf Noble wrote: > > > One thing I've seen done is something like the following contrived example: > > class core{ > @package { 'build essential': > ensure => 'installed', > tag=> 'core_packages' > } > Package <| tag == 'core_packages' |>

[Puppet-dev] Announce: Puppet 3.4.3 Now Available

3.4.3 is a bug fix release in the Puppet 3.4 series. - Final: February 19, 2014. Bug Fixes -- PUP-1473: User resource fails on UTF-8 comment Puppet's user resource now supports UTF-8 characters for the c

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On Wed, Feb 19, 2014 at 11:55 AM, Andy Parker wrote: > This time was a little more relax and slow. Lots of things piling up in > the backlog of actions… :( We have started punting a lot of these to the > 3.6 timeframe. Many are good changes, but with the effort to get 3.5 out we > don't want to t

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

autocorrect changed 'buildessential' to 'build essential'.. mental note to not send to puppet-dev from my phone. ;) On Wed, Feb 19, 2014 at 3:58 PM, Wolf Noble wrote: > > > One thing I've seen done is something like the following contrived example: > > class core{ > @package { 'build esse

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

One thing I've seen done is something like the following contrived example: class core{ @package { 'build essential': ensure => 'installed', tag=> 'core_packages' } Package <| tag == 'core_packages' |> } >From my probably incomplete understanding, virtualizing and realizin

[Puppet-dev] Re: Solving `if defined(Resource['name'])`

On Wednesday, February 19, 2014 5:16:00 AM UTC-6, Daniele Sluijters wrote: > > Hi everyone, > > As I was browsing through a few modules on the Forge I noticed that more > and more people seem to have taken to the `if ! defined(Package['name']) > {}` to ensure their module doesn't cause a duplic

Re: [Puppet-dev] Notes from PR Triage on February 19th, 2014

On Wed, Feb 19, 2014 at 11:55 AM, Andy Parker wrote: > This time was a little more relax and slow. Lots of things piling up in > the backlog of actions... :( We have started punting a lot of these to the > 3.6 timeframe. Many are good changes, but with the effort to get 3.5 out we > don't want to

[Puppet-dev] Notes from PR Triage on February 19th, 2014

This time was a little more relax and slow. Lots of things piling up in the backlog of actions... :( We have started punting a lot of these to the 3.6 timeframe. Many are good changes, but with the effort to get 3.5 out we don't want to take on more work right now. There were several discussions a

[Puppet-dev] PR triage for Wed Feb 19th 2014 starting

The puppet/facter/hiera triage is starting in about 10 minutes at http://links.puppetlabs.com/pr-triage -- Andrew Parker a...@puppetlabs.com Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco - * http://bit.ly/pupconf14 -- Y

Re: [Puppet-dev] unknown message digest algorithm, who can help to explain this issue? thanks a lot!

Thank you for your response. As a workaround, do you think that using an alternate CA (as described here: http://docs.puppetlabs.com/puppet/3/reference/config_ssl_external_ca.html) that is SHA1-compliant would work ? On Wednesday, February 19, 2014 2:11:43 AM UTC+1, Matthaus Litteken wrote: >

Re: [Puppet-dev] Solving `if defined(Resource['name'])`

Thanks for bringing up ensure_resources, I completely forgot about that one. Add it to the list of things I'd rather see solved more permanently. On Wednesday, 19 February 2014 14:32:32 UTC+1, Trevor Vaughan wrote: > > Sorry for the double post, but I just remembered the new way of doing if > de

Re: [Puppet-dev] Solving `if defined(Resource['name'])`

Sorry for the double post, but I just remembered the new way of doing if defined(). A function was added to stdlib called ensure_resource https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/parser/functions/ensure_resource.rb . Looking at it, and how it is used, it's just anothe

Re: [Puppet-dev] Solving `if defined(Resource['name'])`

One of the things that was proposed in the past was allowing different modules to declare the same resource iff it was declared identically in all cases. It was shot down as promoting bad practices but so was if defined() and the fact is that we *need* that because I can't have service { 'foo': en

Re: [Puppet-dev] Solving `if defined(Resource['name'])`

Hi Daniele, thanks for bringing this up. Again :-) On 02/19/2014 12:16 PM, Daniele Sluijters wrote: > I'm not sure if it's even desirable or possible to solve this issue in > the first place but I was curious if anyone has given any more thought > to this? They have. I managed to dig up these tw

[Puppet-dev] Solving `if defined(Resource['name'])`

Hi everyone, As I was browsing through a few modules on the Forge I noticed that more and more people seem to have taken to the `if ! defined(Package['name']) {}` to ensure their module doesn't cause a duplicate resource declaration with another module, third party or your own, that is also man